On the Asus Z13 (2025), a device that would need the amd-pmf quirk that
was removed on the platform_profile refactor, we see the following output
from the sysfs platform profile:

$ cat /sys/firmware/acpi/platform_profile_choices
balanced performance

I.e., the quiet profile is missing. Which is a major regression in terms of
power efficiency and affects both tuned, and ppd (it also affected my
software but I fixed that on Saturday). This would affect any laptop that
loads both amd-pmf and asus-wmi (around 15 models give or take?).

The problem stems from the fact that asus-wmi uses quiet, and amd-pmf uses
low-power. While it is not clear to me what the amd-pmf module is supposed
to do here, and perhaps some autodetection should be done and make it bail,
if we assume it should be kept, then there is a small refactor that is
needed to maintain the existing ABI interface.

This is the subject of this patch series.

Essentially, we introduce the concept of a "secondary" handler. Secondary
handlers work exactly the same, except for the fact they are able to
receive all profile names through the sysfs interface. The expectation
here would be that the handlers choose the closest appropriate profile
they have, and this is what I did for the amd-pmf handler.

In their own platform_profile namespace, these handlers still work normally
and only accept the profiles from their probe functions, with -ENOSUP for
the rest.

In the absence of a primary handler, the options of all secondary handlers
are unioned in the legacy sysfs, which prevents them from hiding each
other's options.

With this patch series applied, the sysfs interface will look like this:

$ cat /sys/firmware/acpi/platform_profile_choices
quiet balanced performance

And writing quiet to it results in the profile being applied to both
platform profile handlers.

$ echo low-power > /sys/firmware/acpi/platform_profile
bash: echo: write error: Operation not supported
$ echo quiet > /sys/firmware/acpi/platform_profile
$ cat /sys/class/platform-profile/platform-profile-*/{name,profile}
asus-wmi
amd-pmf
quiet
quiet

Agreed ABI still works:
$ echo quiet > /sys/class/platform-profile/platform-profile-0/profile
$ echo quiet > /sys/class/platform-profile/platform-profile-1/profile
bash: echo: write error: Operation not supported
$ echo low-power > /sys/class/platform-profile/platform-profile-0/profile
bash: echo: write error: Operation not supported
$ echo low-power > /sys/class/platform-profile/platform-profile-1/profile

Antheas Kapenekakis (3):
  ACPI: platform_profile: Add support for secondary handlers
  ACPI: platform_profile: add all options to amd-pmf as a secondary
    handler
  ACPI: platform_profile: Do not hide options missing in secondary
    handlers

 drivers/acpi/platform_profile.c    | 57 +++++++++++++++++++++++++-----
 drivers/platform/x86/amd/pmf/spc.c |  3 ++
 drivers/platform/x86/amd/pmf/sps.c |  8 +++++
 include/linux/platform_profile.h   |  7 ++++
 4 files changed, 67 insertions(+), 8 deletions(-)

-- 
2.48.1

Hi Antheas,

On Mon, Feb 24, 2025, at 2:50 PM, Antheas Kapenekakis wrote:
> On the Asus Z13 (2025), a device that would need the amd-pmf quirk that
> was removed on the platform_profile refactor, we see the following output
> from the sysfs platform profile:
>
> $ cat /sys/firmware/acpi/platform_profile_choices
> balanced performance
>
> I.e., the quiet profile is missing. Which is a major regression in terms of
> power efficiency and affects both tuned, and ppd (it also affected my
> software but I fixed that on Saturday). This would affect any laptop that
> loads both amd-pmf and asus-wmi (around 15 models give or take?).
>
> The problem stems from the fact that asus-wmi uses quiet, and amd-pmf uses
> low-power. While it is not clear to me what the amd-pmf module is supposed
> to do here, and perhaps some autodetection should be done and make it bail,
> if we assume it should be kept, then there is a small refactor that is
> needed to maintain the existing ABI interface.
>
> This is the subject of this patch series.
>
> Essentially, we introduce the concept of a "secondary" handler. Secondary
> handlers work exactly the same, except for the fact they are able to
> receive all profile names through the sysfs interface. The expectation
> here would be that the handlers choose the closest appropriate profile
> they have, and this is what I did for the amd-pmf handler.
>
> In their own platform_profile namespace, these handlers still work normally
> and only accept the profiles from their probe functions, with -ENOSUP for
> the rest.
>
> In the absence of a primary handler, the options of all secondary handlers
> are unioned in the legacy sysfs, which prevents them from hiding each
> other's options.
>
> With this patch series applied, the sysfs interface will look like this:
>
> $ cat /sys/firmware/acpi/platform_profile_choices
> quiet balanced performance
>
> And writing quiet to it results in the profile being applied to both
> platform profile handlers.
>
> $ echo low-power > /sys/firmware/acpi/platform_profile
> bash: echo: write error: Operation not supported
> $ echo quiet > /sys/firmware/acpi/platform_profile
> $ cat /sys/class/platform-profile/platform-profile-*/{name,profile}
> asus-wmi
> amd-pmf
> quiet
> quiet
>
> Agreed ABI still works:
> $ echo quiet > /sys/class/platform-profile/platform-profile-0/profile
> $ echo quiet > /sys/class/platform-profile/platform-profile-1/profile
> bash: echo: write error: Operation not supported
> $ echo low-power > /sys/class/platform-profile/platform-profile-0/profile
> bash: echo: write error: Operation not supported
> $ echo low-power > /sys/class/platform-profile/platform-profile-1/profile
>

I understand where you're coming from with this implementation but my concern is this is making profiles more complicated - and they're already becoming hard to understand (and debug) for users.

I'm not a huge fan of multiple profile handlers, but can see why some people might want them and that they're a valid tool to have (especially given some of the limitations of what platform vendors themselves implement).

In patch #3 it states that 'It is the expectation that secondary handlers will pick the closest profile they have to what was sent'. I'm not convinced that is true, or desired.

e.g. Quiet and low-power are different things and can have different implementations. One is giving you as much power as possible with the fans running below a certain audible level; and one is giving you a system with as low-power consumption as possible, but still be usable. They're admittedly not very different in practice - but they can be different.

Would it be better here to ask AMD to implement a quiet profile (maybe it can be based on low-power, at least initially)?
I think that would solve the ASUS issue and not introduce another layer of complexity.

Mark

On Mon, 2025-02-24 at 15:52 -0500, Mark Pearson wrote:
> Hi Antheas,
> 
> On Mon, Feb 24, 2025, at 2:50 PM, Antheas Kapenekakis wrote:
> > On the Asus Z13 (2025), a device that would need the amd-pmf quirk
> > that
> > was removed on the platform_profile refactor, we see the following
> > output
> > from the sysfs platform profile:
> > 
> > $ cat /sys/firmware/acpi/platform_profile_choices
> > balanced performance
> > 
> > I.e., the quiet profile is missing. Which is a major regression in
> > terms of
> > power efficiency and affects both tuned, and ppd (it also affected
> > my
> > software but I fixed that on Saturday). This would affect any
> > laptop that
> > loads both amd-pmf and asus-wmi (around 15 models give or take?).
> > 
> > The problem stems from the fact that asus-wmi uses quiet, and amd-
> > pmf uses
> > low-power. While it is not clear to me what the amd-pmf module is
> > supposed
> > to do here, and perhaps some autodetection should be done and make
> > it bail,
> > if we assume it should be kept, then there is a small refactor that
> > is
> > needed to maintain the existing ABI interface.
> > 
> > This is the subject of this patch series.
> > 
> > Essentially, we introduce the concept of a "secondary" handler.
> > Secondary
> > handlers work exactly the same, except for the fact they are able
> > to
> > receive all profile names through the sysfs interface. The
> > expectation
> > here would be that the handlers choose the closest appropriate
> > profile
> > they have, and this is what I did for the amd-pmf handler.
> > 
> > In their own platform_profile namespace, these handlers still work
> > normally
> > and only accept the profiles from their probe functions, with -
> > ENOSUP for
> > the rest.
> > 
> > In the absence of a primary handler, the options of all secondary
> > handlers
> > are unioned in the legacy sysfs, which prevents them from hiding
> > each
> > other's options.
> > 
> > With this patch series applied, the sysfs interface will look like
> > this:
> > 
> > $ cat /sys/firmware/acpi/platform_profile_choices
> > quiet balanced performance
> > 
> > And writing quiet to it results in the profile being applied to
> > both
> > platform profile handlers.
> > 
> > $ echo low-power > /sys/firmware/acpi/platform_profile
> > bash: echo: write error: Operation not supported
> > $ echo quiet > /sys/firmware/acpi/platform_profile
> > $ cat /sys/class/platform-profile/platform-profile-*/{name,profile}
> > asus-wmi
> > amd-pmf
> > quiet
> > quiet
> > 
> > Agreed ABI still works:
> > $ echo quiet > /sys/class/platform-profile/platform-profile-
> > 0/profile
> > $ echo quiet > /sys/class/platform-profile/platform-profile-
> > 1/profile
> > bash: echo: write error: Operation not supported
> > $ echo low-power > /sys/class/platform-profile/platform-profile-
> > 0/profile
> > bash: echo: write error: Operation not supported
> > $ echo low-power > /sys/class/platform-profile/platform-profile-
> > 1/profile
> > 
> 
> I understand where you're coming from with this implementation but my
> concern is this is making profiles more complicated - and they're
> already becoming hard to understand (and debug) for users.
> 
> I'm not a huge fan of multiple profile handlers, but can see why some
> people might want them and that they're a valid tool to have
> (especially given some of the limitations of what platform vendors
> themselves implement).
> 
> In patch #3 it states that 'It is the expectation that secondary
> handlers will pick the closest profile they have to what was sent'.
> I'm not convinced that is true, or desired.
> 
> e.g. Quiet and low-power are different things and can have different
> implementations. One is giving you as much power as possible with the
> fans running below a certain audible level; and one is giving you a
> system with as low-power consumption as possible, but still be
> usable. They're admittedly not very different in practice - but they
> can be different.
> 
> Would it be better here to ask AMD to implement a quiet profile
> (maybe it can be based on low-power, at least initially)?
> I think that would solve the ASUS issue and not introduce another
> layer of complexity.
> 
> Mark

Hi Mark,

I've supported over 80 different ASUS laptops in the last 6 years or
so, I can offer some insight.

Across the entire range (TUF, ROG, Vivobook, Zen) which implements some
form of "thermal throttle" as it is called in asus-wmi (which is what
is used by platform_profile) the difference between low-power and quiet
is very much nil - the "quiet" profile is only a name, and the TDP is
limited along with fans to match - so the result is "low-power".

As Mario suggests in his reply perhaps an alias would be best, or, as I
was going to do, simply rename the "quiet" profile in asus-wmi to "low-
power" as I already did but have not submitted yet due to a large train
of patches in progress. It's a single line change and nullifies the
entire issue and this series.

In any case asus handling of platform profile is something I have been
steadily working on for the last few months for both laptops and
handhelds and I will have a new patch series coming soon (version 7 of
previously submitted dealing with this).

This submitted series is a NACK from me.

Cheers,
Luke.

Am 24.02.25 um 22:51 schrieb Luke Jones:

> On Mon, 2025-02-24 at 15:52 -0500, Mark Pearson wrote:
>> Hi Antheas,
>>
>> On Mon, Feb 24, 2025, at 2:50 PM, Antheas Kapenekakis wrote:
>>> On the Asus Z13 (2025), a device that would need the amd-pmf quirk
>>> that
>>> was removed on the platform_profile refactor, we see the following
>>> output
>>> from the sysfs platform profile:
>>>
>>> $ cat /sys/firmware/acpi/platform_profile_choices
>>> balanced performance
>>>
>>> I.e., the quiet profile is missing. Which is a major regression in
>>> terms of
>>> power efficiency and affects both tuned, and ppd (it also affected
>>> my
>>> software but I fixed that on Saturday). This would affect any
>>> laptop that
>>> loads both amd-pmf and asus-wmi (around 15 models give or take?).
>>>
>>> The problem stems from the fact that asus-wmi uses quiet, and amd-
>>> pmf uses
>>> low-power. While it is not clear to me what the amd-pmf module is
>>> supposed
>>> to do here, and perhaps some autodetection should be done and make
>>> it bail,
>>> if we assume it should be kept, then there is a small refactor that
>>> is
>>> needed to maintain the existing ABI interface.
>>>
>>> This is the subject of this patch series.
>>>
>>> Essentially, we introduce the concept of a "secondary" handler.
>>> Secondary
>>> handlers work exactly the same, except for the fact they are able
>>> to
>>> receive all profile names through the sysfs interface. The
>>> expectation
>>> here would be that the handlers choose the closest appropriate
>>> profile
>>> they have, and this is what I did for the amd-pmf handler.
>>>
>>> In their own platform_profile namespace, these handlers still work
>>> normally
>>> and only accept the profiles from their probe functions, with -
>>> ENOSUP for
>>> the rest.
>>>
>>> In the absence of a primary handler, the options of all secondary
>>> handlers
>>> are unioned in the legacy sysfs, which prevents them from hiding
>>> each
>>> other's options.
>>>
>>> With this patch series applied, the sysfs interface will look like
>>> this:
>>>
>>> $ cat /sys/firmware/acpi/platform_profile_choices
>>> quiet balanced performance
>>>
>>> And writing quiet to it results in the profile being applied to
>>> both
>>> platform profile handlers.
>>>
>>> $ echo low-power > /sys/firmware/acpi/platform_profile
>>> bash: echo: write error: Operation not supported
>>> $ echo quiet > /sys/firmware/acpi/platform_profile
>>> $ cat /sys/class/platform-profile/platform-profile-*/{name,profile}
>>> asus-wmi
>>> amd-pmf
>>> quiet
>>> quiet
>>>
>>> Agreed ABI still works:
>>> $ echo quiet > /sys/class/platform-profile/platform-profile-
>>> 0/profile
>>> $ echo quiet > /sys/class/platform-profile/platform-profile-
>>> 1/profile
>>> bash: echo: write error: Operation not supported
>>> $ echo low-power > /sys/class/platform-profile/platform-profile-
>>> 0/profile
>>> bash: echo: write error: Operation not supported
>>> $ echo low-power > /sys/class/platform-profile/platform-profile-
>>> 1/profile
>>>
>> I understand where you're coming from with this implementation but my
>> concern is this is making profiles more complicated - and they're
>> already becoming hard to understand (and debug) for users.
>>
>> I'm not a huge fan of multiple profile handlers, but can see why some
>> people might want them and that they're a valid tool to have
>> (especially given some of the limitations of what platform vendors
>> themselves implement).
>>
>> In patch #3 it states that 'It is the expectation that secondary
>> handlers will pick the closest profile they have to what was sent'.
>> I'm not convinced that is true, or desired.
>>
>> e.g. Quiet and low-power are different things and can have different
>> implementations. One is giving you as much power as possible with the
>> fans running below a certain audible level; and one is giving you a
>> system with as low-power consumption as possible, but still be
>> usable. They're admittedly not very different in practice - but they
>> can be different.
>>
>> Would it be better here to ask AMD to implement a quiet profile
>> (maybe it can be based on low-power, at least initially)?
>> I think that would solve the ASUS issue and not introduce another
>> layer of complexity.
>>
>> Mark
> Hi Mark,
>
> I've supported over 80 different ASUS laptops in the last 6 years or
> so, I can offer some insight.
>
> Across the entire range (TUF, ROG, Vivobook, Zen) which implements some
> form of "thermal throttle" as it is called in asus-wmi (which is what
> is used by platform_profile) the difference between low-power and quiet
> is very much nil - the "quiet" profile is only a name, and the TDP is
> limited along with fans to match - so the result is "low-power".
>
> As Mario suggests in his reply perhaps an alias would be best, or, as I
> was going to do, simply rename the "quiet" profile in asus-wmi to "low-
> power" as I already did but have not submitted yet due to a large train
> of patches in progress. It's a single line change and nullifies the
> entire issue and this series.
>
> In any case asus handling of platform profile is something I have been
> steadily working on for the last few months for both laptops and
> handhelds and I will have a new patch series coming soon (version 7 of
> previously submitted dealing with this).
>
> This submitted series is a NACK from me.
>
> Cheers,
> Luke.

I agree with you here, changing asus-wmi to using "low-power" would be an
appropriate quick fix here.

But i think the real solution to this is to extend tuned and platform-profiles-daemon
so that they use the new platform-profile class interface when available. This would
prevent such issues in the future.

Maybe someone can open an issue for both projects to notify them that an improved API
for controlling the platform-profiles is available?

Thanks,
Armin Wolf

On 2/24/2025 13:50, Antheas Kapenekakis wrote:
> On the Asus Z13 (2025), a device that would need the amd-pmf quirk that
> was removed on the platform_profile refactor, we see the following output
> from the sysfs platform profile:
> 
> $ cat /sys/firmware/acpi/platform_profile_choices
> balanced performance
> 
> I.e., the quiet profile is missing. Which is a major regression in terms of
> power efficiency and affects both tuned, and ppd (it also affected my
> software but I fixed that on Saturday). This would affect any laptop that
> loads both amd-pmf and asus-wmi (around 15 models give or take?).

To me this raises a fundamental question.  What is really different 
between quiet and low-power?  quiet just affects fan curves and 
low-power affects power?

One could argue that changing power will indirectly affect fan performance.

Because it makes me wonder if we really should just make them permanent 
aliases.

> 
> The problem stems from the fact that asus-wmi uses quiet, and amd-pmf uses
> low-power. While it is not clear to me what the amd-pmf module is supposed
> to do here, and perhaps some autodetection should be done and make it bail,
> if we assume it should be kept, then there is a small refactor that is
> needed to maintain the existing ABI interface.
> 
> This is the subject of this patch series.
> 
> Essentially, we introduce the concept of a "secondary" handler. Secondary
> handlers work exactly the same, except for the fact they are able to
> receive all profile names through the sysfs interface. The expectation
> here would be that the handlers choose the closest appropriate profile
> they have, and this is what I did for the amd-pmf handler.
> 
> In their own platform_profile namespace, these handlers still work normally
> and only accept the profiles from their probe functions, with -ENOSUP for
> the rest.
> 
> In the absence of a primary handler, the options of all secondary handlers
> are unioned in the legacy sysfs, which prevents them from hiding each
> other's options.
> 
> With this patch series applied, the sysfs interface will look like this:
> 
> $ cat /sys/firmware/acpi/platform_profile_choices
> quiet balanced performance
> 
> And writing quiet to it results in the profile being applied to both
> platform profile handlers.
> 
> $ echo low-power > /sys/firmware/acpi/platform_profile
> bash: echo: write error: Operation not supported
> $ echo quiet > /sys/firmware/acpi/platform_profile
> $ cat /sys/class/platform-profile/platform-profile-*/{name,profile}
> asus-wmi
> amd-pmf
> quiet
> quiet
> 
> Agreed ABI still works:
> $ echo quiet > /sys/class/platform-profile/platform-profile-0/profile
> $ echo quiet > /sys/class/platform-profile/platform-profile-1/profile
> bash: echo: write error: Operation not supported
> $ echo low-power > /sys/class/platform-profile/platform-profile-0/profile
> bash: echo: write error: Operation not supported
> $ echo low-power > /sys/class/platform-profile/platform-profile-1/profile
> 
> Antheas Kapenekakis (3):
>    ACPI: platform_profile: Add support for secondary handlers
>    ACPI: platform_profile: add all options to amd-pmf as a secondary
>      handler
>    ACPI: platform_profile: Do not hide options missing in secondary
>      handlers
> 
>   drivers/acpi/platform_profile.c    | 57 +++++++++++++++++++++++++-----
>   drivers/platform/x86/amd/pmf/spc.c |  3 ++
>   drivers/platform/x86/amd/pmf/sps.c |  8 +++++
>   include/linux/platform_profile.h   |  7 ++++
>   4 files changed, 67 insertions(+), 8 deletions(-)
>