linux-kernel - [PATCH v6 0/1] Fix suspend issues with AMD root ports

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 8 Jul 2023 16:44:56 -0500
From:   Mario Limonciello <mario.limonciello@....com>
To:     "Rafael J . Wysocki" <rafael@...nel.org>,
        Bjorn Helgaas <helgaas@...nel.org>
CC:     <linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Len Brown <lenb@...nel.org>, <linux-acpi@...r.kernel.org>,
        Mario Limonciello <mario.limonciello@....com>
Subject: [PATCH v6 0/1] Fix suspend issues with AMD root ports

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@amd.com/ [1]
Link: https://lore.kernel.org/linux-pci/ZHp45fNGuPUWPnO7@bhelgaas/ [2]
Link: https://lore.kernel.org/linux-pci/20230607080154.GA7545@wunner.de/ [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