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. > > 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? Looking at the code again, it looks like that's messing with controller's clock and PLL; seems like it should've been done with CCF anyway. -- balbi -- 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
