2005/10/13, Alan Stern <[EMAIL PROTECTED]>: > On Thu, 13 Oct 2005, Franck wrote: > > obviously endpoint queues are usbcore's data but used by hcd. hcd > > seems to know when an urb is active. Therefore we could export a new > > usbcore's function which would be called by hcd to make an urb active: > > > > void usb_make_active(struct usb_hos_endpoint *ep, struct *urb) > > { > > spin_lock(&hcd_data_lock); > > usb_get_urb(urb); > > atomic_inc(&urb->use_count); > > list_add_tail (&urb->urb_list, &ep->urb_list); > > spin_unlock(&hcd_data_lock); > > } > > This wouldn't work with your HCD, would it? How would your HCD know what > URB to make active next, if the URB wasn't already linked into the list? >
hm, I don't understand what you mean by that. HCD knows what to make active when usbcore calls its hcd->urb_enqueue method. In this method, HCD can make whatever it wants then when it's ready to process this urb, it can call usb_make_active. > Also remember that URBs can be given back out of order if they are > unlinked. Then you have a race: URB is being given back because it was > unlinked, and at the same time your HCD is making it active. > I don't think this can happen. urb_enqueue and urb_dequeue methods are protected by hcd's lock, so these two methods can't be executed at the same time...of course it assumes hcd is the only one that can call usb_hcd_giveback_urb. > I prefer the idea of moving the spinlock into the hcd data structure. Well I have to admit that the lock scheme in usbcore is not very easy to understand for me. And you are probably right when you told me to have my own queues... Thanks -- Franck ------------------------------------------------------- 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