On Wed, Feb 01, 2012 at 11:05:50AM -0800, Sarah Sharp wrote: > 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. Oh, nevermind, I just found the documentation on disable_irq() in kernel/irq/manage.c. So it seems I need to call that function with each MSI-X irq vector. 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
