Hello,

Sorry for my haste, I missed that. We have situation when CPU
stalls in usb_hcd_flush_endpoint(), so at first glance it looked
strange for me. Will analyze more.

Thank you.

> On Mon, 28 Jan 2013, Anton Tikhomirov wrote:
> 
> > Hello,
> >
> > In drivers/usb/core/hcd.c: usb_hcd_flush_endpoint() uses
> > list_for_each_entry() to unlink URBs pending on
> > endpoint. At the same time unlink1() calls usb_rh_urb_dequeue()
> > where URB is removed from its endpoint queue:
> >
> > void usb_hcd_unlink_urb_from_ep(struct usb_hcd *hcd, struct urb *urb)
> > {
> >     /* clear all state linking urb to this dev (and hcd) */
> >     spin_lock(&hcd_urb_list_lock);
> >     list_del_init(&urb->urb_list);
> >     spin_unlock(&hcd_urb_list_lock);
> > }
> >
> > Shall we use safe version of list_for_each_entry() for cancelling
> URBs?
> 
> No.  Read usb_hcd_flush_endpoint() more closely.  After calling
> unlink1() it restarts the loop from the beginning.
> 
> Alan Stern
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to