On Wed, 1 Feb 2012, Sarah Sharp wrote: > Well, it's a moot point now, because looking at the xhci_bus_suspend > method, it has to issue several commands and wait for the host > controller to finish processing them before it can return, if there's a > port that's not suspended: ... > Is there any reason why the USB core would be suspending a bus if all > attached devices were not suspended? Yes, as a matter of fact. This happens during hibernation, in the PMSG_FREEZE stage. The idea is that everything is supposed to be quiescent (no IRQs or DMA) but should remain at full power. The USB core calls the suspend methods for all the device drivers, so all URBs should be cancelled, but it doesn't actually suspend the devices. And it does call the bus_suspend methods for the HCDs, because the host controllers are what actually generate IRQs and do DMA. > I think this shouldn't be an issue > if we're disabling IRQs in xhci_bus_suspend(), and making sure that > we're not in the middle of a resume. What exactly do you mean by "disabling IRQs"? People tend to use terms like that somewhat carelessly. Do you mean disabling an IRQ line? Or disabling interrupts on some or all CPUs? In general those sorts of things should be avoided. > As to your question about the INTE bit, I don't think I really want to > do that. I think I have to stop the host (set the stop bit) to disable > interrupts that way. From a quick search through the xHCI spec, it only > talks about turning that bit on during initialization. I can't find any > text about what the host is supposed to do if that bit gets turned off > while it's running. > > The reason I'm concerned about setting the INTE bit while the host is > running is because xhci_bus_suspend is can be called for one portion of > the roothub, while the other is still trying to run. E.g. the USB 2.0 > bus is being suspended while the USB 3.0 bus is still active. That is a good cause for concern. > However, both Arjan and HPA say that if the device tries to interrupt > while it's MSI-X vector is disabled, there's no guarantee that the xHCI > driver will get the interrupt later. So disabling MSI or MSI-X vectors > doesn't seem to be a good solution. > > Maybe I just need to look for the resume bits in the PCI suspend > function (xhci_suspend), and bail out there if they're set? Well, there are two things to worry about. The first is that you don't want xhci_bus_suspend to return successfully if wakeup is enabled and any ports have generated a wakeup event. The second is that you don't want the interrupt handler routine to be modifying port settings concurrently with xhci_bus_suspend. Alan Stern -- 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
