Hi,
Alan Stern <[email protected]> writes: > 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. Hmm, that's what I remember, but we don't have that documented and dwc3 has a sleep in its dequeue, which I need to remove for other reasons anyway. Can we get a patch updating documentation to make it clear that both queue and dequeue should be callable from any context? -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
