| 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
| ||
|
Message-ID: <2b5b05e4-5913-45ee-846d-9980e17d4df6@tuxedocomputers.com>
Date: Fri, 20 Dec 2024 12:20:06 +0100
From: Werner Sembach <wse@...edocomputers.com>
To: Mario Limonciello <mario.limonciello@....com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Mika Westerberg <mika.westerberg@...ux.intel.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] PCI: Avoid putting some root ports into D3 on some
Ryzen chips
Am 19.12.24 um 21:54 schrieb Mario Limonciello:
> On 12/19/2024 14:46, Werner Sembach wrote:
>>
>> Am 18.12.24 um 16:59 schrieb Werner Sembach:
>>>
>>> Am 18.12.24 um 15:06 schrieb Mario Limonciello:
>>>> On 12/18/2024 04:34, Werner Sembach wrote:
>>>>> From: Mario Limonciello <mario.limonciello@....com>
>>>>>
>>>>> commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the
>>>>> policy that all PCIe ports are allowed to use D3. When the system is
>>>>> suspended if the port is not power manageable by the platform and won't be
>>>>> used for wakeup via a PME this sets up the policy for these ports to go
>>>>> into D3hot.
>>>>>
>>>>> This policy generally makes sense from an OSPM perspective but it leads to
>>>>> problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a
>>>>> specific old BIOS. This manifests as a system hang.
>>>>>
>>>>> On the affected Device + BIOS combination, add a quirk for the PCI device
>>>>> ID used by the problematic root port on to ensure that these root ports are
>>>>> not put into D3hot at suspend.
>>>>>
>>>>> This patch is based on
>>>>> https://lore.kernel.org/linux-pci/20230708214457.1229-2-
>>>>> mario.limonciello@....com/
>>>>> but with the added condition both in the documentation and in the code to
>>>>> apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS.
>>>>>
>>>>> Co-developed-by: Georg Gottleuber <ggo@...edocomputers.com>
>>>>> Signed-off-by: Georg Gottleuber <ggo@...edocomputers.com>
>>>>> Co-developed-by: Werner Sembach <wse@...edocomputers.com>
>>>>> Signed-off-by: Werner Sembach <wse@...edocomputers.com>
>>>>> Cc: stable@...r.kernel.org # 6.1+
>>>>> Reported-by: Iain Lane <iain@...ngesquash.org.uk>
>>>>> Closes: https://forums.lenovo.com/t5/Ubuntu/Z13-can-t-resume-from-
>>>>> suspend-with-external-USB-keyboard/m-p/5217121
>>>>
>>>> These two tag (Reported-by and Closes) should be stripped because this is
>>>> now for very different hardware.
>>> Ack will remove in next version
>>>>
>>>>> Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend")
>>>>> Signed-off-by: Mario Limonciello <mario.limonciello@....com>
>>>>> ---
>>>>> drivers/pci/quirks.c | 26 ++++++++++++++++++++++++++
>>>>> 1 file changed, 26 insertions(+)
>>>>>
>>>>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>>>>> index 76f4df75b08a1..68075a6a5283c 100644
>>>>> --- a/drivers/pci/quirks.c
>>>>> +++ b/drivers/pci/quirks.c
>>>>> @@ -3908,6 +3908,32 @@ static void quirk_apple_poweroff_thunderbolt(struct
>>>>> pci_dev *dev)
>>>>> DECLARE_PCI_FIXUP_SUSPEND_LATE(PCI_VENDOR_ID_INTEL,
>>>>> PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C,
>>>>> quirk_apple_poweroff_thunderbolt);
>>>>> +
>>>>> +/*
>>>>> + * Putting PCIe root ports on Ryzen SoCs with USB4 controllers into D3hot
>>>>> + * may cause problems when the system attempts wake up from s2idle.
>>>>> + *
>>>>> + * On the TUXEDO Sirius 16 Gen 1 with a specific old BIOS this manifests as
>>>>> + * a system hang.
>>>>> + */
>>>>> +static const struct dmi_system_id quirk_ryzen_rp_d3_dmi_table[] = {
>>>>> + {
>>>>> + .matches = {
>>>>> + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
>>>>> + DMI_EXACT_MATCH(DMI_BOARD_NAME, "APX958"),
>>>>> + DMI_EXACT_MATCH(DMI_BIOS_VERSION, "V1.00A00_20240108"),
>>>>> + },
>>>>> + },
>>>>> + {}
>>>>> +};
>>>>> +
>>>>> +static void quirk_ryzen_rp_d3(struct pci_dev *pdev)
>>>>> +{
>>>>> + if (dmi_check_system(quirk_ryzen_rp_d3_dmi_table) &&
>>>>> + !acpi_pci_power_manageable(pdev))
>>>>> + pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
>>>>> +}
>>>>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x14eb, quirk_ryzen_rp_d3);
>>>>
>>>> So it needs to be applied to /all/ the root ports PID 0x14eb, not just one
>>>> of them?
>>> Don't know, I will look into it (I think because of the !
>>> acpi_pci_power_manageable(pdev) it is applied to two of the three on the
>>> device)
>>
>> I tried it like this now:
>>
>> static void quirk_ryzen_rp_d3(struct pci_dev *pdev)
>> {
>> struct pci_dev *root_pdev;
>>
>> if (dmi_check_system(quirk_ryzen_rp_d3_dmi_table)) {
>> root_pdev = pcie_find_root_port(pdev);
>> if (root_pdev && !acpi_pci_power_manageable(root_pdev))
>> root_pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
>> }
>> }
>> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1668, quirk_ryzen_rp_d3);
>> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1669, quirk_ryzen_rp_d3);
>>
>> but that doesn't work.
>
> OK; that means it's more root ports indeed than just the ones above the USB4
> controllers.
Turns out its just a different root controller and with
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1502, quirk_ryzen_rp_d3);
instead of
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1668, quirk_ryzen_rp_d3);
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1669, quirk_ryzen_rp_d3);
it works.
I will now try the other fix with
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x1502, quirk_ryzen_rp_d3);
>
>>
>>>>
>>>>> #endif
>>>>> /*
>>>>
>
Powered by blists - more mailing lists