[FROM-UPSTREAM] platform/x86: asus-armoury: fix mini-LED mode get/set on MO…#56
[FROM-UPSTREAM] platform/x86: asus-armoury: fix mini-LED mode get/set on MO…#56Ghoul4500 wants to merge 1 commit into
Conversation
|
Needs a rebase on the ogc7.y branch |
Ghoul4500
force-pushed
the
asus-armoury-fix-mini-led
branch
from
ceba7cc to
c2f2d9b
Compare
… on MODE2 devices
The mini-LED current_value attribute does not work on devices that use
ASUS_WMI_DEVID_MINI_LED_MODE2 (2024 and newer models).
Reading is broken: mini_led_mode_current_value_show() fetches the mode
from the device but then decodes a literal 0 instead of the value it
just read:
mode = FIELD_GET(ASUS_MINI_LED_MODE_MASK, 0);
So mode is always 0, and the attribute always reports the same thing
regardless of the real hardware state.
Writing is broken too. The number a user writes is an index; the value
the firmware actually wants is looked up from that index in
mini_led_mode_map[]. mini_led_mode_current_value_store() skips that
lookup and passes the raw index straight to armoury_attr_uint_store().
On 2024 devices the firmware numbers its modes differently from the
index, so some writes are rejected with -EINVAL and the rest send the
wrong mode to the hardware.
Fix both paths: decode the value actually read from the device when
reading, and look up the firmware value before sending it when
writing. Older (MODE1) devices were unaffected because there the index
and the firmware value are the same.
Fixes: f99eb09 ("platform/x86: asus-armoury: move existing tunings
to asus-armoury module")
Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
Ghoul4500
changed the title
Ghoul4500
force-pushed
the
asus-armoury-fix-mini-led
branch
from
c2f2d9b to
6bd42f9
Compare
|
Updated patch title and description (transition from FROM-ML to FOR-UPSTREAM and include cherry-picked commit SHA from upstream and link) |
|
What is going on, how are patches being included without being merged? Is someone bypassing the .y branch and cherry picking to manually created versions? |
This specific patch was not cherry-picked into the 7.0.12 branch @hphilm was working on. This was merged upstream and is now available in mainline linux stable 7.0.11. #52 appears to have been cherry-picked though. BUt IDK what's going on either |
|
I renamed both |
4 participants
platform/x86: asus-armoury: fix mini-LED mode get/set on MODE2 devices
The mini-LED current_value attribute does not work on devices that use
ASUS_WMI_DEVID_MINI_LED_MODE2 (2024 and newer models).
Reading is broken: mini_led_mode_current_value_show() fetches the mode
from the device but then decodes a literal 0 instead of the value it
just read:
So mode is always 0, and the attribute always reports the same thing
regardless of the real hardware state.
Writing is broken too. The number a user writes is an index; the value
the firmware actually wants is looked up from that index in
mini_led_mode_map[]. mini_led_mode_current_value_store() skips that
lookup and passes the raw index straight to armoury_attr_uint_store().
On 2024 devices the firmware numbers its modes differently from the
index, so some writes are rejected with -EINVAL and the rest send the
wrong mode to the hardware.
Fix both paths: decode the value actually read from the device when
reading, and look up the firmware value before sending it when
writing. Older (MODE1) devices were unaffected because there the index
and the firmware value are the same.
Link: https://patch.msgid.link/20260517182957.11069-1-yaseen@ghoul.dev
Cherry-picked from commit d2d2e7c
Fixes: f99eb09 ("platform/x86: asus-armoury: move existing tunings to asus-armoury module")
Signed-off-by: Ahmed Yaseen yaseen@ghoul.dev