On Wed, 12 Oct 2005, Franck wrote: > > > A simple fix is to link urb right after > > > calling hcd->urb_enqueue. What do you think about this ? > > > > Not good. The URB must be linked before the HCD is called. Your idea > > runs the risk of the opposite problem: giving back the URB before it has > > been added to the endpoint's list! (Not with your HCD, but with others.) > > > > OK, so we can link it just before calling HCD enqueue method ? > Actually the issue is that we link an URB before it's fully > initialized.
That's because the link belongs to usbcore, not to the HCD. Yes, you could move the code that links the URB to just before calling urb_enqueue. But then (a) you would have to handle the case of root-hub URBs separately, and (b) you would also have to move the code that handles the hcd_data_lock spinlock. > > I still think think using the endpoint's URB list in your HCD isn't a good > > idea. That list can be updated at any time by usbcore. If your HCD > > happens to be following the list pointers when that happens, you could > > easily get into trouble. Of course, this will never arise on a UP system > > if your HCD runs with interrupts disabled. But it's a real possibility > > (even if low probability) on SMP. > > Hm, this mean that we need to duplicate information there. IMHO, > usbcore should be aware that it shares this list with at least HCD. > And once an urb is linked, usbcore or other must use an interface to > unlink URB or to modify linked URB. The problem is that HCDs need to protect their links by locks, and usbcore isn't aware of the HCDs' internal locks. That makes it hard to share the list. Maybe a better idea would be for usbcore not to use the list at all, and rely on the HCD to manage it. However that list is currently the only way usbcore has of checking whether or not an URB actually is active. Maybe instead it could simply look to see whether urb->hcpriv is non-NULL. I'm curious to hear what David has to say about this. Dave? Alan Stern ------------------------------------------------------- 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
