linux-kernel - Re: [PATCH 0/3] ACPI: platform_profile: fix legacy sysfs with multiple handlers

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: 
 <CAGwozwFS_D4k-Q-QUums8FMZ82p_5-RzBvZZJX1k7_YP2E1cfg@mail.gmail.com>
Date: Tue, 25 Feb 2025 17:27:10 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Armin Wolf <W_Armin@....de>
Cc: Luke Jones <luke@...nes.dev>, Mark Pearson <mpearson-lenovo@...ebb.ca>,
	"Limonciello, Mario" <mario.limonciello@....com>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Len Brown <lenb@...nel.org>,
 "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	linux-kernel@...r.kernel.org,
	"platform-driver-x86@...r.kernel.org" <platform-driver-x86@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>, Hans de Goede <hdegoede@...hat.com>,
 me@...egospodneti.ch
Subject: Re: [PATCH 0/3] ACPI: platform_profile: fix legacy sysfs with
 multiple handlers

On Tue, 25 Feb 2025 at 16:56, Armin Wolf <W_Armin@....de> wrote:
>
> Am 25.02.25 um 03:26 schrieb Antheas Kapenekakis:
>
> >> If these "scripts" use `platform_profile_choices` to get their
> >> selections and verify they are available then there should be zero
> >> breakage. If they don't then they should be updated to be correct.
> > Yeah, if any Asus users wrote scripts for their laptops to e.g., "echo
> > quiet | sudo tee /sys/firmware/acpi/platform_profile" or used TLP let
> > them spend a few days finding out why kernel 6.14 does not work. They
> > should have written a 300 line bash script instead.
>
> Hi,
>
> using "echo quiet | sudo tee /sys/firmware/acpi/platform_profile" is quite
> brittle, as some hardware will populate the available profiles dynamically.
>
> Still breaking userspace is indeed not an option here, so we have to think
> of something else.

e.g., for example I had a tdp handler for the ally and had to
transplant it to thermal_throttle_profile when the breakage with
amd_pmf started happening.

> snip
>
> This whole driver was likely written by someone as a hobby, so you already
> depend on a hobby here.
>
> That being said, i agree that fixes have a priority over new features, and
> i think everyone agrees on that.

Indeed.In which case, saying people should use your hobby code perhaps
is a bit overreaching. Haha.

> Maybe the current strategy of the legacy platform-profile interface can be extended
> without introducing the "secondary handler" concept.
>
> The current strategy only advertises platform profiles supported by all handlers, and
> as you pointed out this causes problems for users on certain devices.
>
> I was thinking that be can change this strategy to advertise all platform profiles supported
> by at least one handler can then do something like this:
>
>   - handler 1: supports low_power, balanced and performance
>
>   - handler 2: supports quiet, balanced and balanced-performance
>
> -> legacy interface advertises low_power, quiet, balanced, balanced-performance and performance
>
> When setting low_power, the closes equivalent is picked for handlers which do not support low_power:
>
>   - handler 1: setting low_power
>
>   - handler 2: setting quiet
>
> When setting quiet, the same happens:
>
>   - handler 1: setting balanced
>
>   - handler 2: setting quiet
>
> Basically all profiles get treated like a range:
>
> low_power <- lower end of the performance range
> cool,
> quiet,
> balanced,
> balanced-performance,
> performance <- upper end of the performance range
>
> The only problem will be that getting the current platform profile would be more difficult, as
> the legacy handler has to determine the lowest currently selected platform profile.
>
> Would this approach be OK?
>
> Thanks,
> Armin Wolf
>

So the way this patch series is designed is that the new
/sys/class/platform-profileX works exactly the same.

Then, when asus-wmi is loaded, regardless of whether amd-pmf is
loaded, you get quiet, balanced, and performance. Like it was before.
Setting it to quiet makes amd-pmf use its low power setting. And it
will work the same with all WMI drivers, regardless of whether they
use cool, low-power, quiet, or balanced-power

When asus-wmi is unloaded, you get low-power, balanced, and
performance. As you would with amd-pmf on its own. 0 ABI changes.

Series is small enough so that if you don't like it, it is easy to
refactor out during the 6.15 merge window.

$ cat /sys/firmware/acpi/platform_profile_choices
quiet balanced performance
$ sudo rmmod asus-nb-wmi
$ cat /sys/firmware/acpi/platform_profile_choices
low-power balanced performance

Antheas