On Tue, 13 Jun 2006, David Brownell wrote: > On Tuesday 13 June 2006 11:08 am, Alan Stern wrote: > > > > This works okay with external hubs that are polled only 4 times per > > > > second > > > > and with edge-triggered status interrupts (like UHCI and, I assume, > > > > EHCI). > > > > But with level-triggered interrupts it will fail badly. Khubd will > > > > not clear the source before re-enabling the interrupt. > > > > > > > > I can think of two possible solutions. The first is to call > > > > hub_quiesce > > > > instead of setting hub->busy_bits. This has the disadvantage that > > > > khubd > > > > won't be able to respond to events on other ports while one port is > > > > being > > > > reset or resumed. > > In principle, I like the idea of the USB stack having more such > internal concurrency (two activities on one hub at the same time).
In principle, yes. In practice, one might find that some hubs can't walk and chew gum at the same time. There wouldn't be much point trying to do this with root hubs, for example. > > > > The second solution is to avoid calling usb_enable_root_hub_irq if > > > > hub->busy_bits is nonzero. This has the same disadvantage but it > > > > affects > > > > only OHCI controllers, not all hubs, both root and external. > > That would seem to be simplest; it could be called "later" when > those bits are all cleared, right? Exactly. > And strictly speaking it would > not be needed with all OHCI controllers. (Not that I'd plan on > making the code know about that specific implementation quirk.) Okay, I'll work on the second option when a chance arises. Alan Stern _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
