[PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI entry for HP Laptop 15-fc0xxx

[PATCH AUTOSEL 6.19-6.1] ASoC: amd: yc: Add DMI entry for HP Laptop 15-fc0xxx

[Sasha Levin]

From: Gilson Marquato Júnior <gilsonmandalogo@hotmail.com>

[ Upstream commit 8ec017cf31299c4b6287ebe27afe81c986aeef88 ]

The HP Laptop 15-fc0xxx (subsystem ID 0x103c8dc9) has an internal
DMIC connected to the AMD ACP6x audio coprocessor. Add a DMI quirk
entry so the internal microphone is properly detected on this model.

Tested on HP Laptop 15-fc0237ns with Fedora 43 (kernel 6.19.9).

Signed-off-by: Gilson Marquato Júnior <gilsonmandalogo@hotmail.com>
Link: https://patch.msgid.link/20260330-hp-15-fc0xxx-dmic-v2-v1-1-6dd6f53a1917@hotmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Record: The file is extremely actively maintained with a steady stream
of DMI quirk additions — this is exactly the pattern. The author appears
to be a first-time contributor for this specific laptop.

**Step 3.3-3.5:** This is a standalone data-only addition with no
dependencies. It doesn't reference other commits and doesn't require any
prerequisites.

Record: [Standalone, no dependencies, applies cleanly to any tree
containing this file]

## PHASE 4: MAILING LIST (abbreviated — clear-cut case)

The patch was accepted by Mark Brown (ASoC maintainer) and merged. The
Link tag confirms it went through normal review.

Record: [Accepted by subsystem maintainer Mark Brown]

## PHASE 5: CODE SEMANTIC ANALYSIS

The change is purely a data table entry addition. No functions are
modified. The DMI matching infrastructure is well-established kernel
code. The `acp6x_card` driver_data is the same used by all other
entries.

Record: [No code logic changes, data-only table entry]

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The acp6x-mach.c file and the yc_acp_quirk_table have
existed since the AMD Yellow Carp platform support was added. This file
exists in stable trees.

**Step 6.2:** The patch adds an entry at the beginning of the table,
which may cause minor offset conflicts with other quirk additions, but
the resolution would be trivial.

Record: [File exists in stable trees] [Trivial backport, possible minor
context conflict]

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

- Subsystem: ASoC (ALSA SoC) / AMD audio drivers
- Criticality: IMPORTANT (audio is a key user-facing feature on laptops)
- Maintainer: Mark Brown (well-known, prolific ASoC maintainer) accepted
  the patch

Record: [ASoC/AMD audio] [IMPORTANT — affects laptop users] [Accepted by
maintainer]

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected users: owners of HP Laptop 15-fc0xxx (specific
hardware model)
**Step 8.2:** Trigger: always — internal mic doesn't work at all without
this entry
**Step 8.3:** Failure mode: no internal microphone on this laptop —
functional hardware is unusable. Severity: MEDIUM-HIGH (audio input
completely broken for this model)
**Step 8.4:**
- Benefit: HIGH — makes internal mic work on a specific HP laptop model
- Risk: VERY LOW — 7-line data table addition, affects only this one
  laptop model, cannot cause regression on any other system

Record: [Benefit: HIGH] [Risk: VERY LOW] [Ratio: strongly favors
backporting]

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**
FOR backporting:
- Classic DMI quirk addition (exception category: hardware
  quirk/workaround)
- 7 lines, data-only, zero code logic changes
- Tested on real hardware by the author
- Accepted by ASoC maintainer Mark Brown
- Fixes a real user-facing issue (internal mic not working)
- Identical pattern to dozens of other entries in the same file
- Zero regression risk

AGAINST backporting:
- (None)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — tested on hardware, trivial
   data addition
2. Fixes a real bug? **YES** — internal mic not detected
3. Important issue? **YES** — hardware not functional without it
4. Small and contained? **YES** — 7 lines in one file
5. No new features/APIs? **YES** — just enables existing driver for new
   hardware
6. Can apply to stable? **YES** — trivial apply

**Step 9.3: Exception Category**
This is a **hardware quirk/workaround** (DMI match table entry) — an
automatic YES category.

## Verification
- [Phase 1] Parsed commit message: DMI quirk for HP Laptop 15-fc0xxx
  internal DMIC
- [Phase 2] Diff: +7 lines, data-only addition to yc_acp_quirk_table[],
  identical pattern to existing entries
- [Phase 3] git log: file has 15+ recent commits all adding similar DMI
  quirk entries
- [Phase 3] Standalone commit, no dependencies
- [Phase 7] Mark Brown (ASoC maintainer) accepted the patch
- [Phase 8] Risk: zero regression risk, data-only change affecting one
  laptop model
- [Phase 9] Falls into hardware quirk exception category

**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..97652ab73ea95 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -45,6 +45,13 @@ static struct snd_soc_card acp6x_card = {
 };
 
 static const struct dmi_system_id yc_acp_quirk_table[] = {
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "HP Laptop 15-fc0xxx"),
+		}
+	},
 	{
 		.driver_data = &acp6x_card,
 		.matches = {
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.1] ALSA: hda/realtek: add quirk for Framework F111:000F

[Sasha Levin]

From: "Dustin L. Howett" <dustin@howett.net>

[ Upstream commit bac1e57adf08c9ee33e95fb09cd032f330294e70 ]

Similar to commit 7b509910b3ad ("ALSA hda/realtek: Add quirk for
Framework F111:000C") and previous quirks for Framework systems with
Realtek codecs.

000F is another new platform with an ALC285 which needs the same quirk.

Signed-off-by: Dustin L. Howett <dustin@howett.net>
Link: https://patch.msgid.link/20260327-framework-alsa-000f-v1-1-74013aba1c00@howett.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The referenced commit exists and is identical in nature — a single-line
quirk addition for a different Framework platform.

## PHASE 4: MAILING LIST (abbreviated — textbook quirk)

This is a standard one-line quirk addition accepted by the ALSA
maintainer (Takashi Iwai). No controversy expected.

## PHASE 5: CODE SEMANTIC ANALYSIS

The quirk `ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE` is already
defined and used by five other Framework entries. This just adds the
same quirk for one more device ID. No new code paths.

## PHASE 6: STABLE TREE ANALYSIS

The Framework quirk entries have been present since various stable
releases. The `ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE` fixup is
well-established. The file path has changed recently (moved from
`sound/pci/hda/` to `sound/hda/codecs/realtek/`), which may require
minor path adjustment in older stable trees, but the code itself is a
trivial table entry addition.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

- Subsystem: ALSA/HDA (audio) — IMPORTANT, affects laptop users
- Accepted by Takashi Iwai (ALSA maintainer) — authoritative

## PHASE 8: IMPACT AND RISK ASSESSMENT

- **Affected users:** Framework Laptop owners with platform ID
  0xf111:0x000f
- **Without fix:** Headphone/microphone jack detection doesn't work
  properly (mic no presence detection)
- **Fix quality:** 1 line, identical pattern to 5 existing entries, zero
  regression risk
- **Benefit:** HIGH — makes audio jack work on a specific laptop
- **Risk:** NEAR-ZERO — only triggers on matching PCI subsystem ID

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Textbook hardware quirk addition (explicit exception category)
- Single line, identical pattern to existing entries
- Accepted by subsystem maintainer
- Fixes real hardware for Framework laptop users
- Zero regression risk

**Evidence AGAINST:** None.

**Stable rules checklist:**
1. Obviously correct? YES — identical to adjacent entries
2. Fixes real bug? YES — audio jack not working
3. Important? YES for affected hardware users
4. Small/contained? YES — 1 line
5. No new features? Correct — no new features
6. Applies to stable? YES — trivial addition

**Exception category:** Hardware quirk/workaround — automatic YES.

## Verification:
- [Phase 1] Subject: "add quirk" — hardware quirk addition for Framework
  laptop
- [Phase 2] Diff: +1 line in quirk table, identical pattern to 5
  existing Framework entries
- [Phase 3] `git show 7b509910b3ad6`: confirmed referenced commit
  exists, identical nature (Framework F111:000C)
- [Phase 3] `git log --grep="Framework"`: confirmed history of Framework
  quirk additions to this file
- [Phase 7] Signed-off-by Takashi Iwai confirms maintainer acceptance
- [Phase 8] Risk: near-zero (only affects matching PCI subsystem ID
  0xf111:0x000f)

**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 9a00e1d324cef..19f23c92fdcdb 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7725,6 +7725,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0xf111, 0x0009, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0xf111, 0x000b, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0xf111, 0x000c, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
+	SND_PCI_QUIRK(0xf111, 0x000f, "Framework Laptop", ALC295_FIXUP_FRAMEWORK_LAPTOP_MIC_NO_PRESENCE),
 
 #if 0
 	/* Below is a quirk table taken from the old code.
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.12] ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IMH9

[Sasha Levin]

From: Alexander Savenko <alex.sav4387@gmail.com>

[ Upstream commit 217d5bc9f96272316ac5a3215c7cc32a5127bbf3 ]

The Lenovo Yoga Pro 7 14IMH9 (DMI: 83E2) shares PCI SSID 17aa:3847
with the Legion 7 16ACHG6, but has a different codec subsystem ID
(17aa:38cf). The existing SND_PCI_QUIRK for 17aa:3847 applies
ALC287_FIXUP_LEGION_16ACHG6, which attempts to initialize an external
I2C amplifier (CLSA0100) that is not present on the Yoga Pro 7 14IMH9.

As a result, pin 0x17 (bass speakers) is connected to DAC 0x06 which
has no volume control, making hardware volume adjustment completely
non-functional. Audio is either silent or at maximum volume regardless
of the slider position.

Add a HDA_CODEC_QUIRK entry using the codec subsystem ID (17aa:38cf)
to correctly identify the Yoga Pro 7 14IMH9 and apply
ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN, which redirects pin 0x17 to
DAC 0x02 and restores proper volume control. The existing Legion entry
is preserved unchanged.

This follows the same pattern used for 17aa:386e, where Legion Y9000X
and Yoga Pro 7 14ARP8 share a PCI SSID but are distinguished via
HDA_CODEC_QUIRK.

Link: https://github.com/nomad4tech/lenovo-yoga-pro-7-linux
Tested-by: Alexander Savenko <alex.sav4387@gmail.com>
Signed-off-by: Alexander Savenko <alex.sav4387@gmail.com>
Link: https://patch.msgid.link/20260331082929.44890-1-alex.sav4387@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:

Lore is blocking automated access. Let me check the GitHub link
mentioned in the commit.

Record: [Phase 4: Could not access lore.kernel.org due to access
restrictions. The patch was accepted by Takashi Iwai (ALSA maintainer)
which is the strongest signal for ALSA patches.]

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions modified**
No functions are modified. The change only adds a table entry to the
`alc269_fixup_tbl[]` static array.

**Step 5.2-5.4: Call chain**
The quirk table is looked up during HDA codec probe. The
`HDA_CODEC_QUIRK` macro matches on codec subsystem ID. When matched, it
applies `ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN` which calls
`alc287_fixup_yoga9_14iap7_bass_spk_pin` — a function that already
exists and is already used by other quirk entries (Yoga 9 14IMH9 with
PCI SSIDs 17aa:38d2 and 17aa:38d7).

Record: [Only a static table entry addition. The fixup function and all
supporting code already exist. No new code paths created.]

**Step 5.5: Similar patterns**
Already verified: The same `HDA_CODEC_QUIRK` + `SND_PCI_QUIRK`
disambiguation pattern is used for `0x17aa:0x386e` (Legion Y9000X vs
Yoga Pro 7 14ARP8) and for `0x17aa:0x3802` (DuetITL vs Yoga Pro 9). This
is a well-established pattern.

## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS

**Step 6.1: Does buggy code exist in stable?**
The Legion 7 16ACHG6 PCI SSID quirk (17aa:3847) exists in the tree. The
fixup definition `ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN` was added in
v6.9-rc1. So stable trees >= 6.9 have the prerequisite. For older trees
(6.6.y, 6.1.y), the fixup definition would need to be present (would
need to check if it was backported).

**Step 6.2: Backport complications**
The file was recently split (`ALSA: hda: Split Realtek HD-audio codec
driver` in commit aeeb85f26c3bb). In stable trees, the code is likely
still in the old location (`sound/pci/hda/patch_realtek.c`). The
backport would need to target the old file path, but the actual change
(adding one table entry) is trivial.

**Step 6.3: No related fixes already in stable for this specific
device.**

Record: [Needs path adjustment for older stables where code is in
sound/pci/hda/patch_realtek.c. The prerequisite fixup
ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN must exist in the target stable
tree (present since v6.9-rc1).]

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** Subsystem: sound/hda (ALSA HDA audio). Criticality:
IMPORTANT — audio is essential for laptop users.

**Step 7.2:** Very active subsystem with frequent quirk additions (the
recent history shows many similar patches).

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is affected**
Users of the Lenovo Yoga Pro 7 14IMH9 laptop — a specific but popular
consumer laptop.

**Step 8.2: Trigger conditions**
Every boot. Volume control is completely broken without this quirk. The
user cannot adjust volume at all.

**Step 8.3: Failure mode severity**
Audio volume control completely non-functional — either silent or
maximum volume. This is a HIGH severity usability issue for a laptop.
Not a crash, but makes the device partially unusable.

**Step 8.4: Risk-benefit ratio**
- BENEFIT: HIGH — restores volume control for all users of this specific
  laptop model
- RISK: VERY LOW — 1 table entry addition, using existing fixup,
  following established pattern, no code logic changes, cannot affect
  any other device
- Ratio: Strongly favorable

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence compiled**

FOR backporting:
- Fixes completely broken volume control on a specific laptop (audio
  either silent or max)
- Trivial 1-line functional change (+ 3 comment lines)
- Uses existing fixup definition — no new code
- Follows established disambiguation pattern (HDA_CODEC_QUIRK)
- Tested by the device owner
- Accepted by ALSA maintainer Takashi Iwai
- Classic hardware quirk — explicit exception category for stable

AGAINST backporting:
- File path changed in recent mainline (code was split to new location)
  — may need path adjustment
- Prerequisite fixup enum/definition only exists since v6.9-rc1 — older
  stable trees would need that too
- No Cc: stable tag (but this is expected and not a negative signal)

**Step 9.2: Stable rules checklist**
1. Obviously correct and tested? YES — tested by device owner, accepted
   by maintainer
2. Fixes a real bug? YES — broken volume control on a real laptop
3. Important issue? YES — audio completely unusable (no volume control)
4. Small and contained? YES — 4 lines, single table entry
5. No new features or APIs? CORRECT — no new features, just a quirk
   entry
6. Can apply to stable? YES for 6.12.y+ (may need path adjustment);
   6.9-6.11 needs path adjustment; <6.9 needs prerequisite

**Step 9.3: Exception category**
YES — this is a **hardware quirk/workaround** addition, one of the
explicitly listed exception categories that are almost always
appropriate for stable.

**Step 9.4: Decision**
This is a textbook stable backport candidate: a tiny hardware quirk
addition that fixes completely broken audio volume control on a specific
laptop model, using an existing fixup, with zero risk to other devices.

## Verification

- [Phase 1] Parsed tags: Tested-by from author, Signed-off-by from
  Takashi Iwai (ALSA maintainer)
- [Phase 2] Diff analysis: +4 lines (1 HDA_CODEC_QUIRK entry + 3 comment
  lines) in alc269_fixup_tbl[]
- [Phase 2] Verified the fix reuses existing
  ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN fixup (line 6361)
- [Phase 3] git blame: Legion 16ACHG6 quirk at line 7574 exists in
  current tree (from aeeb85f26c3bb split commit)
- [Phase 3] git log -S: ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN was
  introduced in commit 9b714a59b719b, which is in v6.9-rc1
- [Phase 3] Verified same disambiguation pattern used for 0x17aa:0x386e
  (HDA_CODEC_QUIRK at line 7582)
- [Phase 4] lore.kernel.org: Could not access due to Anubis block —
  UNVERIFIED mailing list discussion
- [Phase 5] Verified fixup definition at line 6361-6366: chains to
  alc287_fixup_yoga9_14iap7_bass_spk_pin + CS35L41_I2C_2
- [Phase 5] Confirmed fixup is already used by two other quirk entries
  (lines 7619, 7624)
- [Phase 6] Prerequisite exists since v6.9-rc1 — stable trees >= 6.12.y
  should have it; older may need check
- [Phase 6] File was split from sound/pci/hda/patch_realtek.c — backport
  needs path adjustment for older trees
- [Phase 8] Impact: volume control completely broken (silent or max) —
  confirmed from commit message
- [Phase 8] Risk: near-zero — table entry only, cannot affect other
  hardware
- UNVERIFIED: Could not verify mailing list discussion for stable
  nominations (lore blocked). This does not affect the decision since
  the technical merits are clear.

**YES**

 sound/hda/codecs/realtek/alc269.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index e55f57cca883a..22fbe9a277523 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7572,6 +7572,10 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x3834, "Lenovo IdeaPad Slim 9i 14ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x383d, "Legion Y9000X 2019", ALC285_FIXUP_LEGION_Y9000X_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x3843, "Lenovo Yoga 9i / Yoga Book 9i", ALC287_FIXUP_LENOVO_YOGA_BOOK_9I),
+	/* Yoga Pro 7 14IMH9 shares PCI SSID 17aa:3847 with Legion 7 16ACHG6;
+	 * use codec SSID to distinguish them
+	 */
+	HDA_CODEC_QUIRK(0x17aa, 0x38cf, "Lenovo Yoga Pro 7 14IMH9", ALC287_FIXUP_YOGA9_14IMH9_BASS_SPK_PIN),
 	SND_PCI_QUIRK(0x17aa, 0x3847, "Legion 7 16ACHG6", ALC287_FIXUP_LEGION_16ACHG6),
 	SND_PCI_QUIRK(0x17aa, 0x384a, "Lenovo Yoga 7 15ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
 	SND_PCI_QUIRK(0x17aa, 0x3852, "Lenovo Yoga 7 14ITL5", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.15] ALSA: usb-audio: Fix quirk flags for NeuralDSP Quad Cortex

[Sasha Levin]

From: Phil Willoughby <willerz@gmail.com>

[ Upstream commit bc5b4e5ae1a67700a618328217b6a3bd0f296e97 ]

The NeuralDSP Quad Cortex does not support DSD playback. We need
this product-specific entry with zero quirks because otherwise it
falls through to the vendor-specific entry which marks it as
supporting DSD playback.

Cc: Yue Wang <yuleopen@gmail.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Signed-off-by: Phil Willoughby <willerz@gmail.com>
Link: https://patch.msgid.link/20260328080921.3310-1-willerz@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:

This is crucial. The lookup iterates the table and **returns on first
match** (line 2572). Since DEVICE_FLG entries (product-specific) come
BEFORE VENDOR_FLG entries in the table, the product-specific entry for
0x152a:0x880a will be found first, preventing the VENDOR_FLG(0x152a,
QUIRK_FLAG_DSD_RAW) from being applied.

The zero flags entry with `return` means the device gets no quirk flags
at all - exactly what's needed for a device that doesn't support DSD.

Record: [Lookup is first-match-wins. Product entry precedes vendor
entry. Fix is trivially correct.]

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE?

The vendor entry (commit 68e851ee4cfd2a) is confirmed present in v5.15+.
All active stable trees (5.15.y, 6.1.y, 6.6.y, 6.12.y) contain this
vendor-level entry that incorrectly applies DSD_RAW to all Thesycon-
based devices including the NeuralDSP Quad Cortex.

Record: [Bug exists in all active stable trees v5.15+]

### Step 6.2: BACKPORT COMPLICATIONS
This is a 2-line addition to a sorted table. The surrounding entries may
differ slightly in stable trees, but the table structure is the same.
The entry needs to be placed in the correct sorted position (by vendor
ID 0x152a).

Record: [Clean apply expected, possibly minor context differences due to
different table entries]

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY SUBSYSTEM
- **Subsystem:** sound/usb (USB audio) - part of the ALSA subsystem
- **Criticality:** IMPORTANT - USB audio devices are widely used (audio
  interfaces, headsets, DACs)
- **Maintainer:** Takashi Iwai applied this commit directly

Record: [ALSA USB audio subsystem, IMPORTANT criticality, applied by
subsystem maintainer]

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: WHO IS AFFECTED
Users of the NeuralDSP Quad Cortex (a popular guitar effects processor /
audio interface used by musicians).

Record: [Affected: NeuralDSP Quad Cortex users (device-specific)]

### Step 8.2: TRIGGER CONDITIONS
The bug triggers every time the device is connected to a Linux system -
the incorrect DSD quirk is always applied.

Record: [Trigger: every device connection, 100% reproducible]

### Step 8.3: FAILURE MODE SEVERITY
With DSD_RAW incorrectly applied, the device may:
- Present DSD playback modes that the device doesn't support
- Potentially cause audio failures or incorrect audio routing
- Confuse audio applications about device capabilities

Record: [Failure mode: incorrect device capabilities reported, potential
audio dysfunction. Severity: MEDIUM]

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit:** Makes a specific USB audio device work correctly on Linux
- **Risk:** Essentially zero - 2-line table entry, only affects this one
  device, zero flags means "no quirks"
- **Ratio:** Very favorable - high benefit (device works correctly),
  essentially no risk

Record: [Benefit: HIGH for affected users. Risk: VERY LOW. Ratio:
strongly favorable]

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a real hardware issue for NeuralDSP Quad Cortex users
- This is a hardware quirk entry - an explicit exception category for
  stable
- 2-line change, trivially correct, zero regression risk
- Applied by ALSA subsystem maintainer (Takashi Iwai)
- Bug exists in all active stable trees (v5.15+)
- First-match-wins lookup logic is well-understood and the fix mechanism
  is proven

**AGAINST backporting:**
- No explicit Cc: stable tag (expected - that's why it's being reviewed)
- Device-specific (only affects Quad Cortex users)
- No crash/security/data-corruption - "just" incorrect device behavior

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - trivially correct table entry
2. Fixes a real bug? **YES** - incorrect DSD quirk applied to
   unsupported device
3. Important issue? **MEDIUM** - not a crash, but makes device
   unusable/buggy for its users
4. Small and contained? **YES** - 2 lines in one file
5. No new features or APIs? **YES** - no new features
6. Can apply to stable trees? **YES** - simple table entry

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
**YES - This is a hardware quirk/workaround.** This is explicitly listed
as an exception category that is automatically YES for stable. It's a
device-specific entry in a USB quirk table to fix incorrect behavior for
a specific device.

### Step 9.4: DECISION
This is a textbook hardware quirk entry for stable. It's a 2-line
addition to a quirk table that prevents incorrect DSD flags from being
applied to a specific USB audio device. The fix is trivially correct,
zero risk, and falls squarely in the "hardware quirks" exception
category.

## Verification

- [Phase 1] Parsed tags: Cc to maintainers, Signed-off-by from author
  and Takashi Iwai (maintainer). No Fixes tag, no Reported-by.
- [Phase 2] Diff analysis: +2 lines, adds DEVICE_FLG(0x152a, 0x880a, 0)
  to quirk_flags_table[]
- [Phase 3] git blame: VENDOR_FLG(0x152a) introduced by commit
  68e851ee4cfd2a (2021-07-29), confirmed present in v5.15
- [Phase 3] git merge-base: confirmed 68e851ee is ancestor of v5.15
- [Phase 5] Code analysis: snd_usb_init_quirk_flags_table() at line 2562
  uses first-match-wins (returns on line 2572), so product-specific
  DEVICE_FLG entries override VENDOR_FLG entries
- [Phase 5] VENDOR_FLG(0x152a) at line 2434 sets QUIRK_FLAG_DSD_RAW for
  all Thesycon devices
- [Phase 6] Bug exists in all active stable trees (v5.15.y, 6.1.y,
  6.6.y, 6.12.y)
- [Phase 6] Expected clean apply (simple sorted table insertion)
- [Phase 7] Applied by Takashi Iwai, ALSA/USB audio subsystem maintainer
- [Phase 8] Failure mode: incorrect DSD capabilities reported for
  device, severity MEDIUM
- [Phase 8] Risk: essentially zero (2-line table entry with zero flags,
  affects only one device)
- UNVERIFIED: Could not access lore.kernel.org discussion due to bot
  protection. This does not affect the decision as the technical merits
  are clear.

This is a standard hardware quirk entry - one of the explicitly listed
exception categories for stable backporting. The fix is trivially
correct, minimal (2 lines), zero risk, and prevents incorrect behavior
for a specific USB audio device. It meets all stable criteria.

**YES**

 sound/usb/quirks.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 09ed935107580..564e7ed9ac62c 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2299,6 +2299,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_PLAYBACK_FIRST | QUIRK_FLAG_GENERIC_IMPLICIT_FB),
 	DEVICE_FLG(0x13e5, 0x0001, /* Serato Phono */
 		   QUIRK_FLAG_IGNORE_CTL_ERROR),
+	DEVICE_FLG(0x152a, 0x880a, /* NeuralDSP Quad Cortex */
+		   0), /* Doesn't have the vendor quirk which would otherwise apply */
 	DEVICE_FLG(0x154e, 0x1002, /* Denon DCD-1500RE */
 		   QUIRK_FLAG_ITF_USB_DSD_DAC | QUIRK_FLAG_CTL_MSG_DELAY),
 	DEVICE_FLG(0x154e, 0x1003, /* Denon DA-300USB */
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] ALSA: hda/realtek: Add quirk for Lenovo Yoga Slim 7 14AKP10

[Sasha Levin]

From: songxiebing <songxiebing@kylinos.cn>

[ Upstream commit e6c888202297eca21860b669edb74fc600e679d9 ]

The Pin Complex 0x17 (bass/woofer speakers) is incorrectly reported as
unconnected in the BIOS (pin default 0x411111f0 = N/A). This causes the
kernel to configure speaker_outs=0, meaning only the tweeters (pin 0x14)
are used. The result is very low, tinny audio with no bass.

The existing quirk ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN (already present
in patch_realtek.c for SSID 0x17aa3801) fixes the issue completely.

Reported-by: Garcicasti <andresgarciacastilla@gmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221298
Signed-off-by: songxiebing <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260331033650.285601-1-songxiebing@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The fixup is well-established and used by 7+ other Lenovo models
already.

**Step 3.1-3.5 Summary:**
Record: [The fixup ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN is well-
established, used by 7+ other Lenovo models] [No dependencies]
[Standalone single-line addition] [Accepted by subsystem maintainer
Takashi Iwai]

## PHASE 4: EXTERNAL RESEARCH (abbreviated — clear-cut case)

The bugzilla link (bug 221298) and the Reported-by tag confirm this is a
real user-reported issue on a shipping Lenovo laptop.

Record: [Real user bug report on bugzilla.kernel.org] [Accepted by ALSA
maintainer]

## PHASE 5: CODE SEMANTIC ANALYSIS

The change is a single quirk table entry. The SND_PCI_QUIRK macro
matches on vendor/subsystem ID and applies the specified fixup. No new
functions, no logic changes.

Record: [Pure data table addition, no code flow analysis needed]

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The `ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN` fixup has
existed since the Yoga 9 14IAP7 support was added. It's present in
stable trees.

**Step 6.2:** This is a single-line table insertion — it will apply
cleanly to any stable tree that has the surrounding entries. The
neighboring entries (0x390d and 0x3913) may or may not be present in
older stable trees, but the quirk table is order-independent for
matching, so minor conflicts are trivially resolvable.

Record: [Should apply cleanly or with trivial context adjustment] [The
referenced fixup exists in stable trees]

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: ALSA/HDA (sound) — IMPORTANT level, affects laptop users
- Maintainer: Takashi Iwai (SUSE) — one of the most experienced and
  careful maintainers
Record: [ALSA/HDA] [IMPORTANT — audio on laptops] [Accepted by Takashi
Iwai]

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects users of the Lenovo Yoga Slim 7 14AKP10 laptop.
**Step 8.2:** Triggers on every boot — the bass speakers simply don't
work without this quirk.
**Step 8.3:** Failure mode: degraded audio (no bass, tinny sound) —
MEDIUM severity but HIGH user impact since the laptop's speakers are
essentially broken.
**Step 8.4:**
- Benefit: HIGH — makes bass speakers work on a current Lenovo laptop
- Risk: VERY LOW — single table entry, only affects this specific SSID,
  uses proven fixup
Record: [Benefit: HIGH] [Risk: VERY LOW] [Excellent ratio]

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence FOR backporting:**
- Fixes real hardware issue (no bass speakers) on a shipping Lenovo
  laptop
- Real user bug report on bugzilla.kernel.org
- Single-line quirk table addition — zero regression risk
- Reuses existing, proven fixup used by 7+ other models
- Accepted by ALSA subsystem maintainer Takashi Iwai
- Falls squarely in the "hardware quirk" exception category

**Evidence AGAINST:** None.

**Step 9.2: Stable Rules Checklist:**
1. Obviously correct? YES — single SND_PCI_QUIRK entry reusing existing
   fixup
2. Fixes real bug? YES — bass speakers don't work
3. Important? YES — hardware broken without it
4. Small and contained? YES — 1 line
5. No new features/APIs? YES — just a quirk table entry
6. Can apply to stable? YES — trivial

**Step 9.3: Exception Category:** Hardware quirk/workaround — automatic
YES category.

**Step 9.4: Decision:** Clear YES.

## Verification

- [Phase 1] Parsed tags: Reported-by from real user, Link to bugzilla
  #221298, signed-off by Takashi Iwai (ALSA maintainer)
- [Phase 2] Diff analysis: +1 line, single SND_PCI_QUIRK entry in quirk
  table
- [Phase 3] Grep confirmed ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN exists
  at line 6355 and is used by 7+ other Lenovo models
- [Phase 3] git log confirmed recent active development on alc269.c
- [Phase 5] Pure data table entry, no code flow changes
- [Phase 6] The fixup definition exists in stable trees; single-line
  addition should apply cleanly
- [Phase 8] Failure mode: broken bass speakers on Lenovo laptop,
  severity MEDIUM-HIGH, risk VERY LOW

**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 1e10af67fdb04..e55f57cca883a 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7633,6 +7633,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
 	SND_PCI_QUIRK(0x17aa, 0x390d, "Lenovo Yoga Pro 7 14ASP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
 	SND_PCI_QUIRK(0x17aa, 0x3913, "Lenovo 145", ALC236_FIXUP_LENOVO_INV_DMIC),
+	SND_PCI_QUIRK(0x17aa, 0x391a, "Lenovo Yoga Slim 7 14AKP10", ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN),
 	SND_PCI_QUIRK(0x17aa, 0x391f, "Yoga S990-16 pro Quad YC Quad", ALC287_FIXUP_TXNW2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x3920, "Yoga S990-16 pro Quad VECO Quad", ALC287_FIXUP_TXNW2781_I2C),
 	SND_PCI_QUIRK(0x17aa, 0x3929, "Thinkbook 13x Gen 5", ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD),
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.12] ALSA: hda/realtek: Add quirk for Samsung Book2 Pro 360 (NP950QED)

[Sasha Levin]

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit ea31be8a2c8c99eac198f3b7f2dc770111f2b182 ]

There is another Book2 Pro model (NP950QED) that seems equipped with
the same speaker module as the non-360 model, which requires
ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS quirk.

Reported-by: Throw <zakkabj@gmail.com>
Link: https://patch.msgid.link/20260330162249.147665-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Record: [ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS was introduced in v6.12-rc1
cycle] [Applicable to stable trees >= 6.12.y] [Note: file was moved from
sound/pci/hda/patch_realtek.c to sound/hda/codecs/realtek/alc269.c —
backport may need path adjustment for older trees]

**Step 6.2:** The quirk table structure is stable. Adding a single entry
should apply cleanly or with trivial context adjustment to any tree that
has the `ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS` enum and fixup definition.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

- Subsystem: ALSA/HDA (sound subsystem) — IMPORTANT level, affects
  laptop users
- Author: Takashi Iwai — THE ALSA subsystem maintainer
- Quirk table additions are routine and very common in stable
Record: [ALSA/HDA] [IMPORTANT] [Authored by subsystem maintainer]

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected: Users of Samsung Galaxy Book2 Pro 360 (NP950QED)
specifically.

**Step 8.2:** Trigger: Every boot on this hardware — speakers don't work
correctly without the quirk.

**Step 8.3:** Failure mode: Audio output broken/incorrect on specific
laptop. Severity: MEDIUM-HIGH (hardware doesn't function as expected,
but not a crash).

**Step 8.4:**
- BENEFIT: High — makes speakers work correctly on a popular Samsung
  laptop
- RISK: Near-zero — single line in quirk table, only matches one PCI
  subsystem ID, cannot affect any other hardware
Record: [High benefit, near-zero risk]

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**
FOR backporting:
- Hardware quirk addition — explicitly allowed exception category
- Single line addition (+1 line), zero regression risk
- Only affects one specific hardware model
- User-reported issue (Reported-by tag)
- Authored by ALSA subsystem maintainer (Takashi Iwai)
- Same quirk already used by sibling Samsung models (NP950XED, NP950XEE)
- Fixes real hardware functionality (speakers)

AGAINST backporting:
- None identified

**Step 9.2: Stable Rules Checklist**
1. Obviously correct? YES — same quirk as identical hardware siblings
2. Fixes real bug? YES — speakers don't work without it
3. Important issue? YES — hardware doesn't function
4. Small and contained? YES — 1 line
5. No new features/APIs? CORRECT — no new features
6. Applies to stable? YES — clean apply for trees with the fixup enum
   (6.12+)

**Step 9.3: Exception Category**
This is a **hardware quirk/workaround** — one of the explicitly listed
exception categories that are automatically YES for stable.

## Verification

- [Phase 1] Parsed tags: Reported-by from user, Link to patch
  submission, SOB from Takashi Iwai (ALSA maintainer)
- [Phase 2] Diff: +1 line SND_PCI_QUIRK entry in alc269_fixup_tbl[] for
  PCI ID 0x144d:0xc1ac
- [Phase 3] Grep confirmed ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS used by 2
  sibling Samsung models (lines 7390-7391)
- [Phase 3] git log -S confirmed the fixup enum was introduced in commit
  7e4d4b32ab953 (v6.12-rc1 cycle)
- [Phase 3] Takashi Iwai confirmed as ALSA maintainer via git log
- [Phase 5] Data-only change to static quirk table, no logic changes
- [Phase 6] Fixup exists in 6.12+ trees; file path changed in recent
  kernels (may need adjustment for older trees)
- [Phase 8] Impact: speakers non-functional on specific Samsung laptop
  without this quirk; risk: near-zero

This is a textbook stable backport candidate: a single-line hardware
quirk addition by the subsystem maintainer, fixing real audio hardware
for a specific laptop model, with zero regression risk.

**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 19f23c92fdcdb..1e10af67fdb04 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7376,6 +7376,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x144d, 0xc188, "Samsung Galaxy Book Flex (NT950QCT-A38A)", ALC298_FIXUP_SAMSUNG_AMP),
 	SND_PCI_QUIRK(0x144d, 0xc189, "Samsung Galaxy Book Flex (NT950QCG-X716)", ALC298_FIXUP_SAMSUNG_AMP),
 	SND_PCI_QUIRK(0x144d, 0xc18a, "Samsung Galaxy Book Ion (NP930XCJ-K01US)", ALC298_FIXUP_SAMSUNG_AMP),
+	SND_PCI_QUIRK(0x144d, 0xc1ac, "Samsung Galaxy Book2 Pro 360 (NP950QED)", ALC298_FIXUP_SAMSUNG_AMP_V2_2_AMPS),
 	SND_PCI_QUIRK(0x144d, 0xc1a3, "Samsung Galaxy Book Pro (NP935XDB-KC1SE)", ALC298_FIXUP_SAMSUNG_AMP),
 	SND_PCI_QUIRK(0x144d, 0xc1a4, "Samsung Galaxy Book Pro 360 (NT935QBD)", ALC298_FIXUP_SAMSUNG_AMP),
 	SND_PCI_QUIRK(0x144d, 0xc1a6, "Samsung Galaxy Book Pro 360 (NP930QBD)", ALC298_FIXUP_SAMSUNG_AMP),
-- 
2.53.0

[PATCH AUTOSEL 6.19-5.10] ASoC: soc-core: call missing INIT_LIST_HEAD() for card_aux_list

[Sasha Levin]

From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

[ Upstream commit b9eff9732cb0f86a68c9d1592a98ceab47c01e95 ]

Component has "card_aux_list" which is added/deled in bind/unbind aux dev
function (A), and used in for_each_card_auxs() loop (B).

	static void soc_unbind_aux_dev(...)
	{
		...
		for_each_card_auxs_safe(...) {
			...
(A)			list_del(&component->card_aux_list);
		}			     ^^^^^^^^^^^^^
	}

	static int soc_bind_aux_dev(...)
	{
		...
		for_each_card_pre_auxs(...) {
			...
(A)			list_add(&component->card_aux_list, ...);
		}			     ^^^^^^^^^^^^^
		...
	}

	#define for_each_card_auxs(card, component)	\
(B)		list_for_each_entry(component, ..., card_aux_list)
						    ^^^^^^^^^^^^^

But it has been used without calling INIT_LIST_HEAD().

	> git grep card_aux_list sound/soc
	sound/soc/soc-core.c:           list_del(&component->card_aux_list);
	sound/soc/soc-core.c:           list_add(&component->card_aux_list, ...);

call missing INIT_LIST_HEAD() for it.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87341mxa8l.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Wait - the current mainline code (after this commit was applied) already
has the fix. The diff in the commit shows `snd_soc_dapm_alloc` context,
but the current code doesn't have it. That means between the commit and
now, `snd_soc_dapm_alloc` was removed. In any case, this is a one-line
addition that can easily be adapted for any stable tree.

Now let me complete the synthesis.

---

## Complete Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1:** Subsystem: `ASoC: soc-core:`. Action: "call missing" (=
fix missing initialization). Summary: Adds missing `INIT_LIST_HEAD()`
for `card_aux_list` in the component initialization function.

**Step 1.2:** Tags:
- `Signed-off-by: Kuninori Morimoto` (author, primary ASoC contributor
  and subsystem co-maintainer)
- `Link:` to patch.msgid.link (patch discussion)
- `Signed-off-by: Mark Brown` (ASoC subsystem maintainer)
- No Fixes: tag (expected for our review)
- No Cc: stable (expected)
- No Reported-by (the author found this through code inspection)

**Step 1.3:** The commit message clearly explains the bug:
`card_aux_list` is used in `list_add`/`list_del` operations during aux
device bind/unbind, and iterated via `for_each_card_auxs()`, but was
never initialized with `INIT_LIST_HEAD()`. The `git grep` output proves
the field is used but never initialized.

**Step 1.4:** This is NOT a hidden bug fix - it's an explicit
initialization bug fix. The "call missing" language is direct.

### PHASE 2: DIFF ANALYSIS

**Step 2.1:** Single file changed: `sound/soc/soc-core.c`, +1 line.
Single function modified: `snd_soc_component_initialize()`.

**Step 2.2:** Before: `card_aux_list` member of `snd_soc_component` was
never initialized. After: it's properly initialized via
`INIT_LIST_HEAD()` alongside the other list heads in the same
initialization function.

**Step 2.3:** Bug category: **Uninitialized data / missing
initialization**. The `card_aux_list` `list_head` structure was zeroed
by `kzalloc` but never properly initialized. A proper `list_head`
requires `next` and `prev` to point to itself (not be NULL). Operations
like `list_empty()` check `head->next == head`, which returns false for
a zeroed list (0 != &self). With `CONFIG_DEBUG_LIST` or
`CONFIG_LIST_HARDENED`, list operations on uninitialized list heads will
trigger warnings/BUGs.

**Step 2.4:** Fix is trivially correct - adding one `INIT_LIST_HEAD()`
call. Zero regression risk. Pattern matches exactly the surrounding
code.

### PHASE 3: GIT HISTORY

**Step 3.1:** The buggy code was introduced in commit `495efdb01f89a`
(v5.4, 2019) which consolidated list initializations into
`snd_soc_component_initialize()` but missed `card_aux_list`. The
`card_aux_list` field itself was added in commit `d2e3a1358c37c` (v4.10,
2016).

**Step 3.2:** No Fixes: tag to follow, but the root cause is
`495efdb01f89a` which moved initialization but missed this list.

**Step 3.3:** The author (Kuninori Morimoto) is the same person who
wrote `495efdb01f89a` - he's fixing his own oversight.

**Step 3.4:** Kuninori Morimoto is the primary ASoC contributor and
effectively co-maintains the subsystem with Mark Brown.

**Step 3.5:** No dependencies - this is a standalone one-line fix.

### PHASE 4: EXTERNAL RESEARCH

Lore was unavailable due to anti-bot protection. From MARC archive: only
the author's patch and Mark Brown's application, no concerns raised.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1:** Modified function: `snd_soc_component_initialize()`
**Step 5.2:** Called from: `snd_soc_register_component()`,
`snd_soc_add_component()` callers, various driver probe functions (Intel
AVS, catpt, MediaTek, STM32, topology tests).
**Step 5.3:** The function initializes component lists and sets up the
component structure.
**Step 5.4:** Every ASoC component goes through this initialization
path. Very widely used.
**Step 5.5:** All other list heads (`dai_list`, `dobj_list`,
`card_list`, `list`) are already initialized - `card_aux_list` was the
only one missing.

### PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The `snd_soc_component_initialize()` function exists in
all active stable trees (v5.10+). The `card_aux_list` field exists since
v4.10.

**Step 6.2:** The context may differ slightly in older stable trees
(e.g., `snd_soc_dapm_alloc` in the commit's context is not in current
code). However, this is a one-line addition that can trivially adapt -
just add `INIT_LIST_HEAD(&component->card_aux_list);` after the other
INIT_LIST_HEAD calls.

**Step 6.3:** No related fixes already in stable.

### PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** Subsystem: ASoC (ALSA System on Chip) audio subsystem.
Criticality: IMPORTANT - affects all systems using ASoC (most
embedded/mobile audio, many laptops).

**Step 7.2:** Very actively developed subsystem.

### PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects all users of ASoC auxiliary devices (aux_dev).
Common on embedded systems (Renesas, Samsung, Intel, MediaTek, STM
platforms).

**Step 8.2:** Triggered when a component is used as an auxiliary device.
The uninitialized list could cause issues on: (1) systems with
`CONFIG_DEBUG_LIST` or `CONFIG_LIST_HARDENED` enabled, (2) potential
subtle memory corruption if `list_del` is called on a component whose
`card_aux_list` was never properly linked.

**Step 8.3:** Failure mode: With `CONFIG_LIST_HARDENED`, a `BUG()`
(kernel crash). Without it, potential NULL pointer dereference or list
corruption. Severity: HIGH.

**Step 8.4:**
- Benefit: HIGH - fixes a latent initialization bug that affects all
  ASoC aux component users and prevents crashes/corruption
- Risk: VERY LOW - single-line addition of `INIT_LIST_HEAD`, identical
  pattern to adjacent code
- Ratio: Strongly favorable for backport

### PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real initialization bug present since 2016/2019
- One-line, obviously correct fix
- Zero regression risk
- Pattern matches adjacent code exactly
- Author is the subsystem co-maintainer who wrote the original code
- Accepted by the ASoC maintainer (Mark Brown)
- Affects all active stable trees
- Prevents potential crashes with CONFIG_LIST_HARDENED/CONFIG_DEBUG_LIST
- Standalone fix with no dependencies

**Evidence AGAINST backporting:**
- No user-reported crash (found by code inspection)
- In normal operation with kzalloc-zeroed memory and no
  CONFIG_DEBUG_LIST, the bug may be latent (components are typically
  added to aux_comp_list before list_del is called)

**Stable rules checklist:**
1. Obviously correct and tested? **YES** - trivially correct one-line
   init
2. Fixes a real bug? **YES** - uninitialized list_head is a real bug
3. Important issue? **YES** - can cause crashes with hardened list
   checking, potential corruption
4. Small and contained? **YES** - 1 line, 1 file
5. No new features? **YES** - pure initialization fix
6. Can apply to stable? **YES** - may need minor context adjustment

### Verification:
- [Phase 1] Parsed tags: Signed-off-by from author (Morimoto) and
  maintainer (Brown), Link to msgid
- [Phase 2] Diff analysis: +1 line adding
  `INIT_LIST_HEAD(&component->card_aux_list)` in
  `snd_soc_component_initialize()`
- [Phase 3] git blame: INIT_LIST_HEAD block introduced in
  `08ff7209faf21` (v5.9 era), moved by `495efdb01f89a` (v5.4 era)
- [Phase 3] git log -S: Confirmed `INIT_LIST_HEAD` for `card_aux_list`
  was NEVER present in the kernel before this commit
- [Phase 3] `card_aux_list` field introduced in `d2e3a1358c37c` (v4.10,
  2016) - bug present since then
- [Phase 5] `snd_soc_component_initialize()` called from
  `snd_soc_register_component()` and multiple driver probes
- [Phase 6] `snd_soc_component_initialize()` confirmed present in v5.10,
  v5.15, v6.1, v6.6, v6.12 via `git merge-base`
- [Phase 6] Component allocated via `devm_kzalloc` at soc-core.c:2929,
  meaning fields are zeroed but not properly initialized as list heads
- [Phase 8] Failure mode: BUG() with CONFIG_LIST_HARDENED, potential
  NULL deref without it. Severity HIGH.
- UNVERIFIED: Could not access lore.kernel.org discussion due to anti-
  bot protection

**YES**

 sound/soc/soc-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 23ba821cd759d..c9a6471661ad7 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2849,6 +2849,7 @@ int snd_soc_component_initialize(struct snd_soc_component *component,
 	INIT_LIST_HEAD(&component->dobj_list);
 	INIT_LIST_HEAD(&component->card_list);
 	INIT_LIST_HEAD(&component->list);
+	INIT_LIST_HEAD(&component->card_aux_list);
 	mutex_init(&component->io_mutex);
 
 	if (!component->name) {
-- 
2.53.0