PPT is set through the deprecated asus_wmi sysfs path

[deepu105]

I've been running z13ctl on a GZ302EA and noticed the PPT writes go through the old asus_wmi platform path, which the kernel now warns is on its way out.

On kernel 7.1.11 I get this at every boot:

asus_wmi: Accessing attributes through /sys/bus/platform/asus_wmi is deprecated
and will be removed in a future release. Please switch over to
/sys/class/firmware_attributes.

The practical effect today is that the two interfaces disagree. After z13ctl tdp --set 45:

# what z13ctl writes
/sys/devices/platform/asus-nb-wmi/ppt_pl1_spl      45
/sys/devices/platform/asus-nb-wmi/ppt_pl2_sppt     45
/sys/devices/platform/asus-nb-wmi/ppt_fppt         45

# what asus-armoury reports
.../asus-armoury/attributes/ppt_pl1_spl/current_value    60
.../asus-armoury/attributes/ppt_pl2_sppt/current_value   75
.../asus-armoury/attributes/ppt_pl3_fppt/current_value   86

The armoury values are just the firmware defaults and never move. z13ctl's writes do take effect behaviourally, so nothing is broken for me right now, but anything else on the system reading the newer interface sees stale numbers. And once the deprecated path is actually removed, TDP control stops working.

The newer interface looks like a drop-in target. All three attributes are there, current_value is writable (0644), and each one exposes bounds so they don't need hardcoding:

ppt_pl1_spl    current=60  default=60  min=28  max=80
ppt_pl2_sppt   current=75  default=75  min=32  max=92
ppt_pl3_fppt   current=86  default=86  min=45  max=93

One naming gotcha: ppt_fppt on the old path maps to ppt_pl3_fppt on the new one.

Is this already on your radar? Happy to test a branch on a GZ302EA, or put together a PR that prefers /sys/class/firmware-attributes/asus-armoury/ and falls back to the old path when it isn't present.

Versions: z13ctl 1.3.2, kernel 7.1.11, asus_wmi BIOS WMI version 9.4.

[deepu105]

Following up on my own report, because the line "z13ctl's writes do take effect behaviourally" was wrong and I would rather correct it than let someone build on it.

I went back and measured properly, with a 27B model saturating the iGPU so the SoC is actually pinned against its ceiling. Reading a value back from sysfs proves only that it was stored, which is the mistake I made the first time. Every number below is an 8 second average taken after a 12 to 20 second settle, read from /sys/class/drm/card*/device/hwmon/hwmon*/power1_input.

The short version: below 75 W the PPT write does nothing at all. Above 75 W it works, and it overrides platform_profile.

profile + command	measured
quiet + tdp --set 30	35.2 W	inert
quiet + tdp --set 90 --force	88.0 W	overrides the profile upward
performance + tdp --set 70	63.3 W	inert
performance + tdp --set 30	61.0 W	inert, cannot lower
performance + tdp --set 75	60.1 W	inert
performance + tdp --set 76 --force	75.8 W	binds

The last two rows are the cleanest evidence. 75 W versus 76 W is a 1.3% difference in what I asked for, and it moved real package power by 15.7 W. So it is not the number that matters, it is crossing the 75 W threshold where z13ctl switches to the --force path and rewrites the fan curve first.

What actually sets the ceiling is platform_profile:

quiet        35.0 W
balanced     49.6 W
performance  63.3 W   (enters at 66.8 W, decays as the die heats)

Those transitions land inside a single 2 second sample, and quiet holds 35 W at 78C while performance runs 94C on the same workload, so they are power caps and not thermal limits.

One more correction to my original report: the asus-armoury attributes do not bind either. ppt_pl1_spl read 60 through all six tests, including the one that drew 88 W. I assumed those values were authoritative because they matched the firmware defaults. They are simply inert, so the interface split I described is real but neither side of it is in control.

Practical impact:

• z13ctl tdp --set N for any N up to 75 is silently ignored. The command succeeds, z13ctl tdp --get and z13ctl status both report N, and nothing changed.
• z13ctl tdp cannot lower power below the current profile at any value.
• Anyone using z13ctl tdp to hold the SoC under a power budget is getting no protection from it. That was my use case: a 100 W USB-C charger that latches off above a certain sustained draw, where I had been setting a low TDP and assuming it did something.

I have not worked out whether the fix belongs in z13ctl or whether the kernel driver is dropping the write, so I am not going to guess at a patch. Happy to run anything you want on a GZ302EA, including a debug build that logs the actual WMI calls.

The test harness is a plain shell script that sets each profile and TDP pair, waits for the SMU to settle, then averages power over 8 seconds. I can attach it or open a PR adding it under a scripts directory if that is useful.

Versions: z13ctl 1.3.2 (current release), kernel 7.1.11, asus_wmi BIOS WMI version 9.4.