On Fri, 14 Oct 2005, Franck wrote: > > > > 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 ?
That test is needed in any case, but it won't fully solve the problem I mentioned above. You need to test urb->hcpriv before sending an URB to the hardware. Then set urb->hcpriv in your urb_enqueue and clear it before calling giveback_urb, and you should be okay. The idea is that you never want to start sending an URB to the hardware if (a) it hasn't gone through urb_enqueue yet or (b) it has already gone through urb_dequeue. > > 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. No, the queue has to be managed by usbcore. Since your driver needs only to examine the URB at the head of the queue, you may be able to get away without access to the queue's lock in the HCD. However, it would be cleaner if you did have access to the lock -- and that's part of the reason why I think the lock should be moved into the usb_hcd structure. 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
