Am Sunday 18 January 2009 18:09:24 schrieb David Brownell: > On Sunday 18 January 2009, Oliver Neukum wrote: > > Am Saturday 17 January 2009 23:44:12 schrieb David Brownell: > > > > Do you know which HCDs are affected? > > > > > > The unlinking issue generally applies to any HCD that > > > doesn't have to disable hardware queues to unlink. > > > It's the "disable queue" which forces a contex switch > > > on stuff like EHCI/OHCI/UHCI, so they don't see $SUBJECT. > > > > Or alternatively, we make sue the status given to the completion > > handler must be used to decide which form of locking is appropriate > > to use. On second thought that seems the most elegant solution > > to me. > > This must be some new definition of "elegant" that I've not > previously come across... I've heard of language evolving > over time, but this seems extreme! Well, I am apparently an extremist ;-) > The general policy with locking is that a given procedure > should always work the same. If there are two different > locking policies, there should be two different entry points. Basically, I don't think this is doable. We've made the basic decision that the completion handler shall always be called, for whatever usbcore returns the URB. So the HCD decides which context the completion handler is called in. Now I see three options. 1. Drivers need to cope with any context and any locks held. This seems to be hardly practical to me. We'd beg for bugs. 2. We disallow HCDs calling the completion handler of any caller calling into usbcore (both usb_unlink_urb() and usb_submit_urb() suffer from this issue). This is very unelegant. It forces HCDs into using work queues needlessly. 3. We tell completion handlers which context they run in. It would be cleaner to do this with separate entry points, but how? Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
