On Tue, Jan 31, 2012 at 01:29:28PM -0500, Alan Stern wrote: > On Tue, 31 Jan 2012, Sarah Sharp wrote: > > > > In fact, all HCDs need to address this sort of problem. It looks like > > > the best answer is to disable IRQ generation at the start of > > > bus_suspend and call synchronize_irq(). As a bonus, the remainder of > > > bus_suspend can run without holding the private lock, since no other > > > threads will enter the driver until the suspend finishes and IRQ > > > generation is re-enabled. > > > > What you described (disabling IRQs, etc) needs to be done in > > xhci_bus_suspend() as well, correct? Or were you thinking it could be > > done in the USB core, since other HCDs also have this problem? > > It can't be done in the core, because the core doesn't know how to tell > the hardware to stop generating IRQs I have to disable IRQs for all the processors before synchronizing the MSI-X vectors, correct? I'm not sure how to do that. (And I did attempt to RTFM, but docbooks no longer builds and Documentation/PCI/MSI-how-to.txt doesn't have anything terribly useful.) If I don't disable IRQs on all processors, synchronize_irq() will ensure that the MSI-X interrupts on different processors finish running, but it doesn't prevent them from running again. I can't take the xHCI lock and disable interrupts because the interrupt handler may drop the xHCI lock to kick khubd on a port change, and attempt to reacquire it. Sarah Sharp -- 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
