On 03.07.13, Ming Lei wrote: > diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c > index 014dc99..26471cd 100644 > --- a/drivers/usb/core/hcd.c > +++ b/drivers/usb/core/hcd.c > @@ -1648,6 +1635,72 @@ int usb_hcd_unlink_urb (struct urb *urb, int status) > > /*-------------------------------------------------------------------------*/ > > +static void __usb_hcd_giveback_urb(struct urb *urb) > +{ > + struct usb_hcd *hcd = bus_to_hcd(urb->dev->bus); > + int status = urb->unlinked; > + unsigned long flags; > + > + urb->hcpriv = NULL; > + if (unlikely((urb->transfer_flags & URB_SHORT_NOT_OK) && > + urb->actual_length < urb->transfer_buffer_length && > + !status)) > + status = -EREMOTEIO; > + > + unmap_urb_for_dma(hcd, urb); > + usbmon_urb_complete(&hcd->self, urb, status); > + usb_unanchor_urb(urb); > + > + /* pass ownership to the completion handler */ > + urb->status = status; > + > + /* > + * We disable local IRQs here avoid possible deadlock because > + * drivers may call spin_lock() to hold lock which might be > + * acquired in one hard interrupt handler. > + * > + * The local_irq_save()/local_irq_restore() around complete() > + * will be removed if current USB drivers have been cleaned up > + * and no one may trigger the above deadlock situation when > + * running complete() in tasklet. > + */ > + local_irq_save(flags); > + urb->complete(urb); > + local_irq_restore(flags); How can there be a dead lock if you always complete in the same context (either BH or hardirq) for a given device [0]? Why do you choose to complete in BH context instead using threaded irqs and complete in the thread? Sebastian -- 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