Hi, I'm working alongside Chris on this issue. On Fri, Mar 16, 2018 at 12:11 AM, Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> wrote: > Scope (_SB.PCI0.XHC) has _PS0 method, so Linux will look for a _S3W to get > the > lowest possible D state in S3, but_S3W is missing, so Linux pci-acpi code > will > probably default to D0 Yes, _S3W is missing, and in this case, acpi_dev_pm_get_state() is setting the maximum number permitted device power state to the minimum value of D0. So the XHCI controller is in D0 when you go into suspend. I tried your hack to force it into D3hot. Now the system can wake up from resume via the USB port. Thanks for finding that. >> ASUS said the BIOS has no problem on USB wakeup under Windows so I don't >> think >> there's any update. Anything else could be cause for this? > > Linux and Windows probably check different DSDT values I've studied the ACPI spec trying to understand better, but I'm struggling with the question: What is the maximum number (lowest power) permitted device power state for a device that is configured as able to wake the system from S3, **that does not implement the _S3W method**? As far as I can see, the ACPI spec doesn't give an answer. It's clear what the behaviour is when _S3W is present, but not unclear what should happen when it is not there. As noted above, Linux's interpretation is that in such case, the device must remain fully on (D0) when going into S3. I am wondering if Windows just has made an alternative assumption that all available device power states can wake the system from suspend in such case. This is working in Windows so hopefully we can find a way to match the behaviour? Thanks Daniel -- 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
