2005/10/14, Alan Stern <[EMAIL PROTECTED]>:
> 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
I was using your previous definition ;)
> 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...
>
correct.
> > > 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.
>
before calling giveback_urb and releasing hcd's lock, urb->status
should be different from -EINPROGRESS. So a test on that value at the
begining of urb_enqueue should make me safe, shouldn't it ?
> 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.
if active means that the HCD is currently sending the URB, yes.
> 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.
That what I'm thinking as well. But only one should manage the queue
and the other should only parse it with lock held. It should be
simpler...For now only usbcore manages and can parse the queue since
the queue's lock is private to usbcore. In my case the queue should be
managed by the HCD and parsed by usbcore.
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
