Summary
On kernels where the asus-armoury driver does not expose a ppt_enabled firmware attribute, setting PPT limits (ppt_pl1_spl / ppt_pl2_sppt) via asusctl or rog-control-center is silently discarded. The tools report success and even read back the requested value, but the hardware limit never changes.
Environment
- asusctl/asusd 6.3.8
- Board: ROG Strix SCAR 17 (G634JZ), i9-13980HX
- Kernel 7.1.2 (mainline asus-armoury class, ≥6.19),
asus_armoury loaded
/sys/class/firmware-attributes/asus-armoury/attributes/ exposes ppt_pl1_spl, ppt_pl2_sppt but no ppt_enabled
Steps to reproduce
$ cat /sys/class/firmware-attributes/asus-armoury/attributes/ppt_pl1_spl/current_value
140
$ asusctl armoury set ppt_pl1_spl 65 # reports success
$ asusctl armoury get ppt_pl1_spl # shows 65 (misleading)
$ cat /sys/class/firmware-attributes/asus-armoury/attributes/ppt_pl1_spl/current_value
140 # <-- unchanged, the write was dropped
Root cause (asusd/src/asus_armoury.rs)
set_current_value for a Ppt attribute only writes to sysfs when the current profile's Tuning.enabled == true; otherwise it logs Tuning is disabled: skipping ... and stores the value in config only.
- The only thing that flips
Tuning.enabled to true is the ppt_enabled firmware attribute. When the kernel does not expose a ppt_enabled sysfs node, that attribute is never registered, and there is no other code path setting tuning.enabled = true. So tuning stays disabled forever and every PPT write is skipped. (/etc/asusd/asusd.ron shows enabled: false for all profiles.)
current_value for Ppt returns the cached config value (or default) instead of reading sysfs, so get / the GUI report the requested value even though the firmware was never changed — which masks the failure.
Impact
Any board using mainline asus-armoury without a ppt_enabled node cannot change CPU TDP through asusctl / rog-control-center, and receives misleading "success" feedback.
Fix
PR incoming — auto-enable the profile's tuning on an explicit PPT set, and make the PPT getter read the real sysfs value.
Summary
On kernels where the
asus-armourydriver does not expose appt_enabledfirmware attribute, setting PPT limits (ppt_pl1_spl/ppt_pl2_sppt) viaasusctlor rog-control-center is silently discarded. The tools report success and even read back the requested value, but the hardware limit never changes.Environment
asus_armouryloaded/sys/class/firmware-attributes/asus-armoury/attributes/exposesppt_pl1_spl,ppt_pl2_spptbut noppt_enabledSteps to reproduce
Root cause (
asusd/src/asus_armoury.rs)set_current_valuefor aPptattribute only writes to sysfs when the current profile'sTuning.enabled == true; otherwise it logsTuning is disabled: skipping ...and stores the value in config only.Tuning.enabledtotrueis theppt_enabledfirmware attribute. When the kernel does not expose appt_enabledsysfs node, that attribute is never registered, and there is no other code path settingtuning.enabled = true. So tuning stays disabled forever and every PPT write is skipped. (/etc/asusd/asusd.ronshowsenabled: falsefor all profiles.)current_valueforPptreturns the cached config value (or default) instead of reading sysfs, soget/ the GUI report the requested value even though the firmware was never changed — which masks the failure.Impact
Any board using mainline asus-armoury without a
ppt_enablednode cannot change CPU TDP through asusctl / rog-control-center, and receives misleading "success" feedback.Fix
PR incoming — auto-enable the profile's tuning on an explicit PPT set, and make the PPT getter read the real sysfs value.