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]
Message-ID: <20230708214457.1229-1-mario.limonciello@amd.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ