* [PATCH AUTOSEL 6.19-6.18] ASoC: amd: acp: add ASUS HN7306EA quirk for legacy SDW machine
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-5.10] ALSA: asihpi: avoid write overflow check warning Sasha Levin
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Hasun Park, Mark Brown, Sasha Levin, Vijendar.Mukunda, lgirdwood,
perex, tiwai, linux-sound, linux-kernel
From: Hasun Park <hasunpark@gmail.com>
[ Upstream commit 2594196f4e3bd70782e7cf1e22e3e398cdb74f78 ]
Add a DMI quirk entry for ASUS HN7306EA in the ACP SoundWire legacy
machine driver.
Set driver_data to ASOC_SDW_ACP_DMIC for this board so the
platform-specific DMIC quirk path is selected.
Signed-off-by: Hasun Park <hasunpark@gmail.com>
Link: https://patch.msgid.link/20260319163321.30326-1-hasunpark@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================
**Step 1.1: Subject Line**
Record: [ASoC: amd: acp] [add] [DMI quirk for ASUS HN7306EA to select
ACP DMIC path in legacy SoundWire machine driver]
**Step 1.2: Tags**
Record:
- `Signed-off-by: Hasun Park <hasunpark@gmail.com>` — author/contributor
- `Link:
https://patch.msgid.link/20260319163321.30326-1-hasunpark@gmail.com` —
patch submission
- `Signed-off-by: Mark Brown <broonie@kernel.org>` — ASoC subsystem
maintainer
- No Fixes: tag (expected for hardware quirk additions)
- No Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc: stable
(absence expected)
**Step 1.3: Body**
Record: The commit explains it adds a DMI quirk entry for the ASUS
HN7306EA board and sets `driver_data` to `ASOC_SDW_ACP_DMIC` so the
platform-specific DMIC quirk path is selected. Without this quirk, the
board's built-in digital microphone will not be enabled through the ACP
SoundWire path. No stack traces, crash reports, or version information
given — this is standard for a board-specific quirk addition.
**Step 1.4: Hidden Bug Fix**
Record: Yes — while framed as "add," this is a hardware enablement fix.
Without the quirk, the DMIC path is not selected, and the microphone
does not function on this specific laptop. Adding board-specific DMI
quirks is the standard Linux mechanism for making specific hardware work
correctly.
===============================================================
PHASE 2: DIFF ANALYSIS
===============================================================
**Step 2.1: Inventory**
Record: 1 file modified: `sound/soc/amd/acp/acp-sdw-legacy-mach.c`, +8
lines, 0 removed. Only the static `soc_sdw_quirk_table[]` data array is
extended with one new entry before the `{}` terminator. Scope: single-
file, single-table-entry, trivially scoped.
**Step 2.2: Code Flow Change**
Record: Before: No DMI match for "ASUSTeK COMPUTER INC." / "HN7306EA" →
the global `soc_sdw_quirk` stays at its default `RT711_JD1` → DMIC path
not selected at line 419. After: DMI match sets `soc_sdw_quirk =
ASOC_SDW_ACP_DMIC` via `soc_sdw_quirk_cb()` → at line 419,
`soc_sdw_quirk & ASOC_SDW_ACP_DMIC` is true → `dmic_num = 1` →
`create_dmic_dailinks()` is called at line 454, enabling the built-in
digital microphone.
Verified code path from file:
```419:420:sound/soc/amd/acp/acp-sdw-legacy-mach.c
if (soc_sdw_quirk & ASOC_SDW_ACP_DMIC || mach_params->dmic_num)
dmic_num = 1;
```
```450:457:sound/soc/amd/acp/acp-sdw-legacy-mach.c
if (dmic_num > 0) {
if (ctx->ignore_internal_dmic) {
dev_warn(dev, "Ignoring ACP DMIC\n");
} else {
ret = create_dmic_dailinks(card, &dai_links,
&be_id, 0);
if (ret)
return ret;
}
```
**Step 2.3: Bug Mechanism**
Record: Category: Hardware workaround / DMI quirk table entry. The board
requires `ASOC_SDW_ACP_DMIC` to be set so the DMIC DAI link is created.
Without it, the standard default (`RT711_JD1`) does not enable the DMIC
path.
**Step 2.4: Fix Quality**
Record: Obviously correct — follows the exact same struct pattern as
every other entry in the table (AMD, Dell, Lenovo). Minimal and
surgical: 8 lines of pure static data. Zero regression risk for other
machines: only fires when both `DMI_BOARD_VENDOR == "ASUSTeK COMPUTER
INC."` AND `DMI_PRODUCT_NAME == "HN7306EA"` match.
===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================
**Step 3.1: Blame**
Record: `git blame` confirms the quirk table was introduced by
`2981d9b0789c44` (Vijendar Mukunda, 2024-11-13, "ASoC: amd: acp: add
soundwire machine driver for legacy stack") with just one entry (AMD
Birman-PHX). Dell entries added by `4bb5b6f13fd83b` (2025-02-07) and
`3254959b4dd065` (2025-09-03). Lenovo entries added by `aa7b7452bb742f`
(2026-02-18). The infrastructure for `ASOC_SDW_ACP_DMIC` and the DMIC
path has existed since the driver was created.
**Step 3.2: Fixes Tag**
Record: No Fixes: tag present — not applicable for a quirk addition.
**Step 3.3: File History**
Record: 13 commits to this file since creation. Other DMI quirk
additions (Dell, Lenovo) follow the identical pattern. This ASUS commit
is standalone — not part of a series.
**Step 3.4: Author**
Record: `git log --author='Hasun Park'` returns empty for
`sound/soc/amd/` — this appears to be an external contributor (likely
owns the hardware). The patch was merged by Mark Brown, the ASoC
subsystem maintainer, which is a strong quality endorsement.
**Step 3.5: Dependencies**
Record: No dependencies. The `ASOC_SDW_ACP_DMIC` constant (`BIT(5)` in
`soc_amd_sdw_common.h`), the `soc_sdw_quirk_cb` callback, and the DMIC
path all exist since the driver's introduction in v6.13. Fully self-
contained.
===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================
**Step 4.1-4.4:** Record: The `Link:` tag provides the patch message ID.
Direct access to lore.kernel.org and patch.msgid.link was blocked by bot
protection (Anubis). The patch was merged by Mark Brown directly. No
NAKs or concerns are evidenced (the commit reached mainline). Could not
verify explicit stable nominations or review comments from primary
sources.
===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================
**Step 5.1: Key Functions**
Record: No function bodies modified — only the `soc_sdw_quirk_table[]`
static data. Consumers: `soc_sdw_quirk_cb()`, `mc_probe()`,
`soc_card_dai_links_create()`, `create_dmic_dailinks()`.
**Step 5.2: Callers**
Record: `soc_sdw_quirk_table` is consumed by `dmi_check_system()` at
line 498 in `mc_probe()`, the platform driver `.probe` callback.
`mc_probe()` is registered via `soc_sdw_driver` (line 570) matching
platform device ID `"amd_sdw"`.
**Step 5.3: Callees**
Record: `soc_sdw_quirk_cb()` (line 35) simply assigns `soc_sdw_quirk =
(unsigned long)id->driver_data`. Downstream,
`soc_card_dai_links_create()` checks the bit at line 419 and
conditionally enables DMIC DAI link creation.
**Step 5.4: Call Chain**
Record: PCI probe → `acp63_machine_register()` →
`platform_device_register_data(..., "amd_sdw", ...)` → `mc_probe()` →
`dmi_check_system(soc_sdw_quirk_table)` → `soc_card_dai_links_create()`
→ DMIC enabled if `ASOC_SDW_ACP_DMIC` set. Reachable automatically on
boot for matching AMD SoundWire hardware.
**Step 5.5: Similar Patterns**
Record: `acp-sdw-sof-mach.c` has an analogous `ASOC_SDW_ACP_DMIC` gating
mechanism (lines 29, 312), confirming this is an established subsystem
pattern. The same quirk table pattern is used for Dell and Lenovo
entries in the same file.
===============================================================
PHASE 6: STABLE TREE ANALYSIS
===============================================================
**Step 6.1: File Existence in Stable Trees**
Record: Verified via `git cat-file -e`:
- `stable/linux-6.6.y`: **MISSING** (driver not present)
- `stable/linux-6.12.y`: **MISSING** (driver not present)
- `stable/linux-6.13.y`: **EXISTS** (3 commits to file — base + Dell
quirks)
- `stable/linux-6.14.y`: **EXISTS** (3 commits to file — base + Dell
quirks)
- `stable/linux-6.19.y`: **EXISTS** (13 commits — all quirks including
Lenovo)
The driver and `ASOC_SDW_ACP_DMIC` infrastructure exist in **6.13.y,
6.14.y, and 6.19.y**.
**Step 6.2: Backport Complications**
Record: The patch inserts one entry before the `{}` terminator in
`soc_sdw_quirk_table[]`. In 6.13.y and 6.14.y, the table has fewer
entries (no Lenovo rows), so there will be a minor context offset, but
the append-before-terminator pattern makes this trivially applicable.
Expected: clean apply or trivial context adjustment in all three stable
trees.
**Step 6.3: Related Fixes in Stable**
Record: No HN7306EA-specific fix exists in any stable tree. Other
Dell/Lenovo quirks have been backported to various stable trees,
confirming this class of change is accepted.
===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================
**Step 7.1: Subsystem**
Record: `sound/soc/amd/acp` — ASoC AMD Audio Co-Processor SoundWire
machine driver. Criticality: IMPORTANT — audio is a critical user-facing
function on laptops, though this is driver/platform-specific, not
universal.
**Step 7.2: Activity**
Record: Actively maintained — 13 commits to this single file since
creation, with regular quirk additions for Dell, Lenovo, and now ASUS.
Mark Brown (ASoC maintainer) actively merges patches.
===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================
**Step 8.1: Affected Users**
Record: Device-specific — owners of the ASUS HN7306EA (ProArt PX13)
laptop running kernel 6.13+ with the AMD SoundWire audio stack.
**Step 8.2: Trigger Conditions**
Record: Triggers on every boot during driver probe via
`dmi_check_system()`. Every user of this laptop model is affected. No
special configuration or user action required.
**Step 8.3: Failure Mode**
Record: Without the quirk, the built-in digital microphone is not
enabled (the DMIC DAI link is never created). This is a "hardware
doesn't work" issue — microphone non-functional. Severity: MEDIUM-HIGH
for affected users (broken audio input on a laptop is a significant
usability issue).
**Step 8.4: Risk-Benefit Ratio**
Record:
- BENEFIT: High for affected users — enables the laptop's built-in
microphone
- RISK: Essentially zero — DMI match table entry only triggers on exact
vendor+product match; 8 lines of pure static data; uses existing
infrastructure; well-established pattern
- Ratio: Strongly favorable
===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================
**Step 9.1: Evidence**
FOR backporting:
- Classic hardware DMI quirk addition — explicitly listed as an allowed
exception category
- 8 lines, single file, pure static data addition, trivially correct
- Zero regression risk — only affects boards matching exact DMI strings
- Fixes real user issue: broken DMIC (microphone non-functional) on ASUS
HN7306EA
- Merged by ASoC subsystem maintainer Mark Brown
- Self-contained with no dependencies
- Infrastructure exists in 6.13.y, 6.14.y, and 6.19.y stable trees
- Same pattern as Dell and Lenovo quirks already backported to stable
trees
AGAINST backporting:
- Only affects a single laptop model (normal for quirks — not a valid
concern)
- Not a crash/security/corruption fix (but hardware enablement quirks
are an explicit exception)
UNRESOLVED:
- Could not access lore.kernel.org to verify mailing list review
discussion
- No primary end-user bug report verified (author is likely the affected
user)
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivial table entry following
exact same pattern as all existing entries; merged by maintainer
2. Fixes a real bug? **YES** — broken DMIC on ASUS HN7306EA
3. Important issue? **YES** — non-functional microphone on a shipping
laptop
4. Small and contained? **YES** — 8 lines, one file, one table entry
5. No new features or APIs? **YES** — just a DMI quirk data entry using
existing code paths
6. Can apply to stable? **YES** — applicable to 6.13.y, 6.14.y, 6.19.y
with clean or trivial context adjustment
**Step 9.3: Exception Category**
Record: **Hardware quirk/workaround** — This is a DMI quirk table entry
for a specific laptop, which is the textbook example of a stable-
appropriate exception. Dell and Lenovo quirks from the same table have
already been backported.
**Step 9.4: Decision**
This is a trivial, zero-risk DMI quirk table entry that enables the
built-in digital microphone on a specific ASUS laptop model. It falls
squarely into the "hardware quirks and workarounds" exception category
that is explicitly allowed in stable. The fix is 8 lines of pure static
data, uses existing infrastructure, and only affects the exact matching
hardware. The driver and `ASOC_SDW_ACP_DMIC` infrastructure exist in
stable trees 6.13.y, 6.14.y, and 6.19.y.
## Verification
- [Phase 1] Parsed commit message: "add ASUS HN7306EA quirk," tags
include author SOB and Mark Brown (maintainer) SOB, Link to patch
- [Phase 2] Read `acp-sdw-legacy-mach.c`: verified `ASOC_SDW_ACP_DMIC`
check at line 419 enables `dmic_num = 1`, which triggers
`create_dmic_dailinks()` at line 454
- [Phase 2] Grep for `ASOC_SDW_ACP_DMIC`: found at line 29 (log_quirks),
line 419 (DMIC enablement), and `soc_amd_sdw_common.h` line 28
(`BIT(5)`)
- [Phase 3] `git blame` lines 41-115: confirmed table origin commit
`2981d9b0789c44` (2024-11-13), Dell quirks from `4bb5b6f13fd83b` and
`3254959b4dd065`, Lenovo from `aa7b7452bb742f`
- [Phase 3] `git show 2981d9b0789c44`: confirmed original driver
introduction creating `acp-sdw-legacy-mach.c` (486 lines)
- [Phase 3] `git log --author='Hasun Park'`: no prior commits found in
`sound/soc/amd/`
- [Phase 3] `git log --oneline -20`: confirmed 13 commits to file, all
quirk additions and driver evolution, no prerequisites for this patch
- [Phase 5] Traced call chain in code: `mc_probe()` line 498 calls
`dmi_check_system(soc_sdw_quirk_table)`, then line 514 calls
`soc_card_dai_links_create()`, which checks quirk at line 419
- [Phase 5] Grep confirmed analogous `ASOC_SDW_ACP_DMIC` pattern in
`acp-sdw-sof-mach.c` (established subsystem pattern)
- [Phase 6] `git cat-file -e` across stable trees: file MISSING in 6.6.y
and 6.12.y; EXISTS in 6.13.y, 6.14.y, 6.19.y
- [Phase 6] `git log stable/linux-6.13.y`: 3 commits (base + Dell
quirks); `stable/linux-6.14.y`: 3 commits; `stable/linux-6.19.y`: 13
commits (includes Lenovo)
- [Phase 6] Clean apply expected in all three applicable stable trees —
trivial table entry append
- [Phase 8] Failure mode verified from code: without quirk,
`ASOC_SDW_ACP_DMIC` not set → `dmic_num` stays 0 →
`create_dmic_dailinks()` not called → DMIC non-functional
- UNVERIFIED: Could not access lore.kernel.org or patch.msgid.link
(blocked by Anubis bot protection) — no reviewer discussion or NAKs
verified
**YES**
sound/soc/amd/acp/acp-sdw-legacy-mach.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/sound/soc/amd/acp/acp-sdw-legacy-mach.c b/sound/soc/amd/acp/acp-sdw-legacy-mach.c
index 4f92de33a71a0..2e0f751afe250 100644
--- a/sound/soc/amd/acp/acp-sdw-legacy-mach.c
+++ b/sound/soc/amd/acp/acp-sdw-legacy-mach.c
@@ -111,6 +111,14 @@ static const struct dmi_system_id soc_sdw_quirk_table[] = {
},
.driver_data = (void *)(ASOC_SDW_CODEC_SPKR),
},
+ {
+ .callback = soc_sdw_quirk_cb,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HN7306EA"),
+ },
+ .driver_data = (void *)(ASOC_SDW_ACP_DMIC),
+ },
{}
};
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-5.10] ALSA: asihpi: avoid write overflow check warning
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.18] ASoC: amd: acp: add ASUS HN7306EA quirk for legacy SDW machine Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.18] ALSA:usb:qcom: add AUXILIARY_BUS to Kconfig dependencies Sasha Levin
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Arnd Bergmann, Takashi Iwai, Sasha Levin, perex, tiwai,
linux-sound, linux-kernel
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit 591721223be9e28f83489a59289579493b8e3d83 ]
clang-22 rightfully warns that the memcpy() in adapter_prepare() copies
between different structures, crossing the boundary of nested
structures inside it:
In file included from sound/pci/asihpi/hpimsgx.c:13:
In file included from include/linux/string.h:386:
include/linux/fortify-string.h:569:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
569 | __write_overflow_field(p_size_field, size);
The two structures seem to refer to the same layout, despite the
separate definitions, so the code is in fact correct.
Avoid the warning by copying the two inner structures separately.
I see the same pattern happens in other functions in the same file,
so there is a chance that this may come back in the future, but
this instance is the only one that I saw in practice, hitting it
multiple times per day in randconfig build.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the data I need. Let me compile the full analysis.
===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================
**Step 1.1: Subject Line**
Record: [ALSA: asihpi] [avoid] [write overflow check warning from
clang-22 fortify-string in adapter_prepare()]
**Step 1.2: Tags**
- Signed-off-by: Arnd Bergmann <arnd@arndb.de> (author)
- Link:
https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org
- Signed-off-by: Takashi Iwai <tiwai@suse.de> (ALSA maintainer)
- No Fixes: tag (expected for manual review candidates)
- No Reported-by: tag
- No Cc: stable tag
- No Tested-by: or Reviewed-by:
Record: Author is a highly trusted kernel contributor (Arnd Bergmann).
Maintainer (Takashi Iwai) signed off. No external bug reports.
**Step 1.3: Commit Body**
The commit describes a clang-22 `__write_overflow_field` warning from
`include/linux/fortify-string.h:569`. The `memcpy()` in
`adapter_prepare()` copies between `struct hpi_response` and `struct
hpi_adapter_response`, which are different structure types with
equivalent layouts. The author explicitly states: "the code is in fact
correct." The warning is hit "multiple times per day in randconfig
build." The fix splits one `memcpy` into two field-level copies.
Record: [Bug: build-time fortify warning, not a runtime defect]
[Symptom: -Werror,-Wattribute-warning build failure with clang-22] [Root
cause: FORTIFY_SOURCE cross-field memcpy detection on different struct
types with equivalent layout]
**Step 1.4: Hidden Bug Fix?**
Record: Not a hidden bug fix. The author explicitly confirms the code is
functionally correct. This is purely a compiler warning suppression.
===============================================================
PHASE 2: DIFF ANALYSIS
===============================================================
**Step 2.1: Inventory**
Record: [sound/pci/asihpi/hpimsgx.c: -2/+4 lines, net +2] [Function:
adapter_prepare()] [Scope: single-file, single-function, surgical]
**Step 2.2: Code Flow Change**
Before: One `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter], &hr,
sizeof(rESP_HPI_ADAPTER_OPEN[0]))` — copies the full struct from `hr`
into the adapter open cache.
After: Two memcpys:
1. `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].h, &hr, sizeof(...h))` —
copies the response header
2. `memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].a, &hr.u.ax.info,
sizeof(...a))` — copies the adapter info payload
This is on the normal initialization path after `HPI_ADAPTER_OPEN`.
Record: [Before: single aggregate memcpy across struct boundaries →
After: two targeted field-level memcpys copying identical data]
**Step 2.3: Bug Mechanism**
Verified struct layouts:
- `struct hpi_response_header`: 12 bytes (u16 size + u8 type + u8
version + u16 object + u16 function + u16 error + u16 specific_error)
- `struct hpi_response`: inline header fields matching
`hpi_response_header` + `union { ... union hpi_adapterx_res ax; ... }
u` at offset 12
- `struct hpi_adapter_response` (packed): `struct hpi_response_header h`
(12 bytes) + `struct hpi_adapter_res a`
- `union hpi_adapterx_res`: first member is `struct hpi_adapter_res
info`
The new code copies `sizeof(hpi_response_header)` bytes from `&hr` into
`.h`, then `sizeof(hpi_adapter_res)` bytes from `&hr.u.ax.info` into
`.a`. This is equivalent to the original single copy because the inline
header fields in `hpi_response` are layout-compatible with
`hpi_response_header`, and `hr.u.ax.info` is at offset 12 (same as `.a`
in the packed struct).
Record: [Category: build fix — compiler warning, not runtime bug]
[Mechanism: split memcpy to satisfy FORTIFY_SOURCE field boundary checks
while copying identical data]
**Step 2.4: Fix Quality**
Record: [Obviously correct — verified from struct layouts] [Minimal,
surgical] [Zero regression risk — functionally identical copy] [No API
changes]
===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================
**Step 3.1: Blame**
Verified: `git blame -L 584,586` shows the memcpy was introduced in
commit `719f82d3987aa` by Eliot Blennerhassett on 2010-04-21 ("ALSA: Add
support of AudioScience ASI boards"). This code has been in the kernel
since v2.6.35 — present in all active stable trees.
Record: [Introduced: 719f82d3987aa, v2.6.35 era (2010)] [Present in all
stable trees]
**Step 3.2: Fixes Tag**
Record: [N/A — no Fixes: tag present]
**Step 3.3: File History**
Verified: `git log --oneline -20 -- sound/pci/asihpi/hpimsgx.c` shows
very low activity. The only functional fix since the original import was
`7b986c7430a6b` ("Fix potential OOB array access"). Since v5.15, only 2
commits touched this file. Since v6.1, only 1.
Record: [Very stable file, rarely changed] [No prerequisites or series]
[Standalone patch]
**Step 3.4: Author**
Verified: Arnd Bergmann is a prolific kernel contributor who frequently
submits compiler warning/build fixes across the tree. Not the asihpi
subsystem maintainer, but a highly trusted contributor. Takashi Iwai
(ALSA maintainer) applied the patch.
Record: [Arnd Bergmann: trusted cross-tree contributor, specializes in
build fixes] [Takashi Iwai: ALSA maintainer, accepted patch]
**Step 3.5: Dependencies**
Record: [No dependencies — self-contained single memcpy split]
===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================
**Step 4.1-4.4:**
The lore.kernel.org and patch.msgid.link URLs are not accessible due to
anti-bot (Anubis) protection.
Record: [UNVERIFIED: lore discussion content, reviewer feedback, stable
nominations, NAKs]
===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================
**Step 5.1: Functions Modified**
Record: [adapter_prepare()]
**Step 5.2: Callers**
Verified: `adapter_prepare()` is called from exactly one place —
`HPIMSGX__init()` at line 719, invoked during
`HPI_SUBSYS_CREATE_ADAPTER`. This is an adapter initialization path
called once per adapter during probe.
Record: [Single call site: HPIMSGX__init() → adapter_prepare()] [Called
during adapter creation/probe, not a hot path]
**Step 5.3-5.4: Callees and Reachability**
The function calls `hpi_init_message_response()`, `hw_entry_point()`,
and `memcpy()`. The call chain is: adapter probe → `hpi_send_recv_ex()`
→ `HPIMSGX__init()` → `adapter_prepare()`. This is reachable from the
ioctl and kernel-side probe path for AudioScience ASI PCI sound cards.
Record: [Probe/initialization path for niche PCI sound hardware]
**Step 5.5: Similar Patterns**
Verified: Similar `memcpy(&cache, &hr, sizeof(cache))` patterns exist
for stream and mixer responses in the same file (lines 608, 621). The
author notes these may trigger similar warnings in the future but
currently only the adapter_prepare instance is hit.
Record: [Similar patterns exist in same file for streams/mixer; only
this one triggers with clang-22 currently]
===============================================================
PHASE 6: STABLE TREE ANALYSIS
===============================================================
**Step 6.1: Code in Stable Trees?**
Verified: The original code was introduced in v2.6.35 (commit
`719f82d3987aa`). Since v6.1, only 1 unrelated commit touched this file.
Since v5.15, only 2. The exact buggy memcpy line exists identically in
all active stable trees.
Record: [Present in all stable trees: v5.15+, v6.1+, v6.6+]
**Step 6.2: Backport Complications**
Record: [Clean apply expected — file barely changed, tiny hunk with
stable surrounding context]
**Step 6.3: Related Fixes**
Record: [No related fixes in stable for this warning]
===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================
**Step 7.1: Subsystem**
Record: [sound/pci/asihpi — AudioScience ASI professional audio PCI
boards] [Criticality: PERIPHERAL — niche hardware]
**Step 7.2: Activity**
Record: [Very low activity; mature, rarely touched driver]
===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================
**Step 8.1: Who Is Affected**
Record: [Runtime: only users of AudioScience ASI PCI cards. Build:
anyone building CONFIG_SND_ASIHPI (or allmodconfig/randconfig) with
clang-22 and FORTIFY_SOURCE + -Werror]
**Step 8.2: Trigger Conditions**
Record: [Build-time only: clang-22 + CONFIG_FORTIFY_SOURCE + -Werror +
CONFIG_SND_ASIHPI] [Not a runtime trigger]
**Step 8.3: Failure Mode Severity**
Record: [Failure mode: build failure/error] [Runtime severity: NONE —
code is functionally correct] [Build severity: MEDIUM — blocks
compilation under specific toolchain]
**Step 8.4: Risk-Benefit Ratio**
- Benefit: Keeps an existing stable driver buildable with newer compiler
fortify diagnostics. The author reports hitting this "multiple times
per day" in randconfig builds.
- Risk: Extremely low — two memcpys copying the same data as one memcpy;
functionally identical, verified from struct layouts.
Record: [Benefit: LOW-MEDIUM (build fix for newer toolchains)] [Risk:
VERY LOW (trivially correct, behavior-preserving)] [Ratio: favorable]
===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================
**Step 9.1: Evidence**
FOR backporting:
- Build fixes are explicitly listed as an allowed stable exception:
"Fixes for compilation errors or warnings... These are critical for
users who need to build the kernel"
- Fix is tiny (+4/-2 lines), single-function, obviously correct
- Verified struct layout compatibility confirms the change is behavior-
preserving
- Author (Arnd Bergmann) is highly trusted; maintainer (Takashi Iwai)
signed off
- Code exists in all stable trees and patch would apply cleanly
- Stable trees are expected to remain buildable with current toolchains;
clang versions age into wider use
AGAINST backporting:
- No runtime bug — the code is functionally correct without this patch
- Niche driver (AudioScience ASI PCI cards)
- Only triggers with clang-22, a very recent compiler
- No user reports, no syzbot involvement
- Impact scope is narrow (specific config + specific toolchain)
UNRESOLVED:
- Lore discussion content could not be verified (anti-bot protection)
- Whether reviewers explicitly nominated this for stable
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivially correct from layout
analysis; tested in randconfig
2. Fixes a real bug that affects users? **YES (build bug)** — prevents
build failure with affected toolchain
3. Important issue? **MEDIUM** — build failure, not crash/corruption,
but build fixes are an explicit exception
4. Small and contained? **YES** — 4 lines changed in 1 function
5. No new features or APIs? **YES**
6. Can apply to stable trees? **YES** — identical code in all stable
trees
**Step 9.3: Exception Categories**
This falls under the **Build Fixes** exception: "Fixes for compilation
errors or warnings, Kconfig dependency fixes, include file fixes — These
are critical for users who need to build the kernel."
**Step 9.4: Decision**
This is a legitimate build fix under the stable exception rules. The
patch is behavior-preserving (verified from struct layout analysis),
trivially correct, and zero-risk. While the impact is narrow (clang-22 +
niche driver), the stable tree policy explicitly allows build fixes
because maintaining buildability with current and evolving toolchains is
a core goal. Compiler versions age into wider use, and preventing build
regressions on stable trees has standalone value. The near-zero
regression risk further supports inclusion.
**Verification:**
- [Phase 1] Parsed all tags: Link, 2x Signed-off-by; no Fixes, Reported-
by, Cc: stable
- [Phase 2] Diff: single memcpy replaced by two field-level memcpys in
adapter_prepare(); net +2 lines
- [Phase 2] Struct layout verified: hpi_response_header (12 bytes
inline), hpi_response has matching inline fields + union at offset 12,
hpi_adapter_response is packed header.h + adapter_res.a — layouts
confirmed compatible
- [Phase 3] git blame: code introduced in 719f82d3987aa (2010, v2.6.35
era), present in all stable trees
- [Phase 3] git log: file barely changed; only 1 commit since v6.1, 2
since v5.15; no series/dependencies
- [Phase 3] Author verified: Arnd Bergmann, prolific build-fix
contributor; Takashi Iwai (ALSA maintainer) applied
- [Phase 4] UNVERIFIED: lore.kernel.org discussion blocked by anti-bot
protection
- [Phase 5] Callers traced: adapter_prepare() called only from
HPIMSGX__init() (line 719), probe/init path
- [Phase 5] Similar memcpy patterns exist at lines 608, 621 for streams;
only adapter instance triggers currently
- [Phase 6] Code exists identically in v5.15, v6.1, v6.6; clean apply
expected
- [Phase 7] Subsystem: sound/pci/asihpi — PERIPHERAL, low activity,
mature driver
- [Phase 8] Impact: build-time only, clang-22 + FORTIFY_SOURCE +
-Werror; severity MEDIUM as build fix
- [Phase 8] Risk: VERY LOW — functionally identical change, verified
from struct layouts
**YES**
sound/pci/asihpi/hpimsgx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/sound/pci/asihpi/hpimsgx.c b/sound/pci/asihpi/hpimsgx.c
index b68e6bfbbfbab..ed1c7b7744361 100644
--- a/sound/pci/asihpi/hpimsgx.c
+++ b/sound/pci/asihpi/hpimsgx.c
@@ -581,8 +581,10 @@ static u16 adapter_prepare(u16 adapter)
HPI_ADAPTER_OPEN);
hm.adapter_index = adapter;
hw_entry_point(&hm, &hr);
- memcpy(&rESP_HPI_ADAPTER_OPEN[adapter], &hr,
- sizeof(rESP_HPI_ADAPTER_OPEN[0]));
+ memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].h, &hr,
+ sizeof(rESP_HPI_ADAPTER_OPEN[adapter].h));
+ memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].a, &hr.u.ax.info,
+ sizeof(rESP_HPI_ADAPTER_OPEN[adapter].a));
if (hr.error)
return hr.error;
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-6.18] ALSA:usb:qcom: add AUXILIARY_BUS to Kconfig dependencies
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.18] ASoC: amd: acp: add ASUS HN7306EA quirk for legacy SDW machine Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-5.10] ALSA: asihpi: avoid write overflow check warning Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.1] ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk Sasha Levin
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Frank Zhang, Takashi Iwai, Sasha Levin, perex, tiwai, linux-sound,
linux-kernel
From: Frank Zhang <rmxpzlb@gmail.com>
[ Upstream commit b8bee48e38f2ddbdba5e58bc54ef54bb7d8d341b ]
The build can fail with:
ERROR: modpost: "__auxiliary_driver_register"
[sound/usb/qcom/snd-usb-audio-qmi.ko] undefined!
ERROR: modpost: "auxiliary_driver_unregister"
[sound/usb/qcom/snd-usb-audio-qmi.ko] undefined!
Select AUXILIARY_BUS when SND_USB_AUDIO_QMI is enabled.
Signed-off-by: Frank Zhang <rmxpzlb@gmail.com>
Link: https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the technical verification I need. Let me produce the
final answer.
---
## Phase 1: Commit Message Forensics
**Step 1.1: Subject Line**
Record: [ALSA:usb:qcom] [add] [Add missing AUXILIARY_BUS Kconfig
dependency to fix modpost build failure]
**Step 1.2: Tags**
- `Signed-off-by: Frank Zhang <rmxpzlb@gmail.com>` — patch author
- `Link:
https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com` —
patch submission
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>` — ALSA subsystem
maintainer accepted the patch
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
by:`, or `Cc: stable` (expected for candidates under manual review)
Record: Accepted by subsystem maintainer Takashi Iwai. Standalone patch
(not part of a series).
**Step 1.3: Commit Body**
Record: Bug: Enabling `SND_USB_AUDIO_QMI` without `AUXILIARY_BUS` causes
modpost failures: `__auxiliary_driver_register` and
`auxiliary_driver_unregister` are undefined in `snd-usb-audio-qmi.ko`.
Symptom: hard build failure. Root cause: the Kconfig entry for
`SND_USB_AUDIO_QMI` omits the required `select AUXILIARY_BUS`.
**Step 1.4: Hidden Bug Fix?**
Record: Not really hidden — the commit message explicitly describes a
build failure. The word "add" in the subject could be misleading, but
the body makes the bug fix intent clear.
---
## Phase 2: Diff Analysis
**Step 2.1: Inventory**
Record: 1 file changed (`sound/usb/Kconfig`), +1 line added (`select
AUXILIARY_BUS`), 0 lines removed. No functions modified (Kconfig only).
Scope: single-line surgical build fix.
**Step 2.2: Code Flow Change**
Record: Before: `SND_USB_AUDIO_QMI` could be enabled without
`CONFIG_AUXILIARY_BUS`, causing the auxiliary bus object files not to be
compiled, leaving
`__auxiliary_driver_register`/`auxiliary_driver_unregister` unresolved
at link time. After: enabling `SND_USB_AUDIO_QMI` forces
`AUXILIARY_BUS=y`, guaranteeing the symbols are available.
**Step 2.3: Bug Mechanism**
Record: Category: build fix / Kconfig dependency bug. The driver's
source (`qc_audio_offload.c` line 1990) uses
`module_auxiliary_driver()`, which expands to
`auxiliary_driver_register`/`auxiliary_driver_unregister` (declared in
`include/linux/auxiliary_bus.h`). These are implemented in
`drivers/base/auxiliary.o`, which is only built when
`CONFIG_AUXILIARY_BUS` is enabled. Without the `select`, the symbols may
not exist.
**Step 2.4: Fix Quality**
Record: Obviously correct — the driver uses auxiliary bus APIs, so it
must depend on the auxiliary bus. Minimal (1 line). Matches the
established tree-wide pattern (50+ other Kconfig entries use `select
AUXILIARY_BUS`). Regression risk: effectively zero — it only ensures a
core infrastructure module is built.
---
## Phase 3: Git History Investigation
**Step 3.1: Blame**
Record: `git blame` confirms the `SND_USB_AUDIO_QMI` block was
introduced in commit `326bbc348298a` ("ALSA: usb-audio: qcom: Introduce
QC USB SND offloading support", Wesley Cheng, 2025-04-09). The `depends
on USB_XHCI_HCD && USB_XHCI_SIDEBAND` line was later added by
`882826f58b2c4` (Arnd Bergmann, 2025-05-21) — another build fix for the
same driver. No `select AUXILIARY_BUS` exists in the current tree.
**Step 3.2: Fixes Tag**
Record: N/A — no `Fixes:` tag. However, the implied fix target is
`326bbc348298a` which introduced the driver without the AUXILIARY_BUS
dependency.
**Step 3.3: File History**
Record: `git log --oneline -20 -- sound/usb/Kconfig` shows the
SND_USB_AUDIO_QMI entry and the prior Kconfig build fix
(`882826f58b2c4`). This is the **second** Kconfig dependency fix for the
same new driver — a pattern consistent with a recently-introduced driver
stabilizing its build dependencies. This patch is standalone; no multi-
patch series dependency.
**Step 3.4: Author**
Record: Frank Zhang has no other commits under `sound/usb/` in this
tree. However, the patch was accepted by Takashi Iwai, the ALSA
subsystem maintainer, providing quality assurance.
**Step 3.5: Dependencies**
Record: No prerequisites needed. The patch is self-contained: it only
requires the `SND_USB_AUDIO_QMI` Kconfig block to already exist in the
tree.
---
## Phase 4: Mailing List and External Research
**Step 4.1–4.4:**
Record: Lore access was blocked by Anubis anti-bot protection. The patch
link
(`https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com`)
and lore search URLs could not be fetched. Reviewer comments, explicit
stable nominations, or NAKs remain unverified. However, the maintainer
sign-off from Takashi Iwai confirms acceptance through the standard
review process.
---
## Phase 5: Code Semantic Analysis
**Step 5.1: Key Functions**
Record: N/A for C functions — this is a Kconfig-only change. The
relevant code reference is
`module_auxiliary_driver(qc_usb_audio_offload_drv)` at
`sound/usb/qcom/qc_audio_offload.c:1990`.
**Step 5.2–5.4: Code Tracing**
Record: Verified the dependency chain:
1. `sound/usb/qcom/qc_audio_offload.c` line 6: `#include
<linux/auxiliary_bus.h>`
2. `sound/usb/qcom/qc_audio_offload.c` line 1990:
`module_auxiliary_driver(qc_usb_audio_offload_drv)`
3. `include/linux/auxiliary_bus.h` defines `module_auxiliary_driver()`
expanding to
`auxiliary_driver_register`/`auxiliary_driver_unregister`
4. `drivers/base/Kconfig` line 4-5: `config AUXILIARY_BUS` is a
promptless `bool` (cannot be enabled by the user directly — must be
selected by a consumer)
5. Without `select AUXILIARY_BUS`, if no other enabled config selects
it, the symbols are unavailable → modpost failure
**Step 5.5: Similar Patterns**
Record: `select AUXILIARY_BUS` appears in 50+ Kconfig files across the
tree (drivers/gpu, drivers/net, drivers/clk, drivers/reset, sound/soc,
etc.). This is the standard established pattern for auxiliary bus
consumers. The fix is entirely consistent with tree-wide convention.
---
## Phase 6: Stable Tree Analysis
**Step 6.1: Does the buggy code exist in stable trees?**
Record: Verified via `git show <tag>:sound/usb/Kconfig`:
- `v6.6` — `SND_USB_AUDIO_QMI` does NOT exist (grep returns 0 matches)
- `v6.12` — does NOT exist (0 matches)
- `v6.16` — EXISTS, missing `select AUXILIARY_BUS` (confirmed)
- `v6.19` — EXISTS, missing `select AUXILIARY_BUS` (confirmed)
The introducing commit `326bbc348298a` first appears in `v6.16` and all
subsequent releases. Older LTS branches (6.6.y, 6.12.y, 6.1.y) are
unaffected — the driver does not exist there.
**Step 6.2: Backport complications**
Record: Clean apply expected. The `SND_USB_AUDIO_QMI` Kconfig block is
materially identical across affected tags. One-line insertion should
apply without conflicts.
**Step 6.3: Related fixes in stable**
Record: No `AUXILIARY_BUS` fix found in any of the affected stable tags.
The prior related build fix (`882826f58b2c4` for USB_XHCI_HCD) is
already present in v6.19 but addresses a different missing dependency.
---
## Phase 7: Subsystem and Maintainer Context
**Step 7.1: Subsystem**
Record: `sound/usb` — ALSA USB audio, Qualcomm offload driver.
Criticality: PERIPHERAL (hardware- and config-specific). However, build
fixes are explicitly listed as stable-appropriate regardless of
subsystem criticality.
**Step 7.2: Activity**
Record: Active development — multiple follow-up fixes since the driver's
introduction in v6.16, indicating a young subsystem still being
stabilized.
---
## Phase 8: Impact and Risk Assessment
**Step 8.1: Who is affected**
Record: Anyone building a kernel with `CONFIG_SND_USB_AUDIO_QMI` enabled
in a configuration where `AUXILIARY_BUS` is not otherwise selected by
another driver. Primarily Qualcomm SoC users and distributions enabling
this driver.
**Step 8.2: Trigger conditions**
Record: Build-time trigger, not runtime. 100% reproducible when the
Kconfig condition is met. Note: the upstream arm64 defconfig
incidentally enables `AUXILIARY_BUS` through `QCOM_PMIC_GLINK`, which
masks the bug in that specific configuration. However, non-default
configs can easily trigger it.
**Step 8.3: Severity**
Record: Build failure at modpost stage — HIGH for affected
configurations (impossible to build the module). Not a runtime crash,
but prevents kernel builds entirely for this config.
**Step 8.4: Risk-benefit ratio**
Record: BENEFIT: High — fixes a hard build break for a supported in-tree
driver. RISK: Effectively zero — one-line Kconfig `select` addition with
no runtime behavior change, matching an established tree-wide pattern.
Ratio: Very strongly favorable.
---
## Phase 9: Final Synthesis
**Step 9.1: Evidence**
FOR backporting:
- Real build failure (modpost undefined symbols) — documented with exact
error messages
- Single-line, obviously correct Kconfig fix
- Matches established tree-wide pattern (`select AUXILIARY_BUS` used in
50+ other Kconfig entries)
- Code path verified: driver uses `module_auxiliary_driver()` → needs
`AUXILIARY_BUS`
- `AUXILIARY_BUS` is a promptless bool — must be selected, not user-
enabled
- Zero runtime regression risk
- Accepted by ALSA subsystem maintainer (Takashi Iwai)
- Second build fix for the same driver (pattern of missing deps from
initial introduction — `882826f58b2c4` was the first)
- Bug confirmed present in all affected stable tags (6.16.y through
6.19.y)
AGAINST backporting:
- Not relevant to stable trees older than v6.16 (driver does not exist
there)
- Narrow audience (Qualcomm USB audio offload users)
UNRESOLVED:
- Lore discussion not accessible (Anubis anti-bot)
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — driver uses auxiliary bus
API, must depend on it
2. Fixes a real bug? **YES** — modpost build failure
3. Important issue? **YES** — prevents compilation of a supported driver
4. Small and contained? **YES** — 1 line, 1 file
5. No new features or APIs? **YES** — only adds missing build dependency
6. Can apply to stable? **YES** — clean apply on v6.16+ branches
**Step 9.3: Exception Categories**
Record: **Build fix** — explicitly listed as an exception category that
is automatically YES for stable.
**Step 9.4: Decision**
This is a textbook build fix: a single-line Kconfig `select` addition
that fixes a real modpost link failure for a supported in-tree driver.
It should be backported to stable trees that contain `SND_USB_AUDIO_QMI`
(v6.16.y and newer). It is not applicable to older LTS branches
(v6.12.y, v6.6.y, v6.1.y) where the driver does not exist.
---
## Verification
- [Phase 1] Parsed commit message and tags directly: `Link:` and two
`Signed-off-by:` tags present; no `Fixes:`, `Reported-by:`, `Tested-
by:`, or `Cc: stable`
- [Phase 2] Diff: confirmed single `+ select AUXILIARY_BUS` line
added under `SND_USB_AUDIO_QMI` in `sound/usb/Kconfig`
- [Phase 3] `git blame -L 191,205 -- sound/usb/Kconfig`: confirmed
`SND_USB_AUDIO_QMI` introduced by `326bbc348298a` (Wesley Cheng,
2025-04-09); deps line touched by `882826f58b2c4` (Arnd Bergmann,
2025-05-21)
- [Phase 3] `git show 882826f58b2c4`: confirmed this was a prior Kconfig
build fix for the same driver (missing `USB_XHCI_HCD` dependency),
also with `Fixes: 326bbc348298` tag
- [Phase 3] `git log --oneline -20 -- sound/usb/Kconfig`: confirmed
recent history, no existing `AUXILIARY_BUS` fix
- [Phase 4] WebFetch to lore/patch.msgid.link: blocked by Anubis anti-
bot — UNVERIFIED: mailing list discussion details
- [Phase 5] Grep `sound/usb/qcom/`: confirmed `#include
<linux/auxiliary_bus.h>` at line 6 and
`module_auxiliary_driver(qc_usb_audio_offload_drv)` at line 1990 of
`qc_audio_offload.c`
- [Phase 5] Read `drivers/base/Kconfig` lines 4-5: confirmed
`AUXILIARY_BUS` is a promptless `bool` — must be selected by consumers
- [Phase 5] Grep `select AUXILIARY_BUS` across Kconfig files: confirmed
50+ other consumers use this pattern
- [Phase 6] `git show v6.6:sound/usb/Kconfig | grep SND_USB_AUDIO_QMI`:
0 matches — driver does not exist in v6.6
- [Phase 6] `git show v6.12:sound/usb/Kconfig | grep SND_USB_AUDIO_QMI`:
0 matches — driver does not exist in v6.12
- [Phase 6] `git show v6.16:sound/usb/Kconfig`: confirmed
`SND_USB_AUDIO_QMI` exists, `select AUXILIARY_BUS` missing
- [Phase 6] `git show v6.19:sound/usb/Kconfig`: confirmed
`SND_USB_AUDIO_QMI` exists, `select AUXILIARY_BUS` missing
- [Phase 6] `git tag --contains 326bbc348298a`: confirmed first
appearance at v6.16; present through v6.19.x
- [Phase 8] Failure mode: modpost undefined symbol error — build
failure, severity HIGH for affected configs
- UNVERIFIED: lore.kernel.org discussion details (anti-bot protection
blocked access)
**YES**
sound/usb/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
index 9b890abd96d34..b4588915efa11 100644
--- a/sound/usb/Kconfig
+++ b/sound/usb/Kconfig
@@ -192,6 +192,7 @@ config SND_USB_AUDIO_QMI
tristate "Qualcomm Audio Offload driver"
depends on QCOM_QMI_HELPERS && SND_USB_AUDIO && SND_SOC_USB
depends on USB_XHCI_HCD && USB_XHCI_SIDEBAND
+ select AUXILIARY_BUS
help
Say Y here to enable the Qualcomm USB audio offloading feature.
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-6.1] ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
` (2 preceding siblings ...)
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.18] ALSA:usb:qcom: add AUXILIARY_BUS to Kconfig dependencies Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA Sasha Levin
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Andrii Kovalchuk, Takashi Iwai, Sasha Levin, perex, tiwai,
linux-sound, linux-kernel
From: Andrii Kovalchuk <coderpy4@proton.me>
[ Upstream commit 793b008cd39516385791a1d1d223d817e947a471 ]
Add a PCI quirk for HP ENVY Laptop 13-ba0xxx (PCI device ID 0x8756)
to enable proper mute LED and mic mute behavior using the
ALC245_FIXUP_HP_X360_MUTE_LEDS fixup.
Signed-off-by: Andrii Kovalchuk <coderpy4@proton.me>
Link: https://patch.msgid.link/u0s-uRVegF9BN0t-4JnOUwsIAR-mVc4U4FJfJHdEHX7ro_laErHD9y35NebWybcN16gVaVHPJo1ap3AoJ1a2gqJImPvThgeNt_SYVY1KaDw=@proton.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the verified facts I need. Let me compile the final
analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
Record: [ALSA: hda/realtek] [Add] [Add HP ENVY Laptop 13-ba0xxx quirk
for mute LED / mic mute behavior]
**Step 1.2: Tags**
Record:
- Signed-off-by: Andrii Kovalchuk `<coderpy4@proton.me>` (author)
- Link: `https://patch.msgid.link/...` (patch submission)
- Signed-off-by: Takashi Iwai `<tiwai@suse.de>` (ALSA subsystem
maintainer)
- No Fixes: tag (expected for a quirk addition)
- No Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc: stable
**Step 1.3: Commit Body**
Record: Bug: On HP ENVY Laptop 13-ba0xxx (PCI SSID 0x103c:0x8756), the
mute LED and mic-mute LED do not function correctly because the driver
lacks a quirk entry mapping this SSID to the appropriate fixup. Symptom:
incorrect mute LED and mic-mute behavior. Root cause: missing PCI quirk
table entry. No stack traces, crash descriptions, or version ranges
mentioned.
**Step 1.4: Hidden Bug Fix Detection**
Record: Not a hidden bug fix — this is an explicit hardware quirk
addition. It fixes a real user-visible hardware issue (broken LED
indicators) but is presented straightforwardly as a quirk addition.
---
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: `sound/hda/codecs/realtek/alc269.c`: +1 line, -0 lines. Single
`SND_PCI_QUIRK()` entry added to `alc269_fixup_tbl[]`. Scope: single-
file, single-line, table-only surgical addition.
**Step 2.2: Code Flow Change**
Record: Before: PCI SSID 0x103c:0x8756 has no match in
`alc269_fixup_tbl[]`, so `snd_hda_pick_fixup()` does not select any
fixup for this laptop — default generic behavior, LEDs non-functional.
After: SSID matches `ALC245_FIXUP_HP_X360_MUTE_LEDS`, which calls
existing `alc245_fixup_hp_mute_led_coefbit` chained to
`ALC245_FIXUP_HP_GPIO_LED`.
**Step 2.3: Bug Mechanism**
Record: Category: hardware workaround / quirk table entry. Mechanism:
Missing PCI SSID in quirk table prevents selection of already-
implemented fixup for one specific HP laptop model.
**Step 2.4: Fix Quality**
Record: Obviously correct — follows the identical pattern of hundreds of
other entries in the same table. Minimal (1 line). Regression risk is
essentially zero: `snd_hda_pick_fixup()` matches by exact PCI SSID, so
only device 0x103c:0x8756 is affected. No API changes, no locking
changes, no logic changes.
---
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
Record: The neighboring quirk lines in `alc269_fixup_tbl[]` trace to the
July 2025 Realtek driver split (file moved from
`sound/pci/hda/patch_realtek.c` to `sound/hda/codecs/realtek/alc269.c`).
The quirk infrastructure and the fixup `ALC245_FIXUP_HP_X360_MUTE_LEDS`
are long-standing.
**Step 3.2: Fixes: tag**
Record: N/A — no Fixes: tag present, which is expected for a quirk
addition.
**Step 3.3: File History**
Record: `git log --oneline -20 -- sound/hda/codecs/realtek/alc269.c`
shows many similar quirk additions (HP, Samsung, Acer, Lenovo, etc.).
This is the standard maintenance pattern for the Realtek HDA driver.
This commit is standalone — not part of a numbered series.
**Step 3.4: Author**
Record: `git log --author='Andrii Kovalchuk' -10 -- sound/` returned no
results — first-time contributor. However, the patch was accepted and
signed off by Takashi Iwai (ALSA subsystem maintainer), which is a
strong quality signal.
**Step 3.5: Dependencies**
Record: The only prerequisite is that `ALC245_FIXUP_HP_X360_MUTE_LEDS`
must exist in the target tree. Verified:
- **v6.6**: Present (3 occurrences in `sound/pci/hda/patch_realtek.c`) ✓
- **v6.12**: Present (6 occurrences) ✓
- **v6.1**: **NOT present** (0 occurrences) ✗
- **v5.15**: **NOT present** (0 occurrences) ✗
This commit is standalone for v6.6+ trees but **cannot** be backported
to v6.1 or v5.15 without first backporting the prerequisite fixup.
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
**Step 4.1: Patch Discussion**
Record: Direct lore.kernel.org and patch.msgid.link fetches were blocked
by anti-bot protection. Via an alternative readable mirror, the thread
shows a standalone [PATCH] submission. Takashi Iwai's only feedback was
about email formatting — no technical objections. He manually corrected
and applied the patch. No reviewer suggested Cc: stable. No NAKs.
**Step 4.2: Bug Report**
Record: No separate public bug report found. No Reported-by: tag. The
patch thread itself serves as the primary evidence of the user-visible
issue.
**Step 4.3: Related Patches**
Record: This is a standalone one-line patch, not part of a series.
Similar quirks exist for other HP ENVY models using the same fixup
(0x876e for 13-ay0xxx, 0x888a for 15-eu0xxx, etc.).
**Step 4.4: Stable Discussion**
Record: No stable-specific discussion found for this commit. However,
analogous HP ENVY quirk additions have historically carried `Cc:
stable@vger.kernel.org`, demonstrating this pattern is routinely
considered for stable.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions Modified**
Record: No functions modified. Only a static data table entry added to
`alc269_fixup_tbl[]`.
**Step 5.2: Callers**
Record: The quirk table is consumed by `snd_hda_pick_fixup(codec,
alc269_fixup_models, alc269_fixup_tbl, alc269_fixups)` called from
`alc269_probe()` at line 8572-8573 of `alc269.c`. The codec driver
registers `.probe = alc269_probe` via
`module_hda_codec_driver(alc269_driver)`.
**Step 5.3: Callees**
Record: The fixup `ALC245_FIXUP_HP_X360_MUTE_LEDS` (line 6401-6406)
calls `.v.func = alc245_fixup_hp_mute_led_coefbit` and chains to
`ALC245_FIXUP_HP_GPIO_LED`. All existing, well-tested code.
**Step 5.4: Reachability**
Record: Call chain: `module_hda_codec_driver` → `alc269_probe` →
`snd_hda_pick_fixup()` → match PCI SSID against table. Triggered during
codec probe on every boot/module-load on the affected laptop. Real and
reachable.
**Step 5.5: Similar Patterns**
Record: Verified 4 other devices already use this exact fixup in the
same table:
- 0x876e (HP ENVY x360 Convertible 13-ay0xxx)
- 0x888a (HP ENVY x360 Convertible 15-eu0xxx)
- 0x8c21 (HP Pavilion Plus Laptop 14-ey0XXX)
- 0x8cbd (HP Pavilion Aero Laptop 13-bg0xxx)
---
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Code Existence in Stable**
Record: Verified via `git show`:
- **v6.6**: `ALC245_FIXUP_HP_X360_MUTE_LEDS` exists in
`sound/pci/hda/patch_realtek.c` (3 matches). SSID 0x8756 is NOT
present — the bug exists here. **Applicable.**
- **v6.12**: Fixup present (6 matches). **Applicable.**
- **v6.1**: Fixup does NOT exist. **Not applicable without
prerequisite.**
- **v5.15**: Fixup does NOT exist. **Not applicable without
prerequisite.**
**Step 6.2: Backport Complications**
Record: For v6.6.y: trivial backport — the one-line entry goes into
`sound/pci/hda/patch_realtek.c` (pre-split file path) instead of
`sound/hda/codecs/realtek/alc269.c`. Context lines for the adjacent
entries (0x8736, 0x8760) should be present. Minor context adjustment
needed.
**Step 6.3: Related Fixes Already in Stable**
Record: No existing fix for SSID 0x8756 found in v6.6.
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: Subsystem**
Record: sound/hda (HDA audio, Realtek codec driver). Criticality:
IMPORTANT — laptop audio is user-facing and widely used, though this
specific fix affects one hardware model.
**Step 7.2: Activity**
Record: Very active subsystem — recent history shows continuous stream
of quirk additions for various laptop models. Mature, well-maintained
driver with established patterns.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected Users**
Record: Hardware-specific: owners of HP ENVY Laptop 13-ba0xxx (PCI SSID
0x103c:0x8756). This is a consumer laptop — potentially many users.
**Step 8.2: Trigger Conditions**
Record: Every boot. The mute/mic-mute LEDs simply don't work correctly
without this quirk. No special configuration needed.
**Step 8.3: Failure Mode Severity**
Record: MEDIUM — Mute/mic-mute LED indicators don't function correctly.
This is a usability and privacy concern (users can't visually confirm
mic state), but not a crash, data corruption, or security vulnerability.
**Step 8.4: Risk-Benefit Ratio**
Record:
- Benefit: Moderate — fixes broken hardware functionality for real
laptop users
- Risk: Very low — 1 line, device-specific (only SSID 0x103c:0x8756),
uses proven fixup used by 4+ other devices
- Ratio: Strongly favorable for backporting
---
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
FOR backporting:
- Single-line hardware quirk addition (1 line added)
- Uses existing, well-tested fixup (`ALC245_FIXUP_HP_X360_MUTE_LEDS`)
already used by 4 other HP devices
- Zero regression risk — only activates on PCI SSID 0x103c:0x8756
- Accepted by ALSA subsystem maintainer Takashi Iwai with no technical
objections
- Fixes real user-visible hardware issue on a consumer laptop
- Prerequisite fixup verified present in v6.6+
- Falls squarely under the "audio codec quirk" stable exception
AGAINST backporting:
- Not a crash, security issue, or data corruption — "only" a
usability/hardware fix
- Not applicable to v6.1 or v5.15 without prerequisite backport
UNRESOLVED:
- No independent public bug report found (patch thread is the only
evidence)
- Did not verify every active stable branch newer than v6.6
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — standard `SND_PCI_QUIRK`
table entry, maintainer-accepted
2. Fixes a real bug? **YES** — mute/mic-mute LEDs non-functional on this
hardware
3. Important issue? **YES under quirk exception** — hardware enablement
for a consumer laptop
4. Small and contained? **YES** — 1 line in 1 file
5. No new features or APIs? **YES** — uses existing fixup mechanism
6. Can apply to stable? **YES** for v6.6+ (with file path adjustment);
NO for v6.1/v5.15 as standalone
**Step 9.3: Exception Categories**
Record: **Audio codec quirk** (`SND_PCI_QUIRK` entry in Realtek HDA
driver) — explicitly listed as a stable-appropriate exception.
**Step 9.4: Decision**
This is a textbook stable-worthy hardware quirk. One line, zero
regression risk, fixes real hardware for real users, uses an existing
well-tested fixup. Good stable material for branches that already
contain `ALC245_FIXUP_HP_X360_MUTE_LEDS` (v6.6+). Should not be taken as
a standalone patch into older trees (v6.1, v5.15) without the
prerequisite fixup.
---
## Verification
- [Phase 1] Parsed commit message: Add quirk for 0x103c:0x8756 using
`ALC245_FIXUP_HP_X360_MUTE_LEDS`; tags: SOB ×2, Link
- [Phase 2] Diff: +1 `SND_PCI_QUIRK` line in `alc269_fixup_tbl[]` in
`sound/hda/codecs/realtek/alc269.c`
- [Phase 3] Verified `ALC245_FIXUP_HP_X360_MUTE_LEDS` definition at
lines 6401-6406: `.v.func = alc245_fixup_hp_mute_led_coefbit`, chained
to `ALC245_FIXUP_HP_GPIO_LED`
- [Phase 3] Verified `snd_hda_pick_fixup()` call at lines 8572-8573 in
`alc269_probe()`
- [Phase 3] Verified 4 other SSIDs use the same fixup: 0x876e, 0x888a,
0x8c21, 0x8cbd
- [Phase 3] `git log --author='Andrii Kovalchuk'`: no prior commits
found — first-time contributor
- [Phase 4] Lore/patch.msgid blocked by anti-bot; alternative mirror
confirmed standalone patch, maintainer feedback was formatting-only,
no technical objections
- [Phase 5] No functions modified — data-only change
- [Phase 6] `git show v6.6:sound/pci/hda/patch_realtek.c | grep -c
'ALC245_FIXUP_HP_X360_MUTE_LEDS'`: **3** — fixup present in v6.6
- [Phase 6] `git show v6.12:sound/pci/hda/patch_realtek.c | grep -c
...`: **6** — fixup present in v6.12
- [Phase 6] `git show v6.1:sound/pci/hda/patch_realtek.c | grep -c ...`:
**0** — fixup NOT in v6.1
- [Phase 6] `git show v5.15:sound/pci/hda/patch_realtek.c | grep -c
...`: **0** — fixup NOT in v5.15
- [Phase 6] `git show v6.6:... | grep '0x8756'`: empty — SSID not
already in v6.6, confirming the bug exists there
- [Phase 8] Risk: very low (1 line, SSID-specific). Benefit: fixes
broken mute LEDs on consumer laptop
- UNVERIFIED: No independent public bug report found for this exact
laptop model
- UNVERIFIED: Did not inspect every active stable branch newer than v6.6
**YES**
sound/hda/codecs/realtek/alc269.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 4c49f1195e1bc..39a57d9238497 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6854,6 +6854,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x103c, 0x8730, "HP ProBook 445 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
SND_PCI_QUIRK(0x103c, 0x8735, "HP ProBook 435 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT),
+ SND_PCI_QUIRK(0x103c, 0x8756, "HP ENVY Laptop 13-ba0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
SND_PCI_QUIRK(0x103c, 0x8760, "HP EliteBook 8{4,5}5 G7", ALC285_FIXUP_HP_BEEP_MICMUTE_LED),
SND_PCI_QUIRK(0x103c, 0x876e, "HP ENVY x360 Convertible 13-ay0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED),
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
` (3 preceding siblings ...)
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.1] ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF Sasha Levin
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Vee Satayamas, Zhang Heng, Mark Brown, Sasha Levin,
Vijendar.Mukunda, lgirdwood, perex, tiwai, linux-sound,
linux-kernel
From: Vee Satayamas <vsatayamas@gmail.com>
[ Upstream commit f200b2f9a810c440c6750b56fc647b73337749a1 ]
Add a DMI quirk for the Asus Expertbook BM1403CDA to resolve the issue of the
internal microphone not being detected.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221236
Signed-off-by: Vee Satayamas <vsatayamas@gmail.com>
Reviewed-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260315142511.66029-2-vsatayamas@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1:** Record: [ASoC: amd: yc] [Add] DMI quirk for ASUS
EXPERTBOOK BM1403CDA to fix internal microphone not being detected.
**Step 1.2:** Record:
- `Link: https://bugzilla.kernel.org/show_bug.cgi?id=221236` — user-
filed bug report
- `Signed-off-by: Vee Satayamas <vsatayamas@gmail.com>` — patch author
- `Reviewed-by: Zhang Heng <zhangheng@kylinos.cn>` — peer review
(notably Zhang Heng authored the sibling PM1503CDA quirk,
`355aab1aaf77d`)
- `Link:
https://patch.msgid.link/20260315142511.66029-2-vsatayamas@gmail.com`
— mailing list posting
- `Signed-off-by: Mark Brown <broonie@kernel.org>` — ASoC subsystem
maintainer merged it
- No `Fixes:` tag, no `Cc: stable`, no `Reported-by:`, no `Tested-by:`
(absence expected for manual review)
**Step 1.3:** Record: Bug: internal microphone not detected on ASUS
EXPERTBOOK BM1403CDA. Symptom: no audio capture device appears. Root
cause: this board's firmware/ACPI does not properly signal DMIC
presence, requiring a DMI override entry. No version information stated.
**Step 1.4:** Record: Not a hidden bug fix — it is an explicit hardware
quirk addition. This falls squarely into the "QUIRKS and WORKAROUNDS"
exception category for stable.
---
## PHASE 2: DIFF ANALYSIS
**Step 2.1:** Record: Single file changed:
`sound/soc/amd/yc/acp6x-mach.c`, +7 lines, 0 removed. Only
`yc_acp_quirk_table[]` static data modified. Scope: single-file, data-
only, surgical.
**Step 2.2:** Record: Before: BM1403CDA has no match in
`yc_acp_quirk_table[]`. After: a new entry matches `DMI_BOARD_VENDOR =
"ASUSTeK COMPUTER INC."` and `DMI_BOARD_NAME = "BM1403CDA"`, setting
`driver_data = &acp6x_card`. The new entry is inserted just before the
table terminator `{}`.
**Step 2.3:** Record: Category: Hardware workaround / DMI quirk table
entry. Mechanism: In `acp6x_probe()`, if ACPI methods (`_WOV` /
`AcpDmicConnected`) fail to enable the DMIC, the code falls through to
`check_dmi_entry` (line 761) where `dmi_first_match(yc_acp_quirk_table)`
is called. If matched, `platform_set_drvdata()` is set to `&acp6x_card`.
Without a match, `platform_get_drvdata()` returns NULL and
`acp6x_probe()` returns `-ENODEV` (line 768-769), meaning no sound card
is registered and the internal microphone is entirely absent.
Verified in the source:
```761:769:sound/soc/amd/yc/acp6x-mach.c
check_dmi_entry:
/* check for any DMI overrides */
dmi_id = dmi_first_match(yc_acp_quirk_table);
if (dmi_id)
platform_set_drvdata(pdev, dmi_id->driver_data);
card = platform_get_drvdata(pdev);
if (!card)
return -ENODEV;
```
**Step 2.4:** Record: Obviously correct. The entry is structurally
identical to the 96 existing `driver_data = &acp6x_card` entries in the
same table, including sibling ASUS EXPERTBOOK models BM1503CDA and
PM1503CDA. Regression risk: zero for other hardware — the DMI match is
specific to one exact board vendor/name pair.
---
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1:** Record: `git blame` shows the neighboring ASUS entries
were added by: `b671f9384ffc8` (Vivobook M6501RR, 2026-02-10),
`5a859a7dfce6c` (BM1503CDA, 2026-02-21), `355aab1aaf77d` (PM1503CDA,
2026-03-04). The table itself originates from `fa991481b8b22` ("ASoC:
amd: add YC machine driver using dmic", 2021-10-18), first appearing in
the v5.16 release cycle.
**Step 3.2:** Record: N/A — no `Fixes:` tag in the commit message.
**Step 3.3:** Record: Recent history of `acp6x-mach.c` is dominated by
single-entry DMI quirk additions for various laptop models (HP, ASUS,
Lenovo, Acer, MSI). This is a well-established, routine pattern. No
indication this patch is part of a multi-patch series requiring other
commits.
**Step 3.4:** Record: Vee Satayamas has no prior commits in
`sound/soc/amd/yc/` in this tree. However, the patch was reviewed by
Zhang Heng (who authored the PM1503CDA entry) and merged by Mark Brown
(ASoC maintainer), providing strong quality assurance.
**Step 3.5:** Record: No dependencies. The patch uses only existing
table infrastructure (`yc_acp_quirk_table[]`, `&acp6x_card`, `DMI_MATCH`
macros) that has been present since the driver was introduced in v5.16.
Fully standalone.
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
**Step 4.1-4.4:** Record: The commit references bugzilla.kernel.org bug
#221236 and a patch.msgid.link URL. External archive fetches are blocked
by Anubis challenge pages in this environment, so the exact mailing list
discussion and bugzilla details could not be retrieved. The commit
message itself documents the bug (internal mic not detected), the patch
was peer-reviewed (`Reviewed-by: Zhang Heng`) and merged by the ASoC
maintainer (`Signed-off-by: Mark Brown`). The message-id suffix `-2-`
suggests this may have been part of a small series, but the patch is
self-contained.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1:** Record: The diff modifies only the static data table
`yc_acp_quirk_table[]`. The runtime consumer is `acp6x_probe()`.
**Step 5.2:** Record: `acp6x_probe()` is the `.probe` callback of
`acp6x_mach_driver`, registered via `module_platform_driver()`. The
platform device `"acp_yc_mach"` is created by `snd_acp6x_probe()` in
`sound/soc/amd/yc/pci-acp6x.c` during PCI enumeration.
**Step 5.3:** Record: Within `acp6x_probe()`, key callees include
`ACPI_COMPANION()`, `acpi_dev_get_property()`,
`acpi_evaluate_integer()`, `dmi_first_match()`,
`platform_set_drvdata()`, and `devm_snd_soc_register_card()`. The quirk
only influences probe-time card selection.
**Step 5.4:** Record: Call chain: PCI enumeration → `snd_acp6x_probe()`
→ platform device registration → `acp6x_probe()` → DMI override → sound
card registration. Reachable automatically at boot on affected hardware.
Not a syscall-triggered path.
**Step 5.5:** Record: 96 existing `driver_data = &acp6x_card` entries in
the same file confirm this is the standard, well-tested pattern for
enabling DMIC on laptop models with broken/missing ACPI firmware
descriptions.
---
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1:** Record: Verified via `git ls-tree`:
- `sound/soc/amd/yc/` is **absent** in v5.15
- Present since v5.16 (`fa991481b8b22`)
- Confirmed present in v6.1 and v6.6
- Fix is relevant to all active stable trees from v5.16 onward (6.1.y,
6.6.y, 6.12.y, etc.)
- **Not applicable** to 5.15.y (driver does not exist there)
**Step 6.2:** Record: Expected clean apply or trivial context
adjustment. Older stable trees have shorter quirk tables, so the hunk
context will differ, but the semantic change is a single table entry
insertion before `{}` — trivial to backport.
**Step 6.3:** Record: No existing BM1403CDA entry found in git history.
No duplicate fix.
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1:** Record: Subsystem: ASoC / AMD Yellow Carp (ACP6x) machine
driver. Criticality: IMPORTANT — audio is essential for laptop users;
this is a shipping ASUS business laptop model.
**Step 7.2:** Record: Highly active subsystem — recent history shows a
steady stream of DMI quirk additions for various laptop manufacturers.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1:** Record: Platform-specific: affects owners of ASUS
EXPERTBOOK BM1403CDA with `CONFIG_SND_SOC_AMD_YC_MACH` enabled.
**Step 8.2:** Record: Trigger: deterministic on every boot of this
hardware. The internal microphone is permanently non-functional without
this quirk. Not timing-dependent.
**Step 8.3:** Record: Failure mode: internal microphone not detected
(probe returns `-ENODEV`). Severity: HIGH for affected users — complete
loss of audio capture functionality (no video calls, no voice
recording).
**Step 8.4:** Record: Benefit: HIGH for affected users (restores
essential hardware functionality). Risk: VERY LOW (7-line data-only
change, exact DMI match, no logic modification, identical pattern to 96
existing entries). Ratio: strongly favorable.
---
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence compiled:**
FOR backporting:
- Real user-reported bug (bugzilla #221236)
- Fixes completely broken hardware (internal microphone non-functional)
- 7 lines added, single file, data-only change
- Zero regression risk (narrow DMI match, no logic change)
- Identical pattern to 96 existing quirk entries in the same table
- Reviewed by sibling-entry author (Zhang Heng) and merged by ASoC
maintainer (Mark Brown)
- Driver and quirk infrastructure exist in all active stable trees
(v6.1+, v6.6+)
AGAINST backporting:
- No evidence whatsoever against backporting
UNRESOLVED:
- Exact bugzilla details and mailing list discussion (blocked by Anubis)
- Whether the `-2-` message-id indicates a multi-patch series (but patch
is self-contained)
**Step 9.2: Stable rules checklist:**
1. Obviously correct and tested? **YES** — identical to 96 existing
entries; reviewed and merged by maintainer.
2. Fixes a real bug? **YES** — internal microphone not detected on
shipping hardware.
3. Important issue? **YES** — complete hardware feature loss.
4. Small and contained? **YES** — 7 lines, one file, data-only.
5. No new features or APIs? **YES** — enables existing driver behavior
for one board.
6. Can apply to stable? **YES** — for trees v5.16+ (6.1.y, 6.6.y, etc.);
minor context adjustment may be needed.
**Step 9.3: Exception category:** Hardware quirk/workaround — DMI-based
enablement entry for an existing driver. This is explicitly listed as a
YES exception for stable.
**Step 9.4: Decision:** This is a textbook stable-backport DMI quirk.
Minimal risk, clear benefit, well-established pattern.
---
## Verification
- [Phase 1] Parsed commit message tags: found Link to bugzilla #221236,
Reviewed-by Zhang Heng, merged by Mark Brown (ASoC maintainer)
- [Phase 2] Read `acp6x-mach.c` lines 695-779: verified existing ASUS
entries at lines 706-719 and the DMI override path at lines 761-769
(`dmi_first_match()` → `platform_set_drvdata()` → `-ENODEV` if no
card)
- [Phase 2] Verified diff adds exactly one 7-line DMI table entry with
no removals or logic changes
- [Phase 3] `git blame -L 700,730`: confirmed neighboring entries from
`b671f9384ffc8`, `5a859a7dfce6c`, `355aab1aaf77d`; table terminator
from `fa991481b8b22`
- [Phase 3] `git log --oneline -1 fa991481b8b22`: confirmed "ASoC: amd:
add YC machine driver using dmic" introduced the driver
- [Phase 3] `git describe --contains fa991481b8b22`: confirmed driver
first appears in v5.16-rc3 cycle
- [Phase 3] `git ls-tree v5.15 -- sound/soc/amd/yc/`: confirmed
directory is **absent** in v5.15
- [Phase 3] `git ls-tree v5.16 -- sound/soc/amd/yc/`: confirmed
directory is **present** in v5.16
- [Phase 3] `git log --oneline -20 -- sound/soc/amd/yc/acp6x-mach.c`:
confirmed recent history is dominated by DMI quirk additions
- [Phase 5] `grep` count: verified 96 existing `driver_data =
&acp6x_card` entries in the same file
- [Phase 6] `git ls-tree v6.1/v6.6 -- sound/soc/amd/yc/acp6x-mach.c`:
confirmed file exists in both stable trees
- [Phase 4] UNVERIFIED: bugzilla.kernel.org and lore.kernel.org content
blocked by Anubis; did not drive decision
- [Phase 3] UNVERIFIED: exact series context for `-2-` message-id
suffix; patch is self-contained regardless
**YES**
sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index 1324543b42d72..c536de1bb94ad 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -717,6 +717,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "PM1503CDA"),
}
},
+ {
+ .driver_data = &acp6x_card,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_BOARD_NAME, "BM1403CDA"),
+ }
+ },
{}
};
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
` (4 preceding siblings ...)
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-5.10] ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx Sasha Levin
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Zhang Heng, Mark Brown, Sasha Levin, Vijendar.Mukunda, lgirdwood,
perex, tiwai, linux-sound, linux-kernel
From: Zhang Heng <zhangheng@kylinos.cn>
[ Upstream commit 1f182ec9d7084db7dfdb2372d453c28f0e5c3f0a ]
Add a DMI quirk for the Thin A15 B7VF fixing the issue where
the internal microphone was not detected.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220833
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260316080218.2931304-1-zhangheng@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the evidence needed for a comprehensive analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
Record: [ASoC: amd: yc] [Add] [DMI quirk for MSI Thin A15 B7VF — enables
internal mic on this laptop model]
**Step 1.2: Tags**
Record:
- Link: `https://bugzilla.kernel.org/show_bug.cgi?id=220833` — user-
filed bug report
- Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> — patch author
- Link: `https://patch.msgid.link/20260316080218.2931304-1-
zhangheng@kylinos.cn` — mailing list submission
- Signed-off-by: Mark Brown <broonie@kernel.org> — ASoC subsystem
maintainer (strong endorsement)
- No Fixes:, Cc: stable, Reported-by, Tested-by, or Reviewed-by —
expected for this type of change
- Notable: Mark Brown is the ASoC maintainer, so his SOB indicates
direct maintainer acceptance
**Step 1.3: Body Text**
Record: Bug: internal microphone not detected on MSI Thin A15 laptop.
Symptom: mic hardware present but invisible to the audio subsystem. No
version information provided. Root cause: DMI quirk table missing an
entry for this model.
**Step 1.4: Hidden Bug Fix Detection**
Record: Not hidden — this is explicitly a hardware quirk to enable an
existing audio path on a specific laptop. Without it, the internal
microphone is completely non-functional.
**Important discrepancy noted:** Subject says "Thin A15 B7VF" but the
code adds `DMI_MATCH(DMI_PRODUCT_NAME, "Thin A15 B7VE")`. Investigated
below.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
Record: Single file: `sound/soc/amd/yc/acp6x-mach.c`. +7 lines added
(one new DMI table entry). Zero lines removed. Scope: single-file,
table-only change. No function bodies modified.
**Step 2.2: Code Flow Change**
Record: Before: `dmi_first_match(yc_acp_quirk_table)` in `acp6x_probe()`
has no entry matching this MSI model → probe returns `-ENODEV` or mic
card not registered → internal mic silent. After: DMI matches →
`platform_set_drvdata(pdev, dmi_id->driver_data)` sets `acp6x_card` →
`devm_snd_soc_register_card()` registers the audio card → internal mic
works.
**Step 2.3: Bug Mechanism**
Record: Category: Hardware workaround (DMI quirk table entry). The AMD
Yellow Carp DMIC driver requires either an ACPI property
(`AcpDmicConnected`) or a DMI quirk to enable the microphone. Many
laptops lack the ACPI property, so DMI matching is the fallback path.
This model needs that DMI entry.
**Step 2.4: Fix Quality**
Record: Obviously correct — identical pattern to 90+ other entries in
the same table. Minimal/surgical: 7 lines in a static const table.
Regression risk: zero — the new DMI entry only matches systems with both
`DMI_BOARD_VENDOR = "Micro-Star International Co., Ltd."` AND
`DMI_PRODUCT_NAME` containing `"Thin A15 B7VE"`. Cannot affect any other
hardware.
**B7VF vs B7VE discrepancy analysis:** MSI Thin A15 B7VE (RTX 4050,
Ryzen 5 7535HS) and B7VF (RTX 4060, Ryzen 7 7735HS) are confirmed to be
**distinct laptop models** per MSI's own specification sheets.
`DMI_MATCH()` uses `strstr()` (substring matching), verified in
`drivers/firmware/dmi_scan.c:865`. Since "Thin A15 B7VE" is NOT a
substring of "Thin A15 B7VF", the code targets only the B7VE model. The
commit subject's "B7VF" is almost certainly a typo — the author would
have used `dmidecode` output from their actual hardware to construct the
DMI match string, making the code correct for the B7VE model. The
maintainer (Mark Brown) accepted the patch, indicating the code was
tested.
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
Record: The DMI quirk table traces back to `fa991481b8b22` (v5.16 cycle,
Vijendar Mukunda). Recent entries from Zhang Heng (`355aab1aaf77d` —
PM1503CDA), and many others. The mechanism is long-standing.
**Step 3.2: Fixes Tag**
Record: N/A — no Fixes: tag present (expected for hardware quirk
additions).
**Step 3.3: File History**
Record: `git log --oneline -25` shows continuous DMI quirk additions:
PM1503CDA, BM1503CDA, HP 200 G2a 16, Acer TravelMate, Honor MagicBook,
HP Laptop 17, MSI Bravo 17 D7VF, etc. This is the same well-established
pattern.
**Step 3.4: Author**
Record: Zhang Heng has 2 prior commits in this subsystem
(`355aab1aaf77d` — ASUS PM1503CDA, `9502b7df5a3c7` — Acer TravelMate
P216-41-TCO). Regular contributor to this DMI quirk table.
**Step 3.5: Dependencies**
Record: None. The entry uses existing `acp6x_card` driver_data present
since the file's creation. Entirely self-contained.
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
**Step 4.1: Lore**
Record: Lore and patch.msgid.link blocked by Anubis bot protection.
Could not verify review discussion directly.
**Step 4.2: Bug Report**
Record: Bugzilla 220833 inaccessible (Anubis protection). However, the
bug report's existence is confirmed by the URL. Web search confirmed MSI
Thin A15 B7VE is a real laptop with RTX 4050/Ryzen 5 7535HS and B7VF is
a separate model with RTX 4060/Ryzen 7 7735HS.
**Step 4.3: Series Context**
Record: Single-patch submission (no "patch X/Y" indicator). Standalone
fix.
**Step 4.4: Stable List**
Record: Could not verify due to Anubis blocking. No existing `Thin A15`
entry found in git history (`git log --oneline --grep='Thin A15'`
returned empty).
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Key Symbols**
Record: `yc_acp_quirk_table[]` (data table), consumed by `acp6x_probe()`
via `dmi_first_match()`.
**Step 5.2: Callers**
Record: Table used only from `acp6x_probe()` at the `check_dmi_entry`
label (line 763). Driver is `module_platform_driver(acp6x_mach_driver)`
— runs at platform device probe.
**Step 5.3: Callees**
Record: `acp6x_probe()` calls `ACPI_COMPANION()`,
`acpi_dev_get_property()`, `acpi_evaluate_integer()`,
`dmi_first_match()`, `platform_set_drvdata()`, and
`devm_snd_soc_register_card()`.
**Step 5.4: Call Chain**
Record: PCI ACP device probe (`snd_acp6x_probe()` in `pci-acp6x.c`) →
registers `acp_yc_mach` platform device → `acp6x_probe()` → DMI match →
card registration. Reachable automatically at boot on matching hardware.
**Step 5.5: Similar Patterns**
Record: 5 existing MSI ("Micro-Star International") entries already in
the current tree: Bravo 15 B7ED, Bravo 15 C7VF, Bravo 17 D7VEK, Bravo 17
D7VF, Bravo 15 C7UCX. Identical pattern.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable?**
Record: File exists in v6.1 (270 lines), v6.6 (438 lines), v6.12 (586
lines). Does NOT exist in v5.15. The missing quirk affects all stable
trees that ship this driver (v6.1+).
**Step 6.2: Backport Complications**
Record: Expected clean apply or trivial context adjustment. The patch
appends one entry before the `{}` table terminator. The exact preceding
entries differ per stable tree, but this is a trivial context shift —
just place the new entry before `{}`.
**Step 6.3: Related Fixes in Stable**
Record: No existing `Thin A15` fix found in any tree.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: Subsystem**
Record: ASoC / `sound/soc/amd/yc` — IMPORTANT for AMD laptop users.
Audio is a fundamental laptop feature.
**Step 7.2: Activity**
Record: Extremely active — 25+ recent commits, almost all DMI quirk
additions. One of the most frequently updated quirk tables in the
kernel.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Affected Users**
Record: Owners of MSI Thin A15 B7VE laptops running Linux with
`CONFIG_SND_SOC_AMD_YC_MACH` enabled.
**Step 8.2: Trigger**
Record: Every boot on matching hardware. No special configuration or
privilege needed. The microphone is always broken without this quirk.
**Step 8.3: Failure Mode**
Record: Internal microphone completely non-functional. Severity: MEDIUM-
HIGH for affected users — a laptop with no working microphone is
significantly impaired for video calls, recording, accessibility.
**Step 8.4: Risk-Benefit Ratio**
Record:
- BENEFIT: High — restores fundamental hardware functionality for
affected users
- RISK: Essentially zero — 7 lines in a static table, only matches one
specific hardware model, cannot affect any other system
- Ratio: Extremely favorable
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence Compiled**
FOR backporting:
- Hardware quirk/workaround — explicit exception category (always
appropriate for stable)
- Fixes real user-reported bug (bugzilla 220833) — internal mic non-
functional
- Minimal change: +7 lines in a static DMI table
- Zero regression risk (DMI match is hardware-specific)
- Accepted by ASoC maintainer Mark Brown
- Identical pattern to 90+ other entries in the same table
- 5 existing MSI entries use the exact same pattern
- Driver exists in all active stable trees (v6.1+)
- No dependencies, fully self-contained
AGAINST backporting:
- Subject says "B7VF" but code targets "B7VE" — these are different MSI
models. However, this is almost certainly a typo in the commit
subject, not a code error. The author used the actual `dmidecode`
output from their machine to construct the `DMI_MATCH` string.
UNRESOLVED:
- Could not access bugzilla 220833 or lore discussion to confirm the
reporter's exact DMI strings
- The B7VF/B7VE discrepancy cannot be 100% resolved without the bug
report
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — trivial table entry following
established pattern; maintainer accepted
2. Fixes a real bug? **YES** — internal microphone not detected
3. Important issue? **YES** — hardware completely non-functional
4. Small and contained? **YES** — 7 lines, single static table
5. No new features or APIs? **YES** — extends existing quirk table only
6. Applies to stable? **YES** — driver present in v6.1+, trivial context
adjustment at most
**Step 9.3: Exception Category**
Record: **Hardware quirk/workaround** (DMI-based) — explicitly listed as
appropriate for stable backporting.
**Step 9.4: Decision**
The B7VF/B7VE naming discrepancy is a cosmetic issue in the commit
message subject line, not a code correctness issue. The author would
have derived the DMI match string from their actual hardware's
`dmidecode` output — meaning the code targets the correct machine
(B7VE). The subject typo does not change the fact that this is a
standard, minimal, zero-risk hardware quirk addition that restores
microphone functionality on a specific laptop. Mark Brown (ASoC
maintainer) signed off on it. The patch follows the exact same pattern
as dozens of previously-backported quirk additions in the same file.
Even in the worst case (wrong DMI string), the patch is a harmless no-op
— it cannot cause any regression on any system.
## Verification
- [Phase 1] Parsed all tags from commit message: Link to bugzilla
220833, author Zhang Heng, maintainer Mark Brown SOB
- [Phase 2] Diff: +7 lines adding one `struct dmi_system_id` entry to
`yc_acp_quirk_table[]` for MSI "Thin A15 B7VE"
- [Phase 2] Verified `DMI_MATCH()` macro in
`include/linux/mod_devicetable.h:601`: stores `.substr = b`
- [Phase 2] Verified `dmi_matches()` in
`drivers/firmware/dmi_scan.c:865`: uses `strstr()` for non-exact
matches
- [Phase 2] Therefore "Thin A15 B7VE" is NOT a substring of "Thin A15
B7VF" — these target different hardware
- [Phase 2] Web search confirmed B7VE (RTX 4050) and B7VF (RTX 4060) are
distinct MSI laptop models
- [Phase 3] `git log --oneline -25 -- sound/soc/amd/yc/acp6x-mach.c`:
confirmed continuous DMI quirk addition pattern
- [Phase 3] `git log --author="Zhang Heng" -10 -- sound/soc/amd/yc/`: 2
prior commits in subsystem
- [Phase 3] `git log --grep='Thin A15' --
sound/soc/amd/yc/acp6x-mach.c`: no existing Thin A15 entry
- [Phase 4] Bugzilla/lore inaccessible due to Anubis bot protection
- [Phase 5] Read `acp6x_probe()`: confirmed
`dmi_first_match(yc_acp_quirk_table)` at line 763, sets
`platform_set_drvdata` from `driver_data`
- [Phase 5] grep for "Micro-Star": 5 existing MSI entries in the table
already
- [Phase 6] File verified present in v6.1 (270 lines), v6.6 (438 lines),
v6.12 (586 lines)
- [Phase 6] File does NOT exist in v5.15 (`fatal: path ... does not
exist in 'v5.15'`)
- [Phase 6] MSI entries: 0 in v6.1, 1 in v6.6 — table framework exists
in both
- [Phase 8] Failure mode: internal microphone completely non-functional
on affected hardware
- [Phase 8] Risk: zero for non-matching hardware; worst case for
matching hardware is a no-op
- UNVERIFIED: Exact contents of bugzilla 220833 (blocked by Anubis)
- UNVERIFIED: Exact lore discussion thread (blocked by Anubis)
- UNVERIFIED: Whether the reporter's machine is truly a B7VE or B7VF
(most likely B7VE given the code)
This is a textbook stable backport candidate: a hardware quirk addition
to an existing driver's DMI table, fixing a real user-reported bug (non-
working internal microphone), with zero regression risk, accepted by the
subsystem maintainer.
**YES**
sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index c536de1bb94ad..6f1c105ca77e3 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -724,6 +724,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "BM1403CDA"),
}
},
+ {
+ .driver_data = &acp6x_card,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Thin A15 B7VE"),
+ }
+ },
{}
};
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-5.10] ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
` (5 preceding siblings ...)
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-5.10] ASoC: SOF: topology: reject invalid vendor array size in token parser Sasha Levin
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: César Montoya, Takashi Iwai, Sasha Levin, perex, tiwai,
linux-sound, linux-kernel
From: César Montoya <sprit152009@gmail.com>
[ Upstream commit 2f388b4e8fdd6b0f27cafd281658daacfd85807e ]
The HP Pavilion 15-eg0xxx with subsystem ID 0x103c87cb uses a Realtek
ALC287 codec with a mute LED wired to GPIO pin 4 (mask 0x10). The
existing ALC287_FIXUP_HP_GPIO_LED fixup already handles this correctly,
but the subsystem ID was missing from the quirk table.
GPIO pin confirmed via manual hda-verb testing:
hda-verb SET_GPIO_MASK 0x10
hda-verb SET_GPIO_DIRECTION 0x10
hda-verb SET_GPIO_DATA 0x10
Signed-off-by: César Montoya <sprit152009@gmail.com>
Link: https://patch.msgid.link/20260321153603.12771-1-sprit152009@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
All verification is complete. Here is the full analysis.
---
===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================
**Step 1.1: PARSE THE SUBJECT LINE**
Record: [ALSA: hda/realtek] [Add] [mute LED quirk for HP Pavilion
15-eg0xxx — adds missing PCI subsystem ID to the Realtek ALC287 quirk
table]
**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- Signed-off-by: César Montoya `<sprit152009@gmail.com>` — patch author
/ hardware owner
- Link: `https://patch.msgid.link/20260321153603.12771-1-
sprit152009@gmail.com` — submission link
- Signed-off-by: Takashi Iwai `<tiwai@suse.de>` — ALSA/HDA subsystem
maintainer (applied the patch)
- No Fixes: tag (expected — quirk additions rarely have one)
- No Reported-by: (author IS the affected user)
- No Cc: stable (absence expected for commits under review)
**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record: Bug: HP Pavilion 15-eg0xxx with subsystem ID 0x103c:0x87cb uses
ALC287 codec with mute LED wired to GPIO pin 4 (mask 0x10). The existing
`ALC287_FIXUP_HP_GPIO_LED` fixup already handles this correctly, but the
subsystem ID was missing from the quirk table. Symptom: mute LED does
not function at all. Root cause: missing SSID→fixup mapping. Evidence:
author confirms GPIO pin via manual `hda-verb` testing (SET_GPIO_MASK,
SET_GPIO_DIRECTION, SET_GPIO_DATA with 0x10).
**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not a hidden bug fix — this is an explicit hardware quirk
addition (a well-known stable exception category). The "bug" is that
hardware doesn't work without the quirk table entry.
===============================================================
PHASE 2: DIFF ANALYSIS — LINE BY LINE
===============================================================
**Step 2.1: INVENTORY THE CHANGES**
Record: 1 file changed: `sound/hda/codecs/realtek/alc269.c`. +1 line, -0
lines. Function modified: none (data table `alc269_fixup_tbl[]` only).
Scope: single-file, single table row — maximally surgical.
**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record: Before: subsystem ID 0x103c:0x87cb is not in
`alc269_fixup_tbl[]`, so the HDA core finds no fixup match during codec
probe, and the mute LED is never configured. After: the new
`SND_PCI_QUIRK(0x103c, 0x87cb, "HP Pavilion 15-eg0xxx",
ALC287_FIXUP_HP_GPIO_LED)` entry causes `snd_hda_pick_fixup()` to match
and apply the GPIO LED fixup during probe.
**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: Category (h) — hardware workaround / quirk table entry. The
added line is inserted in sorted order between 0x87c8 and 0x87cc (the
latter is the same laptop model name using the same fixup). The fixup
`ALC287_FIXUP_HP_GPIO_LED` is defined at line 5921 and calls
`alc287_fixup_hp_gpio_led()`, which invokes
`alc_fixup_hp_gpio_led(codec, action, 0x10, 0)` — GPIO mask 0x10 exactly
matches the commit message's hda-verb testing.
**Step 2.4: ASSESS THE FIX QUALITY**
Record: Obviously correct — identical pattern to the neighboring 0x87cc
entry for the same laptop model. Regression risk: effectively zero — the
quirk only activates on machines with PCI subsystem ID 0x103c:0x87cb. No
logic, no API, no code flow changes. No red flags.
===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================
**Step 3.1: BLAME THE CHANGED LINES**
Record: `git blame -L6868,6872` shows:
- Line 6869 (0x87c8): from `aeeb85f26c3bbe` (Takashi Iwai, 2025-07-09) —
the mass file relocation commit
- Line 6870 (0x87cc): from `7cd3c8cafbc050` (Takashi Iwai, 2025-07-21) —
merge of `9744ede7099e8` which added the 0x87cc entry
- The 0x87cb line does not exist in this tree (this is the candidate
commit adding it)
**Step 3.2: FOLLOW THE FIXES: TAG**
Record: N/A — no Fixes: tag. Expected for quirk additions.
**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record: The related commit `9744ede7099e8` ("ALSA: hda/realtek - Add
mute LED support for HP Pavilion 15-eg0xxx") added the 0x87cc entry for
the same laptop model, was written by a different author (Dawid Rezler),
explicitly carried `Cc: <stable@vger.kernel.org>`, and went into
`sound/pci/hda/patch_realtek.c` (pre-move path). It was tagged
`v6.16~13^2~3`, meaning it entered in v6.16. The current commit adds a
sibling SSID (0x87cb) for the same model. Standalone — no other patches
needed.
**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: César Montoya appears to be an end-user / first-time contributor
fixing their own hardware. Patch was accepted and signed off by Takashi
Iwai (ALSA maintainer), lending strong confidence.
**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: The only prerequisite is `ALC287_FIXUP_HP_GPIO_LED` and its
implementation `alc287_fixup_hp_gpio_led()`. These were introduced long
ago and exist in all active stable trees. No other dependencies. Fully
standalone.
===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================
**Step 4.1: SEARCH LORE.KERNEL.ORG**
Record: The commit includes a Link to
`patch.msgid.link/20260321153603.12771-1-sprit152009@gmail.com`. The
patch was a single standalone submission (not a series — "12771-1" with
no further parts). Takashi Iwai's Signed-off-by indicates direct
application by the maintainer. No NAKs or objections are evident from
the acceptance.
**Step 4.2: SEARCH FOR BUG REPORT**
Record: No separate bug report — the author is the affected user who
submitted the fix directly, confirmed via hda-verb hardware testing.
**Step 4.3: CHECK FOR RELATED PATCHES AND SERIES**
Record: Standalone single patch. The sibling 0x87cc entry (commit
`9744ede7099e8`) was a separate patch from a different author and
already carried `Cc: stable`.
**Step 4.4: CHECK STABLE MAILING LIST HISTORY**
Record: The sibling commit `9744ede7099e8` for 0x87cc already has `Cc:
stable@vger.kernel.org`, confirming the subsystem maintainer considers
this class of quirk appropriate for stable backporting.
===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================
**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: No functions modified. Only a data table entry added to
`alc269_fixup_tbl[]`.
**Step 5.2: TRACE CALLERS**
Record: The table is consumed by `snd_hda_pick_fixup()` during Realtek
ALC269-family codec probe. This is a standard, well-tested code path run
once per codec initialization.
**Step 5.3: TRACE CALLEES**
Record: When matched, the fixup definition at line 5921 invokes
`alc287_fixup_hp_gpio_led()` (line 1360), which calls
`alc_fixup_hp_gpio_led(codec, action, 0x10, 0)`. This configures GPIO
pin 4 for the mute LED — a well-tested helper used by many HP models.
**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Codec probe → `snd_hda_pick_fixup()` → table lookup →
`ALC287_FIXUP_HP_GPIO_LED` → `alc287_fixup_hp_gpio_led()` →
`alc_fixup_hp_gpio_led()`. The path is reachable on every boot for users
with this hardware.
**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: `ALC287_FIXUP_HP_GPIO_LED` appears 11 times in the file. At
least 10 other HP models use the identical fixup. This is a massively
replicated, well-tested pattern.
===============================================================
PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
===============================================================
**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?**
Record: The `ALC287_FIXUP_HP_GPIO_LED` fixup and its implementation have
been in the tree since at least v5.10-era kernels. All active stable
trees (6.1.y, 6.6.y, 6.12.y, etc.) contain the fixup infrastructure. The
only thing missing is this specific SSID table entry.
**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: The file was moved from `sound/pci/hda/patch_realtek.c` to
`sound/hda/codecs/realtek/alc269.c` in commit `6014e9021b28e`
(v6.17-rc1). Stable trees older than 6.17 need the patch applied to the
old path. The table format is identical in both locations. The fix is a
single line addition at a predictable sorted location — trivial to
adjust for either path.
**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE**
Record: The 0x87cb SSID does not appear in the current tree (confirmed
by grep), so no related fix for this specific SSID is already present.
===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================
**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: Subsystem: sound/hda (HD-Audio, Realtek codec). Criticality:
IMPORTANT — audio is critical for laptop users. This specific driver
covers a very large number of consumer laptops.
**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Extremely active — `git log` shows continuous stream of quirk
additions. Takashi Iwai actively maintains and applies these patches.
Quirk additions for HP laptops are the most common type of commit in
this file.
===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================
**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Users of HP Pavilion 15-eg0xxx laptops with PCI subsystem ID
0x103c:0x87cb and ALC287 codec. Platform-specific / driver-specific.
**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Every boot on affected hardware. The mute LED never works
without this quirk — it's not intermittent, it's permanent broken
behavior for these users.
**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: Without the fix, the mute LED does not respond. Severity: LOW
for system stability (no crash/corruption), but this is a real hardware
defect that makes the laptop's audio indicator non-functional. This is
exactly the class of hardware enablement quirk that stable trees
routinely accept.
**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record: Benefit: enables mute LED for a specific HP laptop variant —
real hardware fix for real users. Risk: essentially zero — the
`SND_PCI_QUIRK` entry only matches on the exact subsystem ID
0x103c:0x87cb, and the underlying fixup is well-tested across 10+ other
HP models. Risk-benefit ratio: very favorable.
===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================
**Step 9.1: COMPILE THE EVIDENCE**
Evidence FOR backporting:
- Single-line `SND_PCI_QUIRK` table entry addition — textbook stable
material
- Uses existing, well-tested fixup (`ALC287_FIXUP_HP_GPIO_LED`)
confirmed in 10+ other entries
- GPIO mask 0x10 in the fixup matches the author's hda-verb hardware
verification
- Neighboring entry 0x87cc for the same laptop model uses the identical
fixup
- The sibling 0x87cc commit (`9744ede7099e8`) explicitly carries `Cc:
stable@vger.kernel.org`
- Accepted by ALSA maintainer Takashi Iwai
- Fixup infrastructure exists in all active stable trees (since
v5.10-era)
- Zero regression risk (SSID-gated, affects only this specific hardware)
- Matches the "AUDIO CODEC QUIRKS" exception category explicitly listed
in stable guidelines
Evidence AGAINST backporting:
- None
Unresolved:
- Full mailing list thread content not fetched (but maintainer
acceptance is confirmed via SOB)
**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **YES** — identical pattern to dozens
of entries; hardware-verified by author via hda-verb; accepted by
subsystem maintainer
2. Fixes a real bug that affects users? **YES** — mute LED non-
functional on specific HP laptop
3. Important issue? **YES under exception** — hardware quirk for audio
codec; same class as the explicitly allowed "SND_PCI_QUIRK entries
for specific laptop models"
4. Small and contained? **YES** — 1 line, single table entry
5. No new features or APIs? **YES** — maps an existing fixup to a new
SSID
6. Can apply to stable trees? **YES** — trivially, with path adjustment
for trees < v6.17 (`sound/pci/hda/patch_realtek.c` instead of
`sound/hda/codecs/realtek/alc269.c`)
**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: Hardware quirk / audio codec quirk — explicitly listed as
automatic YES in stable guidelines. `SND_PCI_QUIRK` entries for specific
laptop models are called out by name.
**Step 9.4: MAKE YOUR DECISION**
This is a textbook hardware quirk addition — a single-line
`SND_PCI_QUIRK` entry mapping a missing PCI subsystem ID to an existing,
well-tested fixup function. It enables the mute LED on a specific HP
laptop variant. Zero regression risk, accepted by the subsystem
maintainer, underlying fixup exists in all active stable trees.
---
## Verification
- [Phase 1] Parsed tags: Signed-off-by from author (César Montoya) and
maintainer (Takashi Iwai); Link to patch submission; no
Fixes:/Reported-by: (expected for quirk)
- [Phase 2] Diff: exactly +1 line `SND_PCI_QUIRK(0x103c, 0x87cb, "HP
Pavilion 15-eg0xxx", ALC287_FIXUP_HP_GPIO_LED)` in
`alc269_fixup_tbl[]`
- [Phase 3] git blame -L6868,6872: confirmed 0x87cc at line 6870 from
`7cd3c8cafbc050`, surrounding lines from `aeeb85f26c3bbe` (file move);
0x87cb not present in current tree (grep returns no matches)
- [Phase 3] git show `9744ede7099e8`: confirmed this is the sibling
0x87cc commit for the same laptop model, with `Cc:
<stable@vger.kernel.org>`, tagged `v6.16~13^2~3`
- [Phase 3] git show `6014e9021b28e`: confirmed file moved from
`sound/pci/hda/patch_realtek.c` to `sound/hda/codecs/realtek/alc269.c`
in v6.17-rc1
- [Phase 5] Read lines 1360-1364: `alc287_fixup_hp_gpio_led()` calls
`alc_fixup_hp_gpio_led(codec, action, 0x10, 0)` — GPIO mask 0x10
matches commit message
- [Phase 5] Read lines 5921-5924: `ALC287_FIXUP_HP_GPIO_LED` fixup
definition confirmed, type `HDA_FIXUP_FUNC`
- [Phase 5] Grep: `ALC287_FIXUP_HP_GPIO_LED` appears 11 times in
alc269.c (10+ other HP models)
- [Phase 6] File path differs between mainline and stable < 6.17; table
format is identical — trivial backport adjustment
- [Phase 8] Risk: zero (SSID-gated single table entry, well-tested
existing fixup path)
**YES**
sound/hda/codecs/realtek/alc269.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 75f880efdeaf1..5adc5db6fd52b 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6868,6 +6868,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x103c, 0x8788, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED),
SND_PCI_QUIRK(0x103c, 0x87b7, "HP Laptop 14-fq0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x87cb, "HP Pavilion 15-eg0xxx", ALC287_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x87cc, "HP Pavilion 15-eg0xxx", ALC287_FIXUP_HP_GPIO_LED),
SND_PCI_QUIRK(0x103c, 0x87d3, "HP Laptop 15-gw0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
SND_PCI_QUIRK(0x103c, 0x87df, "HP ProBook 430 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED),
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-5.10] ASoC: SOF: topology: reject invalid vendor array size in token parser
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
` (6 preceding siblings ...)
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-5.10] ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19] ALSA: hda/realtek - Fixed Speaker Mute LED for HP EliteBoard G1a platform Sasha Levin
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Cássio Gabriel, Peter Ujfalusi, Mark Brown, Sasha Levin,
lgirdwood, yung-chuan.liao, ranjani.sridharan, daniel.baluta,
perex, tiwai, sound-open-firmware, linux-sound, linux-kernel
From: Cássio Gabriel <cassiogabrielcontato@gmail.com>
[ Upstream commit 215e5fe75881a7e2425df04aeeed47a903d5cd5d ]
sof_parse_token_sets() accepts array->size values that can be invalid
for a vendor tuple array header. In particular, a zero size does not
advance the parser state and can lead to non-progress parsing on
malformed topology data.
Validate array->size against the minimum header size and reject values
smaller than sizeof(*array) before parsing. This preserves behavior for
valid topologies and hardens malformed-input handling.
Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260319-sof-topology-array-size-fix-v1-1-f9191b16b1b7@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a comprehensive analysis.
===============================================================
## PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================
**Step 1.1:** Record: [ASoC: SOF: topology] [reject] [reject invalid
vendor array size in token parser to prevent non-progress parsing]
**Step 1.2:** Record: Tags present:
- Signed-off-by: Cássio Gabriel (author)
- Acked-by: Peter Ujfalusi (confirmed listed SOF maintainer in
MAINTAINERS)
- Link: patch.msgid.link URL
- Signed-off-by: Mark Brown (ASoC maintainer, merged the patch)
- No Fixes:, Reported-by:, Tested-by:, Cc: stable tags (expected for
manual review candidates)
**Step 1.3:** Record: Bug: `sof_parse_token_sets()` accepts
`array->size` values that are invalid — specifically, a zero size does
not advance parser state. Symptom: non-progress parsing (infinite loop)
on malformed topology data. Root cause: the validation only checked
`asize < 0`, which cannot catch zero or small positive values.
**Step 1.4:** Record: Yes, this is a real bug fix despite "hardens"
language. The commit fixes a concrete infinite loop scenario where
`asize == 0` causes the parser while-loop to never terminate.
===============================================================
## PHASE 2: DIFF ANALYSIS
===============================================================
**Step 2.1:** Record: 1 file changed (`sound/soc/sof/topology.c`), 1
line modified. Function modified: `sof_parse_token_sets()`.
Classification: single-file, single-line surgical fix.
**Step 2.2:** Record: Before: `if (asize < 0)` — only rejects negative
values. After: `if (asize < sizeof(*array))` — rejects any value smaller
than the vendor array header size. The FIXME comment ("A zero-size array
makes no sense") was already documenting this known deficiency.
**Step 2.3:** Record: Bug category: logic/infinite loop. The while loop
at line 735 uses `array_size -= asize` (line 746) and advances the
pointer via `array = (u8*)array + asize` (line 784). When `asize == 0`:
1. `array_size -= 0` — no change, stays positive
2. `array = array + 0` — pointer doesn't advance
3. The while condition `array_size > 0 && total < count *
token_instance_num` remains true
4. Result: **infinite loop / soft lockup**
**Step 2.4:** Record: The fix is obviously correct. `struct
snd_soc_tplg_vendor_array` has three `__le32` header fields (`size`,
`type`, `num_elems`) = 12 bytes minimum, plus a flex array union. Any
valid array must be at least `sizeof(*array)` bytes. Note on type
promotion: `asize` is `int`, `sizeof(*)` is `size_t`. A negative `asize`
promotes to a very large unsigned value, so `asize < sizeof(*)` would be
false — but negative `asize` is still caught by the subsequent
`array_size -= asize; if (array_size < 0)` check at line 747, so no
regression.
===============================================================
## PHASE 3: GIT HISTORY INVESTIGATION
===============================================================
**Step 3.1:** Record: `git blame` confirms the buggy `if (asize < 0)`
check was introduced in commit `311ce4fe7637d9` ("ASoC: SOF: Add support
for loading topologies") by Liam Girdwood, 2019-04-12. `git describe
--contains` shows this is `v5.2-rc1`. The bug has been present since
**v5.2** — all active stable trees contain it.
**Step 3.2:** Record: No Fixes: tag present. The buggy commit is
`311ce4fe7637d9`.
**Step 3.3:** Record: `git log --oneline -20` shows active development
but no related prerequisite or duplicate fix for this specific issue.
**Step 3.4:** Record: Peter Ujfalusi (Acked-by) is a listed maintainer
for SOF in MAINTAINERS. Mark Brown signed off as ASoC subsystem
maintainer. Strong maintainer endorsement.
**Step 3.5:** Record: No dependencies. The fix changes one condition in
an existing function with no new types, helpers, or APIs needed.
===============================================================
## PHASE 4: MAILING LIST RESEARCH
===============================================================
Record: The patch.msgid.link and lore.kernel.org URLs are blocked by
Anubis bot protection in this environment. However, the patch was Acked
by a listed SOF maintainer (Peter Ujfalusi) and merged by the ASoC
maintainer (Mark Brown), providing strong review signal.
===============================================================
## PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================
**Step 5.1:** Record: Modified function: `sof_parse_token_sets()`
**Step 5.2:** Record: `sof_parse_token_sets()` is called from:
1. `sof_parse_tokens()` — a wrapper called from ~9 locations throughout
topology.c (control load, widget parsing, DAI load, link load,
DSPless widget paths)
2. `sof_parse_pin_binding()` — direct call for pin binding token parsing
This is a heavily-used core parsing function in the SOF topology loader.
**Step 5.3-5.4:** Record: The call chain is: `sof_pcm_probe()` →
`snd_sof_load_topology()` → `snd_soc_tplg_component_load()` → SOF
callbacks (widget_ready, dai_load, link_load, control_load) →
`sof_parse_tokens()` → `sof_parse_token_sets()`. This is triggered
during SOF audio component probe when topology firmware blobs are
loaded.
**Step 5.5:** Record: The **same weak check** (`if (asize < 0)`) exists
in `sof_copy_tuples()` at line 544, with identical loop structure and
pointer advancement at line 610. This sibling function has the same
vulnerability but is NOT fixed by this commit. This means the patch is
not a complete fix across all SOF topology parsing paths, but it does
fix the specific path through `sof_parse_token_sets()`.
===============================================================
## PHASE 6: STABLE TREE ANALYSIS
===============================================================
**Step 6.1:** Record: The buggy code was introduced in v5.2. All active
stable trees (5.4.y, 5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y) contain this
vulnerable code.
**Step 6.2:** Record: Expected clean or trivial backport — the `if
(asize < 0)` line with the FIXME comment hasn't changed since
introduction.
**Step 6.3:** Record: No duplicate or alternative fix found for this
exact issue in git history.
===============================================================
## PHASE 7: SUBSYSTEM CONTEXT
===============================================================
**Step 7.1:** Record: Subsystem: sound/soc/sof (Sound Open Firmware).
Criticality: IMPORTANT — SOF is used on most modern Intel laptops for
audio hardware.
**Step 7.2:** Record: Active subsystem with regular commits.
===============================================================
## PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================
**Step 8.1:** Record: Affected users: SOF audio hardware users (very
common on Intel-based laptops/desktops).
**Step 8.2:** Record: Trigger: malformed/corrupt SOF topology blob with
`array->size == 0` (or < header size). Topology files are loaded from
firmware path during driver probe. Trigger requires corrupt or
maliciously crafted topology data — uncommon in normal operation but
possible from disk corruption or adversarial input.
**Step 8.3:** Record: Failure mode: infinite loop in kernel context →
soft lockup → system hang during audio driver probe. Severity: HIGH
(system hang, unavailability).
**Step 8.4:** Record:
- **Benefit:** Prevents a real infinite loop / system hang. The FIXME
comment proves the developer knew this was broken. Low-medium benefit
(real hang, but only on malformed input).
- **Risk:** Very low. Single condition change; valid topologies always
have `asize >= sizeof(*array)`. No regression for valid data. Acked by
subsystem maintainer.
- **Ratio:** Favorable — high confidence in correctness, near-zero
regression risk, fixes real hang.
===============================================================
## PHASE 9: FINAL SYNTHESIS
===============================================================
**Step 9.1: Evidence compilation**
FOR backporting:
- Fixes a concrete infinite loop (system hang) — the FIXME comment
proves this was a known deficiency
- Single-line, obviously correct fix
- Acked by listed SOF subsystem maintainer (Peter Ujfalusi)
- Merged by ASoC maintainer (Mark Brown)
- Bug present since v5.2 — exists in all active stable trees
- Near-zero regression risk for valid topologies
- `sof_parse_token_sets()` is called from ~10 locations — well-used code
path
AGAINST backporting:
- Trigger requires malformed topology data (not normal operation)
- No user/syzbot crash report — found by code inspection
- The parallel `sof_copy_tuples()` function retains the same weak check
(incomplete coverage)
- SOF is important but not core kernel — affects hardware-specific users
**Step 9.2: Stable rules checklist**
1. Obviously correct and tested? **YES** — maintainer acked, trivially
verifiable from code
2. Fixes a real bug? **YES** — infinite loop on malformed input
(acknowledged by FIXME comment)
3. Important issue? **YES** — system hang (soft lockup), HIGH severity
4. Small and contained? **YES** — 1 line changed, 1 function, 1 file
5. No new features or APIs? **YES**
6. Can apply to stable trees? **YES** — identical code in all stable
trees
**Step 9.3:** Record: No exception category — standard bug fix.
**Step 9.4: Decision**
This commit fixes a real, documented infinite loop bug (the original
code even had a FIXME acknowledging the problem). The fix is a single-
line minimum-size validation, acked by the subsystem maintainer, with
near-zero regression risk. While the trigger requires malformed topology
data, a system hang is a serious failure mode — stable kernels should
handle invalid input gracefully without hanging. The incomplete coverage
of the sibling function `sof_copy_tuples()` does not diminish the value
of fixing this specific path. The fix meets all stable kernel criteria.
## Verification
- [Phase 1] Parsed all tags from supplied commit message: Acked-by Peter
Ujfalusi, Signed-off-by Mark Brown, Link to patch.msgid.link
- [Phase 1] Verified Peter Ujfalusi is listed as maintainer in
MAINTAINERS under "SOUND - SOUND OPEN FIRMWARE (SOF) DRIVERS"
- [Phase 2] Read `sof_parse_token_sets()` (lines 724-793): confirmed
while loop at line 735, `array_size -= asize` at line 746, pointer
advance `(u8*)array + asize` at line 784 — `asize == 0` causes
infinite loop
- [Phase 2] Verified `struct snd_soc_tplg_vendor_array` in
`include/uapi/sound/asoc.h` (line 220): three `__le32` fields (`size`,
`type`, `num_elems`) + flex array union — `sizeof(*array)` is the
correct minimum header size
- [Phase 2] Verified type safety: `int asize` compared against `size_t
sizeof(*)` — negative values promote to large unsigned (caught by
subsequent `array_size < 0` check at line 747)
- [Phase 3] git blame: buggy `if (asize < 0)` line attributed to commit
`311ce4fe7637d9` (Liam Girdwood, 2019-04-12)
- [Phase 3] git describe: `311ce4fe7637d9` first appeared in `v5.2-rc1`
— bug present in all active stable trees
- [Phase 3] git log -20: no prerequisites or duplicate fixes found
- [Phase 5] grep callers: `sof_parse_token_sets()` called from
`sof_parse_tokens()` (~9 call sites) and `sof_parse_pin_binding()` (1
call site)
- [Phase 5] grep: found same weak `if (asize < 0)` check in sibling
`sof_copy_tuples()` at line 544, with identical loop/advance pattern
at line 610 — NOT fixed by this commit
- [Phase 6] Buggy code unchanged since v5.2 — clean backport expected to
all active stable trees
- [Phase 8] Failure mode: infinite loop in kernel context → soft
lockup/system hang during topology load. Severity: HIGH
- UNVERIFIED: Lore discussion content (blocked by Anubis protection)
- UNVERIFIED: Whether unprivileged users can trigger topology loading on
specific distributions
- UNVERIFIED: Exact runtime `sizeof(struct snd_soc_tplg_vendor_array)`
(struct is `__packed` with flex array — compile-time verification not
performed)
**YES**
sound/soc/sof/topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index 9bf8ab610a7ea..8880ac5d8d6ff 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -736,7 +736,7 @@ static int sof_parse_token_sets(struct snd_soc_component *scomp,
asize = le32_to_cpu(array->size);
/* validate asize */
- if (asize < 0) { /* FIXME: A zero-size array makes no sense */
+ if (asize < sizeof(*array)) {
dev_err(scomp->dev, "error: invalid array size 0x%x\n",
asize);
return -EINVAL;
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19] ALSA: hda/realtek - Fixed Speaker Mute LED for HP EliteBoard G1a platform
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
` (7 preceding siblings ...)
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-5.10] ASoC: SOF: topology: reject invalid vendor array size in token parser Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add HP Laptop 15-fd0xxx mute LED quirk Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.6] ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EAC Sasha Levin
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Kailang Yang, Chris Chiu, Takashi Iwai, Sasha Levin, perex, tiwai,
linux-sound, linux-kernel
From: Kailang Yang <kailang@realtek.com>
[ Upstream commit d3be95efc6a1e03230ef646b498050152efe2888 ]
On the HP EliteBoard G1a platform (models without a headphone jack).
the speaker mute LED failed to function. The Sysfs ctl-led info showed
empty values because the standard LED registration couldn't correctly
bind to the master switch.
Adding this patch will fix and enable the speaker mute LED feature.
Tested-by: Chris Chiu <chris.chiu@canonical.com>
Signed-off-by: Kailang Yang <kailang@realtek.com>
Link: https://lore.kernel.org/279e929e884849df84687dbd67f20037@realtek.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject Line
Record: [ALSA: hda/realtek] [Fixed] [Speaker mute LED not working on HP
EliteBoard G1a, models without headphone jack]
### Step 1.2: Tags
- **Tested-by**: Chris Chiu <chris.chiu@canonical.com> — Canonical
developer verified the fix on real hardware
- **Signed-off-by**: Kailang Yang <kailang@realtek.com> — author is from
Realtek, the codec vendor
- **Link**:
https://lore.kernel.org/279e929e884849df84687dbd67f20037@realtek.com
- **Signed-off-by**: Takashi Iwai <tiwai@suse.de> — ALSA subsystem
maintainer accepted it
- No Fixes:, Reported-by:, Cc: stable tags (expected for this review
pipeline)
Record: Tested-by from Canonical, author is Realtek vendor engineer,
accepted by ALSA maintainer. No Fixes: tag.
### Step 1.3: Commit Body
Record: Bug: On HP EliteBoard G1a (models without headphone jack), the
speaker mute LED fails to function. Sysfs `ctl-led` info shows empty
values because the standard LED registration couldn't bind to the master
switch. Symptom: Non-functional mute LED. Root cause: The LED classdev
registration mechanism doesn't work properly when there is no HP pin on
the platform.
### Step 1.4: Hidden Bug Fix
Record: Not hidden — explicitly labeled as a "Fixed" in the subject.
This is a straightforward hardware quirk fix.
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Inventory
- **Files changed**: 1 — `sound/hda/codecs/realtek/alc269.c`
- **Lines**: ~20 added, ~1 removed (net +19)
- **Functions**: New `alc245_hp_spk_mute_led_update()`; modified
`alc245_tas2781_i2c_hp_fixup_muteled()`
- **Scope**: Single-file, surgical fix
Record: 1 file, ~20 lines added, 1 function modified, 1 small helper
added. Single-file surgical fix.
### Step 2.2: Code Flow Change
**New function `alc245_hp_spk_mute_led_update()`**: A vmaster hook
callback that writes COEF register 0x0b with mask 0x0c, setting 0x08
when `enabled=1` and 0x04 when `enabled=0`.
**Modified `alc245_tas2781_i2c_hp_fixup_muteled()`**:
- **Before**: Always called `alc245_fixup_hp_mute_led_coefbit()` after
TAS2781 fixup, which registers a LED classdev via
`snd_hda_gen_add_mute_led_cdev()`.
- **After**: Reads `alc_get_hp_pin(spec)` at function entry. If no HP
pin: sets `vmaster_mute.hook` to the new direct-write function, sets
`vmaster_mute_led = 1`, syncs LED state during `HDA_FIXUP_ACT_INIT`.
Only calls `alc245_fixup_hp_mute_led_coefbit()` if `hp_pin` is non-
zero.
Record: Before: always uses LED classdev path. After: uses direct
vmaster hook when no HP pin, LED classdev when HP pin present.
### Step 2.3: Bug Mechanism
Record: [Hardware workaround]. The standard LED classdev registration
via `snd_hda_gen_add_mute_led_cdev()` cannot bind properly to the master
switch on platforms without a headphone pin. The fix bypasses the
classdev and uses the `vmaster_mute.hook` mechanism for direct register
control.
### Step 2.4: Fix Quality — Polarity and Probe Ordering Analysis
**Polarity concern**: The existing `alc245_fixup_hp_mute_led_coefbit`
path uses the LED classdev, which turns LED ON (writes 0x08) when audio
is MUTED. The new vmaster hook path writes 0x08 when `enabled=1` (audio
NOT muted). This is an apparent polarity inversion. However, the
`vmaster_mute.hook` convention (seen in analog.c, conexant.c,
senarytech.c) passes `enabled=1` for unmuted, `enabled=0` for muted — so
the new function maps unmuted → 0x08 (LED on), muted → 0x04 (LED off).
This is opposite to the mute-LED convention but may be intentionally
correct for this specific hardware platform. The Tested-by from Chris
Chiu confirms correct behavior on the target hardware.
**Probe ordering concern**: `alc_get_hp_pin(spec)` reads
`spec->gen.autocfg.hp_pins[0]`, which is populated by
`alc269_parse_auto_config()`. During `HDA_FIXUP_ACT_PRE_PROBE` (line
8595), this function runs BEFORE `alc269_parse_auto_config()` (line
8603), meaning `hp_pins[0]` is always 0 at PRE_PROBE time. This means
`!hp_pin` is ALWAYS true during PRE_PROBE, so the vmaster hook path
activates for ALL platforms using this fixup, not just no-HP models.
However, during INIT (which runs after autocfg parsing), `hp_pin`
correctly reflects the actual hardware. The `if (!hp_pin)` check in the
INIT case correctly gates the LED sync.
Record: Two technical concerns: (1) apparent LED polarity inversion vs
standard convention, (2) probe ordering means hp_pin check is always
true during PRE_PROBE. Both are mitigated by Tested-by on real hardware,
vendor authorship, and maintainer acceptance.
---
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: Blame
`alc245_tas2781_i2c_hp_fixup_muteled` was introduced by commit
`9afbbf4903228c` (Kailang Yang, 2025-11-20, "ALSA: hda/realtek - Enable
Mute LED and Tas2781 for HP platform"). The commit first appeared in
v6.19-rc1. The ZBook 8 G2a entries (0x8f40, 0x8f41, 0x8f42, 0x8f62) were
also added by the same commit.
Record: Function introduced in 9afbbf4903228c, v6.19-rc1 (2025-11-20),
by same author.
### Step 3.2: Fixes Tag
No Fixes: tag present. If one existed, it would logically point to
`9afbbf4903228c`.
Record: N/A — no Fixes tag.
### Step 3.3: File History
Recent `alc269.c` history shows very active development with many quirk
additions and LED fixes. No intermediate fixes for this specific
function were found.
Record: Standalone fix, no visible prerequisites beyond 9afbbf4903228c.
### Step 3.4: Author
Kailang Yang (Realtek) is the codec vendor engineer and a frequent
contributor to this driver. He authored the original function
(9afbbf4903228c), the ZBook LED commit (500372aeb556a), and several
other Realtek fixes. Takashi Iwai (ALSA maintainer) accepted the patch.
Record: Author is the Realtek codec vendor engineer — maximum authority
for codec-specific behavior.
### Step 3.5: Dependencies
- Depends on `alc245_tas2781_i2c_hp_fixup_muteled()` from 9afbbf4903228c
- Depends on `ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED` and associated
SND_PCI_QUIRK entries
- All present in v6.19, absent from v6.18 and older
Record: Dependencies all exist in 6.19.y. Cannot apply to older stable
trees.
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1: Lore
Lore link in the commit points to internal Realtek email;
lore.kernel.org was blocked by Anubis bot protection. Could not access
patch discussion.
Record: UNVERIFIED — could not access lore discussion.
### Step 4.2: Bug Report
**Ubuntu Launchpad Bug #2136846** ("Fix speaker mute and mic mute leds
on a HP EliteBoard G1a") was found and fetched. Key findings:
- Filed by Chris Chiu (the Tested-by person) on 2025-12-19
- Platform: HP NexusX (SSID 0x103c:0x8e8a) using Realtek ALC3315+TAS2783
- The initial upstream fix (fd324768eb2c "ALSA: hda/tas2781: Add new
quirk for HP new project") was insufficient — **Comment #3** from
Chris Chiu: "Verified... the mic-mute led works but the mute led does
not."
- The candidate commit is the follow-up to address the remaining speaker
mute LED issue
- Ubuntu tracked this as an OEM-priority bug and it was marked "Fix
Released" for linux-oem-6.17 and later confirmed "6.19 has it"
Record: Real-world bug confirmed by Ubuntu Launchpad #2136846. Mic-mute
LED worked after first fix, speaker mute LED still broken — this commit
is the specific follow-up fix.
### Step 4.3-4.4: Related Patches and Stable History
No direct stable-mailing-list discussion found. The Launchpad bug shows
Ubuntu already backported the earlier fix to linux-oem-6.17.
Record: Ubuntu already backported related fixes to their OEM kernel.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: Key Functions
- `alc245_hp_spk_mute_led_update()` (new) — vmaster hook for direct LED
control
- `alc245_tas2781_i2c_hp_fixup_muteled()` (modified) — fixup function
### Step 5.2: Callers
`alc245_tas2781_i2c_hp_fixup_muteled` is called via the fixup table
entry `ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED`, triggered by SND_PCI_QUIRK
entries for:
- HP NexusX (0x103c, 0x8e8a)
- HP ZBook 8 G2a 14/16/14W/16W (0x103c, 0x8f40/8f41/8f42/8f62)
The new hook function is called by the generic vmaster framework during
Master Playback Switch changes.
Record: Called from quirk table for 5 specific HP platform SSIDs. Well-
defined scope.
### Step 5.3: Callees
- `alc_update_coef_idx()` — standard codec coefficient register update,
used 64+ times in this file
- `alc_get_hp_pin()` — reads `spec->gen.autocfg.hp_pins[0]` or
line_out_pins[0] if type is HP
### Step 5.4: Call Chain
PCI SSID match → `alc245_tas2781_i2c_hp_fixup_muteled` (PRE_PROBE/INIT)
→ `vmaster_mute.hook` set → generic HDA build connects hook to Master
Playback Switch → hook fires on mute state change. Reachable from
userspace ALSA mixer controls and platform hotkeys.
Record: Path reachable from userspace mixer and hardware mute button.
### Step 5.5: Similar Patterns
The `vmaster_mute.hook` mechanism is used in 4+ other codec drivers
(analog, conexant, senarytech, ca0132). The pattern of direct COEF
register writes for LED control is standard in the Realtek driver.
Record: Uses well-established patterns from multiple codec drivers.
---
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
### Step 6.1: Code Existence in Stable Trees
- **v6.19**: `alc245_tas2781_i2c_hp_fixup_muteled` EXISTS (verified via
`git show v6.19:...`)
- **v6.18**: DOES NOT EXIST (verified, returns 0 matches)
- **v6.12**: DOES NOT EXIST (verified, returns 0 matches)
- `9afbbf4903228c` is ancestor of v6.19 but NOT ancestor of v6.18
Record: **Only 6.19.y contains the buggy code.** Not applicable to
6.18.y, 6.12.y, 6.6.y, 6.1.y, or any older LTS trees.
### Step 6.2: Backport Complications
For 6.19.y: The function body in v6.19 matches the pre-patch context of
the diff. Should apply cleanly.
Record: Clean apply expected for 6.19.y only.
### Step 6.3: Related Fixes in Stable
No related fixes for this specific issue already in stable.
Record: No duplicate fixes.
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: Subsystem Criticality
- Subsystem: sound/hda/codecs/realtek — HDA audio codec driver
- Criticality: IMPORTANT for affected laptops/workstations (audio is
user-facing), but driver-specific
Record: IMPORTANT subsystem, driver-specific fix.
### Step 7.2: Subsystem Activity
The file is extremely active with constant quirk additions and LED
fixes. This is routine maintenance for the Realtek codec driver.
Record: Highly active subsystem; mute LED fixes are common and routine.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: Affected Users
HP EliteBoard G1a (NexusX) and potentially HP ZBook 8 G2a users running
6.19.y stable kernels with the `ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED`
fixup.
Record: Driver-specific, affects users of specific HP platforms on
6.19.y.
### Step 8.2: Trigger Conditions
The bug triggers on every boot — the mute LED simply never works. 100%
reproducible on affected hardware.
Record: Always triggers on affected hardware. Confirmed reproducible by
Launchpad bug.
### Step 8.3: Failure Mode Severity
Non-functional speaker mute LED. Audio mute/unmute itself works
correctly. This is a LOW severity user experience issue — no crash, no
data corruption, no security impact.
Record: Severity LOW — non-functional LED indicator.
### Step 8.4: Risk-Benefit Ratio
- **Benefit**: LOW-MEDIUM — fixes user-visible hardware feature on
specific HP platforms. Ubuntu tracked this as OEM-priority.
- **Risk**: LOW — only activates for specific HP platform SSIDs. ~20
lines, single file. Tested on real hardware. The probe ordering
concern means the vmaster hook path activates for ALL platforms using
this fixup (including ZBook), but the worst-case failure mode is wrong
LED polarity on those platforms (still LOW severity).
- **Ratio**: Favorable — low risk, clear benefit for affected users.
Record: Benefit > Risk. Small, well-tested change with bounded failure
modes.
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence Summary
**FOR backporting:**
- Fixes a real user-facing issue confirmed by Ubuntu Launchpad bug
#2136846
- Hardware quirk/workaround — explicitly allowed in stable rules
- Small, surgical change (~20 lines, single file)
- Author is the Realtek codec vendor engineer (maximum authority)
- Tested-by from Canonical developer (Chris Chiu) on real hardware
- Accepted by ALSA maintainer (Takashi Iwai)
- Uses well-established `vmaster_mute.hook` mechanism (4+ codec drivers)
- Applies cleanly to 6.19.y
- Ubuntu already prioritized the underlying bug as OEM-priority
**AGAINST backporting:**
- Severity is LOW (LED malfunction, not crash/security/corruption)
- Only applicable to 6.19.y (code doesn't exist in older stable trees)
- Probe ordering issue: `alc_get_hp_pin()` always returns 0 during
PRE_PROBE, meaning the vmaster hook path activates for ALL platforms
using this fixup, not just no-HP models
- LED polarity in the vmaster hook appears inverted from the standard
LED classdev convention
- Code is only ~4 months old (introduced in v6.19-rc1)
### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** Tested-by present, but probe
ordering question makes it not 100% "obviously correct" from code
inspection alone. The polarity inversion is either intentional for
this hardware or a concern. The Tested-by and maintainer acceptance
provide practical confidence.
2. **Fixes a real bug?** YES — confirmed by Launchpad bug and Tested-by
3. **Important issue?** Borderline — LED malfunction is low severity,
but it's a real user-visible hardware issue
4. **Small and contained?** YES — ~20 lines, single file
5. **No new features or APIs?** YES — hardware workaround only
6. **Can apply to stable?** YES — to 6.19.y only
### Step 9.3: Exception Categories
This falls squarely into the **hardware quirk/workaround** exception
category. Audio codec quirks for specific platforms are routinely
backported to stable and are explicitly listed as acceptable in stable
rules.
### Step 9.4: Decision
This is a hardware quirk fix for specific HP platforms, authored by the
Realtek codec vendor, tested on real hardware by Canonical, and accepted
by the ALSA maintainer. While there are legitimate technical concerns
about probe ordering (the `alc_get_hp_pin()` check at PRE_PROBE time)
and LED polarity inversion compared to the standard path, the worst-case
failure mode for any regression is wrong LED behavior (LOW severity),
and the fix was verified working on the target hardware. Hardware quirks
are explicitly allowed in stable, and the fix is only applicable to
6.19.y where the prerequisite code exists. The Ubuntu Launchpad bug
confirms this is a real user-facing issue that was tracked as OEM-
priority.
---
## Verification
- [Phase 1] Parsed commit message and tags from provided text: Tested-by
Chris Chiu (Canonical), SOB from Kailang Yang (Realtek) and Takashi
Iwai (ALSA maintainer), Link to lore
- [Phase 2] Read `sound/hda/codecs/realtek/alc269.c` lines 3700-3719
(pre-patch function), lines 1540-1554
(`alc245_fixup_hp_mute_led_coefbit` showing coef values: idx=0x0b,
mask=3<<2=0x0c, on=2<<2=0x08, off=1<<2=0x04)
- [Phase 2] Read `sound/hda/codecs/realtek/alc269.c` lines 1481-1491
(`coef_mute_led_set` → `alc_update_coef_led` using polarity +
brightness)
- [Phase 2] Read `sound/hda/codecs/realtek/alc269.c` lines 1470-1479
(`alc_update_coef_led` logic: if polarity, invert; write on/off based
on boolean)
- [Phase 2] Verified vmaster hook semantics: `sound/core/vmaster.c` line
515: `master->hook(master->hook_private_data, master->val)` —
`master->val` for boolean is 1=unmuted, 0=muted
- [Phase 2] Verified `snd_hda_gen_add_mute_led_cdev()` at
`sound/hda/codecs/generic.c` lines 3952-3971: sets
`vmaster_mute_led=1`, checks `if (spec->vmaster_mute.hook)` and prints
error if already present
- [Phase 2] Confirmed polarity: new hook writes 0x08 when enabled=1
(unmuted), 0x04 when enabled=0 (muted) — opposite to LED classdev
convention where brightness=1 (LED on) means muted
- [Phase 2] Verified probe ordering: `alc269.c` line 8595
(`snd_hda_apply_fixup PRE_PROBE`) runs BEFORE line 8603
(`alc269_parse_auto_config`), so autocfg.hp_pins is zero during
PRE_PROBE
- [Phase 2] Verified `alc_get_hp_pin()` at `realtek.c` lines 506-513:
reads from `spec->gen.autocfg.hp_pins[0]` and `line_out_pins[0]`, both
empty during PRE_PROBE
- [Phase 2] Cross-checked with existing vmaster hooks:
`ad_vmaster_eapd_hook` (analog.c:131) and `senary_auto_vmaster_hook`
(senarytech.c:112) both use `enabled=1` → active, confirming
convention
- [Phase 3] `git blame -L 3703,3719`: confirmed all lines from
`9afbbf4903228c` (Kailang Yang, 2025-11-20)
- [Phase 3] `git show 9afbbf4903228c`: confirmed subject "Enable Mute
LED and Tas2781 for HP platform", 56 lines added, 10 removed
- [Phase 3] `git blame -L 7155,7162`: confirmed ZBook entries
(0x8f40-0x8f62) also from `9afbbf4903228c`, NexusX also from same
commit
- [Phase 3] `git log --author='Kailang Yang' -15`: confirmed frequent
contributor with related commits
- [Phase 4] Fetched Ubuntu Launchpad Bug #2136846: confirmed real bug,
NexusX platform, comment #3 "mic-mute led works but the mute led does
not" after initial upstream fix
- [Phase 5] Grep `ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED`: found 5
SND_PCI_QUIRK entries and fixup table definition
- [Phase 5] Grep `vmaster_mute.hook`: confirmed usage in analog.c,
conexant.c, senarytech.c — well-established pattern
- [Phase 6] `git merge-base --is-ancestor 9afbbf4903228c v6.19` → YES
- [Phase 6] `git merge-base --is-ancestor 9afbbf4903228c v6.18` → NOT
ancestor
- [Phase 6] `git show v6.19:sound/hda/codecs/realtek/alc269.c | grep
alc245_tas2781_i2c_hp_fixup_muteled` → found (exists in v6.19)
- [Phase 6] `git show v6.18:...` and `v6.12:...` → 0 matches (does not
exist in older trees)
- [Phase 6] Fixup table entry confirmed: `.type = HDA_FIXUP_FUNC,
.v.func = alc245_tas2781_i2c_hp_fixup_muteled` — no chaining to other
fixups
- UNVERIFIED: Could not access lore.kernel.org discussion due to Anubis
bot protection
- UNVERIFIED: Whether all ZBook 8 G2a models actually have headphone
jacks (if they don't, the probe ordering concern is moot)
- UNVERIFIED: Whether the LED polarity inversion is intentional for this
hardware family or a latent bug (Tested-by and maintainer acceptance
suggest intentional, but not confirmed)
**YES**
sound/hda/codecs/realtek/alc269.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 1054191d56fa1..0c710daa945ec 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -3699,22 +3699,42 @@ static void alc245_tas2781_spi_hp_fixup_muteled(struct hda_codec *codec,
alc_fixup_hp_gpio_led(codec, action, 0x04, 0x0);
alc285_fixup_hp_coef_micmute_led(codec, fix, action);
}
+
+static void alc245_hp_spk_mute_led_update(void *private_data, int enabled)
+{
+ struct hda_codec *codec = private_data;
+ unsigned int val;
+
+ val = enabled ? 0x08 : 0x04; /* 0x08 led on, 0x04 led off */
+ alc_update_coef_idx(codec, 0x0b, 0x0c, val);
+}
+
/* JD2: mute led GPIO3: micmute led */
static void alc245_tas2781_i2c_hp_fixup_muteled(struct hda_codec *codec,
const struct hda_fixup *fix, int action)
{
struct alc_spec *spec = codec->spec;
+ hda_nid_t hp_pin = alc_get_hp_pin(spec);
static const hda_nid_t conn[] = { 0x02 };
switch (action) {
case HDA_FIXUP_ACT_PRE_PROBE:
+ if (!hp_pin) {
+ spec->gen.vmaster_mute.hook = alc245_hp_spk_mute_led_update;
+ spec->gen.vmaster_mute_led = 1;
+ }
spec->gen.auto_mute_via_amp = 1;
snd_hda_override_conn_list(codec, 0x17, ARRAY_SIZE(conn), conn);
break;
+ case HDA_FIXUP_ACT_INIT:
+ if (!hp_pin)
+ alc245_hp_spk_mute_led_update(codec, !spec->gen.master_mute);
+ break;
}
tas2781_fixup_txnw_i2c(codec, fix, action);
- alc245_fixup_hp_mute_led_coefbit(codec, fix, action);
+ if (hp_pin)
+ alc245_fixup_hp_mute_led_coefbit(codec, fix, action);
alc285_fixup_hp_coef_micmute_led(codec, fix, action);
}
/*
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add HP Laptop 15-fd0xxx mute LED quirk
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
` (8 preceding siblings ...)
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19] ALSA: hda/realtek - Fixed Speaker Mute LED for HP EliteBoard G1a platform Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.6] ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EAC Sasha Levin
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Kshamendra Kumar Mishra, Takashi Iwai, Sasha Levin, perex, tiwai,
linux-sound, linux-kernel
From: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com>
[ Upstream commit faceb5cf5d7a08f4a40335d22d833bb75f05d99e ]
HP Laptop 15-fd0xxx with ALC236 codec does not handle the toggling of
the mute LED.
This patch adds a quirk entry for subsystem ID 0x8dd7 using
ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup, enabling correct mute LED
behavior.
Signed-off-by: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com>
Link: https://patch.msgid.link/DHAB51ISUM96.2K9SZIABIDEQ0@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the facts needed. Here is my comprehensive answer:
---
## Phase 1: Commit Message Forensics
**Step 1.1: Parse the Subject Line**
Record: [ALSA: hda/realtek] [add] [HP Laptop 15-fd0xxx mute LED quirk —
adds SND_PCI_QUIRK entry for subsystem ID 0x103c:0x8dd7 using existing
ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup]
**Step 1.2: Parse All Commit Message Tags**
Record:
- `Signed-off-by: Kshamendra Kumar Mishra
<kshamendrakumarmishra@gmail.com>` — author
- `Link: https://patch.msgid.link/DHAB51ISUM96.2K9SZIABIDEQ0@gmail.com`
— patch submission reference
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>` — ALSA subsystem
maintainer
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
by:`, or `Cc: stable@vger.kernel.org` (expected for manual review
candidates)
**Step 1.3: Analyze the Commit Body Text**
Record: Bug: HP Laptop 15-fd0xxx with ALC236 codec does not handle mute
LED toggling. Symptom: Mute LED does not reflect mute state. Root cause:
Missing SSID-to-fixup mapping in the quirk table. Fix: Add entry for
subsystem ID 0x8dd7 pointing to existing
`ALC236_FIXUP_HP_MUTE_LED_COEFBIT2`.
**Step 1.4: Detect Hidden Bug Fixes**
Record: Not a hidden bug fix — this is an explicit hardware quirk
addition. The message directly describes a non-working mute LED and the
fixup that corrects it.
## Phase 2: Diff Analysis
**Step 2.1: Inventory the Changes**
Record: `sound/hda/codecs/realtek/alc269.c`: +1 line, -0 lines. Single
`SND_PCI_QUIRK` entry added to `alc269_fixup_tbl[]` between existing
entries 0x8dd4 and 0x8de8. Scope: single-file, single-line, table-data-
only.
**Step 2.2: Understand the Code Flow Change**
Record: Before: No quirk entry for 0x103c:0x8dd7; `snd_hda_pick_fixup()`
cannot select `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` for this machine, so
the mute LED is not properly controlled. After: The SSID match triggers
the existing fixup during codec probe, enabling correct mute LED
behavior.
**Step 2.3: Identify the Bug Mechanism**
Record: Bug category: Hardware workaround / missing quirk entry. The
`alc236_fixup_hp_mute_led_coefbit2()` helper programs
`spec->mute_led_coef.idx = 0x07`, `mask = 1`, `on = 1`, `off = 0` and
registers `coef_mute_led_set` via `snd_hda_gen_add_mute_led_cdev()`.
This is an existing, well-tested code path used by 17 other entries in
this file.
**Step 2.4: Assess the Fix Quality**
Record: Obviously correct — identical pattern to many existing HP ALC236
quirk entries. Minimal and surgical. Regression risk is effectively zero
since the new entry only matches one specific subsystem ID and uses an
existing, well-exercised fixup chain.
## Phase 3: Git History Investigation
**Step 3.1: Blame the Changed Lines**
Record: The neighboring entries (0x8dd4 at line 7099, 0x8de8 at line
7100) confirm the correct insertion point. The new 0x8dd7 entry is not
present in the current tree (verified by grep).
**Step 3.2: Follow the Fixes Tag**
Record: N/A — no `Fixes:` tag present.
**Step 3.3: Check File History for Related Changes**
Record: Recent `alc269.c` history shows a steady stream of similar
Realtek quirk additions (Acer, Samsung, HP models). This is a standalone
one-line addition — no patch series marker found.
**Step 3.4: Check the Author's Other Commits**
Record: The accepting maintainer is Takashi Iwai (`tiwai@suse.de`), the
long-standing ALSA maintainer, providing strong endorsement of this
quirk.
**Step 3.5: Check for Dependent/Prerequisite Commits**
Record: The prerequisite helper `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` was
introduced by commit `0659400f18c0e6` ("ALSA: hda/realtek: Enable Mute
LED on HP Laptop 15s-eq2xxx") which first appeared in `v6.5`. That
commit itself had `Cc: stable@vger.kernel.org`. The helper exists in
v6.5+, v6.6, and v6.19. It does **not** exist in v6.1 or v5.15.
## Phase 4: Mailing List and External Research
**Step 4.1: Search Lore**
Record: The `patch.msgid.link` URL returned an anti-bot page. Could not
retrieve the actual patch discussion thread. UNVERIFIED: exact reviewer
comments or stable nominations.
**Step 4.2: Search for Bug Report**
Record: No `Reported-by:` or bugzilla link. The only bug description is
in the commit message itself.
**Step 4.3: Check for Related Patches**
Record: This is a standalone single-line quirk addition, not part of a
multi-patch series.
**Step 4.4: Check Stable Mailing List**
Record: Similar HP Realtek mute LED quirks have been backported to
stable before (e.g., the original `0659400f18c0e6` helper commit had
`Cc: stable`). No specific stable discussion found for this exact patch.
## Phase 5: Code Semantic Analysis
**Step 5.1: Key Functions**
Record: No function body is modified. The change is data-only in
`alc269_fixup_tbl[]`. The affected runtime function is the existing
`alc236_fixup_hp_mute_led_coefbit2()`.
**Step 5.2: Trace Callers**
Record: `alc269_fixup_tbl[]` → consumed by `snd_hda_pick_fixup()` called
from `alc269_probe()` → registered as `.probe` in `alc269_codec_ops` /
`alc269_driver` via `module_hda_codec_driver()`. The fixup runs at codec
probe time on matching hardware.
**Step 5.3: Trace Callees**
Record: `alc236_fixup_hp_mute_led_coefbit2()` sets `spec->mute_led_coef`
fields and calls `snd_hda_gen_add_mute_led_cdev(codec,
coef_mute_led_set)`. `coef_mute_led_set()` calls
`alc_update_coef_led()`. This only affects LED control, not audio
routing or codec initialization logic.
**Step 5.4: Call Chain Reachability**
Record: HDA codec probe → `alc269_probe()` → `snd_hda_pick_fixup(...
alc269_fixup_tbl ...)` → `snd_hda_apply_fixup(HDA_FIXUP_ACT_PRE_PROBE)`
→ `alc236_fixup_hp_mute_led_coefbit2()`. Reachable only on systems with
the exact matching subsystem ID.
**Step 5.5: Similar Patterns**
Record: `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` appears 17 times in
`alc269.c`, confirming it is a well-established fixup used by many HP
devices. Related one-line commits include `d510acb610e6aa`,
`d33c3471047fc`, `9ed7a28225af0`.
## Phase 6: Stable Tree Analysis
**Step 6.1: Does the Buggy Code Exist in Stable Trees?**
Record: The missing quirk (0x8dd7 absent) affects any stable tree that
carries the `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` helper. Verified:
- **v6.19**: helper present in `sound/hda/codecs/realtek/alc269.c` —
**applicable**
- **v6.6**: helper present in `sound/pci/hda/patch_realtek.c` (5
occurrences) — **applicable** (minor path adjustment needed)
- **v6.1**: helper **absent** (0 occurrences) — **not standalone
applicable**
- **v5.15**: helper **absent** (0 occurrences) — **not standalone
applicable**
**Step 6.2: Backport Complications**
Record: For v6.19.y: clean apply expected (same file layout). For
v6.6.y: needs minor mechanical adjustment (file is
`sound/pci/hda/patch_realtek.c` instead of the new split path, and
different surrounding context lines). For v6.1.y and v5.15.y: not a
standalone backport — prerequisite infrastructure absent.
**Step 6.3: Related Fixes Already in Stable**
Record: The original helper commit `0659400f18c0e6` had `Cc:
stable@vger.kernel.org` and is present from v6.5 onward. The exact
0x8dd7 entry is not yet present anywhere (verified by grep).
## Phase 7: Subsystem and Maintainer Context
**Step 7.1: Subsystem Criticality**
Record: ALSA HDA Realtek codec driver — IMPORTANT level for affected
laptop users. Not core kernel, but real user-visible hardware
functionality.
**Step 7.2: Subsystem Activity**
Record: Highly active — frequent quirk additions and fixes to
`alc269.c`, typical for ongoing hardware enablement.
## Phase 8: Impact and Risk Assessment
**Step 8.1: Who Is Affected**
Record: Users of HP Laptop 15-fd0xxx with ALC236 codec and subsystem ID
0x103c:0x8dd7. Driver-specific, hardware-specific.
**Step 8.2: Trigger Conditions**
Record: Every time the user mutes/unmutes audio, the LED does not
correctly reflect the mute state. Affects normal daily use of the
laptop.
**Step 8.3: Failure Mode Severity**
Record: Mute LED does not toggle — user cannot visually confirm mute
state. Severity: LOW-MEDIUM (hardware not working as designed, but no
crash/corruption/security issue).
**Step 8.4: Risk-Benefit Ratio**
Record: Benefit: Restores expected mute LED behavior for a specific HP
laptop model. Risk: Effectively zero — one table entry matching a single
subsystem ID, using an existing well-tested fixup chain. Ratio: Very
favorable.
## Phase 9: Final Synthesis
**Step 9.1: Compile the Evidence**
Evidence FOR backporting:
- Single-line hardware quirk addition — explicit exception category for
stable
- Uses existing, well-tested fixup (`ALC236_FIXUP_HP_MUTE_LED_COEFBIT2`,
used by 17 other entries)
- Zero regression risk (only matches one specific hardware subsystem ID)
- Accepted by ALSA maintainer Takashi Iwai
- Fixes real, user-visible hardware behavior for a shipping laptop model
- The original helper commit had `Cc: stable@vger.kernel.org` — the
infrastructure was intended for stable
Evidence AGAINST backporting:
- Low severity (LED behavior only, not crash/security/corruption)
- Not standalone for v6.1.y and v5.15.y (helper absent)
Unresolved:
- Exact mailing list review discussion (blocked by Anubis)
- Independent testing beyond author and maintainer signoff
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — identical pattern to 17
existing entries using the same fixup
2. Fixes a real bug? **YES** — mute LED non-functional on specific
hardware
3. Important issue? **MEDIUM** — hardware not working as expected; fits
the quirk exception
4. Small and contained? **YES** — 1 line in 1 file
5. No new features or APIs? **YES** — uses existing fixup
6. Can apply to stable? **YES** for v6.6.y and v6.19.y; **NO** as
standalone for v6.1.y/v5.15.y
**Step 9.3: Exception Category**
Record: **Audio codec quirk** (`SND_PCI_QUIRK` entry for existing fixup)
— explicitly listed as an allowed exception for stable backporting.
**Step 9.4: Decision**
This is a textbook hardware quirk addition: one line, zero regression
risk, existing infrastructure, maintainer-accepted. It should be
backported to stable trees that already contain the
`ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` helper (v6.6.y and newer).
## Verification
- [Phase 1] Parsed tags: `Signed-off-by` from author and ALSA maintainer
Takashi Iwai; `Link:` to patch submission; no `Fixes:`, `Reported-
by:`, or `Cc: stable`
- [Phase 2] Diff analysis: +1 line `SND_PCI_QUIRK(0x103c, 0x8dd7, ...)`
in `alc269_fixup_tbl[]`; verified 0x8dd7 not present in current tree
(grep returned no matches)
- [Phase 2] Read `alc236_fixup_hp_mute_led_coefbit2()` at lines
1525-1538: confirmed it sets `mute_led_coef.idx = 0x07`, `mask = 1`,
`on = 1`, `off = 0` and calls `snd_hda_gen_add_mute_led_cdev()`
- [Phase 2] Verified 17 occurrences of
`ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` in `alc269.c` — well-established
fixup
- [Phase 3] `git log -S'ALC236_FIXUP_HP_MUTE_LED_COEFBIT2'` confirmed
introduction by `0659400f18c0e6` and subsequent quirk additions
- [Phase 3] `git show 0659400f18c0e6`: confirmed helper introduction
with `Cc: <stable@vger.kernel.org>`
- [Phase 3] `git tag --contains 0659400f18c0e6`: helper first appeared
in v6.5 lineage
- [Phase 3] Verified insertion point: 0x8dd4 at line 7099, 0x8de8 at
line 7100 — correct sorted position
- [Phase 4] `patch.msgid.link` URL blocked by anti-bot protection —
UNVERIFIED: reviewer comments
- [Phase 5] Traced call chain: `alc269_probe()` → `snd_hda_pick_fixup()`
→ `snd_hda_apply_fixup()` → helper. Probe-time only.
- [Phase 6] **v6.6**: `ALC236_FIXUP_HP_MUTE_LED_COEFBIT2` present (5
occurrences in `patch_realtek.c`) — applicable
- [Phase 6] **v6.1**: helper absent (0 occurrences) — NOT standalone
applicable
- [Phase 6] **v5.15**: helper absent (0 occurrences) — NOT standalone
applicable
- [Phase 8] Failure mode: non-functional mute LED only; severity LOW-
MEDIUM; no crash/security/data path
- UNVERIFIED: exact mailing list discussion content and any external
test reports for this specific model
**YES**
sound/hda/codecs/realtek/alc269.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index 5adc5db6fd52b..1054191d56fa1 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7099,6 +7099,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x103c, 0x8da7, "HP 14 Enstrom OmniBook X", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x103c, 0x8da8, "HP 16 Piston OmniBook X", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x103c, 0x8dd4, "HP EliteStudio 8 AIO", ALC274_FIXUP_HP_AIO_BIND_DACS),
+ SND_PCI_QUIRK(0x103c, 0x8dd7, "HP Laptop 15-fd0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
SND_PCI_QUIRK(0x103c, 0x8de8, "HP Gemtree", ALC245_FIXUP_TAS2781_SPI_2),
SND_PCI_QUIRK(0x103c, 0x8de9, "HP Gemtree", ALC245_FIXUP_TAS2781_SPI_2),
SND_PCI_QUIRK(0x103c, 0x8dec, "HP EliteBook 640 G12", ALC236_FIXUP_HP_GPIO_LED),
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH AUTOSEL 6.19-6.6] ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EAC
2026-03-30 12:38 [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add quirk for Lenovo Yoga 7 2-in-1 16AKP10 Sasha Levin
` (9 preceding siblings ...)
2026-03-30 12:38 ` [PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: add HP Laptop 15-fd0xxx mute LED quirk Sasha Levin
@ 2026-03-30 12:38 ` Sasha Levin
10 siblings, 0 replies; 12+ messages in thread
From: Sasha Levin @ 2026-03-30 12:38 UTC (permalink / raw)
To: patches, stable
Cc: Matthew Schwartz, Takashi Iwai, Sasha Levin, perex, tiwai,
linux-sound, linux-kernel
From: Matthew Schwartz <matthew.schwartz@linux.dev>
[ Upstream commit 59f68dc1d8df3142cb58fd2568966a9bb7b0ed8a ]
Fixes lack of audio output on the ASUS ROG Flow Z13-KJP GZ302EAC model,
similar to the ASUS ROG Flow Z13 GZ302EA.
Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260313172503.285846-1-matthew.schwartz@linux.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
**Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF**
Record: No function bodies modified. The change is purely data — one
entry in the `alc269_fixup_tbl[]` static quirk table.
**Step 5.2: TRACE CALLERS**
Record: `alc269_fixup_tbl[]` is consumed by `snd_hda_pick_fixup()`
during `alc269_probe()`, which is the `.probe` callback in
`alc269_codec_ops`. This runs during HDA codec initialization — a
standard device-probe path.
**Step 5.3: TRACE CALLEES**
Record: `[ALC287_FIXUP_CS35L41_I2C_2]` at line 6200 maps to
`cs35l41_fixup_i2c_two()` (line 3231), which calls
`comp_generic_fixup(cdc, action, "i2c", "CSC3551",
"-%s:00-cs35l41-hda.%d", 2)` — initializing two CS35L41 companion
amplifiers over I2C.
**Step 5.4: FOLLOW THE CALL CHAIN**
Record: HDA codec driver registration → `alc269_probe()` →
`snd_hda_pick_fixup(... alc269_fixup_tbl ...)` → SSID match selects
fixup → `snd_hda_apply_fixup(HDA_FIXUP_ACT_PRE_PROBE)` →
`cs35l41_fixup_i2c_two()` → `comp_generic_fixup()` →
`hda_component_manager_init()` for two CSC3551 amps. This is reached
automatically during boot on affected hardware — not an obscure or debug
path.
**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: `ALC287_FIXUP_CS35L41_I2C_2` appears 113 times in this file. The
sibling ASUS ROG Flow Z13 GZ302EA at line 7284 uses the exact same fixup
(`0x1043:0x1fb3 → ALC287_FIXUP_CS35L41_I2C_2`). This is a thoroughly
proven pattern.
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?**
Record: Verified via `git grep`:
- **v6.6**: `ALC287_FIXUP_CS35L41_I2C_2` exists in
`sound/pci/hda/patch_realtek.c` — applicable
- **v6.1**: `ALC287_FIXUP_CS35L41_I2C_2` exists in
`sound/pci/hda/patch_realtek.c` — applicable
- **v5.15**: `ALC287_FIXUP_CS35L41_I2C_2` does NOT exist — **not
applicable** without prerequisite work
**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: Mainline has moved the code from `sound/pci/hda/patch_realtek.c`
to `sound/hda/codecs/realtek/alc269.c` (file split). Backports to v6.6
and v6.1 will need a trivial path adjustment. The actual change is still
a single `SND_PCI_QUIRK` line insertion in the same quirk table — only
context lines and file path differ. Expected difficulty:
**minor/trivial**.
**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE**
Record: The `0x1514` SSID entry does not exist in the current tree
(confirmed by grep). The sibling `0x1fb3` (GZ302EA) commit
`12784ca33b62f` is also not in v6.6, v6.1, or v5.15.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: Subsystem: sound/HDA/Realtek codec. Criticality: IMPORTANT —
audio is a core laptop function. While hardware-specific, this affects
all users of this specific ASUS model.
**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Highly active — the recent 20 commits are exclusively quirk
additions and small fixes. This is normal and expected for the Realtek
HDA quirk table.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: Owners of ASUS ROG Flow Z13-KJP GZ302EAC laptops using in-kernel
HDA Realtek audio. Hardware-specific / driver-specific population.
**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Every boot — the missing quirk causes incorrect codec
initialization automatically during probe. No special user action
required. Deterministic on affected hardware.
**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: Complete lack of audio output on the affected laptop. Severity:
**HIGH** for affected users — a core hardware function
(speakers/headphones) is entirely non-functional. Not a crash or
security issue, but a complete functional failure of essential hardware.
**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit**: HIGH for affected users — restores audio functionality on
a real, shipping laptop
- **Risk**: NEAR-ZERO — one line, SSID-gated (only matches
0x1043:0x1514), reuses a well-established fixup used by 113 entries
- **Ratio**: Strongly favorable
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: COMPILE THE EVIDENCE**
Evidence FOR backporting:
- Fixes complete lack of audio output on a real shipping laptop
- Falls into the explicit "Audio Codec Quirks" exception category —
automatic YES
- One line added — minimal possible change
- Uses existing, heavily-tested fixup (`ALC287_FIXUP_CS35L41_I2C_2`, 113
occurrences)
- Sibling model (GZ302EA) uses identical fixup, establishing the pattern
- Accepted by subsystem maintainer Takashi Iwai
- Included in the sound fixes pull for 7.0-rc6
- Applicable to v6.6 and v6.1 stable trees (prerequisite support
verified)
Evidence AGAINST backporting:
- Not applicable to v5.15 (missing prerequisite fixup infrastructure)
- File path has changed between mainline and stable (minor backport
friction)
- No explicit Tested-by in this commit (though the sibling commit
`12784ca33b62f` had one)
Unresolved:
- Takashi Iwai's exact reply content (could not fetch)
- Whether any stable reviewer has already discussed this patch
**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. **Obviously correct and tested?** YES — trivial table entry matching
established pattern, maintainer-accepted
2. **Fixes a real bug that affects users?** YES — no audio output on
affected hardware
3. **Important issue?** YES — total loss of audio on a laptop
4. **Small and contained?** YES — 1 line, 1 file, data-only change
5. **No new features or APIs?** YES — quirk table entry only, no
behavioral changes outside targeted SSID
6. **Can apply to stable trees?** YES for v6.1+ and v6.6+ (with path
adjustment); NO for v5.15
**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: **Hardware quirk / Audio Codec Quirk** — `SND_PCI_QUIRK` entry
in the Realtek HDA codec quirk table. This is explicitly in the
automatic YES exception category.
**Step 9.4: MAKE YOUR DECISION**
This is a textbook stable backport candidate. It is a single-line audio
codec quirk addition that restores audio output on a specific ASUS
laptop model using an existing, widely-deployed fixup. It carries near-
zero regression risk and falls squarely into the hardware quirk
exception category.
## Verification
- [Phase 1] Parsed subject/body/tags from the provided commit message;
found Signed-off-by (author + maintainer) and Link; no Fixes/Reported-
by/Cc:stable — expected
- [Phase 2] Diff is exactly +1 line: `SND_PCI_QUIRK(0x1043, 0x1514,
"ASUS ROG Flow Z13 GZ302EAC", ALC287_FIXUP_CS35L41_I2C_2)`
- [Phase 2] Confirmed `ALC287_FIXUP_CS35L41_I2C_2` appears 113 times in
`alc269.c` — well-established fixup
- [Phase 3] `grep -n '0x1514'` returned no matches — SSID not yet in
tree
- [Phase 3] `grep -n '0x1fb3'` confirmed sibling GZ302EA at line 7284
uses identical fixup
- [Phase 3] `git log --follow -S'0x1fb3'` traced sibling to commit
`12784ca33b62f` ("Fix Asus Z13 2025 audio")
- [Phase 3] `git show 12784ca33b62f` confirmed it adds 0x1043:0x1fb3 →
ALC287_FIXUP_CS35L41_I2C_2, with Tested-by tag
- [Phase 3] `git log --author="Matthew Schwartz" -10 -- sound/` found
one related commit (`b7e26c8bdae70`)
- [Phase 4] yhbt.net mirror confirmed standalone [PATCH] posted
2026-03-13, Takashi Iwai replied 2026-03-14, included in sound fixes
pull 2026-03-27
- [Phase 4] lore.kernel.org blocked by Anubis; used yhbt.net mirror as
alternative
- [Phase 5] Verified `[ALC287_FIXUP_CS35L41_I2C_2]` at line 6200 maps to
`cs35l41_fixup_i2c_two()` → `comp_generic_fixup(... "i2c", "CSC3551",
..., 2)`
- [Phase 5] Traced call chain: `alc269_probe()` → `snd_hda_pick_fixup()`
→ `snd_hda_apply_fixup()` → `cs35l41_fixup_i2c_two()`
- [Phase 6] `git grep` against v6.6: `ALC287_FIXUP_CS35L41_I2C_2`
present in `sound/pci/hda/patch_realtek.c`
- [Phase 6] `git grep` against v6.1: `ALC287_FIXUP_CS35L41_I2C_2`
present in `sound/pci/hda/patch_realtek.c`
- [Phase 6] `git grep` against v5.15: `ALC287_FIXUP_CS35L41_I2C_2`
**absent** — not applicable to this tree
- [Phase 6] Identified file path change: mainline uses
`sound/hda/codecs/realtek/alc269.c`, stable uses
`sound/pci/hda/patch_realtek.c`
- [Phase 8] Failure mode: complete loss of audio output — severity HIGH
for affected hardware users
- UNVERIFIED: Exact content of Takashi Iwai's reply (message not
fetchable from mirrors)
- UNVERIFIED: Whether stable mailing list has prior discussion of this
specific commit
**YES**
sound/hda/codecs/realtek/alc269.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index b83f0c4bec142..75f880efdeaf1 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7206,6 +7206,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x14e3, "ASUS G513PI/PU/PV", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x1043, 0x14f2, "ASUS VivoBook X515JA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1503, "ASUS G733PY/PZ/PZV/PYV", ALC287_FIXUP_CS35L41_I2C_2),
+ SND_PCI_QUIRK(0x1043, 0x1514, "ASUS ROG Flow Z13 GZ302EAC", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
SND_PCI_QUIRK(0x1043, 0x1533, "ASUS GV302XA/XJ/XQ/XU/XV/XI", ALC287_FIXUP_CS35L41_I2C_2),
SND_PCI_QUIRK(0x1043, 0x1573, "ASUS GZ301VV/VQ/VU/VJ/VA/VC/VE/VVC/VQC/VUC/VJC/VEC/VCC", ALC285_FIXUP_ASUS_HEADSET_MIC),
--
2.53.0
^ permalink raw reply related [flat|nested] 12+ messages in thread