Problems have been reported on AMD laptops with suspend/resume where particular root ports are put into D3 and then the system is unable to resume properly. The issue boils down to the currently selected kernel policy for root port behavior at suspend time: 0) If the machine is from 2015 or later 1) If a PCIe root port is power manageable by the platform then platform will be used to determine the power state of the root port at suspend. 2) If the PCIe root is not power manageable by the platform then the kernel will check if it was configured to wakeup. 3) If it was, then it will be put into the deepest state that supports wakeup from PME. 4) If it wasn't, then it will be put into D3hot. Earlier more general attempts [1] to fix this have been made in the past to change the policy so that only roots power manageable by the platform would be put into the appropriate power state advertised by the platform firmware. It was hyptothesized[2] that this is a general issue that affects non-AMD hardware as well, so I spent time to try to match it against the PCI or ACPI specs but I can't find anything that says how the OSPM /should behave/ in this case. It seems that this is up to OSPM to decide. A concern was also raised how this would affect other existing hardware that may not have root ports that are power manageable by the platform [3]. I suspect that they *should* be fine as Intel reviewed and acked the original patch, but I have no way to prove this. This patch is a more targeted approach to workaround the issue only for the affected AMD hardware instead of generally changing the policy. Link: https://lore.kernel.org/linux-pci/20230530163947.230418-2-mario.limonciello@xxxxxxx/ [1] Link: https://lore.kernel.org/linux-pci/ZHp45fNGuPUWPnO7@bhelgaas/ [2] Link: https://lore.kernel.org/linux-pci/20230607080154.GA7545@xxxxxxxxx/ [3] Mario Limonciello (1): PCI: Avoid putting some root ports into D3 on some Ryzen chips drivers/pci/quirks.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) -- 2.34.1
