On Thu, 21 Jun 2018, Roger Quadros wrote: > >> Can we avoid the spin_lock() and the work-queue and call usb_ep_dequeue() directly from here? > >>> What is the purpose of the spin_lock()? > > > > I agree that the lock doesn't seem to be necessary. But I believe the whole > > thing is already running in non-sleeping context, even before the spinlock > > is taken. So this wouldn't help much. > > > > Even the io_cancel() syscall takes a spinlock before invoking the cancel > > function. So this issue is not exclusive to program termination. > > > > Are there any documented guidelines on which context usb_ep_dequeue() should > > be able to be called in? The sleep in the dwc3 driver seems to be a recent > > addition. > > drivers/usb/udc/gadget/core.c has the only documentation, but context is not mentioned there. > Felipe, what do you suggest? As far as I remember, usb_ep_dequeue() is supposed to be more or less analogous to usb_ep_queue(); drivers should be allowed to call either routine in an atomic context. Alan Stern -- 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
