[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-5.10] MIPS: mm: Suppress TLB uniquification on EHINV hardware

[Sasha Levin]

From: "Maciej W. Rozycki" <macro@orcam.me.uk>

[ Upstream commit 74283cfe216392c7b776ebf6045b5b15ed9dffcd ]

Hardware that supports the EHINV feature, mandatory for R6 ISA and FTLB
implementation, lets software mark TLB entries invalid, which eliminates
the need to ensure no duplicate matching entries are ever created.  This
feature is already used by local_flush_tlb_all(), via the UNIQUE_ENTRYHI
macro, making the preceding call to r4k_tlb_uniquify() superfluous.

The next change will also modify uniquification code such that it'll
become incompatible with the FTLB and MMID features, as well as MIPSr6
CPUs that do not implement 4KiB pages.

Therefore prevent r4k_tlb_uniquify() from being used on EHINV hardware,
as denoted by `cpu_has_tlbinv'.

Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 arch/mips/mm/tlb-r4k.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/mm/tlb-r4k.c b/arch/mips/mm/tlb-r4k.c
index 44a662536148e..27bb644696047 100644
--- a/arch/mips/mm/tlb-r4k.c
+++ b/arch/mips/mm/tlb-r4k.c
@@ -640,7 +640,8 @@ static void r4k_tlb_configure(void)
 	temp_tlb_entry = current_cpu_data.tlbsize - 1;
 
 	/* From this point on the ARC firmware is dead.	 */
-	r4k_tlb_uniquify();
+	if (!cpu_has_tlbinv)
+		r4k_tlb_uniquify();
 	local_flush_tlb_all();
 
 	/* Did I tell you that ARC SUCKS?  */
-- 
2.53.0

[PATCH AUTOSEL 6.19-6.18] drm/amdkfd: Fix queue preemption/eviction failures by aligning control stack size to GPU page size

[Sasha Levin]

From: Donet Tom <donettom@linux.ibm.com>

[ Upstream commit 78746a474e92fc7aaed12219bec7c78ae1bd6156 ]

The control stack size is calculated based on the number of CUs and
waves, and is then aligned to PAGE_SIZE. When the resulting control
stack size is aligned to 64 KB, GPU hangs and queue preemption
failures are observed while running RCCL unit tests on systems with
more than two GPUs.

amdgpu 0048:0f:00.0: amdgpu: Queue preemption failed for queue with
doorbell_id: 80030008
amdgpu 0048:0f:00.0: amdgpu: Failed to evict process queues
amdgpu 0048:0f:00.0: amdgpu: GPU reset begin!. Source: 4
amdgpu 0048:0f:00.0: amdgpu: Queue preemption failed for queue with
doorbell_id: 80030008
amdgpu 0048:0f:00.0: amdgpu: Failed to evict process queues
amdgpu 0048:0f:00.0: amdgpu: Failed to restore process queues

This issue is observed on both 4 KB and 64 KB system page-size
configurations.

This patch fixes the issue by aligning the control stack size to
AMDGPU_GPU_PAGE_SIZE instead of PAGE_SIZE, so the control stack size
will not be 64 KB on systems with a 64 KB page size and queue
preemption works correctly.

Additionally, In the current code, wg_data_size is aligned to PAGE_SIZE,
which can waste memory if the system page size is large. In this patch,
wg_data_size is aligned to AMDGPU_GPU_PAGE_SIZE. The cwsr_size, calculated
from wg_data_size and the control stack size, is aligned to PAGE_SIZE.

Reviewed-by: Felix Kuehling <felix.kuehling@amd.com>
Signed-off-by: Donet Tom <donettom@linux.ibm.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit a3e14436304392fbada359edd0f1d1659850c9b7)
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a thorough analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line Analysis
- **Subsystem**: drm/amdkfd (AMD KFD - Kernel Fusion Driver for GPU
  compute)
- **Action verb**: "Fix" - explicitly a bug fix
- **Summary**: Fixes GPU queue preemption/eviction failures by aligning
  control stack size to GPU page size instead of system page size

Record: [drm/amdkfd] [Fix] [Queue preemption/eviction failures from
incorrect alignment to CPU page size]

### Step 1.2: Tags
- **Reviewed-by**: Felix Kuehling <felix.kuehling@amd.com> (AMD KFD
  subsystem maintainer)
- **Signed-off-by**: Donet Tom <donettom@linux.ibm.com> (author, IBM)
- **Signed-off-by**: Alex Deucher <alexander.deucher@amd.com> (AMD GPU
  maintainer)
- **Cherry-picked from**: a3e14436304392fbada359edd0f1d1659850c9b7
- No Fixes: tag (expected for manual review candidates)
- No Cc: stable (expected)

Record: Reviewed by AMD KFD maintainer. Author is from IBM (Power
systems, which commonly use 64KB page sizes). Maintainer signoff from
Alex Deucher.

### Step 1.3: Commit Body Text
The commit describes a clear, reproducible bug:
- **Bug**: When control stack size aligns to 64 KB (on systems with
  PAGE_SIZE=64KB), GPU hangs and queue preemption failures occur
- **Symptom**: Real error messages included: "Queue preemption failed",
  "Failed to evict process queues", "GPU reset begin!"
- **Trigger**: Running RCCL unit tests on systems with more than two
  GPUs
- **Root cause**: Control stack size aligned to CPU PAGE_SIZE (which can
  be 64KB) instead of AMDGPU_GPU_PAGE_SIZE (always 4KB)
- **Affected configurations**: Both 4KB and 64KB system page-size
  configurations (but the bug only manifests on 64KB page systems)

Record: GPU hang, queue preemption failures, GPU resets. Clearly
documented with error messages. IBM Power10 with AMD Instinct GPUs is
the main platform affected.

### Step 1.4: Hidden Bug Fix Detection
This is not hidden - it is explicitly labeled as a fix with clear error
messages and reproduction scenario.

Record: Not a hidden fix; explicitly a bug fix with documented failure
mode.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory of Changes
- **Files changed**: 1 (drivers/gpu/drm/amd/amdkfd/kfd_queue.c)
- **Lines changed**: ~5 lines modified in one function
- **Functions modified**: `kfd_queue_ctx_save_restore_size()`
- **Scope**: Single-file surgical fix

Record: 1 file, ~5 lines, 1 function. Very small, very contained.

### Step 2.2: Code Flow Changes

**Hunk 1**: `wg_data_size` alignment changed from `PAGE_SIZE` to
`AMDGPU_GPU_PAGE_SIZE`
- Before: `ALIGN(..., PAGE_SIZE)` → on 64KB page systems, aligns to 64KB
- After: `ALIGN(..., AMDGPU_GPU_PAGE_SIZE)` → always aligns to 4KB (GPU
  page size)

**Hunk 2**: `ctl_stack_size` alignment changed from `PAGE_SIZE` to
`AMDGPU_GPU_PAGE_SIZE`
- Before: `ALIGN(..., PAGE_SIZE)` → on 64KB page systems, could produce
  64KB
- After: `ALIGN(..., AMDGPU_GPU_PAGE_SIZE)` → always aligns to 4KB

**Hunk 3**: `cwsr_size` now aligned to `PAGE_SIZE` for final system
memory allocation
- Before: `cwsr_size = ctl_stack_size + wg_data_size` (no final
  alignment)
- After: `cwsr_size = ALIGN(ctl_stack_size + wg_data_size, PAGE_SIZE)`
  (ensures system page alignment for memory allocation)

Record: Intermediate GPU-internal sizes align to GPU page (4KB), final
allocation size aligns to CPU page. This is the correct design pattern.

### Step 2.3: Bug Mechanism
Category: **Logic/correctness fix** - wrong alignment boundary causes
hardware-incompatible control stack sizes.

On 64KB page systems, the control stack was being padded to 64KB, which
is incompatible with the GPU hardware's expectations. The GPU hardware
operates with 4KB pages, so GPU-internal structures should be aligned to
GPU page boundaries (4KB), not CPU page boundaries.

Record: Logic/correctness bug. Wrong alignment boundary (CPU vs GPU page
size) causes GPU hardware to fail during queue preemption.

### Step 2.4: Fix Quality
- **Obviously correct**: Yes. GPU internal structures should align to
  GPU page size, not CPU page size. The final allocation aligns to CPU
  page size for system memory.
- **Minimal/surgical**: Yes. Only 3 alignment changes in one function.
- **Regression risk**: Very low. On 4KB page systems (majority), this is
  a no-op since `AMDGPU_GPU_PAGE_SIZE == PAGE_SIZE == 4096`. The
  `ALIGN(cwsr_size, PAGE_SIZE)` addition only rounds up, never down.
- **Red flags**: None.

Record: Obviously correct, minimal, very low regression risk. No-op on
4KB page systems.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame the Changed Lines
The buggy code was introduced in commit `517fff221c1e6` ("drm/amdkfd:
Store queue cwsr area size to node properties") by Philip Yang, which
first appeared in v6.12.

Record: Buggy code introduced in v6.12 (commit 517fff221c1e6). Present
in stable trees v6.12.y and later.

### Step 3.2: Fixes Tag
No explicit Fixes: tag present. However, the buggy commit is clearly
`517fff221c1e6` which introduced this function with PAGE_SIZE alignment.

Record: No Fixes: tag, but root cause commit identified as 517fff221c1e6
(v6.12).

### Step 3.3: File History
Recent changes to kfd_queue.c include relaxing size checks, bumping vgpr
sizes, and GFX7/8 queue validation fixes. Several changes have occurred
since v6.12 (7 commits) that modified the function and surrounding code.

Record: 7 commits changed this file since v6.12. The function has had
some macro changes (WG_CONTEXT_DATA_SIZE_PER_CU now takes props
parameter). Minor backport adjustment may be needed.

### Step 3.4: Author's Commits
Donet Tom from IBM has authored related non-4K page size fixes:
- "Fix GART PTE for non-4K pagesize in svm_migrate_gart_map()"
- "Relax size checking during queue buffer get"
- Companion patch: "drm/amd: Fix MQD and control stack alignment for
  non-4K"

Record: Author is actively fixing non-4K page size issues in AMD GPU
drivers. Specialized domain knowledge from IBM Power platform.

### Step 3.5: Dependencies
The companion MQD alignment patch (`6caeace0d1471`) touches different
files (amdgpu_gart.c, amdgpu_ttm.c, kfd_mqd_manager_v9.c) and is NOT in
HEAD. It addresses a separate issue (memory type assignment for MQD vs
control stack on gfx9). The commit under review is self-contained - it
only changes size calculations.

On stable 6.12.y, the `WG_CONTEXT_DATA_SIZE_PER_CU` macro takes only
`(gfxv)` not `(gfxv, props)`. This means the patch will need a trivial
context adjustment for clean application to 6.12.y.

Record: Self-contained fix. Minor context adjustment needed for 6.12.y
due to macro signature difference. Companion MQD patch is independent.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Patch Discussion
The patch went through three RFC versions and a final PATCH v2:
- **Christian König** initially raised concerns about debugger CPU-side
  alignment, but later gave **Acked-by** after the fix was demonstrated
  to resolve GPU hangs
- **Felix Kuehling** gave formal **Reviewed-by** and stated "The series
  looks good to me"
- **Alex Deucher** confirmed inclusion for mainline
- No NAKs
- No explicit stable nomination found in discussion

Record: Positive review from two AMD maintainers. Initial concern from
König was addressed and resolved.

### Step 4.2: Bug Report
The bug was found during RCCL (AMD's collective communications library)
unit testing on Power10 systems with multiple AMD GPUs. Real error
messages in the commit show reproducible GPU hangs.

Record: Real, reproducible bug found in multi-GPU compute testing on IBM
Power systems.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
Modified function: `kfd_queue_ctx_save_restore_size()`

### Step 5.2: Callers
Called from `kfd_topology.c:2193` during topology device initialization.
This runs during GPU driver initialization for every AMD GPU, affecting
all KFD-capable AMD GPU users.

### Step 5.3-5.4: Call Chain
The computed values (`ctl_stack_size`, `cwsr_size`) are stored in node
properties and used during queue creation/validation in
`kfd_queue_acquire_buffers()`. This is a critical path for any GPU
compute workload.

Record: Called during GPU initialization. Values used for all compute
queue operations. High impact surface.

### Step 5.5: Similar Patterns
The companion MQD fix addresses the same root cause (CPU vs GPU page
alignment mismatch) in different code paths, confirming this is a
systematic issue for non-4K page systems.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
The function `kfd_queue_ctx_save_restore_size` was introduced in v6.12
(commit 517fff221c1e6). It exists in stable trees v6.12.y and later.

Record: Bug exists in v6.12.y, v6.13.y, v6.14.y stable trees.

### Step 6.2: Backport Complications
The `WG_CONTEXT_DATA_SIZE_PER_CU` macro signature changed (added `props`
parameter) since v6.12. The patch will need a trivial context adjustment
for 6.12.y (use `WG_CONTEXT_DATA_SIZE_PER_CU(gfxv)` instead of
`WG_CONTEXT_DATA_SIZE_PER_CU(gfxv, props)`).

Record: Minor context adjustment needed for 6.12.y. Should apply more
cleanly to 6.13.y+.

### Step 6.3: Related Fixes in Stable
No related fix for this specific issue found in stable trees.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: drm/amdkfd (GPU compute driver)
- **Criticality**: IMPORTANT - affects users of AMD GPUs for compute
  workloads (HPC, AI/ML, scientific computing)

### Step 7.2: Subsystem Activity
Very active subsystem with frequent commits (20+ in recent history on
kfd_queue.c alone).

Record: Active, important subsystem for GPU compute users.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Population
Systems with non-4K CPU page sizes using AMD GPUs for compute.
Primarily:
- IBM Power systems (ppc64le, 64KB page size) with AMD Instinct GPUs
- ARM64 systems with 64KB page configurations
- Any system where PAGE_SIZE > 4096

Record: Platform-specific but affects all GPU compute workloads on those
platforms.

### Step 8.2: Trigger Conditions
- Multi-GPU compute workloads (RCCL unit tests with >2 GPUs)
- Queue preemption/eviction (normal GPU scheduling operations)
- Trigger is common during real compute workloads

Record: Common trigger during normal GPU compute operations on affected
platforms.

### Step 8.3: Failure Mode Severity
- **GPU hang** → CRITICAL
- **Queue preemption failure** → CRITICAL (GPU becomes unusable)
- **GPU reset** → CRITICAL (interrupts all GPU work)
- **Failed to restore process queues** → Data loss for running GPU
  workloads

Record: CRITICAL severity - GPU hangs, forced resets, compute workload
failures.

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: HIGH - prevents GPU hangs and resets on non-4K page
  systems
- **Risk**: VERY LOW -
  - Only 3 alignment changes in one function
  - No-op on 4KB page systems (the majority)
  - Obviously correct - GPU internal structures should use GPU page
    alignment
  - Reviewed by AMD KFD maintainer

Record: HIGH benefit, VERY LOW risk. Excellent ratio.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Compilation

**FOR backporting:**
- Fixes GPU hangs and forced GPU resets (CRITICAL severity)
- Small, surgical fix (3 alignment changes in 1 function)
- Obviously correct (GPU structures align to GPU page size)
- Reviewed by AMD KFD maintainer (Felix Kuehling)
- Acked by Christian König after initial concerns resolved
- Real, reproducible bug with documented error messages
- Self-contained - no dependencies on other patches
- No-op on 4KB page systems - zero regression risk for majority of users

**AGAINST backporting:**
- No Fixes: tag or Cc: stable (expected for manual review candidates)
- Minor context adjustment needed for 6.12.y backport
- Affects only non-4K page size systems (smaller population)

**UNRESOLVED:**
- Exact impact on ARM64 with 64KB pages (only documented on Power10)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES - Reviewed by maintainer,
   tested on real hardware
2. **Fixes a real bug?** YES - GPU hangs, queue preemption failures, GPU
   resets
3. **Important issue?** YES - GPU hangs are CRITICAL
4. **Small and contained?** YES - 3 lines in 1 function
5. **No new features or APIs?** YES - pure bugfix
6. **Can apply to stable trees?** YES with minor context adjustment for
   6.12.y

### Step 9.3: Exception Categories
Not an exception category - this is a straightforward bug fix that
qualifies on its own merit.

### Step 9.4: Decision
The evidence overwhelmingly supports backporting. This is a small,
obviously correct fix for a CRITICAL GPU hang issue. The fix is self-
contained, reviewed by the subsystem maintainer, and carries effectively
zero regression risk for the majority of systems.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Felix Kuehling (AMD KFD
  maintainer), SOB from Alex Deucher (AMD GPU maintainer), author from
  IBM
- [Phase 2] Diff analysis: 3 alignment changes in
  kfd_queue_ctx_save_restore_size(): wg_data_size and ctl_stack_size
  changed from PAGE_SIZE to AMDGPU_GPU_PAGE_SIZE alignment, cwsr_size
  gets ALIGN(PAGE_SIZE)
- [Phase 2] Verified AMDGPU_GPU_PAGE_SIZE = 4096 (constant) defined in
  amdgpu_gart.h:35
- [Phase 3] git log: function introduced in commit 517fff221c1e6 ("Store
  queue cwsr area size to node properties"), first in v6.12
- [Phase 3] git merge-base: confirmed code is in v6.12 but NOT in v6.11
- [Phase 3] git diff v6.12..HEAD: confirmed 7 commits changed the file
  since v6.12, including macro signature change for
  WG_CONTEXT_DATA_SIZE_PER_CU
- [Phase 3] git log --author="Donet Tom": confirmed 2 other AMD non-4K
  page fixes
- [Phase 3] Confirmed companion MQD patch (6caeace0d) is NOT in HEAD and
  touches different files (independent)
- [Phase 4] Lore/mailing list research: patch went through RFC v1-v3 and
  PATCH v2, received Reviewed-by and Acked-by, no NAKs
- [Phase 5] Grep callers: kfd_queue_ctx_save_restore_size called from
  kfd_topology.c during device init
- [Phase 5] Grep cwsr_size: used in kfd_queue_acquire_buffers for queue
  validation and allocation
- [Phase 6] Confirmed buggy code exists in v6.12.y stable tree
- [Phase 6] Minor context adjustment needed for v6.12.y (macro signature
  difference)
- [Phase 8] Failure mode: GPU hang, forced GPU reset → CRITICAL severity
- [Phase 8] On 4KB page systems: AMDGPU_GPU_PAGE_SIZE == PAGE_SIZE ==
  4096, so fix is a no-op → zero regression risk

**YES**

 drivers/gpu/drm/amd/amdkfd/kfd_queue.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c
index 2822c90bd7be4..b97f4a51db6e3 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_queue.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_queue.c
@@ -444,10 +444,11 @@ void kfd_queue_ctx_save_restore_size(struct kfd_topology_device *dev)
 		    min(cu_num * 40, props->array_count / props->simd_arrays_per_engine * 512)
 		    : cu_num * 32;
 
-	wg_data_size = ALIGN(cu_num * WG_CONTEXT_DATA_SIZE_PER_CU(gfxv, props), PAGE_SIZE);
+	wg_data_size = ALIGN(cu_num * WG_CONTEXT_DATA_SIZE_PER_CU(gfxv, props),
+				AMDGPU_GPU_PAGE_SIZE);
 	ctl_stack_size = wave_num * CNTL_STACK_BYTES_PER_WAVE(gfxv) + 8;
 	ctl_stack_size = ALIGN(SIZEOF_HSA_USER_CONTEXT_SAVE_AREA_HEADER + ctl_stack_size,
-			       PAGE_SIZE);
+			       AMDGPU_GPU_PAGE_SIZE);
 
 	if ((gfxv / 10000 * 10000) == 100000) {
 		/* HW design limits control stack size to 0x7000.
@@ -459,7 +460,7 @@ void kfd_queue_ctx_save_restore_size(struct kfd_topology_device *dev)
 
 	props->ctl_stack_size = ctl_stack_size;
 	props->debug_memory_size = ALIGN(wave_num * DEBUGGER_BYTES_PER_WAVE, DEBUGGER_BYTES_ALIGN);
-	props->cwsr_size = ctl_stack_size + wg_data_size;
+	props->cwsr_size = ALIGN(ctl_stack_size + wg_data_size, PAGE_SIZE);
 
 	if (gfxv == 80002)	/* GFX_VERSION_TONGA */
 		props->eop_buffer_size = 0x8000;
-- 
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.10] wifi: wl1251: validate packet IDs before indexing tx_frames

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit 0fd56fad9c56356e7fa7a7c52e7ecbf807a44eb0 ]

wl1251_tx_packet_cb() uses the firmware completion ID directly to index
the fixed 16-entry wl->tx_frames[] array. The ID is a raw u8 from the
completion block, and the callback does not currently verify that it
fits the array before dereferencing it.

Reject completion IDs that fall outside wl->tx_frames[] and keep the
existing NULL check in the same guard. This keeps the fix local to the
trust boundary and avoids touching the rest of the completion flow.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260323080845.40033-1-pengpeng@iscas.ac.cn
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The function `wl1251_tx_packet_cb()` has been essentially unchanged
since 2009. The surrounding code is identical across all stable trees
(the only recent change was the `ieee80211_tx_status` rename in 2023,
which is only in the newer trees). The patch should apply cleanly or
with trivial adjustment.

Record: Clean apply expected on most stable trees. Minor conflict
possible on older trees due to function name rename
(`ieee80211_tx_status` vs `ieee80211_tx_status_skb`), but the fix itself
(the bounds check at the top of the function) is completely independent
of that.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY IN STABLE
No related fixes for this specific issue found.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM
- **Subsystem**: drivers/net/wireless/ti/wl1251 — WiFi driver for TI
  WL1251 chipset
- **Criticality**: PERIPHERAL — specific hardware driver, but used in
  some embedded/mobile devices (notably Nokia N900 and similar)
- **Maintainer**: Johannes Berg signed off, he is the WiFi subsystem
  maintainer — strong endorsement

Record: [Peripheral WiFi driver] [Maintainer-approved by Johannes Berg]

### Step 7.2: SUBSYSTEM ACTIVITY
Very low activity — 10 commits in the file's lifetime. This is a mature,
stable driver. The bug has been present for 17 years.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
Users of TI WL1251 WiFi hardware (embedded systems, older Nokia phones,
some industrial devices).

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
- Triggered when firmware returns a corrupt or unexpected completion ID
  (>= 16)
- Could be triggered by firmware bugs, hardware glitches, or malicious
  firmware
- The user cannot directly control the trigger, but a compromised/buggy
  firmware can

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Without the bounds check, `result->id` (u8, range 0-255) is used to
index a 16-entry array. An OOB read from `wl->tx_frames[result->id]`
where id >= 16 reads kernel memory beyond the struct. This could result
in:
- **Kernel crash/oops** (if the read returns a value that's dereferenced
  and happens to be invalid)
- **Memory corruption** (line 441: `wl->tx_frames[result->id] = NULL`
  writes NULL to OOB location)
- **Information leak** (reading and processing an arbitrary skb pointer
  from kernel memory)

The OOB **write** at line 441 (`wl->tx_frames[result->id] = NULL`) is
particularly dangerous — it writes NULL to an arbitrary offset within
kernel memory.

Record: Severity HIGH to CRITICAL. OOB read leads to use of arbitrary
pointer; OOB write corrupts kernel memory.

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit**: Prevents OOB read and write from untrusted firmware data.
  Prevents potential kernel crashes and memory corruption.
- **Risk**: Extremely low. The fix adds a single bounds check with
  `ARRAY_SIZE()` and returns early. It cannot introduce a regression.
- **Assessment**: Very favorable benefit-to-risk ratio.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Fixes a genuine OOB array access from untrusted firmware input (both
  read and write)
- Bug has existed since 2009 — present in ALL stable trees
- Fix is 6 lines, obviously correct, minimal, and self-contained
- Uses standard `ARRAY_SIZE()` bounds check idiom
- No dependencies on other patches
- Approved by WiFi subsystem maintainer (Johannes Berg)
- OOB write at line 441 could corrupt arbitrary kernel memory
- Clean backport expected

**AGAINST backporting:**
- Peripheral driver (TI WL1251, limited user base)
- No reported real-world triggers (theoretical, though firmware is
  untrusted)
- No syzbot report or CVE

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES — simple ARRAY_SIZE bounds
   check, merged by maintainer
2. **Fixes a real bug?** YES — OOB array access from unvalidated
   firmware data
3. **Important issue?** YES — potential kernel memory corruption from
   OOB write
4. **Small and contained?** YES — 6 lines in one function in one file
5. **No new features or APIs?** YES — pure validation addition
6. **Can apply to stable trees?** YES — code unchanged since 2009

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Not an exception category — this is a standard bug fix.

### Step 9.4: DECISION
The fix is small, surgical, obviously correct, and prevents out-of-
bounds array access (both read and write) from untrusted firmware data.
The OOB write to `wl->tx_frames[result->id] = NULL` is particularly
dangerous as it could corrupt kernel memory at an offset up to ~2KB
beyond the struct. While the driver serves a limited user base, the fix
has essentially zero regression risk and addresses a real memory safety
issue.

## Verification

- [Phase 1] Parsed tags: Signed-off-by author (Pengpeng Hou) and
  maintainer (Johannes Berg). No Fixes/Reported-by/Cc:stable (expected).
- [Phase 2] Diff analysis: ~6 lines changed in `wl1251_tx_packet_cb()`.
  Adds `ARRAY_SIZE()` bounds check before array index. Also protects OOB
  write at line 441.
- [Phase 2] Confirmed `tx_frames` is a 16-entry array (`struct sk_buff
  *tx_frames[16]` at wl1251.h:310), `result->id` is u8 (range 0-255).
- [Phase 3] git blame: Buggy code introduced in commit 2f01a1f58889fb
  (2009-04-29, Kalle Valo). Present since initial driver submission.
- [Phase 3] git log: File has only 10 commits total, very stable code.
  No recent refactoring.
- [Phase 3] Author check: Pengpeng Hou has 1 other similar bounds-
  checking fix (btusb).
- [Phase 4] UNVERIFIED: Could not access lore.kernel.org (Anubis block).
  Unable to check mailing list discussion.
- [Phase 5] Traced callers: `wl1251_tx_packet_cb()` called from
  `wl1251_tx_complete()` which reads `result` directly from firmware
  shared memory via `wl1251_mem_read()`. The `result->id` is firmware-
  controlled.
- [Phase 5] Both OOB accesses (line 405 read, line 441 write) are
  protected by the new check.
- [Phase 6] Bug exists in all active stable trees (code unchanged since
  2009).
- [Phase 6] Expected clean apply on all stable trees (fix is at top of
  function, independent of other changes).
- [Phase 7] WiFi subsystem maintainer (Johannes Berg) signed off —
  strong endorsement.
- [Phase 8] Failure mode: OOB read + OOB write to kernel memory from
  untrusted firmware input. Severity HIGH.
- [Phase 8] Risk: Extremely low (simple bounds check addition).

**YES**

 drivers/net/wireless/ti/wl1251/tx.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ti/wl1251/tx.c b/drivers/net/wireless/ti/wl1251/tx.c
index adb4840b04893..c264d83e71d9c 100644
--- a/drivers/net/wireless/ti/wl1251/tx.c
+++ b/drivers/net/wireless/ti/wl1251/tx.c
@@ -402,12 +402,14 @@ static void wl1251_tx_packet_cb(struct wl1251 *wl,
 	int hdrlen;
 	u8 *frame;
 
-	skb = wl->tx_frames[result->id];
-	if (skb == NULL) {
-		wl1251_error("SKB for packet %d is NULL", result->id);
+	if (unlikely(result->id >= ARRAY_SIZE(wl->tx_frames) ||
+		     wl->tx_frames[result->id] == NULL)) {
+		wl1251_error("invalid packet id %u", result->id);
 		return;
 	}
 
+	skb = wl->tx_frames[result->id];
+
 	info = IEEE80211_SKB_CB(skb);
 
 	if (!(info->flags & IEEE80211_TX_CTL_NO_ACK) &&
-- 
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-5.15] fs/smb/client: fix out-of-bounds read in cifs_sanitize_prepath

[Sasha Levin]

From: Fredric Cover <FredTheDude@proton.me>

[ Upstream commit 78ec5bf2f589ec7fd8f169394bfeca541b077317 ]

When cifs_sanitize_prepath is called with an empty string or a string
containing only delimiters (e.g., "/"), the current logic attempts to
check *(cursor2 - 1) before cursor2 has advanced. This results in an
out-of-bounds read.

This patch adds an early exit check after stripping prepended
delimiters. If no path content remains, the function returns NULL.

The bug was identified via manual audit and verified using a
standalone test case compiled with AddressSanitizer, which
triggered a SEGV on affected inputs.

Signed-off-by: Fredric Cover <FredTheDude@proton.me>
Reviewed-by: Henrique Carvalho <[2]henrique.carvalho@suse.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background agent confirmed my findings: the commit `78ec5bf2f589e`
was authored March 30, 2026, reviewed and committed by Steve French the
next day, merged via `v7.0-rc6-smb3-client-fix`. Lore was inaccessible
due to Anubis bot protection. No controversy found in the git record.

My analysis and decision stand as written above. This is a clear, small,
obviously correct fix for an out-of-bounds read in a widely-used
filesystem (SMB/CIFS), present since v5.16, with very low regression
risk.

**YES**

 fs/smb/client/fs_context.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c
index e0d2cd78c82f1..e61bb6ac1d111 100644
--- a/fs/smb/client/fs_context.c
+++ b/fs/smb/client/fs_context.c
@@ -589,6 +589,10 @@ char *cifs_sanitize_prepath(char *prepath, gfp_t gfp)
 	while (IS_DELIM(*cursor1))
 		cursor1++;
 
+	/* exit in case of only delimiters */
+	if (!*cursor1)
+		return NULL;
+
 	/* copy the first letter */
 	*cursor2 = *cursor1;
 
-- 
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