On Fri, 18 Oct 2013, Andiry Xu wrote: > On Wed, Oct 16, 2013 at 9:14 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Sarah: > > > > While working on some general fixes for wakeup races during PCI > > suspend, I noticed that xhci_pci_suspend() ignores its do_wakeup > > argument. What's the story? > > > > I believe it's simply because I don't know how to handle the argument > when I wrote the code (Ohci ignores it as well). Ah... Maybe there really is nothing to do. I was thinking of ehci-hcd. Its suspend routine turns off the wakeup flags for all the ports if do_wakeup is false. Here's why: Consider the fifth line of Table 10 in section 4.15.2.3 (Wakeup Events) of the xHCI spec. It says that if a port is disconnected with the WCE bit set to 1, and a connect occurs while the host controller is not in D0, then (Note 10-2) PME# is asserted if enabled. The EHCI spec says essentially the same thing. With EHCI controllers on Intel motherboards, though, if the system is in S3 under those same conditions, a connect will cause the system to wake up even if PME# isn't enabled! I don't know if PME# gets asserted too. Probably not, since it doesn't get asserted if the same thing happens while the system is in S0. I also don't know whether Intel considers this to be a bug in the hardware. To prevent these unwanted wakeups, we have to turn off the wakeup flags for the suspended ports. Have you checked whether the same thing is needed with xHCI? Here's an easy way to find out. Write "enabled" to the power/wakeup sysfs file for each of your xHCI root hubs, and make sure that power/wakeup for the controller device (the root hubs' parent) is set to "disabled". Put the system into S3 suspend, and then see whether plugging a device into one of the xHCI ports causes the system to wake up. 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
