On Monday 05 June 2006 12:54 pm, Alan Stern wrote: > Dave: > > I just realized there is another problem connected with level-triggered > root-hub status interrupts. It probably hasn't affected your tests but > the potential is there. > > Two routines in the hub driver can cause port-change events to occur > outside the scope of khubd: usb_reset_device and usb_resume_device. That > is, these routines are called by processes other than khubd, and they > create PORT_STATUS_C_RESET and PORT_STATUS_C_SUSPEND events respectively. > > Normally khubd would see these events and start interfering with the > reset/resume. That is explicitly prevented in usb_reset_device by code > that sets hub->busy_bits. (Analogous code should be present in > hub_port_resume; leaving it out was an oversight.) When khubd sees a port > is busy, it simply skips over that port.
And when you say "interfering", presumably you mean doing anything other than just ignoring the port that's resetting or resuming. > 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. > > 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. > > Do you have a preference? Both seem kind of roundabout. If the issue is that some of the PORT_STATUS_C_* bits are wrongly left set, why not just have those routines clear them before returning? Or make sure that khubd is smart enough to notice change bits that can safely be ignored? - Dave > 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
