Felipe Balbi <balbi@xxxxxxxxxx> writes: > Hi, > > Robert Jarzmik <robert.jarzmik@xxxxxxx> writes: >>>>> The driver may sleep with holding a spinlock. >>>>> The function call paths (from bottom to top) in Linux-4.16.7 are: >>>>> >>>>> [FUNC] msleep >>>>> drivers/usb/gadget/udc/r8a66597-udc.c, 839: >>>>> msleep in init_controller >>>>> drivers/usb/gadget/udc/r8a66597-udc.c, 96: >>>>> init_controller in r8a66597_usb_disconnect >>>>> drivers/usb/gadget/udc/r8a66597-udc.c, 93: >>>>> spin_lock in r8a66597_usb_disconnect >>>> >>>> That should not happen... >>>> >>>> If think the issue you have is that your usb_connect() and usb_disconnect() are >>>> called from interrupt context. I think the proper fix, as what is done in most >>>> udc phys, is to schedule a workqueue, see drivers/usb/phy/phy-gpio-vbus-usb.c, >>>> gpio_vbus_data.vbus. >>> >>> argh, no. No workqueues needed here. Sorry >> Technically why ? > > well, strictly technically there's nothing wrong. But it opens a can of > worms. We've seen time and time again drivers growing into > unmaintainable mess because of workqueues being fired in several places. I see. >> >> And as bonus question, why is it better to have mdelay() calls in the driver ? > > As a bugfix, it's the smallest fix possible, right? Ideally, we wouldn't > need either of them. Perhaps there's a bit which can be polled instead? Ideally yes. Do you remember if a "threaded interrupt" might use msleep() ? I seem to remember that they can, so won't that be another alternative ? Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
