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: <75faab0b-4514-4678-ba27-af658f6d3485@amd.com>
Date: Mon, 28 Apr 2025 16:06:06 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Marcus Bergo <marcusbergo@...il.com>
Cc: mark.pearson@...ovo.com, linux-acpi@...r.kernel.org,
 platform-driver-x86@...r.kernel.org, lenb@...nel.org,
 LKML <linux-kernel@...r.kernel.org>, "Rafael J. Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH] ACPI: EC: Fix CPU frequency limitation on AMD platforms
 after suspend/resume

On 4/28/2025 2:45 PM, Rafael J. Wysocki wrote:
> On Mon, Apr 28, 2025 at 9:11 PM Mario Limonciello
> <mario.limonciello@....com> wrote:
>>
>> On 4/28/2025 2:02 PM, Rafael J. Wysocki wrote:
>>> On Mon, Apr 28, 2025 at 8:23 PM Mario Limonciello
>>> <mario.limonciello@....com> wrote:
>>>>
>>>> On 4/28/2025 4:51 AM, Marcus Bergo wrote:
>>>>> Yes, it does.
>>>>>
>>>>
>>>> OK thanks for confirming.  Considering your finding with this patch
>>>> you've shared and knowing there is a timing dependency that delaying the
>>>> next s2idle cycle helps I do wonder if we should keep exploring.
>>>>
>>>> Rafael, do you have thoughts here?  Specifically do you think it's worth
>>>> revisiting if b5539eb5ee70 was the correct move.
>>>
>>> Well, it was done for a reason that is explained in its changelog.  I
>>> think that the problem addressed by it is genuine, isn't it?
>>>
>> I mean yes - of course.  My inquiry was whether this should be the
>> default behavior or if it should have been a quirked behavior.
> 
> I believe that it should be the default behavior because the EC GPE
> needs to be cleared after handling an EC event which effectively is
> what the suspend-to-idle code does.
> 
>> I don't have a good sense for the rest of the ecosystem what the impacts
>> would really be at flipping it.  Would it be worth adding a module
>> parameter debug knob and survey what happens on a wide variety of machines?
> 
> Maybe, if you suspect that this might be a widespread issue.

Marcus,

Before going down this path I have an important confirmation I need from 
you.

With just /your/ patch in place did you see a message like this in your 
kernel log?

amd_pmc AMDI000A:00: Last suspend didn't reach deepest state

If so; your patch just papered over the real issue and blocked the 
system from getting into a deep state.