linux-kernel - Re: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD platforms after suspend/resume

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-prev] [day] [month] [year] [list]

Message-ID: <a2747306-447c-432a-a926-e9d0473d9a0e@amd.com>
Date: Sun, 27 Apr 2025 21:06:52 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: "M. Bergo" <marcusbergo@...il.com>, mark.pearson@...ovo.com
Cc: linux-acpi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
 rafael@...nel.org, lenb@...nel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD platforms
 after suspend/resume

On 4/27/2025 1:34 PM, M. Bergo wrote:
> It does make it work fine for me, I saw the clock/timing interference 
> and this sane this problem for Lenovo as well.

Huh?  I think you have a typo; but I don't know what you actually meant.

So you're saying the timing patch helps your system as well?

Thanks,

> 
> On 4/24/25 11:11 AM, Mario Limonciello wrote:
>> On 4/19/2025 1:03 PM, Mario Limonciello wrote:
>>> On 4/19/2025 4:28 AM, M. Bergo wrote:
>>>>  From 881e57c87b9595c186c2ca7e6d35d0a52c1a10c2 Mon Sep 17 00:00:00 2001
>>>> From: Marcus Bergo <marcusbergo@...il.com>
>>>> Date: Sat, 19 Apr 2025 05:19:05 -0300
>>>> Subject: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD 
>>>> platforms after
>>>>   suspend/resume
>>>>
>>>> Several AMD-based laptop models (Lenovo P15v Gen 3, P16v Gen 1, HP 
>>>> EliteBook 845 G10)
>>>> experience a CPU frequency limitation issue where the processor gets 
>>>> stuck at
>>>> approximately 544MHz after resuming from suspend when the power cord 
>>>> is unplugged
>>>> during sleep. This issue makes the systems practically unusable 
>>>> until a full
>>>> power cycle is performed.
>>>>
>>>> The root cause was traced to commit b5539eb5ee70 ("ACPI: EC: Fix
>>>> acpi_ec_dispatch_gpe()") which restored the behavior of clearing the 
>>>> GPE
>>>> in acpi_ec_dispatch_gpe() function to prevent GPE storms. While this 
>>>> fix is
>>>> necessary for most platforms to prevent excessive power consumption 
>>>> during
>>>> suspend-to-idle, it causes problems on certain AMD platforms by 
>>>> interfering
>>>> with the EC's ability to properly restore power management settings 
>>>> after resume.
>>>>
>>>> This patch implements a targeted workaround that:
>>>> 1. Adds DMI-based detection for affected AMD platforms
>>>> 2. Adds a function to check if we're in suspend-to-idle mode
>>>> 3. Modifies the acpi_ec_dispatch_gpe() function to handle AMD 
>>>> platforms specially:
>>>>     - For affected AMD platforms during suspend-to-idle, it advances 
>>>> the
>>>>       transaction without clearing the GPE status bit
>>>>     - For all other platforms, it maintains the existing behavior of 
>>>> clearing
>>>>       the GPE status bit
>>>>
>>>> Testing was performed on a Lenovo P16v Gen 1 with AMD Ryzen 7 PRO 
>>>> 7840HS and
>>>> confirmed that:
>>>> 1. Without the patch, the CPU frequency is limited to 544MHz after the
>>>>   suspend/unplug/resume sequence
>>>> 2. With the patch applied, the CPU properly scales up to its maximum 
>>>> frequency
>>>>     (5.1GHz) after the same sequence
>>>> 3. No regressions were observed in other EC functionality (battery 
>>>> status,
>>>>     keyboard backlight, etc.)
>>>> 4. Multiple suspend/resume cycles with different power states were 
>>>> tested
>>>>     without issues
>>>>
>>>> The patch was also verified not to affect the behavior on Intel- 
>>>> based systems,
>>>> ensuring that the GPE storm prevention remains effective where needed.
>>>>
>>>> Fixes: b5539eb5ee70 ("ACPI: EC: Fix acpi_ec_dispatch_gpe()")
>>>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=218557
>>>> Reported-by: Mark Pearson <mark.pearson@...ovo.com>
>>>> Signed-off-by: Marcus Bergo <marcusbergo@...il.com>
>>>
>>> Great finding with this being a potential root cause of this behavior 
>>> (at least from a Linux perspective).
>>>
>>> Although this helps, I'm not really a fan of the tech debt 
>>> accumulated by needing to quirk this on a system by system basis as a 
>>> bandage.
>>>
>>> At least for HP someone said that this commit happens to help them 
>>> for the same issue you're describing:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform- 
>>> drivers- x86.git/commit/? 
>>> h=fixes&id=9f5595d5f03fd4dc640607a71e89a1daa68fd19d
>>>
>>> That was surprising to me, but it must be changing the timing of some 
>>> of the code running in HP's EC.  Since you happen to have a Lenovo 
>>> system does it happen to help the Lenovo EC too?
>>>
>>> Mark, comments please?
>>>
>> Someone just reported that the timing delay patch helped their Lenovo 
>> system as well.  Can you see if it helps you too?