> > > We will still have the problem that the HCDs don't have access to the > > > spinlock that protects the queue pointers. I suppose the spinlock could > > > be EXPORTed. > > > > That problem is ... what? Exporting that lock would imply there's some > > good reason for code other than usbcore to use it. I haven't seen one. > > maybe one of the reasons is that you use ep's queue without holding > any usbcore's locks in sl811 hcd...
Usbcore only appends to the tail, except for giveback(). The HCD only reads its head, or calls giveback(). Is there some situation where either would see (or create) an inconsistency? > BTW, I noticed something strange in "hcd_endpoint_disable". If I well > understand this function parse the ep's queue and free each of them by > (a) calling hcd->urb_dequeue method Except for URBs that are already being returned by the HCD (as marked by urb->status). > (b) kfreeing urb... No; it does call usb_get_urb() then usb_put_urb() to keep refcounts sane though, while it's looking at the queue. > Don't we need > to remove the urb from ep's queue somewhere before the queue is > rescaned from the start ? You mean, more than calling hcd->urb_dequeue() once per still-pending URB? No. Only giveback() takes urbs out of that queue. - Dave ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
