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

Message-ID: <CAJZ5v0i9ZKgybAarKD0DDH1q6k1LKse+kX=Op94zGO+PjyMvGw@mail.gmail.com>
Date: Mon, 28 Apr 2025 21:45:28 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Mario Limonciello <mario.limonciello@....com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Marcus Bergo <marcusbergo@...il.com>, mark.pearson@...ovo.com, 
	linux-acpi@...r.kernel.org, platform-driver-x86@...r.kernel.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 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.