fix(asusd): apply PPT limits on set even without ppt_enabled attribute#150
Open
IoriAkatsuki wants to merge 1 commit into
Open
fix(asusd): apply PPT limits on set even without ppt_enabled attribute#150IoriAkatsuki wants to merge 1 commit into
IoriAkatsuki wants to merge 1 commit into
Conversation
PPT (ppt_pl1_spl/ppt_pl2_sppt) writes were silently discarded on kernels where asus-armoury does not expose a `ppt_enabled` firmware attribute. The per-profile Tuning.enabled flag gates whether PPT values are written to sysfs, but nothing ever sets it to true when ppt_enabled is absent, so tuning could never be enabled and every set was skipped. The PPT current_value getter also returned the cached config value instead of the real sysfs value, masking the failure (get reports success, hardware unchanged). - set_current_value: auto-enable the profile's tuning on an explicit PPT set so the value is actually written to hardware. - current_value: read the real value from sysfs instead of the cache.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Fixes PPT (
ppt_pl1_spl/ppt_pl2_sppt) writes being silently discarded on kernels without appt_enabledfirmware attribute. Fixes #149.Why
set_current_valuegates PPT sysfs writes on the per-profileTuning.enabledflag, but nothing sets that flag totruewhen theppt_enabledattribute is absent (it is never registered because the sysfs node does not exist). Result: tuning can never be enabled, PPT writes are always skipped, and thecurrent_valuegetter returns the cached config value — soget/ the GUI report success while the hardware limit is unchanged.Changes (
asusd/src/asus_armoury.rs)set_current_value(Ppt): auto-enable the profile's tuning group on an explicit set, so the value is actually written to hardware. This is the only sensible enable path whenppt_enabledis unavailable.current_value(Ppt): read the real value from sysfs instead of the cached config value, so tools report the true state.Testing
On G634JZ (i9-13980HX), kernel 7.1.2, asus-armoury without
ppt_enabled:asusctl armoury set ppt_pl1_spl 65→ sysfs stays140.ppt_pl1_spl/current_value==65; switching profiles now applies per-profile PPT (Quiet 65/95, Balanced 100/120, Performance 140/175), verified by reading the sysfs node directly.cargo build --release -p asusdclean.Open question
Auto-enabling on an explicit set slightly changes semantics for setups where
ppt_enableddoes exist (there the GUI toggle stays authoritative and can still disable afterward). Happy to gate this behind "only when noppt_enabledattribute is present" if you prefer a more conservative fix.