On Tue, Jul 02, 2002, David Brownell <[EMAIL PROTECTED]> wrote: > > While I agree some of the locking can be made simpler, it can't be > > reduced to 1 lock. > > Could you elaborate? It works for OHCI and EHCI, so on > first principles, the same should be true for UHCI. (*) > I'm not saying that some parts of the current drivers don't > assume multiple locks, only that it's not necessary. > > I think that if you treat "one spinlock per HC" as a > technical goal, you'll find it's very possible.
Take a look at the discussions a year (or so?) ago about the recursive spinlocks and the then later with the switch to using the complete list. The short of it: We need to grab usb_list_lock to find which URB finished, which means we hold a lock while complete() is called, and the URB completion routine can submit a new URB = deadlock. usb-uhci plays some really nasty tricks with lists and let's itself get into races, but uses an ugly counter to figure out if there's a race or not. Not pretty. However, that doesn't cover all of the locks and I think it can be made simpler, but I was aiming for correctness first before sitting down and thinking hard about all of the locking issues with reducing the number of locks. JE ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek No, I will not fix your computer. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
