On Tue, 25 Feb 2025 at 16:56, Armin Wolf <W_Armin@xxxxxx> 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
