Re: [PATCH 0/2] asus-armoury: gate PPT writes on active fan curves

From: Ahmed Yaseen

Date: Wed May 13 2026 - 11:01:10 EST


On 12/05/2026 20:14, Derek J. Clark wrote:
> On May 10, 2026 11:19:14 PM PDT, Ahmed Yaseen <yaseen@xxxxxxxxx> wrote:
>> My first kernel patch series, posted in agreement with Denis Benato (Cc'd).
>>
>> On 28 ASUS ROG laptop models flagged with requires_fan_curve in the
>> asus-armoury DMI power_data table, the BIOS ACPI method SPLX silently
>> discards Package Power Tracking (PPT) writes unless the fan mode is
>> set to Manual (FANM=4). FANM is set to 4 by the DEFC method when a
>> custom fan curve is written. Until then, the WMI DEVS call returns
>> success but the firmware ignores the value, so userspace sees no
>> effect from writes to ppt_pl1_spl, ppt_pl2_sppt, ppt_pl3_fppt,
>> ppt_apu_sppt or ppt_platform_sppt.
>>
>
> This very nearly touches on an issue that has been present in the asus_armoury driver for a while, and presents a possible avenue to correct it. When originally adding PPT adjustments it was discussed that doing so should be gated under the "custom" platform profile [1]. This was simple to do for the Lenovo WMI drivers because that interface includes a BIOS custom mode and requires it to be set for PPT settings to take effect. This soft "requirement" was missed when asus_armoury was accepted, and it currently allows PPT settings to override manufacturer intent. Please correct me if I'm wrong, but I believe the fan curves associated in BIOS for low-power, balanced, and performance will not automatically adjust if a user changes the TDP outside of the window. I.e. setting low power and then maximum SPL would leave the fans in a quiet mode.
>
> Since some devices require this bit to be set, it seems like a good opportunity to gate the platform profile under custom, and use custom to set the performance mode and this bit, then allow userspace to set the curve and ppt values.
>
> Adding Mario to CC for his SA/comments on this proposal.
>
> - Derek
>
>
> 1: https://lore.kernel.org/platform-driver-x86/20241206031918.1537-17-mario.limonciello@xxxxxxx/

About the PPT settings overriding manufacturer intent, I believe this is
a misunderstanding. I believe Derek is pointing at how currently PPT
adjustments for these models appear to apply without a custom fan curve
while manufacturer intends for the TDP to only be adjustable with a
custom fan curve applied. To clarify, for the modules that require a
custom fan curve, TDP value adjustments are currently being completely
ignored by the BIOS because the requirement for the existence of a fan
curve prevents it at a hardware level. Meanwhile on the kernel side of
things, it would appear that TDP values are actually being set, while it
is actually ignored. This is the reason for my gating custom TDP values
behind requires_fan_curve for models that require it. Please correct me
if i am understanding the previous message incorrectly though.

As for the other issue mentioned (if a user were to choose low power and
set maximum SPL), this is an issue I was not able to properly recreate.
I have attempted to do this but on my device at least, a custom TDP
cannot be set without a custom fan curve. Even in low power mode, I am
able to ramp my fans up to 100% with a custom fan curve and increasing
TDP knobs works perfectly and my fans are loud as expected. It may be
the case that due to the bug I mentioned earlier, TDP was possible to
visually max out without a custom fan curve while being in quiet mode.

However, on an older device that doesn't require a custom fan curve for
TDP might behave as Derek mentioned, as there is no hardware level
enforcement for the user to take over the fan curve before changing TDP.
I am unable to test this as I do not have such a device, but I believe
this is how the device's design is. The user can simply use custom fan
curves if their device supports it in this case. Instead, there are
min-max power limits for each power profile defined for these to prevent
damage.

As for the proposal to implement a 'custom' power profile, I believe
this needs more discussion. Unlike Lenovo, ASUS does not have this as a
native option in the BIOS, Instead ASUS ships 4 fan modes (Quiet,
Balanced, Performance, Custom) which we are already using. The long term
plan I have in mind for this is that the custom fan curve can be applied
separately to all 3 performance profiles, saved somewhere, and switched
between them by the user.

So while I can see a lot of things becoming cleaner if a custom fan mode
mapped directly to a custom power profile, too many issues come together
with it. For instance, would this new custom mode use Performance,
Balanced, or Quiet as a baseline? what about the TDP value limits that
differ per profile according to Asus Armoury Crate in Widnows? it also
causes more complications for some users that only decrease TDP to
reduce power consumption as they will then also be switched to a custom
mode by the kernel which would now apply a custom fan curve which also
needs us to create defaults for these. In the case of Lenovo, the BIOS
likely ships with these baselines per device but this is not applicable
in our case.

If we can discuss this custom mode in more depth and the pros outweigh
the cons, I believe we can discuss this for a follow-up patch

- Ahmed Yaseen

>
>> The requires_fan_curve flag has existed in the per-model power_data
>> entries for some time but was never read. This series wires it up:
>>
>> Patch 1: Adds the actual gate. Exports
>> asus_wmi_custom_fan_curve_is_enabled() from asus-wmi so
>> asus-armoury can query fan-curve state across module boundaries,
>> and returns -ENODEV with a pr_warn() from the PPT write path on
>> affected models when no fan curve is active.
>>
>> Patch 2: Exposes the same flag to userspace as a read-only sysfs
>> attribute (requires_fan_curve) so tools like asusctl and rogcc
>> can surface the prerequisite to the user before issuing PPT
>> writes. Documented in
>> Documentation/ABI/testing/sysfs-class-firmware-attributes.
>>
>> Testing:
>> Verified on G835LW (ROG Strix SCAR 18 2025, requires_fan_curve=true):
>> - With no fan curve active, writes to ppt_pl1_spl return -ENODEV
>> and the cached value is unchanged.
>> - With pwm1_enable=1 on /sys/class/hwmon/.../asus_custom_fan_curve,
>> PPT writes succeed and readback matches.
>> - The pr_warn fires exactly once per rejected write.
>>
>> I do not have access to the other 27 affected models. Testers from
>> any of these would be appreciated: FX507VI, FX507VV, FX507Z,
>> GA402X, GA403UI, GA403UV, GA403WM, GA403WR, GA403WW, GA605W,
>> GU605CR, GU605CW, GU605CX, GU605M, G513I, G513QM, G513QY, G513R,
>> G614J, G615LR, G634J, G713PV, G733C, G733P, G814J, G834J, G835LR.
>>
>> Ahmed Yaseen (2):
>> platform/x86: asus-armoury: gate PPT writes behind active fan curve
>> platform/x86: asus-armoury: expose requires_fan_curve via sysfs
>>
>> .../testing/sysfs-class-firmware-attributes | 25 +++++++++++++
>> drivers/platform/x86/asus-armoury.c | 35 +++++++++++++++++++
>> drivers/platform/x86/asus-wmi.c | 28 +++++++++++++++
>> include/linux/platform_data/x86/asus-wmi.h | 5 +++
>> 4 files changed, 93 insertions(+)
>>
>