[Bug 222044] hp-wmi: Mute and mic-mute LEDs not supported on HP Laptop 15-fc0xxx (board 8DC9)

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=222044

--- Comment #9 from Piyush (neonblade018@proton.me) ---
A bit more technical detail on what happened during the test:

In the current tree, `ALC236_FIXUP_HP_DMIC` already had `.chained = true`
pointing further down the fixup chain (to `ALC269_FIXUP_THINKPAD_ACPI` /
standard HP fixup defaults). Because of this:
1. Adding `.chained = true` and `.chain_id =
ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO` directly inside `ALC236_FIXUP_HP_DMIC`
broke or orphaned the downstream chain that the driver was already following.
2. In the existing quirk table, our SSID (`103c:8b2f`) was mapped directly to
`ALC236_FIXUP_HP_DMIC`. When chaining was redirected, there was a collision
between preserving the DMIC pin configuration (`0x12 -> 0x90a60160`) and
pulling in both the speaker mute COEF and GPIO 0 mic-mute LED handling.

To resolve the conflict cleanly:
Instead of terminating or clobbering the chain at `ALC236_FIXUP_HP_DMIC`, we
linked `ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO` into the chain sequence while
keeping the pin table intact. 

Once chained through in that order:
- `hda::mute` and `hda::micmute` registered immediately under
`/sys/class/leds/`.
- Both LEDs auto-bound to native kernel triggers (`[audio-mute]` and
`[audio-micmute]`) and respond in hardware.
- The AMD ACP6x internal digital mic array remains fully functional without pin
table regression.

If you are preparing an upstream patch, making
`ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO` part of that sequential chain (or
chaining one into the other rather than replacing the existing tail) is the
exact way to do it.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.