linux-kernel - Re: [PATCH v2 2/2] ACPI: platform_profile: make amd-pmf a secondary handler

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: 
 <CAGwozwEqVkDC_HvuJhGE=PUep-73RVFnuZNWh0E+8ucfko1F8g@mail.gmail.com>
Date: Thu, 27 Feb 2025 18:28:04 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Mario Limonciello <mario.limonciello@....com>
Cc: mpearson-lenovo@...ebb.ca, ilpo.jarvinen@...ux.intel.com, lenb@...nel.org,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
	platform-driver-x86@...r.kernel.org, rafael@...nel.org, hdegoede@...hat.com,
	me@...egospodneti.ch, luke@...nes.dev
Subject: Re: [PATCH v2 2/2] ACPI: platform_profile: make amd-pmf a secondary
 handler

On Thu, 27 Feb 2025 at 18:24, Mario Limonciello
<mario.limonciello@....com> wrote:
>
> On 2/27/2025 11:18, Antheas Kapenekakis wrote:
> > On Thu, 27 Feb 2025 at 18:10, Mario Limonciello
> > <mario.limonciello@....com> wrote:
> >>
> >> On 2/27/2025 11:04, Antheas Kapenekakis wrote:
> >>> On Thu, 27 Feb 2025 at 17:46, Mario Limonciello
> >>> <mario.limonciello@....com> wrote:
> >>>>
> >>>> On 2/27/2025 09:36, Antheas Kapenekakis wrote:
> >>>>> Since amd-pmf is expected to run alongside other platform handlers, it
> >>>>> should be able to accept all platform profiles. Therefore, mark it as
> >>>>> secondary and in the case of a custom profile, make it NOOP without an
> >>>>> error to allow primary handlers to receive a custom profile.
> >>>>> The sysfs endpoint will still report custom, after all.
> >>>>>
> >>>>> Signed-off-by: Antheas Kapenekakis <lkml@...heas.dev>
> >>>>> ---
> >>>>>     drivers/platform/x86/amd/pmf/spc.c | 3 +++
> >>>>>     drivers/platform/x86/amd/pmf/sps.c | 8 ++++++++
> >>>>>     2 files changed, 11 insertions(+)
> >>>>>
> >>>>> diff --git a/drivers/platform/x86/amd/pmf/spc.c b/drivers/platform/x86/amd/pmf/spc.c
> >>>>> index f34f3130c330..99c48378f943 100644
> >>>>> --- a/drivers/platform/x86/amd/pmf/spc.c
> >>>>> +++ b/drivers/platform/x86/amd/pmf/spc.c
> >>>>> @@ -219,12 +219,15 @@ static int amd_pmf_get_slider_info(struct amd_pmf_dev *dev, struct ta_pmf_enact_
> >>>>>
> >>>>>         switch (dev->current_profile) {
> >>>>>         case PLATFORM_PROFILE_PERFORMANCE:
> >>>>> +     case PLATFORM_PROFILE_BALANCED_PERFORMANCE:
> >>>>>                 val = TA_BEST_PERFORMANCE;
> >>>>>                 break;
> >>>>>         case PLATFORM_PROFILE_BALANCED:
> >>>>>                 val = TA_BETTER_PERFORMANCE;
> >>>>>                 break;
> >>>>>         case PLATFORM_PROFILE_LOW_POWER:
> >>>>> +     case PLATFORM_PROFILE_COOL:
> >>>>> +     case PLATFORM_PROFILE_QUIET:
> >>>>>                 val = TA_BEST_BATTERY;
> >>>>
> >>>> I would really prefer we do the absolute bare minimum to help this issue
> >>>> on ASUS (just special case quiet) and leave adding compat for other
> >>>> profiles for other development.
> >>>
> >>> I cannot risk other drivers having their options disabled. This can
> >>> have carry-on effects in other drivers too.
> >>>
> >>> Including in the legion v3 driver, in which you will end up disabling
> >>> balanced-performance. Since Derek posted the v3 for that today.
> >>>
> >>
> >> Sure - but let's handle that separately from this bug fix.  That driver
> >> will be targeted to 6.15 or later.
> >>
> >> We need to be cognizant about what can go into 6.14 needs to be bug
> >> fixes for drivers in tree.
> >
> > For me to consider this problem resolved, I need a mitigation that
> > matches the behavior of this patch series 1-1.
> >
> > If you have a better suggestion, I can implement it and test it real quick.
>
> I think just covering the QUIET == LOW_POWER is the important one for now.

Sure, how do we do that? You want to make amd-pmf accept both just for
6.14? I would be ok with that.

> >
> > If this issue is not fully resolved, it will cause a lot of downstream
> > issues that will result in the legacy interface becoming unusable.
> >
> > Acer and alienware implement balanced performance too. In the current tree.
>
> But do Acer and Alienware have designs that amd-pmf will bind at the
> same time?
>
> I'm not so sure.

>From a quick google search, Acer Swift Edge 16 - 8840U. But we do not
have a lot of acer users I'd say.

> >
> snip
> >>
>