On Fri, 14 Oct 2005, Franck wrote:
> 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.
We're getting confused over definitions. I thought you used "active" to
mean that this was the URB being sent by the hardware. Your HCD sends an
URB to the hardware when it's at the head of the endpoint queue, right?
So if an URB doesn't get added to the queue until your HCD calls
usb_make_active, and the HCD doesn't realize the URB should be made active
until it's at the head of the endpoint queue...
> > 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.
It's not completely true that urb_enqueue and urb_dequeue can't run at the
same time. Before urb_dequeue calls giveback_urb, it has to release the
HCD's lock. So urb_enqueue could run before giveback_urb returns, while
urb_dequeue is still active (sort of) on the stack.
Besides, your HCD makes URBs active at times other than when urb_enqueue
is called, doesn't it? If urb_enqueue is called while another URB is
already active, the new URB won't be made active until the first one
finishes.
> > 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...
Dave said that having parallel queues is a waste, and I agree -- provided
that usbcore and the HCD can manage to share a single queue without
interference.
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
