One some systems, the firmware does not allow certain PCI devices to
be put in deep D-states. This can cause problems for wakeup
signalling, if the device does not support PME# in the deepest allowed
suspend state. For example, Pierre reports that on his system, ACPI
does not permit his xHCI host controller to go into D3 during runtime
suspend -- but D3 is the only state in which the controller can generate
PME# signals. As a result, the controller goes into runtime suspend
but never wakes up, so it doesn't work properly. USB devices plugged
into the controller are never detected.
If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately
report that it cannot do wakeup from runtime suspend. This patch
modifies the pci_dev_run_wake() routine to add this check.
Signed-off-by: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
CC: Lukas Wunner <lukas@xxxxxxxxx>
Reported-by: Pierre de Villemereuil <flyos@xxxxxxxxxx>
Tested-by: Pierre de Villemereuil <flyos@xxxxxxxxxx>
CC: <stable@xxxxxxxxxxxxxxx>
---
[as1814]
drivers/pci/pci.c | 4 ++++
1 file changed, 4 insertions(+)
Index: usb-4.x/drivers/pci/pci.c
===================================================================
--- usb-4.x.orig/drivers/pci/pci.c
+++ usb-4.x/drivers/pci/pci.c
@@ -2064,6 +2064,10 @@ bool pci_dev_run_wake(struct pci_dev *de
if (!dev->pme_support)
return false;
+ /* PME-capable in principle, but not from the intended sleep state */
+ if (!pci_pme_capable(dev, pci_target_state(dev)))
+ return false;
+
while (bus->parent) {
struct pci_dev *bridge = bus->self;
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
