[PATCH AUTOSEL 7.0-5.10] ASoC: tas2552: Allow audio enable GPIO to sleep

[PATCH AUTOSEL 7.0-5.10] ASoC: tas2552: Allow audio enable GPIO to sleep

[Sasha Levin]

From: Marek Vasut <marex@nabladev.com>

[ Upstream commit 5ebc20921b7fff9feb44de465448e17a382c9965 ]

The audio enable GPIO is not toggled in any critical section where it
could not sleep, allow the audio enable GPIO to sleep. This allows the
driver to operate the audio enable GPIO connected to I2C GPIO expander.

Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260220202332.241035-1-marex@nabladev.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `ASoC: tas2552` (sound, ASoC codec driver)
- Action verb: "Allow" - implies enabling something previously not
  supported
- Summary: Allow the enable GPIO to sleep, enabling use with I2C GPIO
  expanders

**Step 1.2: Tags**
- Signed-off-by: Marek Vasut <marex@nabladev.com> (author)
- Link:
  https://patch.msgid.link/20260220202332.241035-1-marex@nabladev.com
- Signed-off-by: Mark Brown <broonie@kernel.org> (ASoC subsystem
  maintainer)
- No Fixes: tag, no Reported-by, no Cc: stable (expected for autosel
  candidates)

**Step 1.3: Commit Body**
The commit describes that the enable GPIO is never toggled from atomic
context, so it's safe to use the sleeping variant. This allows the
driver to work when the enable GPIO is connected to an I2C GPIO expander
(which requires sleeping for bus access).

**Step 1.4: Hidden Bug Fix Detection**
YES - this is a bug fix. Using `gpiod_set_value()` with a sleeping GPIO
triggers `WARN_ON(desc->gdev->can_sleep)` in gpiolib.c:3899. This is
incorrect API usage that produces kernel warnings.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `sound/soc/codecs/tas2552.c`
- 5 lines changed (identical substitution at each site)
- Functions modified: `tas2552_runtime_suspend`,
  `tas2552_runtime_resume`, `tas2552_component_probe` (x2),
  `tas2552_component_remove`

**Step 2.2: Code Flow Change**
Each hunk is identical: `gpiod_set_value(tas2552->enable_gpio, X)` ->
`gpiod_set_value_cansleep(tas2552->enable_gpio, X)`. No logic change —
both APIs call the same `gpiod_set_value_nocheck()` internally.

**Step 2.3: Bug Mechanism**
Verified in `drivers/gpio/gpiolib.c`:

```3895:3901:drivers/gpio/gpiolib.c
int gpiod_set_value(struct gpio_desc *desc, int value)
{
        VALIDATE_DESC(desc);
        /* Should be using gpiod_set_value_cansleep() */
        WARN_ON(desc->gdev->can_sleep);
        return gpiod_set_value_nocheck(desc, value);
}
```

vs:

```4359:4364:drivers/gpio/gpiolib.c
int gpiod_set_value_cansleep(struct gpio_desc *desc, int value)
{
        might_sleep();
        VALIDATE_DESC(desc);
        return gpiod_set_value_nocheck(desc, value);
}
```

The bug: When the enable GPIO is on an I2C GPIO expander (`can_sleep =
true`), `gpiod_set_value()` fires `WARN_ON` producing a kernel warning
with stack trace on every suspend/resume cycle and on probe/remove.

**Step 2.4: Fix Quality**
- Obviously correct: the only change is which wrapper is used; both call
  the same underlying function
- Minimal: 5 identical one-line substitutions
- Zero regression risk: `gpiod_set_value_cansleep()` is strictly more
  permissive (works with both sleeping and non-sleeping GPIOs)
- All call sites are process context (PM callbacks, probe, remove) where
  sleeping is allowed

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The `gpiod_set_value()` calls were introduced by commit `82cf77a1bd61d9`
(Axel Lin, 2015) which simplified NULL checks. The original code existed
since `5df7f71d5cdfbc` (Dan Murphy, 2014). The buggy code has been
present since v4.3-rc1.

**Step 3.2: Fixes tag**
No Fixes: tag present (expected for autosel).

**Step 3.3: File History**
Recent changes to the file are trivial: RUNTIME_PM_OPS conversion,
removing redundant `pm_runtime_mark_last_busy()`, dropping unused GPIO
includes. No conflicts.

**Step 3.4: Author**
Marek Vasut is a prolific kernel contributor with extensive work across
DRM, DT bindings, and sound subsystems. Not the TAS2552 maintainer but a
well-known contributor.

**Step 3.5: Prerequisites**
None. The change is standalone and independent of the RUNTIME_PM_OPS
conversion. It touches only the `gpiod_set_value()` calls which exist in
all stable trees.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Patch**
Found via `b4 am`. The patch was submitted as a single standalone patch
on 2026-02-20. CC'd appropriate maintainers (Mark Brown, Takashi Iwai,
TI engineers, linux-sound, linux-kernel). Applied directly by Mark Brown
(ASoC maintainer). No v2/v3 revisions — accepted as-is.

**Step 4.2: Reviewers**
The patch was CC'd to all relevant TI and ASoC maintainers. Mark Brown
(ASoC subsystem maintainer) applied it directly.

**Step 4.3: Bug Report**
No external bug report. Marek Vasut likely encountered this on a board
with an I2C GPIO expander.

**Step 4.4: Related Patches**
This is a well-established pattern. Multiple identical fixes have been
applied to other ASoC codecs:
- `5f83ee4b1f0c0` ASoC: tas5086: use sleeping variants of gpiod API
- `897d8e86bac76` ASoC: tlv320aic31xx: switch to
  gpiod_set_value_cansleep
- `5d7e0b1516dfc` ASoC: dmic: Allow GPIO operations to sleep
- `ea2a2ad17ca1e` ASoC: dio2125: use gpiod_set_value_cansleep (had
  Fixes: tag)

**Step 4.5: Stable Discussion**
No stable-specific discussion found. The dio2125 variant (ea2a2ad17ca1e)
had a Fixes: tag and was likely auto-selected for stable.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
- `tas2552_runtime_suspend()` — PM runtime callback
- `tas2552_runtime_resume()` — PM runtime callback
- `tas2552_component_probe()` — ASoC component probe (x2 sites)
- `tas2552_component_remove()` — ASoC component remove

**Step 5.2: Callers**
All five call sites are invoked from process context:
- Runtime PM callbacks are invoked by the PM subsystem in process
  context
- Component probe/remove are called from the ASoC registration path,
  always sleepable

**Step 5.3-5.4: No atomic context concerns**
All callers can sleep. The `gpiod_set_value_cansleep()` API with its
`might_sleep()` is the correct choice.

**Step 5.5: Similar Patterns**
There are 5 remaining `gpiod_set_value()` calls in this file — this
patch converts all of them. Other ASoC drivers have undergone identical
transformations.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable?**
YES. The `gpiod_set_value()` calls date back to commit `82cf77a1bd61d9`
(v4.3-rc1, 2015). All active stable trees contain this code.

**Step 6.2: Backport Complications**
Minimal. The `gpiod_set_value()` lines are identical across all stable
versions. The only difference is that pre-6.12 trees have `#ifdef
CONFIG_PM` guards and `SET_RUNTIME_PM_OPS` instead of `RUNTIME_PM_OPS`,
but this doesn't affect the changed lines. The patch should apply
cleanly or with trivial context offset.

**Step 6.3: No Existing Fix**
No related fix for this specific issue in any stable tree.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** Sound/ASoC codec driver — PERIPHERAL criticality (specific
codec driver), but TAS2552 is used in embedded systems.

**Step 7.2:** The driver is mature/stable with minimal recent activity
(only cleanup commits).

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Users of the TAS2552 audio amplifier who have the enable GPIO connected
to an I2C GPIO expander. This is a valid embedded hardware
configuration.

**Step 8.2: Trigger Conditions**
The WARN_ON triggers on EVERY suspend/resume cycle and on driver
probe/remove — not rare at all for affected hardware.

**Step 8.3: Failure Mode**
- WARN_ON with full stack trace in kernel log (MEDIUM severity normally)
- With `panic_on_warn=1`: kernel panic (CRITICAL severity for those
  configurations)
- Without panic_on_warn: console spam, log pollution, incorrect API
  usage flagged

**Step 8.4: Risk-Benefit**
- BENEFIT: Eliminates WARN_ON spam, enables I2C GPIO expander hardware
  correctly, fixes incorrect API usage
- RISK: Virtually zero — both APIs call the same underlying function,
  the only difference is the debug assertion

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes incorrect GPIO API usage that triggers WARN_ON
- Can cause kernel panic with `panic_on_warn=1`
- Trivially small (5 identical line substitutions), trivially correct
- Zero regression risk (both APIs have identical functional behavior)
- Well-established pattern applied to many other drivers
- Applied by ASoC subsystem maintainer Mark Brown
- Buggy code present since v4.3 — affects all stable trees
- No dependencies on other patches

AGAINST backporting:
- No Reported-by (no evidence of real-world user reports)
- WARN_ON is non-fatal in default configurations
- Affects specific hardware configuration (I2C GPIO expander)
- Could be seen as "enablement" rather than pure "fix"

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested: YES — trivially provable
2. Fixes a real bug: YES — WARN_ON from incorrect API usage
3. Important issue: MEDIUM — WARN_ON, potential panic with panic_on_warn
4. Small and contained: YES — 5 lines in 1 file
5. No new features: YES — just API correction
6. Can apply to stable: YES — clean apply expected

**Step 9.3: Exception Categories**
This is closest to a hardware quirk/workaround — it makes the driver
work correctly with I2C GPIO expanders.

## Verification

- [Phase 1] Parsed tags: Signed-off-by from author and ASoC maintainer,
  Link to patch.msgid
- [Phase 2] Diff analysis: 5 identical `gpiod_set_value` ->
  `gpiod_set_value_cansleep` substitutions
- [Phase 2] Verified `gpiod_set_value()` has
  `WARN_ON(desc->gdev->can_sleep)` at gpiolib.c:3899
- [Phase 2] Verified `gpiod_set_value_cansleep()` calls same
  `gpiod_set_value_nocheck()` at gpiolib.c:4363
- [Phase 3] git blame: `gpiod_set_value` calls introduced by commit
  82cf77a1bd61d9 (v4.3-rc1, 2015)
- [Phase 3] git log: no conflicting changes in recent history
- [Phase 3] RUNTIME_PM_OPS conversion (1570c33f2f38b) does not affect
  the changed lines
- [Phase 4] b4 am: found original patch, single standalone submission
- [Phase 4] Multiple identical fixes applied to other ASoC codecs
  (tas5086, tlv320aic31xx, dmic, dio2125)
- [Phase 5] All call sites (runtime_suspend/resume,
  component_probe/remove) are process context — can sleep
- [Phase 6] Buggy code present since v4.3, exists in all active stable
  trees
- [Phase 6] Patch applies cleanly — no conflicting changes to the
  affected lines
- [Phase 8] WARN_ON triggers on every suspend/resume for affected
  hardware, not a rare event

The fix is trivially correct, carries zero regression risk, and fixes
incorrect GPIO API usage that produces kernel warnings (and potential
panics) for valid hardware configurations. While it's not fixing a crash
in the default configuration, the WARN_ON is a genuine bug indicator,
and this well-established pattern has been applied to many other
drivers.

**YES**

 sound/soc/codecs/tas2552.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/tas2552.c b/sound/soc/codecs/tas2552.c
index 43449d7c25843..80206c2e09462 100644
--- a/sound/soc/codecs/tas2552.c
+++ b/sound/soc/codecs/tas2552.c
@@ -487,7 +487,7 @@ static int tas2552_runtime_suspend(struct device *dev)
 	regcache_cache_only(tas2552->regmap, true);
 	regcache_mark_dirty(tas2552->regmap);
 
-	gpiod_set_value(tas2552->enable_gpio, 0);
+	gpiod_set_value_cansleep(tas2552->enable_gpio, 0);
 
 	return 0;
 }
@@ -496,7 +496,7 @@ static int tas2552_runtime_resume(struct device *dev)
 {
 	struct tas2552_data *tas2552 = dev_get_drvdata(dev);
 
-	gpiod_set_value(tas2552->enable_gpio, 1);
+	gpiod_set_value_cansleep(tas2552->enable_gpio, 1);
 
 	tas2552_sw_shutdown(tas2552, 0);
 
@@ -583,7 +583,7 @@ static int tas2552_component_probe(struct snd_soc_component *component)
 		return ret;
 	}
 
-	gpiod_set_value(tas2552->enable_gpio, 1);
+	gpiod_set_value_cansleep(tas2552->enable_gpio, 1);
 
 	ret = pm_runtime_resume_and_get(component->dev);
 	if (ret < 0) {
@@ -608,7 +608,7 @@ static int tas2552_component_probe(struct snd_soc_component *component)
 
 probe_fail:
 	pm_runtime_put_noidle(component->dev);
-	gpiod_set_value(tas2552->enable_gpio, 0);
+	gpiod_set_value_cansleep(tas2552->enable_gpio, 0);
 
 	regulator_bulk_disable(ARRAY_SIZE(tas2552->supplies),
 					tas2552->supplies);
@@ -621,7 +621,7 @@ static void tas2552_component_remove(struct snd_soc_component *component)
 
 	pm_runtime_put(component->dev);
 
-	gpiod_set_value(tas2552->enable_gpio, 0);
+	gpiod_set_value_cansleep(tas2552->enable_gpio, 0);
 };
 
 #ifdef CONFIG_PM
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ASoC: Intel: bytcr_rt5651: Fix MCLK leak on platform_clock_control error

[Sasha Levin]

From: Aravind Anilraj <aravindanilraj0702@gmail.com>

[ Upstream commit b022e5c142efe4c5497e6cfda1f143618b4b9254 ]

If byt_rt5651_prepare_and_enable_pll1() fails, the function returns
without calling clk_disable_unprepare() on priv->mclk, which was
already enabled earlier in the same code path. Add the missing
cleanup call to prevent the clock from leaking.

Signed-off-by: Aravind Anilraj <aravindanilraj0702@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260401220507.23557-3-aravindanilraj0702@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: ASoC: Intel: bytcr_rt5651
- **Action verb**: "Fix" — explicitly a bug fix
- **Summary**: Fix clock (MCLK) resource leak on error path in
  `platform_clock_control`

### Step 1.2: Tags
- **Signed-off-by**: Aravind Anilraj (author, community contributor — no
  prior commits in this subsystem)
- **Reviewed-by**: Cezary Rojewski (Intel audio maintainer)
- **Link**: patch.msgid.link/20260401220507.23557-3 — patch 3 in a
  series
- **Signed-off-by**: Mark Brown (ASoC subsystem maintainer — applied the
  patch)
- No Fixes: tag, no Cc: stable, no Reported-by (all expected for autosel
  review)

### Step 1.3: Commit Body
The message clearly describes: if `byt_rt5651_prepare_and_enable_pll1()`
fails, the function returns without calling `clk_disable_unprepare()` on
`priv->mclk`, which was already enabled by `clk_prepare_enable()`. This
is a straightforward clock resource leak on an error path.

### Step 1.4: Hidden Bug Fix?
No — this is explicitly labeled as a bug fix and is genuinely one. The
commit message directly describes the resource leak mechanism.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 (`sound/soc/intel/boards/bytcr_rt5651.c`)
- **Lines added**: 2 (`+if (ret < 0)` and
  `+clk_disable_unprepare(priv->mclk);`)
- **Lines removed**: 0
- **Function modified**: `platform_clock_control()`
- **Scope**: Single-file, single-function, 2-line surgical fix

### Step 2.2: Code Flow Change
**Before**: In the `SND_SOC_DAPM_EVENT_ON` branch:
1. `clk_prepare_enable(priv->mclk)` — enables the clock
2. `byt_rt5651_prepare_and_enable_pll1()` — configures PLL
3. If step 2 fails, `ret < 0` falls through to the error path at line
   225, which logs the error and returns — **without disabling the
   clock**

**After**: If `byt_rt5651_prepare_and_enable_pll1()` fails,
`clk_disable_unprepare(priv->mclk)` is called immediately, properly
balancing the earlier `clk_prepare_enable()`.

### Step 2.3: Bug Mechanism
**Category**: Resource leak (clock) on error path.
- `clk_prepare_enable()` increments the clock's reference count
- On PLL1 failure, the corresponding `clk_disable_unprepare()` was never
  called
- The clock remains permanently enabled, leaking the resource

### Step 2.4: Fix Quality
- **Obviously correct**: Yes — directly mirrors the existing cleanup in
  the `else` branch (line 221-222)
- **Minimal**: Yes — 2 lines, no unnecessary changes
- **Regression risk**: Essentially zero — only executes on an existing
  error path

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- Line 206 (`clk_prepare_enable`): Refactored by `a8627df5491e00` (Andy
  Shevchenko, 2021-10-07) — but the original logic dates to
  `02c0a3b3047f8f` (Pierre-Louis Bossart, 2017-10-12)
- Line 211 (`byt_rt5651_prepare_and_enable_pll1`): Introduced by
  `aeec6cc0821573` (Hans de Goede, 2018-03-04) — **this is when the bug
  was introduced**. The PLL1 call was added between the clock enable and
  the end of the branch, without error handling for the clock.

### Step 3.2: Fixes Target
No explicit Fixes: tag. The implicit fix target is `aeec6cc0821573`
("ASoC: Intel: bytcr_rt5651: Configure PLL1 before using it",
v4.17-rc1). This commit is present in **all active stable trees** (it
dates to 2018).

### Step 3.3: Related Changes
The file has had several unrelated changes since the bug was introduced,
but none touch the specific error path being fixed. The fix applies
cleanly.

### Step 3.4: Author
Aravind Anilraj appears to be a community contributor (no other commits
in this subsystem found). However, the patch was **Reviewed-by** Cezary
Rojewski (Intel audio maintainer) and **merged by** Mark Brown (ASoC
maintainer).

### Step 3.5: Dependencies
None. The fix is completely standalone — it references only `priv->mclk`
and `clk_disable_unprepare()`, both of which have existed since the
original code. No prerequisites needed.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.2: Patch Discussion
The Link tag indicates this is patch 3 in a series (message-id contains
"23557-3"). Lore.kernel.org was blocked by anti-bot protection,
preventing direct discussion retrieval. However:
- The patch was reviewed by Intel's audio maintainer (Cezary Rojewski)
- Merged by the ASoC subsystem maintainer (Mark Brown)
- Both are strong trust indicators

### Step 4.3-4.5
No explicit bug report or syzbot link — this appears to be found by code
inspection. No previous stable discussion found.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: Function Context
`platform_clock_control()` is registered as a DAPM supply callback:

```253:255:sound/soc/intel/boards/bytcr_rt5651.c
        SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0,
                            platform_clock_control, SND_SOC_DAPM_PRE_PMU
|
                            SND_SOC_DAPM_POST_PMD),
```

This is called every time the audio path is powered up (PRE_PMU) or down
(POST_PMD). It is a **common path** for any user of this audio hardware.

### Step 5.3: Callees
- `clk_prepare_enable()` / `clk_disable_unprepare()`: standard Linux
  clock framework
- `byt_rt5651_prepare_and_enable_pll1()`: configures PLL via
  `snd_soc_dai_set_pll()` and `snd_soc_dai_set_sysclk()` — can fail if
  the codec rejects the configuration

### Step 5.4: Sibling Pattern Confirmation
The sibling driver `bytcr_rt5640.c` has the **identical bug** at lines
285-291:

```285:291:sound/soc/intel/boards/bytcr_rt5640.c
        if (SND_SOC_DAPM_EVENT_ON(event)) {
                ret = clk_prepare_enable(priv->mclk);
                if (ret < 0) {
                        dev_err(card->dev, "could not configure MCLK
state\n");
                        return ret;
                }
                ret = byt_rt5640_prepare_and_enable_pll1(codec_dai,
48000);
```

No `clk_disable_unprepare()` on PLL1 failure there either. This confirms
the bug pattern is real and systematic.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code in Stable
The buggy code was introduced in `aeec6cc0821573` (v4.17-rc1, March
2018). This code exists in **all active stable trees** (5.4.y, 5.10.y,
5.15.y, 6.1.y, 6.6.y, 6.12.y).

### Step 6.2: Backport Complications
The fix is 2 lines with minimal context sensitivity. The surrounding
code has been stable since the a8627df5491e00 refactoring in 2021. It
should apply cleanly to all trees from 5.15+ at minimum; older trees may
need trivial context adjustment for the `BYT_RT5651_MCLK_EN` quirk check
that was removed by `a8627df5491e00`.

### Step 6.3: No related fixes for this bug already in stable.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

- **Subsystem**: ASoC / Intel audio machine driver
- **Criticality**: PERIPHERAL — affects users of Bay Trail / Cherry
  Trail devices with RT5651 codec (budget tablets, laptops)
- **Activity**: Moderate — file sees occasional updates

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
Users with Intel Bay Trail or Cherry Trail devices using the RT5651
audio codec. These are common budget tablets and laptops.

### Step 8.2: Trigger Conditions
Triggered when: (a) audio starts playing (DAPM PRE_PMU event), AND (b)
PLL1 configuration fails. While PLL failure is itself an error
condition, repeated failures with clock leaks can compound the problem
and prevent power management from working correctly.

### Step 8.3: Failure Mode
- **Severity: MEDIUM** — The leaked clock prevents the MCLK from being
  disabled, which:
  - Wastes power (clock stays enabled)
  - May prevent subsequent clock operations from working correctly
  - Could contribute to audio subsystem malfunction after error recovery

### Step 8.4: Risk-Benefit
- **Benefit**: Fixes a real resource leak, prevents clock reference
  count imbalance
- **Risk**: Essentially zero — 2-line addition only on error path,
  obviously correct
- **Ratio**: Very favorable for backport

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a real clock resource leak on error path
- 2-line fix, minimal and surgical
- Obviously correct (mirrors existing cleanup pattern in the else
  branch)
- Reviewed by Intel audio maintainer, merged by ASoC subsystem
  maintainer
- Bug exists since v4.17, present in all active stable trees
- No dependencies, completely standalone
- Sibling driver (bytcr_rt5640) has the identical bug, confirming the
  pattern

**AGAINST backporting:**
- The trigger requires PLL1 configuration failure (uncommon in normal
  operation)
- No user reports or syzbot bugs — found by code inspection
- Author is a community contributor with no other commits in this
  subsystem

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** — trivially correct, reviewed
   by maintainer
2. Fixes a real bug? **YES** — clock resource leak on error path
3. Important issue? **MEDIUM** — resource leak, not a crash
4. Small and contained? **YES** — 2 lines in 1 file
5. No new features/APIs? **YES** — no new functionality
6. Applies to stable trees? **YES** — code unchanged, clean apply
   expected

### Step 9.3: Exception Categories
Not applicable — this is a standard bug fix, not an exception category.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Cezary Rojewski (Intel), Signed-
  off-by Mark Brown (ASoC maintainer)
- [Phase 2] Diff analysis: 2 lines added to error path in
  `platform_clock_control()`, adds missing `clk_disable_unprepare()`
- [Phase 3] git blame: buggy code path introduced in `aeec6cc0821573`
  (v4.17-rc1, 2018-03-04), present in all stable trees
- [Phase 3] git describe: confirmed `aeec6cc0821573` first appeared in
  v4.17-rc1
- [Phase 3] git log: no prior fix for this issue exists
- [Phase 4] lore.kernel.org: blocked by anti-bot protection, could not
  read discussion
- [Phase 4] b4 dig: confirmed PLL1 commit is patch v3 15/22 from Hans de
  Goede series
- [Phase 5] Verified `platform_clock_control()` is a DAPM supply
  callback (line 253-255), called on every audio path enable/disable
- [Phase 5] Verified sibling `bytcr_rt5640.c` has identical bug pattern
  at lines 285-291
- [Phase 6] Code exists in all active stable trees (bug from v4.17,
  2018)
- [Phase 8] Failure mode: clock resource leak preventing proper power
  management, severity MEDIUM
- UNVERIFIED: Could not read mailing list discussion due to anti-bot
  protection; relied on tags in commit message for review assessment

The fix is small, surgical, obviously correct, and meets all stable
kernel criteria. It fixes a genuine resource leak with zero regression
risk.

**YES**

 sound/soc/intel/boards/bytcr_rt5651.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5651.c b/sound/soc/intel/boards/bytcr_rt5651.c
index 68cf463f1d507..8932fc5d6f4f2 100644
--- a/sound/soc/intel/boards/bytcr_rt5651.c
+++ b/sound/soc/intel/boards/bytcr_rt5651.c
@@ -209,6 +209,8 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w,
 			return ret;
 		}
 		ret = byt_rt5651_prepare_and_enable_pll1(codec_dai, 48000, 50);
+		if (ret < 0)
+			clk_disable_unprepare(priv->mclk);
 	} else {
 		/*
 		 * Set codec clock source to internal clock before
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: usb-audio: Add iface reset and delay quirk for HUAWEI USB-C HEADSET

[Sasha Levin]

From: Lianqin Hu <hulianqin@vivo.com>

[ Upstream commit 9575766a682f50ec4bcb85ecd438685bdc09f9cc ]

Setting up the interface when suspended/resumeing fail on this card.
Adding a reset and delay quirk will eliminate this problem.

usb 1-1: new full-speed USB device number 2 using xhci-hcd
usb 1-1: New USB device found, idVendor=12d1, idProduct=3a07
usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-1: Product: HUAWEI USB-C HEADSET
usb 1-1: Manufacturer: bestechnic
usb 1-1: SerialNumber: 0296C100000000000000000000000

Signed-off-by: Lianqin Hu <hulianqin@vivo.com>
Link: https://patch.msgid.link/TYUPR06MB62176A18EA7A9DD0AC2826BCD2582@TYUPR06MB6217.apcprd06.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have sufficient information for a thorough analysis. Let me
compile everything.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Parse the Subject Line
- **Subsystem**: `ALSA: usb-audio`
- **Action verb**: "Add" (adding quirk flags)
- **Summary**: Adds interface reset and delay quirk for HUAWEI USB-C
  HEADSET (0x12d1:0x3a07)

Record: [ALSA: usb-audio] [Add] [Hardware quirk flags for suspend/resume
fix on HUAWEI USB-C HEADSET]

### Step 1.2: Parse All Commit Message Tags
- **Signed-off-by**: Lianqin Hu <hulianqin@vivo.com> (author)
- **Signed-off-by**: Takashi Iwai <tiwai@suse.de> (ALSA subsystem
  maintainer)
- **Link**: https://patch.msgid.link/TYUPR06MB62176A18EA7A9DD0AC2826BCD2
  582@TYUPR06MB6217.apcprd06.prod.outlook.com
- No Fixes: tag (expected for quirk addition)
- No Reported-by: tag (the author discovered the issue themselves)
- No Cc: stable tag

Record: Accepted by Takashi Iwai (ALSA subsystem maintainer). Author
works at vivo (mobile phone manufacturer - plausible USB-C headset
user).

### Step 1.3: Analyze the Commit Body Text
The commit says: "Setting up the interface when suspended/resumeing fail
on this card." This describes a concrete bug: the USB audio interface
setup fails during suspend/resume cycles. The fix is adding
`QUIRK_FLAG_FORCE_IFACE_RESET` and `QUIRK_FLAG_IFACE_DELAY` flags. The
USB device info (VID/PID, manufacturer "bestechnic", product "HUAWEI
USB-C HEADSET") is included for identification.

Record: Bug = interface setup failure during suspend/resume. Symptom =
audio device non-functional after suspend/resume. Root cause = device
requires an interface reset and a 50ms delay during interface setup.

### Step 1.4: Detect Hidden Bug Fixes
This is not hidden - it's an explicit hardware workaround for a device
that fails during suspend/resume. This is a textbook USB audio quirk.

Record: Not a hidden bug fix; it's an explicit hardware
quirk/workaround.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory the Changes
- **Files changed**: 1 (`sound/usb/quirks.c`)
- **Lines**: -2 / +3 (net +1 line)
- **Functions modified**: None - only a data table entry is changed
- **Scope**: Single-line modification to an existing quirk table entry

Record: Extremely minimal change. Only the existing DEVICE_FLG entry for
0x12d1, 0x3a07 is modified.

### Step 2.2: Understand the Code Flow Change
- **Before**: `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE |
  QUIRK_FLAG_MIXER_CAPTURE_MIN_MUTE`
- **After**: `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE |
  QUIRK_FLAG_MIXER_CAPTURE_MIN_MUTE | QUIRK_FLAG_FORCE_IFACE_RESET |
  QUIRK_FLAG_IFACE_DELAY`
- Also updated the comment from "Huawei Technologies Co., Ltd." to
  "HUAWEI USB-C HEADSET" (cosmetic)

The two new flags are consumed in existing code paths:
- `QUIRK_FLAG_IFACE_DELAY` causes a 50ms sleep in
  `snd_usb_endpoint_set_interface()` (endpoint.c:942-943) and in
  `snd_usb_init_sample_rate()` (clock.c:649-650)
- `QUIRK_FLAG_FORCE_IFACE_RESET` forces `need_prepare = true` and
  `need_setup = true` when stopping a stream (endpoint.c:1695-1700)

Record: Data-only change adding well-established flags to an existing
device entry. No logic changes.

### Step 2.3: Identify the Bug Mechanism
Category: **(h) Hardware workarounds**
- This is a device-specific quirk table entry modification
- The HUAWEI USB-C HEADSET (Bestechnic chipset) requires both an
  interface reset and a delay for proper operation during suspend/resume

Record: Hardware quirk. The device's USB audio firmware doesn't handle
interface re-setup correctly without a forced reset and delay.

### Step 2.4: Assess the Fix Quality
- Obviously correct: adds flags to a static data table, no logic change
- Minimal/surgical: 3 lines modified in a single entry
- Regression risk: Essentially zero. These flags are already used by 10+
  other devices. The only effect is a 50ms delay and a forced interface
  reset for this specific device.

Record: Fix quality = excellent. Regression risk = negligible.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame the Changed Lines
From git blame:
- `2cbe4ac193ed71` (qaqland, 2025-08-29): Added initial entry for
  0x12d1, 0x3a07 with `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`
- `806a38293fc0df` (Cryolitia PukNgae, 2025-09-03): Added
  `QUIRK_FLAG_MIXER_CAPTURE_MIN_MUTE`

The device entry was present since kernel ~6.17.

Record: Device entry exists in tree since ~v6.17. The flags being added
(FORCE_IFACE_RESET since 2022, IFACE_DELAY since 2021) are both long-
established.

### Step 3.2: Follow the Fixes: Tag
No Fixes: tag present. This is expected for a quirk addition.

### Step 3.3: Check File History
Recent changes to `sound/usb/quirks.c` show 5 nearly identical commits
by the same author adding `QUIRK_FLAG_FORCE_IFACE_RESET |
QUIRK_FLAG_IFACE_DELAY` for other devices:
- AB13X USB Audio (2 variants)
- AB17X USB Audio
- SPACETOUCH USB Audio
- GHW-123P

Record: The author has submitted numerous identical-pattern quirk
patches, all accepted by Takashi Iwai. This is a well-established
pattern.

### Step 3.4: Check the Author's Other Commits
Lianqin Hu has 10+ commits in the USB audio area, almost all adding
delay/reset quirks for specific devices. They are clearly a regular
contributor for USB audio quirks, likely working at vivo on mobile
device compatibility.

Record: Regular USB audio quirk contributor with a track record of
accepted patches.

### Step 3.5: Check for Dependent/Prerequisite Commits
The prerequisite is that the device entry (0x12d1, 0x3a07) exists in the
target tree. This was added in ~v6.17 (commit 2cbe4ac193ed71). Both
quirk flags have existed since v5.x era.

Record: Requires the base entry (v6.17+). Both flags exist since v5.x.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1-4.2: Find the Original Patch Discussion
The Link: in the commit points to the patch submission. The patch was
accepted directly by Takashi Iwai (ALSA subsystem maintainer). Web
search confirms the pattern: identical patches for AB13X were submitted
with the same message format and accepted.

Record: Accepted by subsystem maintainer. Standard quirk addition
pattern.

### Step 4.3-4.5: Bug Report and Stable Context
No separate bug report link. The author discovered the suspend/resume
failure with this device directly. Similar quirk additions have been
routinely backported to stable in the past.

Record: Self-reported by hardware tester at vivo.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions in the Diff
No functions modified - only a data table entry.

### Step 5.2-5.4: Trace Callers
The flags are consumed by:
1. `snd_usb_endpoint_set_interface()` in endpoint.c (IFACE_DELAY: adds
   50ms sleep after usb_set_interface)
2. Stream stop path in endpoint.c (FORCE_IFACE_RESET: marks interface as
   needing re-setup)
3. `snd_usb_init_sample_rate()` in clock.c (IFACE_DELAY: 50ms sleep
   after rate change)

These are core USB audio paths that run during stream start/stop and
suspend/resume.

Record: The flags affect well-tested code paths in the USB audio stack.

---

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

### Step 6.1: Does the Buggy Code Exist in Stable Trees?
The device entry exists in 7.0. For older stable trees (6.6.y, 6.1.y,
etc.), the device entry does NOT exist (it was added in v6.17). So this
quirk would only be relevant for stable trees >= 6.17 (or wherever the
entry was backported to).

Record: Relevant for stable trees that contain the device entry
(v6.17+).

### Step 6.2: Backport Complications
The patch should apply cleanly to any tree that has the existing
DEVICE_FLG(0x12d1, 0x3a07, ...) entry. The diff is minimal.

Record: Clean apply expected for any tree with the base device entry.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem Criticality
- **Subsystem**: sound/usb (USB audio driver)
- **Criticality**: IMPORTANT - USB-C headsets are very common on laptops
  and phones

Record: USB audio = IMPORTANT subsystem. USB-C headsets are widely used.

### Step 7.2: Subsystem Activity
54 changes to `sound/usb/quirks.c` between v6.12 and v7.0. Extremely
active - this file gets frequent quirk additions.

Record: Highly active, many quirk additions routinely accepted.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
Users of HUAWEI USB-C HEADSET (VID 0x12d1, PID 0x3a07, manufactured by
Bestechnic). This is a branded headset likely sold with Huawei phones
but also usable on any USB-C Linux device.

Record: Device-specific. Affects all users of this specific HUAWEI USB-C
headset.

### Step 8.2: Trigger Conditions
Triggered on every suspend/resume cycle when the headset is connected.
Very common for laptop users.

Record: Common trigger - any suspend/resume with device connected.

### Step 8.3: Failure Mode Severity
Without the quirk, the interface setup fails during resume. The headset
stops working after suspend/resume, requiring re-plugging. This is a
functional failure.

Record: Severity = HIGH for affected users (device non-functional after
suspend/resume).

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: Fixes suspend/resume for HUAWEI USB-C headset users
- **Risk**: Extremely low. Data table change only. The flags are used by
  10+ other devices already. No logic changes.

Record: Very high benefit/risk ratio.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Classic hardware quirk addition to existing device entry
- Fixes real suspend/resume failure
- Tiny, data-only change (3 lines in a static table)
- Both flags are well-established (2021/2022 vintage)
- Same flags used by 10+ other devices successfully
- Accepted by ALSA subsystem maintainer (Takashi Iwai)
- Author has track record of identical, accepted quirk patches
- Zero regression risk (device-specific, data-only)

**AGAINST backporting:**
- No Fixes: tag (expected for quirks)
- Limited to one specific device
- Base device entry only exists in v6.17+

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - data table change, accepted
   by maintainer
2. Fixes a real bug? **YES** - suspend/resume failure
3. Important issue? **YES** - device non-functional after suspend/resume
4. Small and contained? **YES** - 3 lines in one file
5. No new features or APIs? **YES** - just adds flags to existing entry
6. Can apply to stable trees? **YES** - clean apply for trees with the
   base entry

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

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by Takashi Iwai (ALSA maintainer),
  Link to patch submission
- [Phase 2] Diff analysis: +1 net line, adds
  QUIRK_FLAG_FORCE_IFACE_RESET | QUIRK_FLAG_IFACE_DELAY to existing
  entry for 0x12d1:0x3a07
- [Phase 3] git blame: device entry introduced by 2cbe4ac193ed71 (v6.17
  era), flags exist since 2021/2022
- [Phase 3] Author commits: 10+ similar quirk patches all accepted by
  Takashi Iwai
- [Phase 4] Web search: confirmed identical pattern patches (AB13X,
  AB17X, etc.) accepted
- [Phase 5] Flag usage: IFACE_DELAY triggers 50ms sleep in
  endpoint.c:942, FORCE_IFACE_RESET forces re-setup in
  endpoint.c:1695-1700
- [Phase 5] 10+ other devices already use these same flags (verified via
  grep)
- [Phase 6] Base entry exists in 7.0 tree (confirmed via git blame)
- [Phase 7] sound/usb/quirks.c: 54 changes between v6.12-v7.0, highly
  active
- [Phase 8] Failure mode: device non-functional after suspend/resume,
  severity HIGH for affected users
- UNVERIFIED: Could not access lore.kernel.org directly due to anti-bot
  protection; relied on web search confirmation

This is a textbook USB audio hardware quirk addition. It adds two well-
established flags to an existing device entry, fixing suspend/resume
failure for a specific HUAWEI USB-C headset. The change is data-only,
obviously correct, zero regression risk, and accepted by the ALSA
subsystem maintainer.

**YES**

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

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 4cfa24c06fcdf..d3a69995c1ad5 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2291,8 +2291,9 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
 	DEVICE_FLG(0x1101, 0x0003, /* Audioengine D1 */
 		   QUIRK_FLAG_GET_SAMPLE_RATE),
-	DEVICE_FLG(0x12d1, 0x3a07, /* Huawei Technologies Co., Ltd. */
-		   QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE | QUIRK_FLAG_MIXER_CAPTURE_MIN_MUTE),
+	DEVICE_FLG(0x12d1, 0x3a07, /* HUAWEI USB-C HEADSET */
+		   QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE | QUIRK_FLAG_MIXER_CAPTURE_MIN_MUTE |
+		   QUIRK_FLAG_FORCE_IFACE_RESET | QUIRK_FLAG_IFACE_DELAY),
 	DEVICE_FLG(0x1224, 0x2a25, /* Jieli Technology USB PHY 2.0 */
 		   QUIRK_FLAG_GET_SAMPLE_RATE | QUIRK_FLAG_MIC_RES_16),
 	DEVICE_FLG(0x1395, 0x740a, /* Sennheiser DECT */
-- 
2.53.0

[PATCH AUTOSEL 6.18] 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:

Error: Failed to generate final synthesis

 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 1c8ee8263ab3a..2e89528e5cec1 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7402,6 +7402,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 7.0-5.10] ALSA: aoa/tas: Fix OF node leak on probe failure

[Sasha Levin]

From: wangdicheng <wangdicheng@kylinos.cn>

[ Upstream commit 1558905669e4da922fbaa7cf6507eb14779bffbd ]

Add missing of_node_put() in the error path.

Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260402023604.54682-1-wangdich9700@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

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

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `ALSA: aoa/tas` (ALSA Apple Onboard Audio, TAS codec)
- **Action verb**: "Fix"
- **Summary**: Fix OF (Open Firmware) node reference leak on probe
  failure path

### Step 1.2: Tags
- **Signed-off-by**: wangdicheng <wangdicheng@kylinos.cn> (author)
- **Link**:
  `https://patch.msgid.link/20260402023604.54682-1-wangdich9700@163.com`
- **Signed-off-by**: Takashi Iwai <tiwai@suse.de> (ALSA subsystem
  maintainer)
- No Fixes: tag, no Cc: stable, no Reported-by — all expected for
  AUTOSEL candidates
- Takashi Iwai as committer is a strong signal: he is the ALSA
  maintainer

### Step 1.3: Commit Body
The message is very brief: "Add missing of_node_put() in the error
path." This concisely describes a reference counting bug (missing put on
error path).

### Step 1.4: Hidden Bug Fix
This is an explicit bug fix — no disguise. The commit directly states it
fixes a missing `of_node_put()`.

Record: [Reference counting bug fix — missing of_node_put on error path
in probe function]

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 (`sound/aoa/codecs/tas.c`)
- **Lines added**: 1
- **Lines removed**: 0
- **Function modified**: `tas_i2c_probe()` — the `fail:` error path
- **Scope**: Single-file, single-line, surgical fix

### Step 2.2: Code Flow Change
Before the fix, the `fail:` path in `tas_i2c_probe()`:

```873:876:sound/aoa/codecs/tas.c
 fail:
        mutex_destroy(&tas->mtx);
        kfree(tas);
        return -EINVAL;
```

After the fix, `of_node_put(tas->codec.node)` is added between
`mutex_destroy` and `kfree`. The reference taken at line 864
(`tas->codec.node = of_node_get(node)`) is now properly released.

### Step 2.3: Bug Mechanism
**Category**: Reference counting bug (OF node reference leak)
- At line 864, `of_node_get(node)` increments the OF node's refcount and
  stores the result in `tas->codec.node`
- If `aoa_codec_register()` fails at line 866, execution jumps to
  `fail:`
- Without the fix, the `fail:` path calls `kfree(tas)` which frees the
  struct holding the only pointer to the refcounted node — the refcount
  is never decremented
- The `tas_i2c_remove()` function at line 885 correctly calls
  `of_node_put(tas->codec.node)`, confirming the expected pattern

### Step 2.4: Fix Quality
- **Obviously correct**: Yes — mirrors the cleanup pattern already in
  `tas_i2c_remove()` (line 885)
- **Minimal**: Yes — 1 line added
- **Regression risk**: Essentially zero — only adds cleanup on an error
  path
- **Placement**: Correct — `of_node_put(tas->codec.node)` is placed
  before `kfree(tas)` so the pointer is still valid

Record: [1 file, +1 line, reference counting fix on error path,
obviously correct, zero regression risk]

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The buggy code (`of_node_get(node)` without matching put on error path)
was introduced in commit `f3d9478b2ce468` by Johannes Berg on 2006-06-21
("[ALSA] snd-aoa: add snd-aoa"). This is the initial commit for the
entire snd-aoa subsystem, from the v2.6.18 era.

Record: [Bug has been present since 2006 (v2.6.18). Present in ALL
stable trees.]

### Step 3.2: No Fixes: Tag
No Fixes: tag present — expected for AUTOSEL candidates. However, the
implicit fix target is `f3d9478b2ce468`.

### Step 3.3: File History
The file has had only minor maintenance changes (strscpy, guard()
conversions, kzalloc_obj treewide changes). No related of_node_put fixes
for this specific path.

The related commit `222bce5eb88d1` ("ALSA: snd-aoa: add of_node_put() in
error path") fixed a similar bug in `sound/aoa/core/gpio-feature.c` —
different file, same subsystem, same bug class.

### Step 3.4: Author
The author (wangdicheng) has contributed several ALSA fixes. The patch
was accepted by Takashi Iwai, the ALSA maintainer, giving it strong
credibility.

### Step 3.5: Dependencies
None. The fix is a single `of_node_put()` call — it is completely
standalone and applies cleanly.

Record: [No dependencies. Standalone fix. Accepted by subsystem
maintainer.]

---

## PHASE 4: MAILING LIST

### Step 4.1: Original Submission
b4 dig could not find the original submission (the commit hash is from
the autosel pipeline, not mainline). The Link: in the commit message
points to
`patch.msgid.link/20260402023604.54682-1-wangdich9700@163.com`. Lore was
not accessible due to bot protection.

### Step 4.2-4.5
Could not access lore.kernel.org due to Anubis anti-scraping protection.
However, the commit was accepted by the ALSA maintainer (Takashi Iwai),
which means it passed his review.

Record: [Lore inaccessible. Patch accepted by ALSA maintainer Takashi
Iwai.]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions Modified
Only `tas_i2c_probe()` — specifically its `fail:` error path.

### Step 5.2: Callers
`tas_i2c_probe` is the I2C probe callback registered in the `tas_driver`
struct (line 904). It is called by the I2C subsystem when the device is
enumerated. This is a standard device probe path.

### Step 5.3-5.4: Call Chain
The error path is reached when `aoa_codec_register()` fails. Looking at
the function body (`sound/aoa/core/core.c` lines 57-69), it fails when
`attach_codec_to_fabric()` returns an error. This is a plausible failure
scenario during boot or module loading.

### Step 5.5: Similar Patterns
The sibling driver `onyx.c` has the **exact same bug** at lines 980-988:
- `onyx->codec.node = of_node_get(node)` at line 980
- The `fail:` label at line 987-989 calls `kfree(onyx)` without
  `of_node_put(onyx->codec.node)`

Record: [Same pattern bug exists in onyx.c. Probe function called by I2C
subsystem during device enumeration.]

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code Existence
The buggy code was introduced in 2006 (`f3d9478b2ce468`). It exists in
**every** stable tree (5.4.y, 5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y,
etc.).

### Step 6.2: Backport Complications
The only concern is the `kzalloc_obj` conversion on line 848 (from Feb
2026), which exists only in mainline 7.0. In older stable trees, this
will be `kzalloc(sizeof(*tas), GFP_KERNEL)`. However, the fix (adding
one line in the `fail:` path) is completely independent of the
allocation call. The `fail:` label context (mutex_destroy + kfree) has
been stable since 2006. The fix should apply cleanly or with trivial
context adjustment.

### Step 6.3: No related fixes in stable
No previous fix for this specific bug exists in stable trees.

Record: [Bug exists in all stable trees. Fix should apply cleanly with
minor context fuzz.]

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **Subsystem**: ALSA (sound), Apple Onboard Audio — codec driver for
  TAS3004
- **Criticality**: PERIPHERAL — only affects Apple PowerPC-based
  machines with TAS3004 codec (PowerBooks, PowerMacs)

### Step 7.2: Activity
The file gets very infrequent changes (mostly treewide cleanups). This
is a mature, stable subsystem with minimal churn.

Record: [PERIPHERAL subsystem (Apple PowerPC audio). Mature code with
low churn.]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Population
Users with Apple PowerPC hardware using the TAS3004 audio codec. This is
a niche population, but real users exist (retrocomputing, legacy
systems).

### Step 8.2: Trigger Conditions
The bug triggers only when `aoa_codec_register()` fails during probe.
This is an error path, so it's not common, but it represents a real leak
each time it occurs (e.g., resource contention, misconfiguration).

### Step 8.3: Failure Mode Severity
- **OF node reference leak**: The node refcount is never decremented, so
  the OF node structure is never freed.
- Severity: **LOW-MEDIUM** — resource leak on error path, not a crash or
  security issue, but a real correctness bug.

### Step 8.4: Risk-Benefit Ratio
- **Benefit**: Fixes a real reference counting bug that leaks memory on
  probe failure.
- **Risk**: Essentially zero — 1-line, obviously correct, mirrors
  existing cleanup in the remove function.
- **Ratio**: Very favorable — minimal risk, real correctness
  improvement.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting**:
- Fixes a real reference counting bug (missing `of_node_put()` on error
  path)
- 1-line fix, obviously correct, mirrors cleanup in `tas_i2c_remove()`
- Bug has existed since 2006, present in all stable trees
- Accepted by ALSA maintainer Takashi Iwai
- Zero regression risk
- Classic reference counting fix — standard stable material

**AGAINST backporting**:
- Only affects Apple PowerPC hardware with TAS3004 codec (niche)
- Only triggers on probe failure (error path, not common)
- Severity is LOW-MEDIUM (resource leak, not crash/security)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** — mirrors existing cleanup in
   remove()
2. Fixes a real bug? **YES** — OF node reference leak
3. Important issue? **MODERATE** — resource leak, not critical
4. Small and contained? **YES** — 1 line, 1 file
5. No new features/APIs? **YES** — pure fix
6. Can apply to stable? **YES** — standalone, no dependencies

### Step 9.3: Exception Categories
Not an exception category. Standard bug fix.

### Step 9.4: Decision
This is a small, obviously correct reference counting fix. While the
impact is limited (niche hardware, error path only), the fix has
essentially zero risk and addresses a real correctness bug. OF node
reference leak fixes are routinely accepted in stable, and this follows
a well-established pattern.

---

## Verification

- [Phase 1] Parsed subject: ALSA: aoa/tas subsystem, "Fix" verb, OF node
  leak on probe failure
- [Phase 1] Parsed tags: Signed-off-by from author and Takashi Iwai
  (ALSA maintainer), Link to lore
- [Phase 2] Diff analysis: 1 line added in `tas_i2c_probe()` fail path:
  `of_node_put(tas->codec.node)` before `kfree(tas)`
- [Phase 2] Verified `of_node_get(node)` at line 864 takes a reference
  that is not released on error path
- [Phase 2] Verified `tas_i2c_remove()` at line 885 calls
  `of_node_put(tas->codec.node)` — confirming correct pattern
- [Phase 3] git blame: buggy code introduced in f3d9478b2ce468
  (2006-06-21, "[ALSA] snd-aoa: add snd-aoa")
- [Phase 3] git log: only treewide cleanups on this file, no prior fix
  for this specific bug
- [Phase 3] Related commit 222bce5eb88d1 fixed same bug class in gpio-
  feature.c (different file, same subsystem)
- [Phase 4] b4 dig: could not match rebased commit hash; lore.kernel.org
  blocked by Anubis
- [Phase 5] Verified `onyx.c` at lines 980-988 has the same unfixed bug
  pattern (systematic issue)
- [Phase 5] Verified `aoa_codec_register()` in core.c can fail when
  `attach_codec_to_fabric()` errors
- [Phase 6] Bug exists since 2006 — present in all active stable trees
- [Phase 6] Minor context difference in stable (kzalloc_obj vs kzalloc)
  won't affect the fix line
- [Phase 8] Failure mode: OF node reference leak on probe error path,
  severity LOW-MEDIUM
- UNVERIFIED: Could not access lore.kernel.org to check full review
  discussion or stable nominations

**YES**

 sound/aoa/codecs/tas.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/aoa/codecs/tas.c b/sound/aoa/codecs/tas.c
index 13da2b159ad0d..25214d3da65d1 100644
--- a/sound/aoa/codecs/tas.c
+++ b/sound/aoa/codecs/tas.c
@@ -872,6 +872,7 @@ static int tas_i2c_probe(struct i2c_client *client)
 	return 0;
  fail:
 	mutex_destroy(&tas->mtx);
+	of_node_put(tas->codec.node);
 	kfree(tas);
 	return -EINVAL;
 }
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ASoC: ti: davinci-mcasp: Add system suspend/resume support

[Sasha Levin]

From: Sen Wang <sen@ti.com>

[ Upstream commit 5879521cb558871472b97c4744dbe634a4286f0e ]

The McASP driver supports runtime PM callbacks for register save/restore
during device idle, but doesn't provide system suspend/resume callbacks.
This causes audio to fail to resume after system suspend.

Since the driver already handles runtime suspend & resume, we can reuse
existing runtime PM logics.

Signed-off-by: Sen Wang <sen@ti.com>
Link: https://patch.msgid.link/20260211221001.155843-1-sen@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

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

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: ASoC: ti: davinci-mcasp
- **Action verb**: "Add" (system suspend/resume support)
- **Summary**: Adds system suspend/resume PM ops to bridge to existing
  runtime PM callbacks

Record: [ASoC: ti: davinci-mcasp] [Add] [system suspend/resume support
by reusing runtime PM]

### Step 1.2: Tags
- **Signed-off-by**: Sen Wang <sen@ti.com> (author, TI employee - the
  SoC vendor)
- **Link**: https://patch.msgid.link/20260211221001.155843-1-sen@ti.com
- **Signed-off-by**: Mark Brown <broonie@kernel.org> (ASoC subsystem
  maintainer, applied the patch)
- No Fixes: tag (expected for commits under review)
- No Reported-by: tag
- No Cc: stable

Record: Author is TI employee (hardware vendor). Applied by ASoC
maintainer Mark Brown.

### Step 1.3: Commit Body
The message states: "The McASP driver supports runtime PM callbacks for
register save/restore during device idle, but doesn't provide system
suspend/resume callbacks. **This causes audio to fail to resume after
system suspend.**"

This describes a clear user-visible failure: audio breaks after system
suspend.

Record: Bug = audio fails to resume after S2RAM/suspend. Root cause =
missing system sleep PM ops when runtime PM callbacks handle context
save/restore. No stack traces or error messages described.

### Step 1.4: Hidden Bug Fix Detection
Despite the subject saying "Add", this is actually **restoring**
functionality that was removed by commit 6175471755075d (Jan 2019). That
commit moved context save/restore from DAI-level suspend/resume to
runtime PM callbacks but failed to bridge system sleep to runtime PM.
This is a regression fix disguised as a feature addition.

Record: YES, this is a hidden bug fix - it restores system suspend
functionality that was inadvertently broken in commit 6175471755075d.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 (`sound/soc/ti/davinci-mcasp.c`)
- **Lines added**: 2
- **Lines removed**: 0
- **Functions modified**: None (only the `davinci_mcasp_pm_ops` struct
  is changed)
- **Scope**: Single-file, ultra-surgical, 2-line addition

### Step 2.2: Code Flow Change
**Before**: `davinci_mcasp_pm_ops` only had `SET_RUNTIME_PM_OPS()`.
System suspend/resume had no callbacks → device context lost on S2RAM.

**After**: `SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
pm_runtime_force_resume)` is added, which tells the PM core to force
runtime suspend/resume during system sleep. This triggers
`davinci_mcasp_runtime_suspend()` and `davinci_mcasp_runtime_resume()`
during S2RAM, saving and restoring all McASP registers.

### Step 2.3: Bug Mechanism
Category: **Logic/correctness fix** + **hardware workaround**

The McASP hardware loses its register context during system suspend.
Without system sleep callbacks, the registers are never saved, so after
resume the hardware is in an undefined state and audio playback/capture
fails.

`pm_runtime_force_suspend`/`pm_runtime_force_resume` are standard kernel
PM helpers used by 35+ other sound drivers in the exact same way.

### Step 2.4: Fix Quality
- **Obviously correct**: YES - this is the standard, well-documented
  pattern
- **Minimal/surgical**: YES - 2 lines, no unrelated changes
- **Regression risk**: Extremely low - uses standard PM infrastructure,
  used identically by dozens of drivers
- **Red flags**: None

---

## PHASE 3: GIT HISTORY

### Step 3.1: Blame
The `davinci_mcasp_pm_ops` struct was introduced by commit
6175471755075d (Peter Ujfalusi, 2019-01-03) titled "ASoC: ti: davinci-
mcasp: Move context save/restore to runtime_pm callbacks". This commit:
1. Removed the old DAI-level
   `davinci_mcasp_suspend()`/`davinci_mcasp_resume()` which DID handle
   system suspend
2. Added
   `davinci_mcasp_runtime_suspend()`/`davinci_mcasp_runtime_resume()`
   for runtime PM
3. Created `davinci_mcasp_pm_ops` with only `SET_RUNTIME_PM_OPS` —
   **missing the system sleep bridge**

Record: Bug introduced by 6175471755075d (Jan 2019), which first
appeared around v5.2-rc1. Present in all active stable trees.

### Step 3.2: Fixes Tag
No Fixes: tag present, but the implicit target is 6175471755075d.
Confirmed this commit exists in stable trees (verified it's tagged in
p-5.10, p-5.15 and later).

### Step 3.3: File History
20+ commits to this file since v5.15, but none touch the PM ops area.
The `davinci_mcasp_pm_ops` struct has been unchanged since
6175471755075d.

### Step 3.4: Author
Sen Wang (<sen@ti.com>) is a TI employee with recent contributions to
this driver (3 commits to davinci-mcasp, plus DT bindings). TI is the
manufacturer of the McASP hardware.

### Step 3.5: Dependencies
None. The fix adds 2 lines to an existing struct using APIs that have
been available since v4.x. No prerequisite commits needed.

---

## PHASE 4: MAILING LIST RESEARCH

b4 dig could not find the commit by message-id. Lore.kernel.org returned
anti-bot pages. However, the Link: tag in the commit message confirms it
was submitted and reviewed on the ALSA/ASoC mailing list. Mark Brown
(ASoC maintainer) applied it directly.

### Step 4.2: Reviewers
Applied by Mark Brown (broonie@kernel.org), the ASoC subsystem
maintainer. He is the authoritative reviewer for this subsystem.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
The diff doesn't modify any functions - it adds
`pm_runtime_force_suspend`/`pm_runtime_force_resume` (existing kernel
APIs) to the PM ops struct.

### Step 5.2: Callers
The PM core calls these functions during system suspend/resume based on
the `dev_pm_ops` structure. This affects every system that uses McASP
hardware and performs system suspend (S2RAM, hibernate).

### Step 5.3-5.5: Similar Patterns
Verified that 35+ sound drivers use this exact same
`SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend, pm_runtime_force_resume)`
pattern. This is the standard approach for drivers that handle context
save/restore via runtime PM.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Code Existence
The buggy code (`davinci_mcasp_pm_ops` with only `SET_RUNTIME_PM_OPS`)
exists in ALL active stable trees since v5.2. Confirmed commit
6175471755075d is in p-5.10 and p-5.15.

### Step 6.2: Backport Complications
The PM ops area has been completely unchanged since 2019. The patch
should apply cleanly to all stable trees (6.6.y, 6.1.y, 5.15.y, 5.10.y).

### Step 6.3: No related fixes already in stable for this issue.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
`sound/soc/ti/` - TI Audio SoC driver. Criticality: PERIPHERAL (specific
embedded hardware - TI AM335x/AM437x/AM65x/J7 platforms, including
BeagleBone). However, this is a widely-used embedded platform.

### Step 7.2: Activity
Moderately active - 10+ commits since v6.6.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All users of TI DaVinci McASP audio hardware who perform system
suspend/resume. This includes BeagleBone users, TI AM335x/AM437x/AM65x
industrial platforms, and any TI-based embedded system using audio.

### Step 8.2: Trigger
System suspend/resume (S2RAM). Very common operation on laptops and many
embedded systems. Triggered by user action (closing lid, `systemctl
suspend`).

### Step 8.3: Failure Mode
Audio completely fails after resume - the hardware registers are in
undefined state. Severity: **HIGH** - functionality loss requiring
reboot to recover.

### Step 8.4: Risk-Benefit
- **BENEFIT**: HIGH - fixes audio breakage after suspend for all McASP
  users
- **RISK**: Very low - 2 lines using standard, well-tested kernel PM
  APIs used by 35+ other drivers
- **Ratio**: Strongly favorable

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a real user-visible bug (audio fails after system suspend)
- This is a regression fix: commit 6175471755075d (2019) removed system
  suspend callbacks without adding the runtime PM bridge
- Ultra-minimal: 2 lines added
- Uses standard kernel PM APIs
  (`pm_runtime_force_suspend`/`pm_runtime_force_resume`)
- Pattern used by 35+ other sound drivers
- No dependencies or prerequisites
- Applies cleanly to all stable trees
- Authored by TI employee (hardware vendor), applied by ASoC maintainer
- Bug affects all stable trees since v5.2

**AGAINST backporting:**
- Subject line says "Add" which sounds like new feature (but substance
  is a regression fix)
- No Fixes: tag (expected for candidates under review)
- No explicit Reported-by (but the TI author would be testing this
  hardware)
- The bug has existed since 2019 without being reported/fixed (low
  urgency, but real)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - standard pattern, accepted by
   maintainer
2. Fixes a real bug? **YES** - audio fails after system suspend
3. Important issue? **YES** - complete audio loss requiring reboot
4. Small and contained? **YES** - 2 lines in one file
5. No new features or APIs? **YES** - restores accidentally removed
   functionality using existing APIs
6. Can apply to stable? **YES** - clean apply expected

### Step 9.3: Exception Category
This is a suspend/resume fix, which is a common category of stable-
appropriate fixes (fixes prevent data loss / functionality loss on real
hardware).

### Step 9.4: Decision
This is a regression fix for commit 6175471755075d which accidentally
removed system suspend support in 2019. The fix is 2 lines, uses
standard, well-proven kernel PM infrastructure, has zero regression
risk, and fixes complete audio loss after system suspend for all TI
McASP users. It should be backported.

---

## Verification

- [Phase 1] Parsed tags: Author is TI employee, applied by ASoC
  maintainer Mark Brown
- [Phase 2] Diff analysis: 2 lines added to `davinci_mcasp_pm_ops`
  struct, adding `SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
  pm_runtime_force_resume)`
- [Phase 3] git blame: PM ops struct introduced by commit 6175471755075d
  (2019-01-03), which removed old system suspend callbacks without
  adding runtime PM bridge
- [Phase 3] git show 6175471755075d: confirmed it removed
  `davinci_mcasp_suspend()`/`davinci_mcasp_resume()` DAI callbacks that
  previously handled system suspend
- [Phase 3] git tag --contains 6175471755075d: confirmed present in
  p-5.10 and p-5.15 (all active stable trees)
- [Phase 3] git log v6.1..HEAD / v5.15..HEAD: PM ops area unchanged in
  stable trees, patch will apply cleanly
- [Phase 4] b4 dig: could not match by message-id; lore blocked by anti-
  bot measures
- [Phase 5] Grep for `pm_runtime_force_suspend` in sound/: found 35+
  drivers using identical pattern
- [Phase 6] Code exists unchanged in all active stable trees since v5.2
- [Phase 8] Failure mode: complete audio loss after system suspend,
  severity HIGH
- UNVERIFIED: Could not read lore.kernel.org discussion due to anti-bot
  protection. However, the maintainer's Signed-off-by confirms review
  and acceptance.

**YES**

 sound/soc/ti/davinci-mcasp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c
index 2d260fbc9b835..14267be4a288a 100644
--- a/sound/soc/ti/davinci-mcasp.c
+++ b/sound/soc/ti/davinci-mcasp.c
@@ -2823,6 +2823,8 @@ static int davinci_mcasp_runtime_resume(struct device *dev)
 #endif
 
 static const struct dev_pm_ops davinci_mcasp_pm_ops = {
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
 	SET_RUNTIME_PM_OPS(davinci_mcasp_runtime_suspend,
 			   davinci_mcasp_runtime_resume,
 			   NULL)
-- 
2.53.0

[PATCH AUTOSEL 6.18] ALSA: asihpi: avoid write overflow check warning

[Sasha Levin]

From: Arnd Bergmann <arnd@arndb.de>

[ Upstream commit 591721223be9e28f83489a59289579493b8e3d83 ]

clang-22 rightfully warns that the memcpy() in adapter_prepare() copies
between different structures, crossing the boundary of nested
structures inside it:

In file included from sound/pci/asihpi/hpimsgx.c:13:
In file included from include/linux/string.h:386:
include/linux/fortify-string.h:569:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
  569 |                         __write_overflow_field(p_size_field, size);

The two structures seem to refer to the same layout, despite the
separate definitions, so the code is in fact correct.

Avoid the warning by copying the two inner structures separately.
I see the same pattern happens in other functions in the same file,
so there is a chance that this may come back in the future, but
this instance is the only one that I saw in practice, hitting it
multiple times per day in randconfig build.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20260318124016.3488566-1-arnd@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 sound/pci/asihpi/hpimsgx.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/sound/pci/asihpi/hpimsgx.c b/sound/pci/asihpi/hpimsgx.c
index b68e6bfbbfbab..ed1c7b7744361 100644
--- a/sound/pci/asihpi/hpimsgx.c
+++ b/sound/pci/asihpi/hpimsgx.c
@@ -581,8 +581,10 @@ static u16 adapter_prepare(u16 adapter)
 		HPI_ADAPTER_OPEN);
 	hm.adapter_index = adapter;
 	hw_entry_point(&hm, &hr);
-	memcpy(&rESP_HPI_ADAPTER_OPEN[adapter], &hr,
-		sizeof(rESP_HPI_ADAPTER_OPEN[0]));
+	memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].h, &hr,
+		sizeof(rESP_HPI_ADAPTER_OPEN[adapter].h));
+	memcpy(&rESP_HPI_ADAPTER_OPEN[adapter].a, &hr.u.ax.info,
+		sizeof(rESP_HPI_ADAPTER_OPEN[adapter].a));
 	if (hr.error)
 		return hr.error;
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ASoC: rt5640: Handle 0Hz sysclk during stream shutdown

[Sasha Levin]

From: Sheetal <sheetal@nvidia.com>

[ Upstream commit 247d1c13992d2c501e2e020e84d9d2920e11bf78 ]

Commit 2458adb8f92a ("SoC: simple-card-utils: set 0Hz to sysclk when
shutdown") sends a 0Hz sysclk request during stream shutdown to clear
codec rate constraints. The rt5640 codec forwards this 0Hz to
clk_set_rate(), which can cause clock controller firmware faults on
platforms where MCLK is SoC-driven (e.g. Tegra) and 0Hz falls below
the hardware minimum rate.

Handle the 0Hz case by clearing the internal sysclk state and
returning early, avoiding the invalid clk_set_rate() call.

Signed-off-by: Sheetal <sheetal@nvidia.com>
Link: https://patch.msgid.link/20260406090547.988966-1-sheetal@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The code is identical across v6.6, v6.12, and v7.0. The fix will apply
cleanly. Let me now compile my complete analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: ASoC: rt5640 (audio codec driver)
- **Action verb**: "Handle" - indicates fixing incorrect handling of a
  specific case
- **Summary**: Handles the 0Hz sysclk case during stream shutdown to
  prevent clock controller faults

### Step 1.2: Tags
- **Link**:
  `https://patch.msgid.link/20260406090547.988966-1-sheetal@nvidia.com`
  - original patch submission
- **Signed-off-by**: Sheetal (NVIDIA) - author, and Mark Brown
  (subsystem maintainer) - applied it
- No Fixes: tag (expected for autosel candidates)
- No Reported-by tag
- No Cc: stable tag

### Step 1.3: Commit Body Analysis
The commit explains:
- **Cause**: Commit 2458adb8f92a added a 0Hz sysclk request during
  stream shutdown
- **Bug**: rt5640 forwards this 0Hz to `clk_set_rate()`, which causes
  clock controller firmware faults on Tegra platforms where MCLK is SoC-
  driven and 0Hz falls below hardware minimum
- **Symptom**: Clock controller firmware fault during audio stream
  shutdown
- **Fix approach**: Check for 0Hz, clear internal sysclk state, return
  early

### Step 1.4: Hidden Bug Fix Detection
This is explicitly a bug fix for an interaction between two commits. The
word "Handle" means "fix the missing handling of this case."

Record: This IS a bug fix - it prevents firmware faults during normal
audio stream shutdown.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files**: `sound/soc/codecs/rt5640.c` only (single file)
- **Lines**: +4 added, 0 removed
- **Function modified**: `rt5640_set_dai_sysclk()`
- **Scope**: Single-file surgical fix

### Step 2.2: Code Flow Change
- **Before**: `rt5640_set_dai_sysclk()` enters the switch statement
  unconditionally. With `clk_id=0` (RT5640_SCLK_S_MCLK),
  `clk_set_rate(rt5640->mclk, 0)` is called, hitting the clock
  controller with an invalid 0Hz rate.
- **After**: When `freq==0`, the function sets `rt5640->sysclk = 0` and
  returns early, avoiding the `clk_set_rate(mclk, 0)` call entirely.

### Step 2.3: Bug Mechanism
Category: **Logic/correctness fix** (missing case handling)
- The 0Hz value is a convention from `simple-card-utils` to signal
  "clear constraints"
- rt5640 didn't handle this convention, passing the invalid rate
  directly to the clock framework
- This causes firmware faults on platforms like Tegra

### Step 2.4: Fix Quality
- **Obviously correct**: Yes - the exact same pattern exists in
  rockchip, ep93xx, wm8904, and stm32 sai drivers
- **Minimal/surgical**: Yes - 4 lines, single early-return guard
- **Regression risk**: Extremely low - only affects the freq==0 case,
  which was already broken
- **No red flags**: Doesn't touch locking, APIs, or other subsystems

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- `rt5640_set_dai_sysclk()` original structure by Bard Liao (2013,
  v3.11-era)
- `clk_set_rate()` call added by Sameer Pujar (9f138bb2eaf661, v6.3) -
  an NVIDIA engineer
- The 0Hz shutdown behavior (2458adb8f92ad) was added in v5.10

### Step 3.2: Fixes tag analysis
No explicit Fixes: tag, but the commit references 2458adb8f92a. The bug
is an interaction between:
1. 2458adb8f92a (v5.10) - sends 0Hz sysclk on shutdown
2. 9f138bb2eaf661 (v6.3) - added `clk_set_rate(mclk, freq)` to rt5640

Both commits are in v6.6 and later stable trees.

### Step 3.3: Related changes
Multiple identical fixes exist for the same 0Hz issue in other drivers:
- f1879d7b98dc9 - rockchip (v5.10)
- 9b7a7f921689d - stm32 sai (v5.10)
- 66dc3b9b9a6f4 - ep93xx (v6.3) - includes a concrete crash stack trace
- 2a0bda276c642 - wm8904

### Step 3.4: Author context
Sheetal is an NVIDIA Tegra audio engineer. Sameer Pujar (who added
clk_set_rate) is also NVIDIA. This is the team that owns this platform
and hit this bug directly.

### Step 3.5: Dependencies
None. The fix is completely standalone - it adds a guard before the
existing switch statement.

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1-4.2: Patch discussion
- b4 dig could not find the commit by message-id (too new)
- Lore is behind Anubis anti-scraping protection
- Mark Brown (ASoC maintainer) applied it directly, confirming
  acceptance
- The pattern is well-established: identical fixes for ep93xx, rockchip,
  stm32, wm8904

### Step 4.3: Bug report
The ep93xx fix (66dc3b9b9a6f4) includes a full stack trace showing
`__div0` crash from `clk_set_rate(0)` during shutdown. The rt5640 commit
describes "clock controller firmware faults" on Tegra - same class of
issue.

### Step 4.4-4.5: Series context
This is a standalone single-patch fix, not part of a series.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: Function context
`rt5640_set_dai_sysclk()` is registered as `.set_sysclk` in the DAI ops.
It is called by `snd_soc_dai_set_sysclk()` from the ASoC core, triggered
by `asoc_simple_shutdown()` during every stream close.

### Step 5.3-5.4: Call chain
```
PCM stream close -> soc_pcm_close -> soc_pcm_clean ->
snd_soc_link_shutdown
-> asoc_simple_shutdown -> snd_soc_dai_set_sysclk(codec_dai, 0, 0, ...)
-> rt5640_set_dai_sysclk(freq=0) -> clk_set_rate(mclk, 0) -> FIRMWARE
FAULT
```

This is a normal-operation path triggered on every audio stream
shutdown.

### Step 5.5: Similar patterns
Verified: at least 4 other drivers already have identical 0Hz guards
(`if (!freq) return 0` or `if (freq == 0) return 0`).

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy code in stable?
- **v6.1.y**: Does NOT have 9f138bb2eaf661 (`clk_set_rate()` not added)
  - bug does not exist
- **v6.6.y**: HAS both 2458adb8f92a and 9f138bb2eaf661 - **BUG EXISTS**
- **v6.12.y**: Same code, **BUG EXISTS**

### Step 6.2: Backport complications
The `rt5640_set_dai_sysclk()` code is **identical** in v6.6, v6.12, and
v7.0. The patch will apply cleanly without any modifications.

### Step 6.3: Related fixes already in stable
No other fix for this specific issue in rt5640 found.

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem criticality
- **Subsystem**: ASoC codecs (sound/soc/codecs/) - audio driver
- **Criticality**: IMPORTANT - rt5640 is a widely-used Realtek audio
  codec found in many embedded platforms (Tegra, Chromebooks, etc.)

### Step 7.2: Subsystem activity
Active development - multiple recent commits for rt5640.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected users
Users of platforms combining:
- rt5640 codec with SoC-driven MCLK (Tegra platforms specifically
  mentioned)
- simple-card or audio-graph-card machine driver with `mclk-fs` property

### Step 8.2: Trigger conditions
- Triggered on **every audio stream shutdown** - extremely common
  operation
- No special conditions needed beyond the hardware configuration above
- This is a normal-operation failure, not an edge case

### Step 8.3: Failure mode severity
- **Clock controller firmware fault** - platform-dependent, but can
  cause:
  - Error returns from `clk_set_rate()` breaking audio shutdown
  - On some platforms (ep93xx), division by zero causing kernel crash
  - On Tegra, firmware-level faults that may affect system stability
- **Severity**: HIGH (firmware fault on every stream close)

### Step 8.4: Risk-benefit ratio
- **Benefit**: HIGH - prevents firmware fault/crash on every audio
  stream shutdown on affected platforms
- **Risk**: VERY LOW - 4-line early return guard, only affects the
  freq==0 case which was already broken
- **Ratio**: Excellent - this is exactly the kind of fix stable trees
  are meant to carry

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence compilation

**FOR backporting**:
- Fixes a real bug: clock controller firmware faults during normal audio
  stream shutdown
- Well-established fix pattern: identical fixes exist for 4+ other
  drivers
- Concrete crash evidence from ep93xx (division by zero stack trace)
- Tiny, surgical fix: 4 lines, single early-return guard
- Obviously correct: follows exact pattern validated in other drivers
- Clean applicability: code is identical in v6.6, v6.12, and v7.0
- Applied by Mark Brown (ASoC maintainer)
- Author is from the affected platform team (NVIDIA/Tegra)

**AGAINST backporting**:
- None identified

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **YES** - identical pattern used in 4+
   other drivers, applied by maintainer
2. Fixes a real bug? **YES** - firmware faults on every stream shutdown
3. Important issue? **YES** - prevents crash/fault on normal audio
   operations
4. Small and contained? **YES** - 4 lines, single function
5. No new features/APIs? **YES** - pure defensive guard
6. Can apply to stable? **YES** - verified identical code in v6.6 and
   v6.12

### Step 9.3: Exception categories
Not an exception category - this is a straightforward bug fix.

## Verification

- [Phase 1] Parsed tags: Link to patch.msgid.link, Signed-off-by Mark
  Brown (maintainer)
- [Phase 2] Diff analysis: 4 lines added, inserts `if (!freq) {
  rt5640->sysclk = 0; return 0; }` before switch in
  `rt5640_set_dai_sysclk()`
- [Phase 3] git blame: `clk_set_rate()` added by 9f138bb2eaf661 (Sameer
  Pujar, v6.3); 0Hz shutdown added by 2458adb8f92ad (v5.10)
- [Phase 3] `git merge-base --is-ancestor`: 9f138bb2eaf661 IS in v6.6
  (YES), NOT in v6.1 (NO)
- [Phase 3] `git merge-base --is-ancestor`: 2458adb8f92ad IS in v6.6
  (YES) - both triggering commits present
- [Phase 3] git log: verified 4+ identical fixes (rockchip
  f1879d7b98dc9, ep93xx 66dc3b9b9a6f4, stm32 sai 9b7a7f921689d, wm8904
  2a0bda276c642)
- [Phase 3] git show 66dc3b9b9a6f4: confirmed ep93xx fix includes
  division-by-zero stack trace as concrete crash evidence
- [Phase 4] b4 dig: could not find original submission by message-id
  (recent commit)
- [Phase 4] lore: blocked by Anubis anti-scraping
- [Phase 5] grep: `rt5640_set_dai_sysclk` registered as `.set_sysclk` in
  DAI ops, called from ASoC framework during shutdown
- [Phase 6] `git show v6.6:sound/soc/codecs/rt5640.c`: code is identical
  to v7.0 - patch applies cleanly
- [Phase 6] `git show v6.12:sound/soc/codecs/rt5640.c`: code is
  identical to v7.0 - patch applies cleanly
- [Phase 8] Trigger: every audio stream shutdown on affected platforms;
  severity HIGH (firmware fault)

The fix is small (4 lines), surgical, obviously correct (proven pattern
in 4+ other drivers), fixes a real firmware fault on every audio stream
shutdown, and applies cleanly to all active stable trees containing the
buggy code (v6.6+).

**YES**

 sound/soc/codecs/rt5640.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c
index db2222e6f2e75..f6c6294e15880 100644
--- a/sound/soc/codecs/rt5640.c
+++ b/sound/soc/codecs/rt5640.c
@@ -1838,6 +1838,11 @@ static int rt5640_set_dai_sysclk(struct snd_soc_dai *dai,
 	unsigned int pll_bit = 0;
 	int ret;
 
+	if (!freq) {
+		rt5640->sysclk = 0;
+		return 0;
+	}
+
 	switch (clk_id) {
 	case RT5640_SCLK_S_MCLK:
 		ret = clk_set_rate(rt5640->mclk, freq);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ALSA: compress: Refuse to update timestamps for unconfigured streams

[Sasha Levin]

From: Mark Brown <broonie@kernel.org>

[ Upstream commit cf6c18cf83e48986ac40a053d09d3c33624135f6 ]

There are a number of mechanisms, including the userspace accessible
timestamp and buffer availability ioctl()s, which allow us to trigger
a timestamp update on a stream before it has been configured. Since
drivers might rely on stream configuration for reporting of pcm_io_frames,
including potentially doing a division by the number of channels, and
these operations are not meaningful for an unconfigured stream reject
attempts to read timestamps before any configuration is done.

Signed-off-by: Mark Brown <broonie@kernel.org>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260401-alsa-unconfigured-tstamp-v1-1-694c2cb5f71d@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

This confirms: `snd_compr_ioctl_avail` calls `snd_compr_calc_avail`
(line 267) which calls `snd_compr_update_tstamp` **before** the state
check at line 275. So even the AVAIL ioctl triggers the `->pointer()`
callback before checking state. The fix in `snd_compr_update_tstamp`
itself properly guards *both* paths (TSTAMP and AVAIL).

Now let me finalize the analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `ALSA: compress`
- Action verb: "Refuse" (defensive/preventive - indicates preventing
  incorrect behavior)
- Summary: Refuse timestamp updates for streams that haven't been
  configured yet.

Record: [ALSA: compress] [Refuse] [Prevent timestamp update on
unconfigured streams]

**Step 1.2: Tags**
- `Signed-off-by: Mark Brown <broonie@kernel.org>` - Author is the ASoC
  subsystem maintainer
- `Acked-by: Vinod Koul <vkoul@kernel.org>` - Vinod Koul is the original
  compress_offload author
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>` - Takashi Iwai is the
  ALSA top-level maintainer
- `Link:` to patch.msgid.link (the submission)

Record: Authored by ASoC subsystem maintainer, Acked by compress_offload
author, merged by ALSA maintainer. Strong review pedigree.

**Step 1.3: Commit Body**
The commit describes: userspace-accessible timestamp and buffer
availability ioctls can trigger a timestamp update on a stream before it
has been configured. Drivers might rely on stream configuration for
reporting `pcm_io_frames`, including "potentially doing a division by
the number of channels." Since these operations are not meaningful for
unconfigured streams, reject attempts to read timestamps before
configuration.

Record: Bug = calling driver `->pointer()` callback before `set_params`
has been called. Symptom = potential divide-by-zero in drivers (number
of channels = 0 before configuration). Root cause = missing state
validation in `snd_compr_update_tstamp()`.

**Step 1.4: Hidden Bug Fix?**
This is explicitly a defensive fix preventing a divide-by-zero crash.
The "Refuse" language hides what is actually a crash prevention fix.

Record: YES, this is a hidden bug fix. The commit message explicitly
says "doing a division by the number of channels" which is the crash
mechanism.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Single file: `sound/core/compress_offload.c`
- Lines added: ~7 (switch statement checking SNDRV_PCM_STATE_OPEN)
- Lines removed: 0
- Function modified: `snd_compr_update_tstamp()`
- Classification: Single-file surgical fix

**Step 2.2: Code Flow Change**
Before: `snd_compr_update_tstamp()` immediately calls
`stream->ops->pointer()` with no state validation.
After: A switch statement checks if `stream->runtime->state ==
SNDRV_PCM_STATE_OPEN` (pre-configuration state) and returns `-EBADFD` if
so, preventing the `->pointer()` call.

**Step 2.3: Bug Mechanism**
Category: Divide-by-zero / uninitialized state access. When a compress
offload stream is just opened (state = OPEN), driver parameters
(channels, sample_container_bytes) are zero. Calling `->pointer()` in
this state causes drivers like SOF's `sof_compr_pointer()` to execute
`div_u64(..., sstream->channels * sstream->sample_container_bytes)`
which divides by zero.

**Step 2.4: Fix Quality**
- Obviously correct: The state check pattern is used extensively
  throughout this same file (lines 276, 391, 446, 652, 846, 946, 998)
- Minimal: 7 lines added
- No regression risk: Returning -EBADFD for OPEN state is the standard
  pattern used by all other ioctls
- The caller `snd_compr_calc_avail` already has comment "Still need to
  return avail even if tstamp can't be filled in" showing it handles the
  error

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- `snd_compr_update_tstamp()` was introduced by commit b21c60a4edd22e
  (2011, v3.3-era) by Vinod Koul as part of the original
  compress_offload support
- The bug has existed since the very beginning (~2011)

**Step 3.2: Fixes tag**
- No Fixes: tag present (expected for autosel candidates)

**Step 3.3: File history**
- Recent changes to the file: 64-bit timestamp infrastructure
  (2c92e2fbe9e22c, Sept 2025) made the issue more visible since it
  changed the pointer callback signature, but the underlying bug
  predates that

**Step 3.4: Author**
- Mark Brown (`broonie@kernel.org`) is the ASoC subsystem maintainer -
  one of the most trusted kernel developers

**Step 3.5: Dependencies**
- This fix applies independently. It only adds a state check using
  existing infrastructure (`SNDRV_PCM_STATE_OPEN`).
- NOTE: In older stable trees (pre-6.12ish), the function signature may
  differ (uses `snd_compr_tstamp` instead of `snd_compr_tstamp64`), but
  the state check logic is identical and would need only trivial
  adaptation.

## PHASE 4: MAILING LIST

Lore was blocked by Anubis anti-bot protection. However:
- The patch was v1 (no revisions needed, indicating it was clean from
  the start)
- It was Acked by the compress_offload author Vinod Koul
- Merged directly by ALSA maintainer Takashi Iwai

Record: Could not fetch lore discussion. Strong review indicators from
tags.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions modified**
- `snd_compr_update_tstamp()` - the internal timestamp update helper

**Step 5.2: Callers**
- `snd_compr_calc_avail()` (line 209) - called from AVAIL/AVAIL64 ioctls
- `snd_compr_tstamp()` (line 760) - called from TSTAMP/TSTAMP64 ioctls
- Both paths are directly reachable from userspace via ioctl

**Step 5.3-5.4: Call chain**
`open() → ioctl(SNDRV_COMPRESS_TSTAMP) → snd_compr_tstamp() →
snd_compr_update_tstamp() → stream->ops->pointer()` - This is directly
triggerable by any user with access to the compress device.

**Step 5.5: Similar patterns**
- Confirmed: `sof_compr_pointer()` does `div_u64(..., sstream->channels
  * sstream->sample_container_bytes)` at line 384-385
- `sst_cdev_tstamp()` does `div_u64(fw_tstamp.hardware_counter,
  stream->num_ch * ...)` at line 348-349
- Both would divide by zero if called before set_params

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code exists in stable trees**
- The buggy function `snd_compr_update_tstamp()` has existed since 2011
  (v3.3)
- Present in ALL active stable trees
- NOTE: The 64-bit tstamp infrastructure is only in v6.12+. Older trees
  use `snd_compr_tstamp` struct. The fix concept applies to all, but the
  exact patch applies cleanly only to v7.0 and trees with the 64-bit
  tstamp change.

**Step 6.2: Backport complications**
- For v7.0: Applies cleanly (verified function matches exactly)
- For older trees: Needs minor adaptation (different struct type in
  signature)

**Step 6.3: Related fixes**
- No similar state check has been applied to `snd_compr_update_tstamp`
  before

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem**
- `sound/core/` - ALSA core, IMPORTANT criticality
- Compress offload is used by mobile/embedded platforms (Qualcomm, Intel
  Atom, SOF)

**Step 7.2: Activity**
- Active subsystem with recent work (64-bit tstamp infrastructure added
  in 2025)

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is affected**
- Users of ALSA compressed audio (primarily mobile/embedded, Android,
  Intel Atom, SOF platforms)

**Step 8.2: Trigger conditions**
- Trivially triggerable: open compress device, call TSTAMP or AVAIL
  ioctl before SET_PARAMS
- Can be triggered by unprivileged user with access to the audio device
- No special timing required - completely deterministic

**Step 8.3: Failure severity**
- Divide-by-zero → kernel oops/crash → **CRITICAL**

**Step 8.4: Risk-benefit**
- BENEFIT: Very high - prevents deterministic kernel crash from
  userspace
- RISK: Very low - 7 lines, uses established pattern, authored by ASoC
  maintainer, acked by compress_offload author

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR:**
1. Fixes a divide-by-zero crash triggerable from userspace (CRITICAL)
2. Extremely small and surgical fix (7 lines)
3. Uses an existing, well-established pattern (same check at 6+ other
   locations in the file)
4. Authored by ASoC subsystem maintainer Mark Brown
5. Acked by compress_offload original author Vinod Koul
6. Bug exists since 2011 - affects all stable trees
7. Multiple drivers have the vulnerable division (SOF, Intel Atom)

**Evidence AGAINST:**
1. Needs minor adaptation for trees without 64-bit tstamp (pre-6.12ish)

**Stable rules checklist:**
1. Obviously correct? YES - uses identical pattern to 6+ other ioctls in
   same file
2. Fixes a real bug? YES - divide-by-zero crash
3. Important issue? YES - kernel crash triggerable from userspace
4. Small and contained? YES - 7 lines, single function
5. No new features/APIs? Correct - purely defensive check
6. Applies to stable? YES for 7.0 (clean apply); needs minor rework for
   older trees

## Verification

- [Phase 1] Parsed tags: Signed-off-by Mark Brown (ASoC maintainer),
  Acked-by Vinod Koul (compress_offload author), Signed-off-by Takashi
  Iwai (ALSA maintainer)
- [Phase 2] Diff analysis: 7 lines added in `snd_compr_update_tstamp()`,
  adds state check for SNDRV_PCM_STATE_OPEN
- [Phase 3] git blame: `snd_compr_update_tstamp()` introduced in commit
  b21c60a4edd22e (2011), present in all stable trees
- [Phase 3] git show b21c60a4edd22e: confirmed original compress_offload
  commit
- [Phase 3] git merge-base: confirmed 64-bit tstamp infrastructure
  (2c92e2fbe9e22c) is ancestor of v7.0
- [Phase 4] Lore blocked by Anubis; relied on tag analysis for review
  evidence
- [Phase 5] Grep callers: `snd_compr_update_tstamp` called from lines
  209 and 760, both ioctl-reachable
- [Phase 5] Verified SOF driver `sof_compr_pointer()` does `div_u64(...,
  sstream->channels * sstream->sample_container_bytes)` at line 384-385
- [Phase 5] Verified Intel Atom `sst_cdev_tstamp()` does `div_u64(...,
  stream->num_ch * ...)` at line 348-349
- [Phase 5] Verified `snd_compr_set_params()` sets channels (line 256 in
  sof compress.c), confirming channels=0 before set_params
- [Phase 6] git show v7.0:compress_offload.c: function matches current
  HEAD exactly, clean apply confirmed
- [Phase 6] Existing divide-by-zero protection commit 678e2b44c8e3fec
  (2018) validates this class of bug is real
- [Phase 7] Identified `snd_compr_ioctl_avail` line 267 calls
  update_tstamp BEFORE its own state check at line 275, confirming both
  AVAIL and TSTAMP paths are vulnerable
- [Phase 8] Failure mode: divide-by-zero → kernel oops, severity
  CRITICAL, trivially triggerable from userspace

This is a textbook stable backport: a small, surgical fix preventing a
deterministic kernel crash (divide-by-zero) that is trivially
triggerable from userspace via ioctl. Authored and reviewed by the top
three relevant maintainers.

**YES**

 sound/core/compress_offload.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c
index fdba6e4b25fdc..67b3b1a3b5261 100644
--- a/sound/core/compress_offload.c
+++ b/sound/core/compress_offload.c
@@ -192,6 +192,14 @@ static int snd_compr_update_tstamp(struct snd_compr_stream *stream,
 {
 	if (!stream->ops->pointer)
 		return -ENOTSUPP;
+
+	switch (stream->runtime->state) {
+	case SNDRV_PCM_STATE_OPEN:
+		return -EBADFD;
+	default:
+		break;
+	}
+
 	stream->ops->pointer(stream, tstamp);
 	pr_debug("dsp consumed till %u total %llu bytes\n", tstamp->byte_offset,
 		 tstamp->copied_total);
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ASoC: Intel: cht_bsw_rt5672: Fix MCLK leak on platform_clock_control error

[Sasha Levin]

From: Aravind Anilraj <aravindanilraj0702@gmail.com>

[ Upstream commit dced5a373a96cfd9f3bd0ffcf5339a7579d1473a ]

If snd_soc_dai_set_pll() or snd_soc_dai_set_sysclk() fail inside the
EVENT_ON path, the function returns without calling
clk_disable_unprepare() on ctx->mclk, which was already enabled earlier
in the same code path. Add the missing clk_disable_unprepare() calls
before returning the error.

Signed-off-by: Aravind Anilraj <aravindanilraj0702@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260401220507.23557-4-aravindanilraj0702@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have all the information needed for a complete analysis. Let me
compile the full assessment.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [ASoC: Intel: cht_bsw_rt5672] [Fix] [MCLK leak on
platform_clock_control error path]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by:** Aravind Anilraj (author)
- **Reviewed-by:** Cezary Rojewski (Intel ASoC reviewer)
- **Link:** patch.msgid.link to the original patch
- **Signed-off-by:** Mark Brown (ASoC subsystem maintainer, committer)
- No Fixes: tag (expected for manual review candidates)
- No Reported-by: tag
- No Cc: stable tag

Record: Reviewed by Intel ASoC developer and merged by ASoC subsystem
maintainer. No syzbot or external reporter — this is a code-inspection-
found bug.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit message clearly states: if `snd_soc_dai_set_pll()` or
`snd_soc_dai_set_sysclk()` fail in the EVENT_ON path, the function
returns without calling `clk_disable_unprepare()` on `ctx->mclk`, which
was already enabled. The fix adds the missing cleanup calls.

Record: Bug: clock resource leak on error paths. Symptom: MCLK left
enabled after error, preventing proper power management. Root cause:
missing cleanup in two error return paths.

### Step 1.4: DETECT HIDDEN BUG FIXES
This is explicitly labeled as a "Fix" and describes a resource leak — no
disguise here.

Record: This is an overt bug fix for a resource leak.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
- **File:** `sound/soc/intel/boards/cht_bsw_rt5672.c`
- **Lines added:** +4 (two `if (ctx->mclk)
  clk_disable_unprepare(ctx->mclk);` blocks)
- **Lines removed:** 0
- **Functions modified:** `platform_clock_control()`
- **Scope:** Single-file, surgical fix

Record: 1 file, 4 lines added, 0 removed. Single function modified.
Extremely contained.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
- **Before:** In the EVENT_ON path, after
  `clk_prepare_enable(ctx->mclk)` succeeds, if either
  `snd_soc_dai_set_pll()` or `snd_soc_dai_set_sysclk()` fails, the
  function returns the error without disabling the clock.
- **After:** Both error paths now call
  `clk_disable_unprepare(ctx->mclk)` (guarded by `if (ctx->mclk)`)
  before returning the error.

Record: Error paths now properly clean up the enabled clock before
returning.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category: Error path / resource leak fix.**

The clock `ctx->mclk` is enabled via `clk_prepare_enable()` at line 67.
If subsequent calls fail (lines 78-81 or 86-89), the function returns
without the matching `clk_disable_unprepare()`. This leaves the platform
clock running, preventing proper power management. The EVENT_OFF path at
line 103-104 already properly calls `clk_disable_unprepare()`,
confirming the intended pattern.

Record: Resource leak — MCLK left in enabled/prepared state on error
paths.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct:** Yes. Mirrors the existing cleanup pattern in
  the EVENT_OFF path (line 103-104). The `if (ctx->mclk)` guard is
  consistent with the guard at line 66.
- **Minimal/surgical:** Yes. Only 4 lines added, no unrelated changes.
- **Regression risk:** Extremely low. Only affects error paths. The
  `clk_disable_unprepare()` call is the exact counterpart to
  `clk_prepare_enable()` that was already called.

Record: Fix is obviously correct, minimal, and has negligible regression
risk.

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The MCLK handling was introduced by commit `c25695ae88ce26` (Pierre-
Louis Bossart, 2017-06-23) — "ASoC: Intel: cht_bsw_rt5672: 19.2MHz clock
for Baytrail platforms". The bug has existed since that commit, which
was included in v4.13-rc1.

Record: Buggy code introduced in c25695ae88ce26 (v4.13-rc1, 2017).
Present in all active stable trees.

### Step 3.2: FOLLOW THE FIXES: TAG
No Fixes: tag present. However, the logical "Fixes:" target is
`c25695ae88ce26`, which introduced the MCLK handling without proper
error path cleanup.

Record: The implicit Fixes target (c25695ae88ce26) is in all stable
trees since v4.13.

### Step 3.3: CHECK FILE HISTORY
The file has had ~20 commits over the years, mostly cleanups and
conversions. No prior attempt to fix this specific leak was found (no
commits matching "MCLK leak" in the history).

Record: Standalone fix, no prerequisites needed. No prior fix for this
issue exists.

### Step 3.4: CHECK THE AUTHOR
The author (Aravind Anilraj) appears to be a new contributor. However,
the patch was reviewed by Cezary Rojewski (Intel ASoC reviewer) and
merged by Mark Brown (ASoC subsystem maintainer).

Record: Reviewed by experienced subsystem developers despite being from
a new contributor.

### Step 3.5: CHECK FOR DEPENDENCIES
The fix only adds `clk_disable_unprepare()` calls to existing error
paths. No new functions, structures, or APIs are used. The fix is
completely self-contained.

Record: No dependencies. Can apply standalone.

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1-4.5: PATCH DISCUSSION
The lore.kernel.org site was not reachable due to bot protection. b4 dig
could not find the commit by message-id (it doesn't exist in this tree
as a commit). However, the commit tags show:
- **Reviewed-by:** Cezary Rojewski (Intel) — an active ASoC reviewer
- **Signed-off-by:** Mark Brown — the ASoC subsystem maintainer who
  merged it

These signatures indicate the patch went through proper review.

Record: Proper review by Intel ASoC developer and subsystem maintainer.
Could not access lore discussion directly.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: FUNCTION AND CALLERS
`platform_clock_control()` is registered as a DAPM supply widget
callback:

```114:116:sound/soc/intel/boards/cht_bsw_rt5672.c
        SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0,
                        platform_clock_control, SND_SOC_DAPM_PRE_PMU |
                        SND_SOC_DAPM_POST_PMD),
```

It is called by the DAPM framework whenever the "Platform Clock" supply
widget powers up (PRE_PMU) or down (POST_PMD). This happens during every
audio playback/capture start and stop operation. All audio paths
("Headphone", "Headset Mic", "Int Mic", "Ext Spk") depend on this widget
(lines 130-133).

Record: Called on every audio stream open/close. High frequency for
audio-active systems.

### Step 5.3-5.5: SIMILAR PATTERNS
I found the same bug pattern in sibling drivers `bytcr_rt5651.c` and
`bytcr_rt5640.c`, though those have slightly different code structure.
The `cht_bsw_rt5672.c` fix is specific to this driver and doesn't
require changes to siblings.

Record: Similar pattern exists in sibling drivers but this fix is self-
contained for cht_bsw_rt5672.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: BUGGY CODE IN STABLE
The buggy code was introduced in v4.13-rc1 (commit c25695ae88ce26). It
exists in all active stable trees (5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y,
etc.).

Record: Bug affects all active stable trees.

### Step 6.2: BACKPORT COMPLICATIONS
The file has been relatively stable. The current code at the fix site
matches what was introduced in c25695ae88ce26, with only minor changes
(the `if (ctx->mclk)` guard and the `65b2df10a1e62` commit that changed
the EVENT_OFF path). The fix should apply cleanly or with minimal
adjustment.

Record: Expected clean or near-clean apply to all stable trees.

### Step 6.3: RELATED FIXES
No prior fix for this specific issue was found in any tree.

Record: No existing fix for this leak.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem:** sound/soc/intel/boards — ASoC Intel machine driver
- **Criticality:** PERIPHERAL (specific to Cherryview/Baytrail platforms
  with RT5672 codec)
- **Affected hardware:** Lenovo and other Cherryview/Baytrail-based
  laptops/tablets with RT5670/RT5672 codec (reasonably common consumer
  devices)

Record: ASoC Intel board driver, PERIPHERAL but for consumer devices
(laptops/tablets).

### Step 7.2: SUBSYSTEM ACTIVITY
The file sees occasional updates (cleanups and fixes). It's a mature
driver.

Record: Mature, stable driver with occasional maintenance commits.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: AFFECTED USERS
Users of Cherryview/Baytrail platforms with RT5670/RT5672 codec. This
includes Lenovo and similar consumer laptops/tablets from the Baytrail
era.

Record: Platform-specific but for real consumer devices.

### Step 8.2: TRIGGER CONDITIONS
The bug triggers when `snd_soc_dai_set_pll()` or
`snd_soc_dai_set_sysclk()` fails during audio stream start. While these
failures are not common in normal operation, they can occur during
hardware errors, suspend/resume transitions, or codec communication
issues.

Record: Trigger requires PLL/sysclk configuration failure during audio
start. Uncommon but possible.

### Step 8.3: FAILURE MODE SEVERITY
When triggered, the platform clock remains enabled (leaked), preventing
proper power management. Repeated triggering could cause increased power
consumption. The clock framework may also track prepare/enable counts
incorrectly, potentially affecting system suspend or causing warnings.

Record: Severity: MEDIUM (resource leak affecting power management, no
crash).

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit:** Fixes a real resource leak on error paths, improves power
  management reliability.
- **Risk:** Very low — 4 lines added, only on error paths, mirrors
  existing cleanup patterns.
- **Ratio:** Favorable. Even though the trigger is uncommon, the fix is
  trivially safe.

Record: Benefit outweighs risk. Minimal fix with no regression
potential.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILATION
**FOR backporting:**
- Fixes a real clock resource leak (missing `clk_disable_unprepare()` on
  error paths)
- Extremely small and surgical (4 lines, single file, single function)
- Obviously correct — mirrors existing cleanup pattern in the same
  function
- Bug has existed since v4.13-rc1 (2017), affects all stable trees
- Reviewed by Intel ASoC developer, merged by subsystem maintainer
- No dependencies, self-contained
- No regression risk

**AGAINST backporting:**
- No user reports of the issue (code-inspection find)
- Trigger requires error conditions that are uncommon in normal
  operation
- Driver-specific (not core kernel)

### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** — reviewed by Intel developer,
   merged by maintainer
2. Fixes a real bug? **YES** — clock resource leak on error paths
3. Important issue? **MEDIUM** — resource leak, not a crash
4. Small and contained? **YES** — 4 lines, single file
5. No new features or APIs? **YES** — only adds cleanup calls
6. Can apply to stable? **YES** — code unchanged since introduction

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

### Step 9.4: DECISION
This is a small, obvious, and safe fix for a real resource leak. The fix
adds missing `clk_disable_unprepare()` calls on two error paths where
the clock was already enabled. It's reviewed by the right people, has no
dependencies, and applies to all stable trees.

## Verification

- [Phase 1] Parsed tags: Reviewed-by Cezary Rojewski (Intel), merged by
  Mark Brown (ASoC maintainer)
- [Phase 2] Diff analysis: 4 lines added, two `if (ctx->mclk)
  clk_disable_unprepare(ctx->mclk)` blocks on error paths
- [Phase 3] git blame: buggy code introduced in c25695ae88ce26
  (v4.13-rc1, 2017), present in all stable trees
- [Phase 3] git show c25695ae88ce26: confirmed original commit added
  MCLK handling without error path cleanup
- [Phase 3] git describe --contains c25695ae88ce26:
  v4.13-rc1~142^2~1^2~5^2~8 — confirmed it's been in mainline since
  v4.13
- [Phase 3] git log --oneline -20 -- file: no prior MCLK leak fix found
- [Phase 4] b4 dig: could not find commit by message-id in local tree;
  lore blocked by bot protection
- [Phase 5] DAPM widget registration at lines 114-116 confirms
  `platform_clock_control` is called on every audio stream start/stop
- [Phase 5] DAPM routes at lines 130-133 confirm all audio paths depend
  on Platform Clock
- [Phase 5] Grep for clk_disable_unprepare in sibling drivers confirms
  the same cleanup pattern is expected
- [Phase 6] Code at the fix site is essentially unchanged since
  c25695ae88ce26 — clean apply expected
- [Phase 8] Failure mode: clock resource leak preventing proper power
  management, severity MEDIUM
- UNVERIFIED: Could not access lore.kernel.org discussion for reviewer
  commentary on stable suitability

**YES**

 sound/soc/intel/boards/cht_bsw_rt5672.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/sound/soc/intel/boards/cht_bsw_rt5672.c b/sound/soc/intel/boards/cht_bsw_rt5672.c
index 359723f2700e4..57d6997eb12ff 100644
--- a/sound/soc/intel/boards/cht_bsw_rt5672.c
+++ b/sound/soc/intel/boards/cht_bsw_rt5672.c
@@ -77,6 +77,8 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w,
 				CHT_PLAT_CLK_3_HZ, 48000 * 512);
 		if (ret < 0) {
 			dev_err(card->dev, "can't set codec pll: %d\n", ret);
+			if (ctx->mclk)
+				clk_disable_unprepare(ctx->mclk);
 			return ret;
 		}
 
@@ -85,6 +87,8 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w,
 			48000 * 512, SND_SOC_CLOCK_IN);
 		if (ret < 0) {
 			dev_err(card->dev, "can't set codec sysclk: %d\n", ret);
+			if (ctx->mclk)
+				clk_disable_unprepare(ctx->mclk);
 			return ret;
 		}
 	} else {
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ASoC: codecs: wcd-clsh: Always update buck/flyback on transitions on transitions

[Sasha Levin]

From: Cédric Bellegarde <cedric.bellegarde@adishatz.org>

[ Upstream commit f8d51e903a6c97d8d298f14d9f8b4fff808670e3 ]

The WCD934x audio outputs (earpiece, headphone, speaker) share two power
supply converters, a buck and a flyback, managed by reference counters
(buck_users, flyback_users) in the Class-H controller.

The early return in wcd_clsh_ctrl_set_state() when nstate == ctrl->state
prevented _wcd_clsh_ctrl_set_state() from being called when switching
between outputs sharing the same state value. As a result, the buck and
flyback reference counters were never decremented on disable, leaving the
converters active and their counters out of sync with the actual hardware
state.

This caused audible distortion on the earpiece output and spurious MBHC
over-current protection interrupts on HPHL/HPHR during output switching.

Remove the early return so that CLSH_REQ_ENABLE and CLSH_REQ_DISABLE are
always dispatched, keeping the buck and flyback reference counters
consistent on every state transition.

Signed-off-by: Cédric Bellegarde <cedric.bellegarde@adishatz.org>
Link: https://patch.msgid.link/20260304141006.280894-1-cedric.bellegarde@adishatz.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem:** ASoC: codecs: wcd-clsh
- **Action verb:** "Always update" (implies something was incorrectly
  not being updated = bug fix)
- **Summary:** Remove an incorrect early return that prevented
  buck/flyback power supply reference counters from being updated during
  audio output transitions.

### Step 1.2: Tags
- **Signed-off-by:** Cédric Bellegarde (author)
- **Link:** https://patch.msgid.link/20260304141006.280894-1-
  cedric.bellegarde@adishatz.org
- **Signed-off-by:** Mark Brown (ASoC maintainer, applied the patch)
- No Fixes: tag, no Reported-by, no Cc: stable — all expected for
  candidate review.

### Step 1.3: Commit Body Analysis
The commit message is detailed and clearly explains:
- **Bug:** Early return in `wcd_clsh_ctrl_set_state()` when `nstate ==
  ctrl->state` prevented `_wcd_clsh_ctrl_set_state()` from being called
  during disable transitions.
- **Root cause:** Each audio output (earpiece, HPHL, HPHR) calls
  `set_state` with the same `nstate` for both enable (PRE_DAC) and
  disable (POST_PA). The early return silently skips the disable call.
- **Symptom:** Buck/flyback reference counters never decremented →
  converters left active → audible distortion on earpiece + spurious
  MBHC over-current interrupts on HPHL/HPHR.
- **Fix:** Remove the 3-line early return.

### Step 1.4: Hidden Bug Fix?
No — this is explicitly described as a bug fix with clear user-visible
symptoms. The commit message thoroughly explains the bug mechanism.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed:** 1 (`sound/soc/codecs/wcd-clsh-v2.c`)
- **Lines:** -3, +0 (pure deletion)
- **Function modified:** `wcd_clsh_ctrl_set_state()`
- **Scope:** Single-file, surgical fix

### Step 2.2: Code Flow Change
**Before:** When `nstate == ctrl->state`, the function returns
immediately without calling `_wcd_clsh_ctrl_set_state()`. This means
neither CLSH_REQ_ENABLE nor CLSH_REQ_DISABLE is dispatched.

**After:** The function always proceeds to the switch on `clsh_event`,
dispatching either CLSH_REQ_ENABLE or CLSH_REQ_DISABLE to
`_wcd_clsh_ctrl_set_state()`.

### Step 2.3: Bug Mechanism
This is a **reference counting bug**. Looking at the actual call pattern
in wcd934x.c:

1. **Enable EAR** (PRE_PMU): `set_state(ctrl, PRE_DAC,
   WCD_CLSH_STATE_EAR, CLS_H_NORMAL)` → state=EAR, buck_users++,
   flyback_users++
2. **Disable EAR** (POST_PMD): `set_state(ctrl, POST_PA,
   WCD_CLSH_STATE_EAR, CLS_H_NORMAL)` → nstate=EAR == ctrl->state=EAR →
   **EARLY RETURN!** Buck/flyback never decremented.

The same pattern affects ALL outputs (HPHL, HPHR, LO, AUX) across ALL
WCD codec drivers (wcd9335, wcd934x, wcd937x, wcd938x, wcd939x).

### Step 2.4: Fix Quality
- **Obviously correct:** Yes. The early return was clearly wrong — the
  function uses `clsh_event` (enable vs disable) to dispatch different
  operations, and the early return bypasses this dispatch.
- **Minimal/surgical:** Maximum surgical — 3-line deletion.
- **Regression risk:** Very low. The removed check was a premature
  optimization that incorrectly assumed same nstate means no-op. The
  `_wcd_clsh_ctrl_set_state` sub-functions use reference counting
  (buck_users, flyback_users) which already handles idempotency
  correctly.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The buggy early return at line 851-852 was introduced in commit
`cc2e324d39b26` ("ASoC: wcd9335: add CLASS-H Controller support") by
Srinivas Kandagatla, merged in **v5.1-rc1**. This code has been present
since the initial creation of the file.

### Step 3.2: Fixes Tag
No Fixes: tag present. However, the bug was clearly introduced by
`cc2e324d39b26` (v5.1-rc1).

### Step 3.3: File History
9 commits to `wcd-clsh-v2.c` since initial creation. Changes have been
minor: unused function removal, new codec version support, symbol
renaming, GENMASK fixes. No prior fix to this early return logic.

### Step 3.4: Author
Cédric Bellegarde has one other commit in the tree (ASoC: qcom: q6asm:
drop DSP responses for closed data streams). Not the subsystem
maintainer, but the patch was accepted by Mark Brown (ASoC maintainer).

### Step 3.5: Dependencies
None. This is a standalone 3-line deletion with no dependencies on other
patches.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Original Discussion
Found via web search at yhbt.net/lore mirror. The patch was submitted on
2026-03-04 and applied by Mark Brown on 2026-03-16 to `broonie/sound
for-7.1` (commit `f8d51e903a6c`).

### Step 4.2: Reviewer Feedback
Mark Brown applied directly with no review comments or objections — a
clean accept from the ASoC subsystem maintainer. No NAKs or concerns
raised.

### Step 4.3: Bug Report
No separate bug report; the author discovered this through direct
debugging (audio distortion and spurious interrupts during output
switching).

### Step 4.4: Series Context
Single standalone patch, not part of any series.

### Step 4.5: Stable Discussion
No stable-specific discussion found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Modified Function
`wcd_clsh_ctrl_set_state()` — exported function, the main API for the
Class-H controller.

### Step 5.2: Callers
`wcd_clsh_ctrl_set_state()` is called from **5 different WCD codec
drivers**:
- `wcd9335.c` — 8 call sites (EAR, HPHL, HPHR, LO)
- `wcd934x.c` — 8 call sites (EAR, HPHL, HPHR, LO)
- `wcd937x.c` — 8 call sites (EAR, HPHL, HPHR, AUX)
- `wcd938x.c` — 10 call sites (EAR, HPHL, HPHR, AUX)
- `wcd939x.c` — 6 call sites (EAR, HPHL, HPHR)

All follow the same pattern: PRE_DAC enable on PMU, POST_PA disable on
PMD.

### Step 5.3-5.4: Call Chain
These are called from DAPM widget event handlers, triggered during
normal audio routing changes. Every user who plays audio through
earpiece, headphones, or speaker on a Qualcomm WCD93xx-based device
triggers this code path.

### Step 5.5: Similar Patterns
The reference counting pattern in `wcd_clsh_buck_ctrl()` and
`wcd_clsh_flyback_ctrl()` (and v3 variants) all use increment-on-
enable/decrement-on-disable with `buck_users`/`flyback_users`. The early
return prevented the decrement path from ever executing.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable
The bug was introduced in `cc2e324d39b26` (v5.1-rc1). This code exists
in **all active stable trees**: 5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y,
and any other LTS/stable branches.

### Step 6.2: Backport Complications
The file has had only minor changes (renaming, cleanup). The patch is a
simple 3-line deletion that should apply cleanly to all stable trees.

### Step 6.3: Related Fixes
No prior fix for this issue in any stable tree.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem
- **Path:** sound/soc/codecs/
- **Subsystem:** ASoC (Audio System on Chip) — audio codec drivers
- **Criticality:** IMPORTANT — affects audio on all Qualcomm WCD93xx
  codec-based phones and devices (many Android devices, some embedded
  systems)

### Step 7.2: Activity
Moderately active subsystem with steady fixes and improvements.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
All users of Qualcomm WCD93xx-series audio codecs (WCD9335, WCD934x,
WCD937x, WCD938x, WCD939x). This includes many Android phones and
Qualcomm-based embedded systems.

### Step 8.2: Trigger Conditions
- **Trigger:** Any normal audio output switching (e.g., call on
  earpiece, then play music through headphones) — extremely common
  operation.
- **Unprivileged trigger:** Yes — any userspace audio playback triggers
  this.

### Step 8.3: Failure Mode Severity
- **Audible distortion** on earpiece — MEDIUM-HIGH (user-perceivable
  audio quality issue)
- **Spurious MBHC over-current interrupts** — MEDIUM (can cause spurious
  headphone detection events)
- **Power supply reference counter leak** — MEDIUM (converters left
  active, wasted power, potential for undefined hardware behavior)
- Overall severity: **HIGH** — directly affects audio functionality

### Step 8.4: Risk-Benefit Ratio
- **Benefit:** HIGH — fixes audio distortion and spurious interrupts on
  a wide class of devices, bug present since v5.1
- **Risk:** VERY LOW — 3-line deletion, obviously correct, no regression
  risk (the removed check was always wrong)
- **Ratio:** Very favorable for backporting

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Compilation

**FOR backporting:**
- Fixes a real, user-visible bug: audio distortion and spurious
  interrupts
- Reference counting bug — buck/flyback users never decremented on
  disable
- Affects ALL WCD93xx codec users (5 codec drivers, ~40 call sites)
- Bug present since v5.1-rc1 — affects all active stable trees
- Fix is minimal: 3-line deletion, obviously correct
- Applied by ASoC maintainer Mark Brown with no concerns
- No dependencies — standalone fix
- Will apply cleanly to all stable trees

**AGAINST backporting:**
- No Fixes: tag (expected — that's why it's under manual review)
- Author is not the subsystem maintainer
- No formal Reported-by (author found it themselves)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — 3-line deletion, logic
   clearly wrong, applied by maintainer
2. **Fixes a real bug?** YES — audio distortion, spurious interrupts,
   reference counter leak
3. **Important issue?** YES — user-perceivable audio quality degradation
   on common hardware
4. **Small and contained?** YES — 3 lines removed from 1 file, 1
   function
5. **No new features or APIs?** YES — pure bug fix
6. **Can apply to stable?** YES — clean apply expected

### Step 9.3: Exception Categories
Not applicable — this is a straightforward bug fix, not an exception
category.

### Step 9.4: Decision
This is a clear, minimal fix for a real reference counting bug that
causes audible audio distortion on all Qualcomm WCD93xx codec-based
devices. The bug has existed since v5.1. The fix is a 3-line deletion
that is obviously correct and was accepted by the ASoC maintainer.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by (author + Mark Brown), Link to
  patch.msgid.link
- [Phase 2] Diff analysis: 3 lines removed from
  `wcd_clsh_ctrl_set_state()`, removes incorrect early return
- [Phase 2] Verified bug mechanism: PRE_DAC sets state=EAR, POST_PA
  passes same nstate=EAR, early return prevents DISABLE dispatch
- [Phase 2] Verified reference counting: `wcd_clsh_buck_ctrl()` (line
  182-183) and `wcd_clsh_flyback_ctrl()` (line 231-232) use
  increment/decrement of `buck_users`/`flyback_users`
- [Phase 3] git blame: buggy code introduced in cc2e324d39b26 (v5.1-rc1)
  — present since file creation
- [Phase 3] git log: only 9 commits to this file since creation, no
  prior fix for this issue
- [Phase 4] Found original submission at yhbt.net lore mirror: single
  patch, clean accept by Mark Brown for-7.1
- [Phase 4] No NAKs, no review concerns raised
- [Phase 5] Verified callers: 5 codec drivers (wcd9335, wcd934x,
  wcd937x, wcd938x, wcd939x), ~40 call sites, all follow enable/disable
  pattern
- [Phase 6] Code exists in all active stable trees (v5.1+)
- [Phase 6] File has minimal changes — clean apply expected
- [Phase 8] Failure mode: audio distortion + spurious interrupts,
  severity HIGH

**YES**

 sound/soc/codecs/wcd-clsh-v2.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/sound/soc/codecs/wcd-clsh-v2.c b/sound/soc/codecs/wcd-clsh-v2.c
index 13d07296916f6..62ca22ea0f3b6 100644
--- a/sound/soc/codecs/wcd-clsh-v2.c
+++ b/sound/soc/codecs/wcd-clsh-v2.c
@@ -848,9 +848,6 @@ int wcd_clsh_ctrl_set_state(struct wcd_clsh_ctrl *ctrl,
 {
 	struct snd_soc_component *comp = ctrl->comp;
 
-	if (nstate == ctrl->state)
-		return 0;
-
 	if (!wcd_clsh_is_state_valid(nstate)) {
 		dev_err(comp->dev, "Class-H not a valid new state:\n");
 		return -EINVAL;
-- 
2.53.0

[PATCH AUTOSEL 6.18] ALSA:usb:qcom: add AUXILIARY_BUS to Kconfig dependencies

[Sasha Levin]

From: Frank Zhang <rmxpzlb@gmail.com>

[ Upstream commit b8bee48e38f2ddbdba5e58bc54ef54bb7d8d341b ]

The build can fail with:

ERROR: modpost: "__auxiliary_driver_register"
[sound/usb/qcom/snd-usb-audio-qmi.ko] undefined!
ERROR: modpost: "auxiliary_driver_unregister"
[sound/usb/qcom/snd-usb-audio-qmi.ko] undefined!

Select AUXILIARY_BUS when SND_USB_AUDIO_QMI is enabled.

Signed-off-by: Frank Zhang <rmxpzlb@gmail.com>
Link: https://patch.msgid.link/20260317102527.556248-1-rmxpzlb@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 sound/usb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/usb/Kconfig b/sound/usb/Kconfig
index 9b890abd96d34..b4588915efa11 100644
--- a/sound/usb/Kconfig
+++ b/sound/usb/Kconfig
@@ -192,6 +192,7 @@ config SND_USB_AUDIO_QMI
 	tristate "Qualcomm Audio Offload driver"
 	depends on QCOM_QMI_HELPERS && SND_USB_AUDIO && SND_SOC_USB
 	depends on USB_XHCI_HCD && USB_XHCI_SIDEBAND
+	select AUXILIARY_BUS
 	help
 	  Say Y here to enable the Qualcomm USB audio offloading feature.
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] ASoC: SDCA: Fix overwritten var within for loop

[Sasha Levin]

From: Maciej Strozek <mstrozek@opensource.cirrus.com>

[ Upstream commit 23e0cbe55736de222ed975863cf06baf29bee5fe ]

mask variable should not be overwritten within the for loop or it will
skip certain bits. Change to using BIT() macro.

Fixes: b9ab3b618241 ("ASoC: SDCA: Add some initial IRQ handlers")
Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260408093835.2881486-2-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 sound/soc/sdca/sdca_interrupts.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/sound/soc/sdca/sdca_interrupts.c b/sound/soc/sdca/sdca_interrupts.c
index f83413587da5a..4189efdfe2747 100644
--- a/sound/soc/sdca/sdca_interrupts.c
+++ b/sound/soc/sdca/sdca_interrupts.c
@@ -104,9 +104,7 @@ static irqreturn_t function_status_handler(int irq, void *data)
 
 	status = val;
 	for_each_set_bit(mask, &status, BITS_PER_BYTE) {
-		mask = 1 << mask;
-
-		switch (mask) {
+		switch (BIT(mask)) {
 		case SDCA_CTL_ENTITY_0_FUNCTION_NEEDS_INITIALIZATION:
 			//FIXME: Add init writes
 			break;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.19] ASoC: sdw_utils: Add CS42L43B codec info

[Sasha Levin]

From: Maciej Strozek <mstrozek@opensource.cirrus.com>

[ Upstream commit 3e314fde2304b328929c471a70906bc5968f9dcf ]

Add codec_info for a new variant of CS42L43. It can resue existing info
but needs a new part_id.

Signed-off-by: Maciej Strozek <mstrozek@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260306152829.3130530-2-mstrozek@opensource.cirrus.com
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
Record: [ASoC: sdw_utils] [Add] [CS42L43B codec info entry to
codec_info_list]

**Step 1.2: Tags**
- Signed-off-by: Maciej Strozek (Cirrus Logic engineer, author)
- Reviewed-by: Charles Keepax (Cirrus Logic, subsystem expert)
- Tested-by: Charles Keepax (verified the fix works)
- Link: patch.msgid.link for original submission
- Signed-off-by: Mark Brown (ASoC maintainer, applied the patch)

Record: Reviewed AND tested by Charles Keepax (Cirrus Logic), applied by
ASoC maintainer Mark Brown. No Fixes tag (expected). No syzbot.

**Step 1.3: Body Text**
The message says: "Add codec_info for a new variant of CS42L43. It can
reuse existing info but needs a new part_id." This is adding a device ID
(part_id = 0x2A3B) for a hardware variant of the existing CS42L43 codec.

Record: New hardware variant CS42L43B needs a new part_id entry. Reuses
existing callbacks and configuration.

**Step 1.4: Hidden Bug Fix Detection**
At face value this is a device ID addition, not a "hidden" bug fix.
However, as I'll show in Phase 6, the ACPI match tables referencing
CS42L43B are already in v7.0, making this missing entry cause audio
probe failure on affected systems.

Record: This is a device ID addition that also fixes a functional gap
(ACPI tables present but codec_info missing).

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files changed: `sound/soc/sdw_utils/soc_sdw_utils.c`
- Lines added: ~54 lines (all data, no code logic)
- Lines removed: 0
- Functions modified: None; the change is within the `codec_info_list[]`
  static array initializer
- Scope: single-file, purely additive data entry

Record: 1 file, +54 lines of struct data, 0 removed, purely data.

**Step 2.2: Code Flow Change**
The diff adds a new `codec_info_list[]` entry with `.part_id = 0x2A3B`
between the existing CS42L43 entry (0x4243) and the CS42L45 entry
(0x4245). The new entry is structurally identical to the CS42L43 entry —
same name_prefix, same sidecar functions, same 4 DAIs with same
callbacks, same quirks. The only difference is `.part_id = 0x2A3B`.

Record: Before: no entry for 0x2A3B; After: new entry identical to
0x4243 but with part_id 0x2A3B.

**Step 2.3: Bug Mechanism**
This is category (h) — Hardware workaround / Device ID addition. The new
`part_id = 0x2A3B` is the SoundWire equivalent of a PCI/USB device ID,
enabling the CS42L43B hardware variant to be matched by
`asoc_sdw_find_codec_info_part()`.

Record: Device ID addition (new part_id for SoundWire codec variant).

**Step 2.4: Fix Quality**
- The data is an exact copy of the existing 0x4243 entry with only
  part_id changed
- All referenced callbacks (`asoc_sdw_cs42l43_hs_rtd_init`,
  `asoc_sdw_cs42l43_spk_init`, etc.) already exist
- No new code logic, no new functions, no API changes
- Regression risk: essentially zero (only affects systems with CS42L43B
  hardware)

Record: Trivially correct, minimal regression risk. Pure data addition.

---

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The existing CS42L43 entry (0x4243) was introduced in commit
`e377c94773171e` by Vijendar Mukunda on 2024-08-01, when the
codec_info_list was moved from Intel SOF to common sdw_utils. This file
has been in the tree since v6.12.

Record: File created v6.12 (2024-08-01). CS42L43 entry (0x4243) has been
stable since then.

**Step 3.2: No Fixes tag** — expected, N/A.

**Step 3.3: File History**
Recent changes to this file are mostly additions of new codec entries
and minor fixes. The file is actively maintained as new codecs and
variants are added.

Record: Active file with frequent codec_info additions. No conflicts
expected.

**Step 3.4: Author Context**
Maciej Strozek is a Cirrus Logic engineer, a regular contributor to the
CS42L43/CS42L45 codec subsystem. He has ~10 recent commits in the sound
subsystem.

Record: Author is domain expert at Cirrus Logic, the vendor of this
codec.

**Step 3.5: Dependencies**
The critical dependency is the ACPI match entries for CS42L43B. These
exist in:
- `sound/soc/amd/acp/amd-acp70-acpi-match.c` (commit `ddd9bf2212ab8`,
  2026-01-27) — **already in v7.0**
- `sound/soc/amd/acp/amd-acp63-acpi-match.c` (commit `fd13fc700e3e2`,
  2026-02-24) — **already in v7.0**

Both ACPI match tables reference `0x00003101FA2A3B01ull` which encodes
part_id 0x2A3B. These are already in the stable tree. Without this
codec_info entry, the ACPI match succeeds but the codec configuration
lookup fails.

Record: Dependencies are MET — ACPI match tables for cs42l43b already in
v7.0.

---

## PHASE 4: MAILING LIST

**Step 4.1-4.5:**
b4 dig could not find the commit (likely the Message-ID format didn't
match expectations). Lore was protected by anti-scraping. However, the
commit itself documents the review chain: Reviewed-by and Tested-by from
Charles Keepax, applied by Mark Brown. This is the standard ASoC review
process.

Record: Could not fetch lore discussion due to anti-scraping protection.
The commit tags show proper review process.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Key Functions**
No functions are modified. The change is in the static
`codec_info_list[]` array.

**Step 5.2: Callers of `asoc_sdw_find_codec_info_part()`**
This function is called at two critical points:
- Line 1366: `asoc_sdw_count_sdw_endpoints()` — if it returns NULL,
  returns `-EINVAL`, causing the entire endpoint counting to fail
- Line 1526: the DAI link creation path — if it returns NULL, returns
  `-EINVAL`, causing the machine driver probe to fail

Record: Without a matching codec_info entry, the machine driver probe
fails with -EINVAL. Audio is completely non-functional on affected
systems.

**Step 5.3-5.5:** N/A — no new code logic to trace.

---

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable Trees**
The `codec_info_list[]` array exists in v7.0 (file created in v6.12).
The ACPI match tables for cs42l43b are already in v7.0 (`ddd9bf2212ab8`
and `fd13fc700e3e2` both verified as ancestors of v7.0). This means v7.0
stable already has systems defined that use CS42L43B hardware, but the
codec_info entry for part_id 0x2A3B is MISSING.

Record: The gap exists in v7.0 — ACPI tables reference CS42L43B but
codec_info_list lacks the entry.

**Step 6.2: Backport Complications**
The patch is purely additive data into a well-defined array. It should
apply cleanly.

Record: Clean apply expected.

**Step 6.3:** No prior fix for this issue.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1:** ASoC / SoundWire machine driver support — IMPORTANT
subsystem. Audio is a core user-facing feature.
**Step 7.2:** Actively maintained with frequent additions.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who is Affected**
Users with AMD ACP63 or ACP70 platforms that have CS42L43B audio codec
hardware. These are real laptop configurations defined in the ACPI match
tables already in v7.0.

**Step 8.2: Trigger Conditions**
Boot any system with CS42L43B hardware → audio subsystem probes → ACPI
match succeeds → codec_info lookup fails → `-EINVAL` → no audio. This is
100% reproducible on affected hardware.

**Step 8.3: Failure Mode**
Machine driver probe failure (returns -EINVAL). Complete audio loss on
affected systems. Severity: **HIGH** — audio is a fundamental feature.

**Step 8.4: Risk-Benefit**
- Benefit: HIGH — enables audio on affected hardware; fixes complete
  functional failure
- Risk: VERY LOW — purely additive data, identical to existing proven
  entry, only part_id differs
- Ratio: Strongly favorable

---

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Device ID addition to existing driver (explicit stable exception)
- ACPI match tables referencing this hardware are ALREADY in v7.0
- Without this, audio probe fails with -EINVAL on affected systems
- Purely data — no new code paths, no new logic
- Exact copy of existing, proven CS42L43 entry with only part_id changed
- Reviewed AND tested by Cirrus Logic domain expert
- Applied by ASoC maintainer Mark Brown
- Zero regression risk (only affects cs42l43b hardware)

**Evidence AGAINST backporting:**
- No explicit Fixes: tag or Cc: stable (expected for autosel candidates)
- 54 lines rather than single-line ID addition (but all data, no code)
- Commit message doesn't describe a "bug" — describes hardware
  enablement

**Stable Rules Checklist:**
1. Obviously correct and tested? **YES** — exact copy of existing entry,
   tested by reviewer
2. Fixes a real bug? **YES** — audio probe failure on hardware already
   matched by ACPI tables in v7.0
3. Important? **YES** — complete audio loss
4. Small and contained? **YES** — 54 lines of data in one file
5. No new features or APIs? **YES** — just a device ID
6. Can apply to stable? **YES** — clean apply expected

**Exception Category:** Device ID addition to existing driver.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by + Tested-by from Charles Keepax
  (Cirrus), applied by Mark Brown (ASoC maintainer)
- [Phase 2] Diff analysis: +54 lines, all struct data, new
  `codec_info_list[]` entry with `.part_id = 0x2A3B`, identical to
  existing 0x4243 entry
- [Phase 3] git blame: CS42L43 entry (0x4243) introduced in
  e377c94773171e (v6.12, 2024-08-01), present in v7.0
- [Phase 3] git merge-base: ddd9bf2212ab8 (ACP70 cs42l43b ACPI match) IS
  ancestor of v7.0 — confirmed
- [Phase 3] git merge-base: fd13fc700e3e2 (ACP63 cs42l43b ACPI match) IS
  ancestor of v7.0 — confirmed
- [Phase 4] b4 dig failed to find match; lore anti-scraping blocked web
  fetch
- [Phase 5] Verified call sites: `asoc_sdw_find_codec_info_part()`
  returns NULL for unknown part_id → callers return -EINVAL → probe
  failure
- [Phase 5] Read lines 1366-1368 and 1526-1528: confirmed NULL → -EINVAL
  return path
- [Phase 6] ACPI match tables reference `0x00003101FA2A3B01ull` (part_id
  0x2A3B) already in v7.0
- [Phase 6] codec_info_list lacks 0x2A3B entry in v7.0 — confirmed via
  grep
- [Phase 8] Failure mode: probe returns -EINVAL → complete audio loss on
  cs42l43b systems, severity HIGH

The ACPI match tables already in v7.0 promise CS42L43B support, but
without this codec_info entry, the machine driver probe fails. This is a
device ID addition that fixes complete audio failure on affected AMD
laptop platforms.

**YES**

 sound/soc/sdw_utils/soc_sdw_utils.c | 54 +++++++++++++++++++++++++++++
 1 file changed, 54 insertions(+)

diff --git a/sound/soc/sdw_utils/soc_sdw_utils.c b/sound/soc/sdw_utils/soc_sdw_utils.c
index 0e67d9f34cba3..4f9089b2a9f84 100644
--- a/sound/soc/sdw_utils/soc_sdw_utils.c
+++ b/sound/soc/sdw_utils/soc_sdw_utils.c
@@ -723,6 +723,60 @@ struct asoc_sdw_codec_info codec_info_list[] = {
 		},
 		.dai_num = 4,
 	},
+	{
+		.part_id = 0x2A3B,
+		.name_prefix = "cs42l43",
+		.count_sidecar = asoc_sdw_bridge_cs35l56_count_sidecar,
+		.add_sidecar = asoc_sdw_bridge_cs35l56_add_sidecar,
+		.dais = {
+			{
+				.direction = {true, false},
+				.codec_name = "cs42l43-codec",
+				.dai_name = "cs42l43-dp5",
+				.dai_type = SOC_SDW_DAI_TYPE_JACK,
+				.dailink = {SOC_SDW_JACK_OUT_DAI_ID, SOC_SDW_UNUSED_DAI_ID},
+				.rtd_init = asoc_sdw_cs42l43_hs_rtd_init,
+				.controls = generic_jack_controls,
+				.num_controls = ARRAY_SIZE(generic_jack_controls),
+				.widgets = generic_jack_widgets,
+				.num_widgets = ARRAY_SIZE(generic_jack_widgets),
+			},
+			{
+				.direction = {false, true},
+				.codec_name = "cs42l43-codec",
+				.dai_name = "cs42l43-dp1",
+				.dai_type = SOC_SDW_DAI_TYPE_MIC,
+				.dailink = {SOC_SDW_UNUSED_DAI_ID, SOC_SDW_DMIC_DAI_ID},
+				.rtd_init = asoc_sdw_cs42l43_dmic_rtd_init,
+				.widgets = generic_dmic_widgets,
+				.num_widgets = ARRAY_SIZE(generic_dmic_widgets),
+				.quirk = SOC_SDW_CODEC_MIC,
+				.quirk_exclude = true,
+			},
+			{
+				.direction = {false, true},
+				.codec_name = "cs42l43-codec",
+				.dai_name = "cs42l43-dp2",
+				.dai_type = SOC_SDW_DAI_TYPE_JACK,
+				.dailink = {SOC_SDW_UNUSED_DAI_ID, SOC_SDW_JACK_IN_DAI_ID},
+			},
+			{
+				.direction = {true, false},
+				.codec_name = "cs42l43-codec",
+				.dai_name = "cs42l43-dp6",
+				.dai_type = SOC_SDW_DAI_TYPE_AMP,
+				.dailink = {SOC_SDW_AMP_OUT_DAI_ID, SOC_SDW_UNUSED_DAI_ID},
+				.init = asoc_sdw_cs42l43_spk_init,
+				.rtd_init = asoc_sdw_cs42l43_spk_rtd_init,
+				.controls = generic_spk_controls,
+				.num_controls = ARRAY_SIZE(generic_spk_controls),
+				.widgets = generic_spk_widgets,
+				.num_widgets = ARRAY_SIZE(generic_spk_widgets),
+				.quirk = SOC_SDW_CODEC_SPKR | SOC_SDW_SIDECAR_AMPS,
+			},
+		},
+		.dai_num = 4,
+	},
 	{
 		.part_id = 0x4245,
 		.name_prefix = "cs42l45",
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] ASoC: mxs-sgtl5000: disable MCLK on error paths of mxs_sgtl5000_probe()

[Sasha Levin]

From: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>

[ Upstream commit c8ef13d692f19cdbbf195fb845421a5b71801704 ]

Call mxs_saif_put_mclk() to disable MCLK on error
paths of mxs_sgtl5000_probe().

Signed-off-by: Haoxiang Li <lihaoxiang@isrc.iscas.ac.cn>
Link: https://patch.msgid.link/20260401053051.586290-1-lihaoxiang@isrc.iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a complete picture. Let me compile the full analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `ASoC: mxs-sgtl5000`
- Action verb: "disable" (implies fixing a missing cleanup)
- Summary: Disable MCLK on error paths of `mxs_sgtl5000_probe()`
- Record: [ASoC/mxs-sgtl5000] [disable/fix] [Add missing
  mxs_saif_put_mclk() on probe error paths]

**Step 1.2: Tags**
- Signed-off-by: Haoxiang Li (author) - a contributor focused on error-
  path resource leak fixes
- Link: `https://patch.msgid.link/20260401053051.586290-1-
  lihaoxiang@isrc.iscas.ac.cn`
- Signed-off-by: Mark Brown (ASoC maintainer applied the patch)
- No Fixes: tag, no Reported-by, no Cc: stable (expected for review
  candidates)

**Step 1.3: Commit Body**
The message is concise: call `mxs_saif_put_mclk()` to disable MCLK on
error paths. The bug is a resource leak - `mxs_saif_get_mclk()` enables
a hardware clock, and if probe fails after that point, the clock remains
enabled.

**Step 1.4: Hidden Bug Fix Detection**
This IS a resource leak fix. The wording "disable MCLK on error paths"
is a classic resource-leak-on-error-path fix pattern.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `sound/soc/mxs/mxs-sgtl5000.c`
- 2 lines added: two `mxs_saif_put_mclk(0)` calls + braces adjustment
- Functions modified: `mxs_sgtl5000_probe()`
- Scope: single-file surgical fix

**Step 2.2: Code Flow Change**
Two error paths are fixed:

1. **`snd_soc_of_parse_audio_routing()` failure** (line 160): BEFORE:
   returned directly without disabling MCLK. AFTER: calls
   `mxs_saif_put_mclk(0)` before returning.

2. **`devm_snd_soc_register_card()` failure** (line 165): BEFORE:
   returned directly without disabling MCLK. AFTER: calls
   `mxs_saif_put_mclk(0)` before returning.

**Step 2.3: Bug Mechanism**
Category: **Error path / resource leak fix**.

`mxs_saif_get_mclk()` at line 144:
- Calls `__mxs_saif_get_mclk()` which sets `saif->mclk_in_use = 1`
- Calls `clk_prepare_enable(saif->clk)` to enable the hardware clock
- Writes to SAIF_CTRL to enable MCLK output

When probe fails after this, `mxs_saif_put_mclk()` (which disables the
clock, clears MCLK output, and sets `mclk_in_use = 0`) is never called.
The `remove()` callback only runs if `probe()` succeeded.

**Step 2.4: Fix Quality**
- Obviously correct: mirrors the cleanup done in `mxs_sgtl5000_remove()`
- Minimal/surgical: only 2 meaningful lines added
- Regression risk: essentially zero - only affects error paths
- The fix follows the exact same pattern as the existing `remove()`
  function

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame Analysis**
- The `mxs_saif_get_mclk()` call was introduced in the original driver
  commit `fcb5e47eff29a1` (2011, v3.2). So the register_card error-path
  leak has existed since 2011.
- The audio-routing error path was introduced by `949293d45d6b09` (2018,
  v4.16) which added `snd_soc_of_parse_audio_routing()` without cleanup
  on failure.
- Both error paths predate all active stable trees.

**Step 3.2: No Fixes: tag** (expected for review candidates)

**Step 3.3: Related Changes**
- `6ae0a4d8fec55` (2022): Fixed a different resource leak (of_node_put)
  in the same probe function - shows this function has a history of
  incomplete error handling.
- `7a17f6a95a613` (2021): Switched to `dev_err_probe()` for
  register_card failure.

**Step 3.4: Author Context**
Haoxiang Li is a prolific error-path/resource-leak fix contributor.
Their commit history shows many similar fixes across kernel subsystems
(PCI, SCSI, media, DRM, clock, bus drivers).

**Step 3.5: Dependencies**
No dependencies. The fix only adds `mxs_saif_put_mclk(0)` calls, which
has existed since the driver was created. Should apply cleanly to all
stable trees.

## PHASE 4: MAILING LIST RESEARCH

Lore was not accessible due to bot protection. However:
- The patch was accepted by Mark Brown (ASoC subsystem maintainer)
  directly
- The Link tag points to the original submission
- Single-version submission (no v2/v3), suggesting it was
  straightforward

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
Only `mxs_sgtl5000_probe()` is modified.

**Step 5.2: Resource Chain**
- `mxs_saif_get_mclk()` → `__mxs_saif_get_mclk()` → sets
  `mclk_in_use=1`, clears CLKGATE, configures clock rate →
  `clk_prepare_enable()` → writes SAIF_CTRL to enable MCLK RUN
- `mxs_saif_put_mclk()` → `clk_disable_unprepare()` → sets CLKGATE →
  clears RUN → `mclk_in_use=0`

Without the fix, on error: clock stays enabled, hardware MCLK output
stays active, `mclk_in_use` remains 1 (preventing future attempts to get
MCLK).

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Code Presence**
The buggy code exists in ALL active stable trees:
- The register_card error leak exists since v3.2 (2011)
- The audio-routing error leak exists since v4.16 (2018)
- All stable trees (5.4.y, 5.10.y, 5.15.y, 6.1.y, 6.6.y, 6.12.y) contain
  both bugs

**Step 6.2: Backport Difficulty**
The patch should apply cleanly or with trivial fuzz. Stable trees older
than 6.1 use `of_find_property()` instead of `of_property_present()`,
but the error path code is unchanged. The `devm_snd_soc_register_card`
error path in trees before 5.15 uses slightly different error printing
(not `dev_err_probe`), but the fix location is the same.

## PHASE 7: SUBSYSTEM CONTEXT

- Subsystem: ASoC (sound/soc) - audio driver infrastructure
- Criticality: PERIPHERAL (MXS/i.MX28 embedded audio, specific platform)
- The MXS SAIF + SGTL5000 combination is used on Freescale/NXP i.MX28
  boards

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
Platform-specific: users of i.MX28 boards with SGTL5000 audio codec
(embedded systems).

**Step 8.2: Trigger**
Probe failure on the audio device. This can be triggered by:
- Invalid/malformed audio-routing DT property
- `devm_snd_soc_register_card()` failure (e.g., codec not ready, probe
  deferral errors)

**Step 8.3: Failure Mode**
- Clock resource leak (hardware clock left enabled, consuming power)
- `mclk_in_use` flag remains set, potentially blocking future MCLK
  acquisition
- Severity: MEDIUM (resource leak, not crash)

**Step 8.4: Risk-Benefit**
- BENEFIT: Fixes resource leak on error paths. Clean cleanup of hardware
  state.
- RISK: Very low. Only 2 lines, only error paths, mirrors existing
  remove() logic.
- Ratio: Favorable. Very low risk fix for a real resource leak.

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR backporting:**
- Fixes a real resource leak (hardware clock left enabled on probe
  failure)
- Fixes `mclk_in_use` state leak that can prevent subsequent attempts
- Tiny, surgical fix (2 lines of meaningful code)
- Obviously correct (mirrors the cleanup in `remove()`)
- Accepted by ASoC subsystem maintainer (Mark Brown)
- Bug exists in all stable trees (since v3.2/v4.16)
- Zero regression risk (only error paths affected)
- The same function had a prior similar fix (`6ae0a4d8fec55` for
  of_node_put)

**Evidence AGAINST:**
- Platform-specific driver (limited user base, i.MX28)
- No Reported-by (found by code review, not user complaint)
- Resource leak, not crash/security/corruption
- No Fixes: tag (but expected for review candidates)

**Stable Rules Checklist:**
1. Obviously correct and tested? **YES** - mirrors remove() pattern,
   accepted by maintainer
2. Fixes a real bug? **YES** - clock resource leak on error
3. Important issue? **MEDIUM** - resource leak, not critical severity
4. Small and contained? **YES** - 2 lines, 1 file
5. No new features? **YES** - pure bugfix
6. Can apply to stable? **YES** - should apply cleanly to all active
   trees

## Verification

- [Phase 1] Parsed tags: Link to patch.msgid.link, SOB by Mark Brown
  (maintainer), author Haoxiang Li
- [Phase 2] Diff analysis: 2 lines of `mxs_saif_put_mclk(0)` added to
  two error paths in `mxs_sgtl5000_probe()`
- [Phase 3] git blame: `mxs_saif_get_mclk()` introduced in
  fcb5e47eff29a1 (v3.2, 2011); audio-routing error path introduced in
  949293d45d6b09 (v4.16, 2018)
- [Phase 3] git show 949293d45d6b09: confirmed it added
  `snd_soc_of_parse_audio_routing()` error path without cleanup
- [Phase 3] git show 6ae0a4d8fec55: confirmed prior error-handling fix
  in same function (of_node_put leak)
- [Phase 3] Author commits: Haoxiang Li is a serial error-path leak
  fixer
- [Phase 4] Lore inaccessible due to bot protection; patch accepted by
  Mark Brown directly
- [Phase 5] Read mxs_saif_get_mclk: confirms it enables clock + sets
  mclk_in_use=1; put_mclk disables clock + clears flag
- [Phase 6] Code exists in all stable trees from 5.4.y through 6.12.y
- [Phase 6] git log v6.6..HEAD: only 4 commits to this file since v6.6,
  none conflicting
- [Phase 8] Failure mode: clock resource leak + mclk_in_use state leak
  on probe error, severity MEDIUM

The fix is small, surgical, obviously correct, and fixes a real resource
leak that has existed since 2011/2018. It meets all stable kernel
criteria.

**YES**

 sound/soc/mxs/mxs-sgtl5000.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/sound/soc/mxs/mxs-sgtl5000.c b/sound/soc/mxs/mxs-sgtl5000.c
index 245f174116384..f1c0e612313dd 100644
--- a/sound/soc/mxs/mxs-sgtl5000.c
+++ b/sound/soc/mxs/mxs-sgtl5000.c
@@ -157,13 +157,16 @@ static int mxs_sgtl5000_probe(struct platform_device *pdev)
 		if (ret) {
 			dev_err(&pdev->dev, "failed to parse audio-routing (%d)\n",
 				ret);
+			mxs_saif_put_mclk(0);
 			return ret;
 		}
 	}
 
 	ret = devm_snd_soc_register_card(&pdev->dev, card);
-	if (ret)
+	if (ret) {
+		mxs_saif_put_mclk(0);
 		return dev_err_probe(&pdev->dev, ret, "snd_soc_register_card failed\n");
+	}
 
 	return 0;
 }
-- 
2.53.0

[PATCH AUTOSEL 6.18] ASoC: amd: acp: update DMI quirk and add ACP DMIC for Lenovo platforms

[Sasha Levin]

From: Syed Saba Kareem <Syed.SabaKareem@amd.com>

[ Upstream commit 6b6f7263d626886a96fce6352f94dfab7a24c339 ]

Replace DMI_EXACT_MATCH with DMI_MATCH for Lenovo SKU entries (21YW,
21YX) so the quirk applies to all variants of these models, not just
exact SKU matches.

Add ASOC_SDW_ACP_DMIC flag alongside ASOC_SDW_CODEC_SPKR in driver_data
for these Lenovo platform entries, as these platforms use ACP PDM DMIC
instead of SoundWire DMIC for digital microphone support.

Fixes: 3acf517e1ae0 ("ASoC: amd: amd_sdw: add machine driver quirk for Lenovo models")
Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Reviewed-by: Mark Pearson <mpearson-lenovo@squebb.ca>
Signed-off-by: Syed Saba Kareem <Syed.SabaKareem@amd.com>
Reviewed-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://patch.msgid.link/20260408133029.1368317-1-syed.sabakareem@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 sound/soc/amd/acp/acp-sdw-legacy-mach.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/acp/acp-sdw-legacy-mach.c b/sound/soc/amd/acp/acp-sdw-legacy-mach.c
index 504b700200660..2b2910b1856d5 100644
--- a/sound/soc/amd/acp/acp-sdw-legacy-mach.c
+++ b/sound/soc/amd/acp/acp-sdw-legacy-mach.c
@@ -99,17 +99,17 @@ static const struct dmi_system_id soc_sdw_quirk_table[] = {
 		.callback = soc_sdw_quirk_cb,
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-			DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "21YW"),
+			DMI_MATCH(DMI_PRODUCT_SKU, "21YW"),
 		},
-		.driver_data = (void *)(ASOC_SDW_CODEC_SPKR),
+		.driver_data = (void *)((ASOC_SDW_CODEC_SPKR) | (ASOC_SDW_ACP_DMIC)),
 	},
 	{
 		.callback = soc_sdw_quirk_cb,
 		.matches = {
 			DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
-			DMI_EXACT_MATCH(DMI_PRODUCT_SKU, "21YX"),
+			DMI_MATCH(DMI_PRODUCT_SKU, "21YX"),
 		},
-		.driver_data = (void *)(ASOC_SDW_CODEC_SPKR),
+		.driver_data = (void *)((ASOC_SDW_CODEC_SPKR) | (ASOC_SDW_ACP_DMIC)),
 	},
 	{
 		.callback = soc_sdw_quirk_cb,
-- 
2.53.0

[PATCH AUTOSEL 6.18] ALSA: hda/realtek: Add HP ENVY Laptop 13-ba0xxx quirk

[Sasha Levin]

From: Andrii Kovalchuk <coderpy4@proton.me>

[ Upstream commit 793b008cd39516385791a1d1d223d817e947a471 ]

Add a PCI quirk for HP ENVY Laptop 13-ba0xxx (PCI device ID 0x8756)
to enable proper mute LED and mic mute behavior using the
ALC245_FIXUP_HP_X360_MUTE_LEDS fixup.

Signed-off-by: Andrii Kovalchuk <coderpy4@proton.me>
Link: https://patch.msgid.link/u0s-uRVegF9BN0t-4JnOUwsIAR-mVc4U4FJfJHdEHX7ro_laErHD9y35NebWybcN16gVaVHPJo1ap3AoJ1a2gqJImPvThgeNt_SYVY1KaDw=@proton.me
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 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 0654850687447..1b64292220ac8 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6732,6 +6732,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8730, "HP ProBook 445 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x8735, "HP ProBook 435 G7", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF),
 	SND_PCI_QUIRK(0x103c, 0x8736, "HP", ALC285_FIXUP_HP_GPIO_AMP_INIT),
+	SND_PCI_QUIRK(0x103c, 0x8756, "HP ENVY Laptop 13-ba0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
 	SND_PCI_QUIRK(0x103c, 0x8760, "HP EliteBook 8{4,5}5 G7", ALC285_FIXUP_HP_BEEP_MICMUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x876e, "HP ENVY x360 Convertible 13-ay0xxx", ALC245_FIXUP_HP_X360_MUTE_LEDS),
 	SND_PCI_QUIRK(0x103c, 0x877a, "HP", ALC285_FIXUP_HP_MUTE_LED),
-- 
2.53.0

[PATCH AUTOSEL 6.18] 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:

Error: Failed to generate final synthesis

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

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index 9f585dbc770cb..a2c039a1b3cd6 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2296,6 +2296,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.18] ASoC: amd: yc: Add DMI quirk for ASUS EXPERTBOOK BM1403CDA

[Sasha Levin]

From: Vee Satayamas <vsatayamas@gmail.com>

[ Upstream commit f200b2f9a810c440c6750b56fc647b73337749a1 ]

Add a DMI quirk for the Asus Expertbook BM1403CDA to resolve the issue of the
internal microphone not being detected.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221236
Signed-off-by: Vee Satayamas <vsatayamas@gmail.com>
Reviewed-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260315142511.66029-2-vsatayamas@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index 1324543b42d72..c536de1bb94ad 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -717,6 +717,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_BOARD_NAME, "PM1503CDA"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+			DMI_MATCH(DMI_BOARD_NAME, "BM1403CDA"),
+		}
+	},
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 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:

Error: Failed to generate final synthesis

 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 c76d339009a9b..1c8ee8263ab3a 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7464,6 +7464,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.18] ALSA: hda/realtek: Add quirk for Lenovo Yoga Pro 7 14IAH10

[Sasha Levin]

From: songxiebing <songxiebing@kylinos.cn>

[ Upstream commit f0541edb2e7333f320642c7b491a67912c1f65db ]

The bass speakers are not working, and add the following entry
in /etc/modprobe.d/snd.conf:
options snd-sof-intel-hda-generic hda_model=alc287-yoga9-bass-spk-pin
Fixes the bass speakers.

So add the quick ALC287_FIXUP_YOGA9_14IAP7_BASS_SPK_PIN here.

Reported-by: Fernando Garcia Corona <fgarcor@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221317
Signed-off-by: songxiebing <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260405012651.133838-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:

Error: Failed to generate final synthesis

 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 2e89528e5cec1..6b53a7d90932d 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7467,6 +7467,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x17aa, 0x38fd, "ThinkBook plus Gen5 Hybrid", ALC287_FIXUP_TAS2781_I2C),
 	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, 0x3911, "Lenovo Yoga Pro 7 14IAH10", 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),
-- 
2.53.0

[PATCH AUTOSEL 6.18] ASoC: stm32_sai: fix incorrect BCLK polarity for DSP_A/B, LEFT_J

[Sasha Levin]

From: Tomasz Merta <tomasz.merta@arrow.com>

[ Upstream commit 0669631dbccd41cf3ca7aa70213fcd8bb41c4b38 ]

The STM32 SAI driver do not set the clock strobing bit (CKSTR) for DSP_A,
DSP_B and LEFT_J formats, causing data to be sampled on the wrong BCLK
edge when SND_SOC_DAIFMT_NB_NF is used.

Per ALSA convention, NB_NF requires sampling on the rising BCLK edge.
The STM32MP25 SAI reference manual states that CKSTR=1 is required for
signals received by the SAI to be sampled on the SCK rising edge.
Without setting CKSTR=1, the SAI samples on the falling edge, violating
the NB_NF convention. For comparison, the NXP FSL SAI driver correctly
sets FSL_SAI_CR2_BCP for DSP_A, DSP_B and LEFT_J, consistent with its
I2S handling.

This patch adds SAI_XCR1_CKSTR for DSP_A, DSP_B and LEFT_J in
stm32_sai_set_dai_fmt which was verified empirically with a cs47l35 codec.
RIGHT_J (LSB) is not investigated and addressed by this patch.

Note: the STM32 I2S driver (stm32_i2s_set_dai_fmt) may have the same issue
for DSP_A mode, as I2S_CGFR_CKPOL is not set. This has not been verified
and is left for a separate investigation.

Signed-off-by: Tomasz Merta <tommerta@gmail.com>
Link: https://patch.msgid.link/20260408084056.20588-1-tommerta@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 sound/soc/stm/stm32_sai_sub.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/sound/soc/stm/stm32_sai_sub.c b/sound/soc/stm/stm32_sai_sub.c
index 5ae4d2577f28b..c2540383ab86f 100644
--- a/sound/soc/stm/stm32_sai_sub.c
+++ b/sound/soc/stm/stm32_sai_sub.c
@@ -802,6 +802,7 @@ static int stm32_sai_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
 		break;
 	/* Left justified */
 	case SND_SOC_DAIFMT_MSB:
+		cr1 |= SAI_XCR1_CKSTR;
 		frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSDEF;
 		break;
 	/* Right justified */
@@ -809,9 +810,11 @@ static int stm32_sai_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt)
 		frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSDEF;
 		break;
 	case SND_SOC_DAIFMT_DSP_A:
+		cr1 |= SAI_XCR1_CKSTR;
 		frcr |= SAI_XFRCR_FSPOL | SAI_XFRCR_FSOFF;
 		break;
 	case SND_SOC_DAIFMT_DSP_B:
+		cr1 |= SAI_XCR1_CKSTR;
 		frcr |= SAI_XFRCR_FSPOL;
 		break;
 	default:
-- 
2.53.0

[PATCH AUTOSEL 6.18] ASoC: amd: yc: Add DMI quirk for Thin A15 B7VF

[Sasha Levin]

From: Zhang Heng <zhangheng@kylinos.cn>

[ Upstream commit 1f182ec9d7084db7dfdb2372d453c28f0e5c3f0a ]

Add a DMI quirk for the Thin A15 B7VF fixing the issue where
the internal microphone was not detected.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220833
Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Link: https://patch.msgid.link/20260316080218.2931304-1-zhangheng@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index c536de1bb94ad..6f1c105ca77e3 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -724,6 +724,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_BOARD_NAME, "BM1403CDA"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Thin A15 B7VE"),
+		}
+	},
 	{}
 };
 
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.19] ALSA: hda/realtek: Add support for HP Laptops

[Sasha Levin]

From: Stefan Binding <sbinding@opensource.cirrus.com>

[ Upstream commit 8dbbd39d0605b93a176f2c775dd2b6bb7c7a8adb ]

Add support for HP Auster, Trekker and Agusta G7KX.
Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with I2C

Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://patch.msgid.link/20260330134651.443439-2-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I now have all the information needed for a comprehensive analysis.
Here's my complete walkthrough:

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `ALSA: hda/realtek` (HDA audio codec - Realtek)
- **Action verb**: "Add support" - adding hardware support entries
- **Summary**: Adds PCI quirk entries for HP Auster, Trekker G7JC, and
  Agusta G7KX laptops
- Record: [ALSA/HDA Realtek] [Add] [Hardware quirk entries for HP
  laptops with CS35L41 amps]

### Step 1.2: Tags
- **Signed-off-by**: Stefan Binding (sbinding@opensource.cirrus.com) -
  Cirrus Logic engineer, regular CS35L41 contributor
- **Link**: `https://patch.msgid.link/20260330134651.443439-2-
  sbinding@opensource.cirrus.com` - patch 2 of series
- **Signed-off-by**: Takashi Iwai (tiwai@suse.de) - ALSA subsystem
  maintainer
- No Fixes: tag (expected for quirk additions)
- No Reported-by: tag (expected - hardware enablement)
- No Cc: stable tag (expected - this is what we're evaluating)
- Record: Standard tags for a quirk addition. Merged by the ALSA
  subsystem maintainer.

### Step 1.3: Commit Body
- "Add support for HP Auster, Trekker and Agusta G7KX."
- "Laptops use 2 CS35L41 Amps with HDA, using Internal boost, with I2C"
- This is a standard hardware enablement description from Cirrus Logic.
- Record: Without these quirk entries, the CS35L41 amplifiers on these
  HP laptops won't be configured correctly, resulting in no audio output
  or broken audio.

### Step 1.4: Hidden Bug Fix?
- Not a hidden bug fix - this is a straightforward hardware enablement
  via quirk table entries. However, the absence of these entries means
  audio doesn't work on these laptops, which is a real user-facing
  issue.
- Record: Not a hidden bug fix. It's a hardware quirk addition, which is
  an explicitly allowed exception for stable.

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 file (`sound/hda/codecs/realtek/alc269.c`)
- **Lines added**: 4 (pure additions)
- **Lines removed**: 0
- **Functions modified**: None (only the `alc269_fixup_tbl[]` data table
  is changed)
- Record: Single-file, 4-line addition to a data table. Minimal scope.

### Step 2.2: Code Flow Change
Four new `SND_PCI_QUIRK()` entries inserted in sorted order:
1. `0x8e75` → "HP Trekker G7JC" → `ALC287_FIXUP_CS35L41_I2C_2`
2. `0x8f07` → "HP Agusta G7KX" → `ALC287_FIXUP_CS35L41_I2C_2`
3. `0x8f2d` → "HP Auster 14" → `ALC287_FIXUP_CS35L41_I2C_2`
4. `0x8f2e` → "HP Auster 14" → `ALC287_FIXUP_CS35L41_I2C_2`

Before: These PCI subsystem IDs have no quirk entry → generic behavior →
CS35L41 amps not properly configured.
After: These IDs match → `cs35l41_fixup_i2c_two()` is called → 2 CS35L41
amps configured via I2C with internal boost.

### Step 2.3: Bug Mechanism
- Category: **Hardware workaround / device ID addition**
- Without the quirk entry, the HDA codec driver doesn't know these
  laptop models have CS35L41 amplifiers that need specific I2C
  configuration. Audio will be broken or absent.

### Step 2.4: Fix Quality
- Obviously correct: just adds entries to a sorted lookup table using an
  existing fixup
- Minimal/surgical: 4 lines, data-only
- Zero regression risk: only affects the specific HP PCI subsystem IDs
  listed
- No code logic changes whatsoever

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- The `ALC287_FIXUP_CS35L41_I2C_2` fixup was introduced in commit
  `07bcab93946cd` (January 2022, merged in v5.18). It has been stable
  and used by dozens of other HP/ASUS laptop quirk entries ever since.
- Record: The fixup function exists in all active stable trees (v5.18+).

### Step 3.2: No Fixes: tag (expected for quirk additions)

### Step 3.3: File History
- Stefan Binding has numerous similar commits adding CS35L41 quirk
  entries for HP laptops: `108c422c495dc` (HP Clipper), `720eebd514c0c`
  (HP Trekker), `f8b1ff6555868` (HP Turbine). This is a well-established
  pattern.
- Record: Standalone commit, no prerequisites needed.

### Step 3.4: Author
- Stefan Binding is a Cirrus Logic engineer who is the primary
  contributor for CS35L41 HDA support. He has dozens of similar commits
  over the past 4 years.
- Record: Author is the de facto maintainer of CS35L41 HDA integration.

### Step 3.5: Dependencies
- This is part of a 2-patch series (patch 1/2). Patch 2/2 adds ASUS
  laptop quirks. The two patches are completely independent - they add
  entries for different manufacturers to the same table.
- `ALC287_FIXUP_CS35L41_I2C_2` already exists (line 6248 in current
  tree).
- Record: Fully standalone; no dependencies.

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Original Submission
- Found via `b4 am`: Series is "[PATCH v1 0/2] Add support for various
  HP and ASUS laptops using CS35L41 HDA"
- Cover letter confirms: "These laptops use Internal boost, with SPI or
  I2C."
- v1 only (no revisions needed) - accepted as-is by Takashi Iwai.
- Record: Clean submission, applied without revisions.

### Step 4.2: Reviewers
- Sent to Jaroslav Kysela (ALSA co-maintainer), Takashi Iwai (ALSA
  maintainer), linux-sound@vger.kernel.org,
  patches@opensource.cirrus.com
- Applied by Takashi Iwai directly.
- Record: Proper review chain through the subsystem maintainer.

### Step 4.3: No bug report (hardware enablement, not a bug report)

### Step 4.4: Series context
- Patch 2/2 adds ASUS quirks; completely independent.

### Step 4.5: Lore blocked by anti-bot protection; unable to search
stable mailing list directly. No stable-specific discussion expected for
a new quirk addition.

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Functions
- No functions modified. Only the `alc269_fixup_tbl[]` static data table
  is changed.

### Step 5.2-5.4: Call chain
- The quirk table is consulted during HDA codec probe via
  `snd_pci_quirk_lookup()`. When a matching PCI subsystem vendor/device
  ID is found, the corresponding fixup function
  (`cs35l41_fixup_i2c_two`) is called during codec initialization.
- This is a standard, well-tested path used by 100+ existing quirk
  entries.

### Step 5.5: Similar patterns
- 114 existing uses of `ALC287_FIXUP_CS35L41_I2C_2` in the current tree.
  This is one of the most commonly used fixups.

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy code in stable?
- The "bug" is the absence of quirk entries for these specific HP laptop
  models. The fixup infrastructure exists in all stable trees from v5.18
  onward.
- Record: `ALC287_FIXUP_CS35L41_I2C_2` confirmed present in v5.18 (13
  uses) and v6.6 (25 uses).

### Step 6.2: Backport complications
- Minor context mismatch: in the mainline diff, entry `0x8e60` shows "HP
  Trekker" with `ALC287_FIXUP_CS35L41_I2C_2`, but in the current 7.0
  tree, it shows "HP OmniBook 7 Laptop 16-bh0xxx" with
  `ALC245_FIXUP_CS35L41_I2C_2_MUTE_LED`. This means the first hunk
  context won't match exactly, but the insertion points (after 0x8e62,
  after 0x8ee7, after 0x8f0e) all exist and match.
- For older stable trees (pre-6.14), the file is at
  `sound/pci/hda/patch_realtek.c` instead of
  `sound/hda/codecs/realtek/alc269.c` (file moved in July 2025).
- Record: Minor fuzz needed for 7.0; path adjustment needed for older
  trees. Trivial.

### Step 6.3: No related fixes already in stable for these specific PCI
IDs.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1
- Subsystem: ALSA/HDA (audio) - **IMPORTANT** level. Audio is critical
  for laptop users.
- HP is one of the largest laptop manufacturers globally.

### Step 7.2
- This file is extremely actively maintained - frequent quirk additions
  for new laptop models.

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected users
- Users of HP Auster 14, HP Trekker G7JC, and HP Agusta G7KX laptops.
- These are new HP commercial/consumer laptop models.

### Step 8.2: Trigger
- Every boot on these specific laptop models. Audio is broken without
  the quirk.

### Step 8.3: Failure mode
- Without the quirk: CS35L41 amplifiers not configured → no audio output
  (speakers don't work).
- Severity: HIGH for affected users (audio completely non-functional).

### Step 8.4: Risk-benefit
- **Benefit**: Enables audio on specific HP laptop models. High value
  for affected users.
- **Risk**: Essentially zero. Adds 4 entries to a lookup table. Only
  affects the exact PCI subsystem IDs listed. Cannot affect any other
  hardware.
- **Ratio**: Extremely favorable.

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence
**FOR backporting:**
- Textbook hardware quirk addition (explicitly listed as an exception in
  stable rules)
- 4 lines of pure data additions, zero logic changes
- Uses well-established fixup present since v5.18
- Author is the primary CS35L41 maintainer at Cirrus Logic
- Merged by the ALSA subsystem maintainer (Takashi Iwai)
- Fixes real user-facing issue (broken audio on new HP laptops)
- Identical pattern to dozens of previously-backported quirk entries

**AGAINST backporting:**
- Minor context mismatch requiring trivial adjustment
- File path differs in older stable trees (pre-6.14)

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** - data table entries using
   existing fixup
2. Fixes a real bug? **YES** - audio doesn't work on these laptops
   without it
3. Important issue? **YES** - complete audio failure on affected
   hardware
4. Small and contained? **YES** - 4 lines, single file, data-only
5. No new features or APIs? **CORRECT** - no new features
6. Can apply to stable? **YES** - with minor fuzz for context

### Step 9.3: Exception Category
This is a **hardware quirk addition** - one of the explicitly allowed
exception categories for stable.

### Step 9.4: Decision
Clear YES. This is a textbook example of a stable-worthy hardware quirk
addition.

## Verification

- [Phase 1] Parsed tags: Signed-off-by Stefan Binding (Cirrus Logic),
  applied by Takashi Iwai (ALSA maintainer)
- [Phase 2] Diff analysis: 4 lines added to `alc269_fixup_tbl[]` data
  table, all using existing `ALC287_FIXUP_CS35L41_I2C_2` fixup
- [Phase 3] git show 07bcab93946cd: confirmed
  `ALC287_FIXUP_CS35L41_I2C_2` introduced January 2022 (v5.18)
- [Phase 3] git show v5.18/v6.6 confirmed fixup present: 13 uses in
  v5.18, 25 in v6.6
- [Phase 3] git log author: Stefan Binding has dozens of identical quirk
  additions (108c422c495dc, 720eebd514c0c, f8b1ff6555868)
- [Phase 4] b4 am: Found 2-patch series, both independent quirk
  additions. v1 only, accepted without revision
- [Phase 4] b4 dig -w (on related commit): Sent to ALSA maintainers and
  linux-sound list
- [Phase 5] Grep: 114 existing uses of ALC287_FIXUP_CS35L41_I2C_2 in
  current tree
- [Phase 6] Fixup definition confirmed at line 6248; all insertion
  points (0x8e62, 0x8ee7, 0x8f0e) present in 7.0 tree
- [Phase 6] Context mismatch: 0x8e60 entry differs between mainline and
  7.0 (different name/fixup) - minor fuzz needed
- [Phase 6] File renamed from `sound/pci/hda/patch_realtek.c` to
  `sound/hda/codecs/realtek/alc269.c` in v6.14 cycle
- [Phase 8] Risk: zero (data-only, only matches specific PCI IDs).
  Benefit: high (enables audio on HP laptops)

**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 d86781e976ac0..44f0fcd20cf51 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7198,6 +7198,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8e60, "HP OmniBook 7 Laptop 16-bh0xxx", ALC245_FIXUP_CS35L41_I2C_2_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x8e61, "HP Trekker ", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8e62, "HP Trekker ", ALC287_FIXUP_CS35L41_I2C_2),
+	SND_PCI_QUIRK(0x103c, 0x8e75, "HP Trekker G7JC", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8e8a, "HP NexusX", ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x8e9c, "HP 16 Clipper OmniBook X X360", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8e9d, "HP 17 Turbine OmniBook X UMA", ALC287_FIXUP_CS35L41_I2C_2),
@@ -7219,8 +7220,11 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8ee4, "HP Bantie A6U", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO),
 	SND_PCI_QUIRK(0x103c, 0x8ee5, "HP Bantie A6U", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO),
 	SND_PCI_QUIRK(0x103c, 0x8ee7, "HP Abe A6U", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO),
+	SND_PCI_QUIRK(0x103c, 0x8f07, "HP Agusta G7KX", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8f0c, "HP ZBook X G2i 16W", ALC236_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x8f0e, "HP ZBook X G2i 16W", ALC236_FIXUP_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x8f2d, "HP Auster 14", ALC287_FIXUP_CS35L41_I2C_2),
+	SND_PCI_QUIRK(0x103c, 0x8f2e, "HP Auster 14", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8f40, "HP ZBook 8 G2a 14", ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x8f41, "HP ZBook 8 G2a 16", ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x8f42, "HP ZBook 8 G2a 14W", ALC245_FIXUP_HP_TAS2781_I2C_MUTE_LED),
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] ALSA: hda/realtek: Add quirk for Acer PT316-51S headset mic

[Sasha Levin]

From: Faye Nichols <faye.opensource@gmail.com>

[ Upstream commit a7b56be59b47f4195ddc79ecab238c4401a60bbb ]

The Acer PT316-51S (PCI SSID 1025:160e) with ALC287 codec does not
detect the headset microphone due to missing BIOS pin configuration
for pin 0x19. Apply ALC2XX_FIXUP_HEADSET_MIC to enable it.

Signed-off-by: Faye Nichols <faye.opensource@gmail.com>
Link: https://patch.msgid.link/20260413212645.117119-1-faye.opensource@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:

Here is my complete analysis:

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `ALSA: hda/realtek`
- Action verb: "Add" (quirk)
- Summary: Adds a PCI SSID quirk for Acer PT316-51S to enable headset
  microphone detection.
Record: [ALSA/hda/realtek] [Add] [Hardware quirk for Acer PT316-51S
headset mic]

**Step 1.2: Tags**
- Signed-off-by: Faye Nichols (author)
- Link: patch.msgid.link (standard patch submission)
- Signed-off-by: Takashi Iwai (ALSA subsystem maintainer) — indicates
  maintainer review and acceptance
- No Fixes: tag (expected for quirk additions)
- No Reported-by: (the author likely is the user affected)
Record: [Maintainer SOB from Takashi Iwai — strong acceptance signal]

**Step 1.3: Body Text**
The commit clearly states: The Acer PT316-51S (PCI SSID 1025:160e) with
ALC287 codec does not detect the headset microphone due to missing BIOS
pin configuration for pin 0x19. The fix applies
`ALC2XX_FIXUP_HEADSET_MIC` to override the BIOS-provided (or missing)
pin configuration.
Record: [Bug: headset mic not detected] [Root cause: missing BIOS pin
config for pin 0x19] [Fix: apply existing fixup]

**Step 1.4: Hidden Bug Fix?**
Not hidden — this directly fixes non-functioning hardware (headset mic).
Record: [Explicit hardware fix, not disguised]

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `sound/hda/codecs/realtek/alc269.c`
- 1 line added
- 0 lines removed
- Function modified: none — this adds an entry to a static data table
  (`alc269_fixup_tbl[]`)
Record: [+1 line, single file, table entry addition] [Scope:
minimal/surgical]

**Step 2.2: Code Flow**
The new line inserts `SND_PCI_QUIRK(0x1025, 0x160e, "Acer PT316-51S",
ALC2XX_FIXUP_HEADSET_MIC)` into the PCI quirk table between 0x1597 and
0x169a entries (sorted order). When the HDA codec driver matches PCI
SSID 1025:160e, it will apply the `ALC2XX_FIXUP_HEADSET_MIC` fixup.
Record: [Before: no quirk for this SSID, so headset mic not configured.
After: fixup is applied during codec init.]

**Step 2.3: Bug Mechanism**
This is category (h) — hardware workaround / device ID addition. The
`ALC2XX_FIXUP_HEADSET_MIC` fixup (verified at line 3545-3561) sets pin
0x19 to config value 0x03a1103c, updates a codec coefficient, and sets
the HEADSET_MIC parse flag. Without this, the BIOS-provided (or absent)
pin config leaves the headset mic non-functional.
Record: [Hardware quirk table entry] [Existing fixup, only adds PCI SSID
matching]

**Step 2.4: Fix Quality**
- Obviously correct: identical pattern to dozens of existing entries (21
  uses of `ALC2XX_FIXUP_HEADSET_MIC` already)
- Minimal: 1 line in a data table
- Regression risk: essentially zero — only affects this specific PCI
  SSID
Record: [Obviously correct, zero regression risk]

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
The surrounding entries using the same fixup
(`ALC2XX_FIXUP_HEADSET_MIC`) were added by various contributors (Breno
Baptista 2026-02-04, Takashi Iwai 2025-07-09, Matouš Lánský 2025-12-31).
The fixup function `alc2xx_fixup_headset_mic` and enum
`ALC2XX_FIXUP_HEADSET_MIC` have been in the tree since at least kernel
6.x era.
Record: [ALC2XX_FIXUP_HEADSET_MIC infrastructure exists in stable trees]

**Step 3.2: No Fixes: tag** — N/A for quirk additions.

**Step 3.3: File History**
The file receives continuous quirk additions (20 recent commits shown
are almost all quirk additions). This is a well-tested and routine
change pattern.
Record: [File receives frequent identical-pattern changes]

**Step 3.4: Author**
Faye Nichols has no other commits in this tree. This is a single
community contribution. However, it was accepted by Takashi Iwai (ALSA
subsystem maintainer), which validates the change.
Record: [Community contributor, maintainer-accepted]

**Step 3.5: Dependencies**
The `ALC2XX_FIXUP_HEADSET_MIC` enum and function exist in the 7.0 tree.
Verified at line 4089 (enum), 6467-6470 (fixup table definition),
3545-3561 (function implementation). This was introduced by commit
50db91fccea0d (Dec 2024). For stable trees, we need to verify this
enum/function exists. Given it was merged in late 2024, it should be in
6.12+ stable trees.
Record: [Depends on ALC2XX_FIXUP_HEADSET_MIC infrastructure from Dec
2024]

## PHASE 4: MAILING LIST

**Step 4.1-4.5:** Lore.kernel.org was blocked by anti-bot protection.
However, the patch link in the commit message
(`patch.msgid.link/20260413212645.117119-1-faye.opensource@gmail.com`)
and the maintainer's Signed-off-by confirm it went through standard
review. Takashi Iwai (the ALSA maintainer) signed off on it, which is
the standard acceptance path for HDA quirk additions.
Record: [Unable to fetch lore discussion due to anti-bot. Maintainer
acceptance confirmed via SOB.]

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.5:** The change is a single data table entry. The
`alc2xx_fixup_headset_mic` function (lines 3545-3561) applies pin
configuration for pin 0x19, updates a codec coefficient, and sets the
headset mic parse flag. This is a well-understood, thoroughly tested
fixup path used by 20+ other devices. No new code paths are introduced.
Record: [No new code, only adds a match entry to existing fixup
infrastructure]

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The `ALC2XX_FIXUP_HEADSET_MIC` infrastructure was added in
Dec 2024. It should exist in stable trees 6.12.y and newer. For older
stable trees (6.6.y, 6.1.y), this specific fixup enum might not exist
and would require a different backport approach (though similar fixups
like `ALC256_FIXUP_ACER_HEADSET_MIC` exist in older trees).
Record: [Applies cleanly to 6.12+ stable trees. Older trees may lack the
specific fixup enum.]

**Step 6.2:** The patch is a 1-line insertion in a sorted table. It will
apply cleanly or with trivial context adjustment.
Record: [Trivial to backport, clean apply expected]

**Step 6.3:** No existing fix for this specific PCI SSID (0x1025:0x160e)
was found in the tree.
Record: [No prior fix for this device]

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** ALSA/HDA subsystem — IMPORTANT criticality (audio is a
core user-facing feature).
Record: [ALSA/HDA, IMPORTANT criticality]

**Step 7.2:** The file receives very frequent updates (105 commits since
v6.6, mostly quirk additions). This is one of the most actively
maintained quirk tables in the kernel.
Record: [Very active, routine quirk additions]

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affects users of the Acer PT316-51S laptop specifically.
Record: [Driver-specific: Acer PT316-51S laptop users]

**Step 8.2:** The trigger is deterministic: every boot on this hardware,
the headset mic is non-functional.
Record: [100% reproducible on affected hardware, every boot]

**Step 8.3:** Failure: headset microphone does not work at all. For
laptop users who need headset mic for calls/meetings, this is a
significant usability problem.
Record: [Non-functional hardware, severity: HIGH for affected users]

**Step 8.4:**
- BENEFIT: Enables headset mic on a specific laptop model — high benefit
  for affected users
- RISK: 1-line data table entry, only matches specific PCI SSID —
  essentially zero risk
Record: [High benefit, near-zero risk — excellent ratio]

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence FOR backporting:**
- Classic audio codec quirk (one of the explicitly listed exception
  categories)
- Single line addition to a static data table
- Uses well-established, pre-existing fixup infrastructure
- Accepted by ALSA subsystem maintainer (Takashi Iwai)
- Fixes real hardware for real users (headset mic non-functional)
- Zero regression risk (only affects one PCI SSID)
- Identical pattern to hundreds of other backported quirks

**Evidence AGAINST:** None identified.

**Step 9.2: Stable Rules Checklist:**
1. Obviously correct and tested? **YES** — identical to dozens of
   existing entries
2. Fixes a real bug? **YES** — headset mic non-functional on specific
   hardware
3. Important issue? **YES** — non-functional hardware
4. Small and contained? **YES** — 1 line in a data table
5. No new features or APIs? **YES** — uses existing fixup
6. Can apply to stable? **YES** — trivially, for trees that have
   ALC2XX_FIXUP_HEADSET_MIC

**Step 9.3: Exception Category:** This is a **hardware
quirk/workaround** — one of the explicitly allowed exception categories
for stable.

## Verification

- [Phase 1] Parsed tags: maintainer SOB from Takashi Iwai confirms
  acceptance
- [Phase 2] Diff analysis: exactly 1 line added — `SND_PCI_QUIRK(0x1025,
  0x160e, ...)` to quirk table
- [Phase 3] git blame: surrounding entries added by various contributors
  2025-2026, established pattern
- [Phase 3] Verified ALC2XX_FIXUP_HEADSET_MIC exists at line 4089
  (enum), 6467-6470 (table def), 3545-3561 (function)
- [Phase 3] Confirmed 21 existing uses of ALC2XX_FIXUP_HEADSET_MIC in
  the quirk table
- [Phase 4] Lore blocked by anti-bot; maintainer acceptance verified
  through SOB
- [Phase 5] Verified fixup function sets pin 0x19 config to 0x03a1103c
  and HEADSET_MIC flag
- [Phase 6] ALC2XX_FIXUP_HEADSET_MIC infrastructure from Dec 2024,
  available in 6.12+ stable
- [Phase 6] 1138 SND_PCI_QUIRK entries in file — this is an extremely
  common pattern
- [Phase 8] Failure mode: non-functional headset mic on every boot,
  severity HIGH for affected users

**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 44f0fcd20cf51..f10ee482151f6 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6718,6 +6718,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1025, 0x1539, "Acer Nitro 5 AN515-57", ALC2XX_FIXUP_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1025, 0x159c, "Acer Nitro 5 AN515-58", ALC2XX_FIXUP_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1025, 0x1597, "Acer Nitro 5 AN517-55", ALC2XX_FIXUP_HEADSET_MIC),
+	SND_PCI_QUIRK(0x1025, 0x160e, "Acer PT316-51S", ALC2XX_FIXUP_HEADSET_MIC),
 	SND_PCI_QUIRK(0x1025, 0x169a, "Acer Swift SFG16", ALC256_FIXUP_ACER_SFG16_MICMUTE_LED),
 	SND_PCI_QUIRK(0x1025, 0x171e, "Acer Nitro ANV15-51", ALC245_FIXUP_ACER_MICMUTE_LED),
 	SND_PCI_QUIRK(0x1025, 0x173a, "Acer Swift SFG14-73", ALC245_FIXUP_ACER_MICMUTE_LED),
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: usb-audio: add Studio 1824 support

[Sasha Levin]

From: Frederic Popp <frederic.l.popp@t-online.de>

[ Upstream commit c4791ce96b88a444b04c7089ae2827a3b3ae1877 ]

Adapt the already implemented support for the Studio 1824c
audio interface to the predecessor Studio 1824.

Basically just a change adding the
different hardware ID in the relevant places.

Tested as much as possible.
All implemented functionality seemingly works.

Signed-off-by: Frederic Popp <frederic.l.popp@t-online.de>
Link: https://patch.msgid.link/20260308153334.50433-2-frederic.l.popp@t-online.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The context matches the diff perfectly. The patch would apply cleanly.
Now I have all the information needed.

---

## Complete Analysis

### PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Parse the Subject Line**
- Subsystem: `ALSA: usb-audio`
- Action verb: "add" (add support)
- Summary: Adding USB device ID for Presonus Studio 1824 to existing
  driver
Record: [ALSA: usb-audio] [add] [Studio 1824 device support via ID
addition to existing 1824c code paths]

**Step 1.2: Parse All Commit Message Tags**
- Signed-off-by: Frederic Popp <frederic.l.popp@t-online.de> (author)
- Link: https://patch.msgid.link/20260308153334.50433-2-
  frederic.l.popp@t-online.de (patch 2 in a series)
- Signed-off-by: Takashi Iwai <tiwai@suse.de> (ALSA maintainer, accepted
  the patch)
- No Fixes: tag (expected)
- No Cc: stable (expected)
- No Reported-by: tag (author is the user of this hardware)
Record: Author SOB, maintainer SOB, link suggests patch 2 of a series.
Maintainer Takashi Iwai applied it.

**Step 1.3: Analyze the Commit Body Text**
The commit message says: "Adapt the already implemented support for the
Studio 1824c audio interface to the predecessor Studio 1824. Basically
just a change adding the different hardware ID in the relevant places."
Author states they tested it: "Tested as much as possible. All
implemented functionality seemingly works."
Record: No bug described. This adds hardware support for an existing
device family. The Studio 1824 is a predecessor of the 1824c with a
different USB product ID (0x0107 vs 0x010d).

**Step 1.4: Detect Hidden Bug Fixes**
This is not a hidden bug fix. It is straightforwardly adding a new USB
device ID to an existing driver to enable a hardware device. This falls
under the "NEW DEVICE IDs" exception category.
Record: Not a hidden bug fix. This is a device ID addition.

### PHASE 2: DIFF ANALYSIS - LINE BY LINE

**Step 2.1: Inventory the Changes**
- `sound/usb/format.c`: +4 lines (new device ID check for sample rate
  filtering)
- `sound/usb/mixer_quirks.c`: +3 lines (new case in switch for mixer
  init)
- `sound/usb/mixer_s1810c.c`: +2 lines in two locations (new case labels
  in switches)
- Total: ~9 lines added, 0 removed
- Functions modified: `parse_uac2_sample_rate_range()`,
  `snd_usb_mixer_apply_create_quirk()`, `snd_s1810c_init_mixer_maps()`,
  `snd_sc1810_init_mixer()`
Record: 3 files, +9 lines, all adding `USB_ID(0x194f, 0x0107)` case
entries. Scope: trivial device ID addition.

**Step 2.2: Code Flow Change**
Each hunk adds the Presonus Studio 1824 USB ID (0x194f, 0x0107) to the
same code paths that already handle the 1824c (0x194f, 0x010d):
1. `format.c`: Before: 1824 rates not filtered. After: invalid sample
   rates filtered using same `s1810c_valid_sample_rate()` function.
2. `mixer_quirks.c`: Before: 1824 not recognized. After: calls
   `snd_sc1810_init_mixer()` like the 1824c does.
3. `mixer_s1810c.c` (init_mixer_maps): Before: 1824 not handled. After:
   falls through to 1824c case for initial mix setup.
4. `mixer_s1810c.c` (snd_sc1810_init_mixer): Before: 1824 not handled.
   After: falls through to 1824c case for mono switch init.
Record: All hunks simply add the 1824 USB ID alongside the existing
1824c ID to follow the same code paths.

**Step 2.3: Bug Mechanism**
Category: Hardware enablement - device ID addition. Not a bug fix per
se, but enables a hardware device that is otherwise non-functional or
partially functional without proper mixer initialization and sample rate
filtering.
Record: [Device ID addition] [Without this, the Studio 1824 would lack
proper mixer initialization and sample rate filtering]

**Step 2.4: Fix Quality**
- Obviously correct: Yes. Identical pattern to the existing 1824c
  entries.
- Minimal/surgical: Yes. Only device ID additions, 9 lines total.
- Regression risk: Essentially zero. Only affects users who plug in a
  Presonus Studio 1824 (USB ID 0x194f:0x0107). Cannot affect any other
  device.
- No red flags.
Record: Fix quality excellent. Zero regression risk. Trivial, obviously
correct.

### PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame the Changed Lines**
The code being modified was introduced by:
- `8dc5efe3d17cd` (v5.7-rc1): Initial 1810c support by Nick Kossifidis
- `080564558eb13` (v6.15-rc1): 1824c device ID addition by Amin Dandache
- `0ca29010d426e` (v6.18-rc1): 1824c initial mixer maps by Roy Vegard
  Ovesen
- `659169c4eb21f` (v6.18-rc1): 1824c mono switch by Roy Vegard Ovesen
Record: Driver has been in the tree since v5.7. The 1824c support (which
this 1824 commit mirrors) landed in v6.15/v6.18.

**Step 3.2: Follow the Fixes: tag**
No Fixes: tag present (expected - this is a device ID addition, not a
bug fix).
Record: N/A

**Step 3.3: File History**
The mixer_s1810c.c file has seen active development recently with 1824c
improvements (initial mix, mono switch, cleanups). The Studio 1824
support piggybacks on all of this.
Record: Active file with recent 1824c-related improvements. This commit
adds 1824 on top of that work.

**Step 3.4: Author's Other Commits**
Frederic Popp has no other commits in this tree. First-time contributor
with tested hardware support. Patch was accepted by subsystem maintainer
Takashi Iwai.
Record: First-time contributor. Patch vetted by ALSA maintainer.

**Step 3.5: Dependencies**
The commit depends on:
1. `080564558eb13` - 1824c basic support (v6.15) - **IN TREE**
   (verified)
2. `0ca29010d426e` - 1824c initial mixer maps (v6.18) - **IN TREE**
   (verified)
3. `659169c4eb21f` - 1824c mono switch (v6.18) - **IN TREE** (verified)
4. `d1d6ad7f6686e` - Removal of skip_setting quirk for 1824c - **IN
   TREE** (verified)

All dependencies present. The message-id suggests patch 2 of a series,
but the diff is self-contained (patch 1 was likely a cover letter or an
unrelated companion change).
Record: All dependencies present in tree. Commit is self-contained.

### PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.5: Mailing List**
Lore.kernel.org is blocking automated access (Anubis protection). b4 dig
could not find the commit (not yet in the tree). However, the Link: tag
confirms the patch was submitted to the ALSA mailing list and was
accepted by Takashi Iwai (the ALSA subsystem maintainer).
Record: Could not access lore discussion. Patch was accepted by ALSA
maintainer Takashi Iwai.

### PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.5: Functions Modified**
The changes are all switch case additions:
- `parse_uac2_sample_rate_range()` - called during USB audio format
  parsing
- `snd_usb_mixer_apply_create_quirk()` - called during mixer creation
- `snd_s1810c_init_mixer_maps()` - called during mixer initialization
- `snd_sc1810_init_mixer()` - called during mixer initialization

All are in the device probe/initialization path. The code paths are only
triggered when a device with USB ID 0x194f:0x0107 is connected.
Record: All changes in probe/init path, device-ID gated. No impact on
any other device.

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

**Step 6.1: Does the Code Exist in Stable Trees?**
This is for stable tree 7.0.y. The v7.0 tree has all prerequisites. For
older stable trees (6.12.y, 6.6.y, etc.), the 1824c support may not
exist, making this patch inapplicable there.
Record: Applies to 7.0.y. May not apply to older stable trees without
1824c support (added in v6.15/v6.18).

**Step 6.2: Backport Complications**
The patch would apply cleanly to the 7.0 tree - verified that the
context lines match exactly.
Record: Clean apply expected.

**Step 6.3: Related Fixes Already in Stable**
No related fixes for Studio 1824 in any stable tree (this is the first
time this device is supported).
Record: No prior fixes exist.

### PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: Subsystem Criticality**
- Subsystem: ALSA USB audio (`sound/usb/`)
- Criticality: IMPORTANT (USB audio is widely used)
Record: ALSA USB audio, IMPORTANT criticality.

**Step 7.2: Subsystem Activity**
Active subsystem with frequent device-specific additions and quirk
updates.
Record: Active subsystem.

### PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who Is Affected**
Only users of Presonus Studio 1824 hardware. Without this patch, the
device would operate as a generic UAC2 device but lack proper mixer
initialization, sample rate filtering, and control switches.
Record: Driver-specific, affects Presonus Studio 1824 owners.

**Step 8.2: Trigger Conditions**
Triggered when a user plugs in a Presonus Studio 1824 USB audio
interface.
Record: Device-specific trigger. Common for users of this hardware.

**Step 8.3: Failure Mode**
Without this patch: improper mixer setup, potentially wrong sample
rates, missing controls. Not a crash or security issue, but a hardware
enablement gap.
Record: Severity: MEDIUM (hardware not fully functional without the
patch)

**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Enables proper hardware support for Presonus Studio 1824
  owners on stable kernels.
- RISK: Essentially zero. 9 lines of device ID additions, affecting only
  one specific USB device. Cannot regress any other functionality.
Record: Very high benefit-to-risk ratio.

### PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**
FOR backporting:
- Classic device ID addition to existing driver (exception category)
- Trivially small (9 lines) and obviously correct
- Mirrors existing 1824c entries exactly
- Author tested on real hardware
- Accepted by ALSA subsystem maintainer Takashi Iwai
- Zero regression risk (device-ID gated)
- All dependencies are in the 7.0 tree
- Would apply cleanly

AGAINST backporting:
- Not a bug fix; it's new hardware enablement
- First-time contributor (mitigated by maintainer acceptance)
- Could not verify mailing list discussion (lore blocked)

UNRESOLVED:
- Could not access lore discussion (Anubis protection)
- Could not determine if there was a companion patch 1 in the series

**Step 9.2: Stable Rules Checklist**
1. Obviously correct? YES - identical pattern to existing entries
2. Fixes a real bug? NO (but falls under Device ID exception)
3. Important issue? Device enablement for existing hardware family
4. Small and contained? YES - 9 lines across 3 files
5. No new features or APIs? Correct - no new APIs, just ID table
   additions
6. Can apply to stable? YES - clean apply verified

**Step 9.3: Exception Categories**
This is a **Device ID addition** to an existing driver. The Presonus
Studio 1824 uses USB product ID 0x194f:0x0107, and the existing driver
already supports its successor (1824c, ID 0x194f:0x010d). The commit
adds the 1824's ID to the same code paths. This is the textbook
definition of a stable-eligible device ID addition.

**Step 9.4: Decision**
This is a straightforward device ID addition - one of the explicitly
allowed exception categories for stable backports. It's trivially small,
obviously correct, zero regression risk, and enables real hardware for
real users.

### Verification

- [Phase 1] Parsed tags: SOB from author and maintainer Takashi Iwai,
  Link to patch submission
- [Phase 2] Diff analysis: +9 lines across 3 files, all adding
  USB_ID(0x194f, 0x0107) to existing switch/if chains
- [Phase 3] git merge-base: confirmed all prerequisite commits
  (080564558eb13, 0ca29010d426e, 659169c4eb21f, d1d6ad7f6686e) are
  ancestors of HEAD
- [Phase 3] git describe: 1810c support in v5.7, 1824c support in
  v6.15/v6.18
- [Phase 3] git show 080564558eb13: confirmed 1824c was added via
  identical pattern
- [Phase 4] b4 dig: could not find commit (not yet in tree) - EXPECTED
  for candidate
- [Phase 4] lore access: blocked by Anubis - UNVERIFIED: mailing list
  discussion details
- [Phase 5] Code paths: all changes are device-ID gated, only triggered
  for USB ID 0x194f:0x0107
- [Phase 6] Context match verified: diff hunks match current tree state
  exactly, clean apply expected
- [Phase 6] No 0x0107 entries exist in sound/usb/ for Presonus vendor ID
  (confirmed via grep)
- [Phase 8] Risk: zero (device-ID gated, 9 lines, mirrors existing code
  exactly)

**YES**

 sound/usb/format.c       | 4 ++++
 sound/usb/mixer_quirks.c | 3 +++
 sound/usb/mixer_s1810c.c | 2 ++
 3 files changed, 9 insertions(+)

diff --git a/sound/usb/format.c b/sound/usb/format.c
index 1207c507882ad..030b4307927a2 100644
--- a/sound/usb/format.c
+++ b/sound/usb/format.c
@@ -455,6 +455,10 @@ static int parse_uac2_sample_rate_range(struct snd_usb_audio *chip,
 			if (chip->usb_id == USB_ID(0x194f, 0x010d) &&
 			    !s1810c_valid_sample_rate(fp, rate))
 				goto skip_rate;
+			/* Filter out invalid rates on Presonus Studio 1824 */
+			if (chip->usb_id == USB_ID(0x194f, 0x0107) &&
+			    !s1810c_valid_sample_rate(fp, rate))
+				goto skip_rate;
 
 			/* Filter out invalid rates on Focusrite devices */
 			if (USB_ID_VENDOR(chip->usb_id) == 0x1235 &&
diff --git a/sound/usb/mixer_quirks.c b/sound/usb/mixer_quirks.c
index 11e205da7964d..1d2a74df7ab09 100644
--- a/sound/usb/mixer_quirks.c
+++ b/sound/usb/mixer_quirks.c
@@ -4477,6 +4477,9 @@ int snd_usb_mixer_apply_create_quirk(struct usb_mixer_interface *mixer)
 	case USB_ID(0x194f, 0x010d): /* Presonus Studio 1824c */
 		err = snd_sc1810_init_mixer(mixer);
 		break;
+	case USB_ID(0x194f, 0x0107): /* Presonus Studio 1824 */
+		err = snd_sc1810_init_mixer(mixer);
+		break;
 	case USB_ID(0x2a39, 0x3fb0): /* RME Babyface Pro FS */
 		err = snd_bbfpro_controls_create(mixer);
 		break;
diff --git a/sound/usb/mixer_s1810c.c b/sound/usb/mixer_s1810c.c
index 7eac7d1bce647..2e5a8d37ec578 100644
--- a/sound/usb/mixer_s1810c.c
+++ b/sound/usb/mixer_s1810c.c
@@ -362,6 +362,7 @@ static int snd_s1810c_init_mixer_maps(struct snd_usb_audio *chip)
 		snd_s1810c_send_ctl_packet(dev, a, 3, 0, 1, MIXER_LEVEL_0DB);
 		break;
 
+	case USB_ID(0x194f, 0x0107): /* 1824 */
 	case USB_ID(0x194f, 0x010d): /* 1824c */
 		/* Set all output faders to unity gain */
 		a = SC1810C_SEL_OUTPUT;
@@ -685,6 +686,7 @@ int snd_sc1810_init_mixer(struct usb_mixer_interface *mixer)
 			return ret;
 
 		break;
+	case USB_ID(0x194f, 0x0107): /* Presonus Studio 1824 */
 	case USB_ID(0x194f, 0x010d): /* Presonus Studio 1824c */
 		ret = snd_s1810c_switch_init(mixer, &snd_s1824c_mono_sw);
 		if (ret < 0)
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.1] ASoC: amd: yc: Add MSI Vector A16 HX A8WHG to quirk table

[Sasha Levin]

From: Ihor Uzlov <igor.uzlov@gmail.com>

[ Upstream commit 72dcd84938f5026dc44d0e7e1e68d9d571c113a0 ]

Add the MSI Vector A16 HX A8WHG (board MS-15MM) to the DMI quirk table
to enable DMIC support. This laptop uses an AMD Ryzen 9 7945HX (Dragon
Range) with the ACP6x audio coprocessor (rev 0x62) and a Realtek ALC274
codec. The built-in digital microphone is connected via the ACP PDM
interface and requires this DMI entry to be activated.

Tested on MSI Vector A16 HX A8WHG with kernel 6.8.0-107 (Ubuntu 24.04).
DMIC capture device appears as 'acp6x' and records audio correctly.

Signed-off-by: Ihor Uzlov <igor.uzlov@gmail.com>
Link: https://patch.msgid.link/20260410094553.24654-1-igor.uzlov@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a thorough analysis. Let me
compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `ASoC: amd: yc` (AMD Yellow Carp audio)
- Action verb: "Add" (adding a new DMI quirk entry)
- Summary: Add MSI Vector A16 HX A8WHG laptop to the DMI quirk table for
  DMIC support
- Record: [ASoC: amd: yc] [Add] [New DMI entry for MSI laptop to enable
  DMIC]

**Step 1.2: Tags**
- Signed-off-by: Ihor Uzlov (author)
- Link:
  https://patch.msgid.link/20260410094553.24654-1-igor.uzlov@gmail.com
- Signed-off-by: Mark Brown (ASoC subsystem maintainer, applied the
  patch)
- No Fixes: tag (expected for a quirk addition)
- No Reported-by: tag (user self-submitted)
- No Cc: stable tag (expected - why this needs review)
- Record: Author is the laptop owner/tester. Applied by Mark Brown, the
  ASoC maintainer.

**Step 1.3: Commit Body**
- Hardware: MSI Vector A16 HX A8WHG (board MS-15MM), AMD Ryzen 9 7945HX,
  ACP6x audio coprocessor (rev 0x62), Realtek ALC274 codec
- Bug: Built-in digital microphone does not work without the DMI quirk
  entry
- Tested: kernel 6.8.0-107 (Ubuntu 24.04), DMIC capture via 'acp6x'
  works correctly
- Record: Without this entry, the laptop's built-in microphone is non-
  functional. User-tested and confirmed working.

**Step 1.4: Hidden Bug Fix Detection**
- This is a hardware enablement quirk, not a hidden bug fix. The
  microphone hardware exists but the driver lacks the DMI entry to
  recognize and activate it.
- Record: This is a straightforward hardware quirk addition, not a
  disguised bug fix. The "bug" is that the microphone doesn't work at
  all on this laptop without it.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file modified: `sound/soc/amd/yc/acp6x-mach.c`
- +7 lines added, 0 lines removed
- Modifies: `yc_acp_quirk_table[]` (static DMI table, no code logic
  change)
- Scope: Single-file, single-table-entry addition
- Record: [1 file, +7 lines] [yc_acp_quirk_table array] [Trivial table
  addition]

**Step 2.2: Code Flow**
- Before: The `yc_acp_quirk_table` did not have an entry for "Vector A16
  HX A8WHG"
- After: The table now includes this laptop, matched by DMI_BOARD_VENDOR
  "Micro-Star International Co., Ltd." and DMI_PRODUCT_NAME "Vector A16
  HX A8WHG"
- The probe function (`acp6x_probe`) calls
  `dmi_first_match(yc_acp_quirk_table)` and if it finds a match, it sets
  the platform driver data to `acp6x_card`, enabling DMIC support
- Record: [Before: no match -> microphone disabled] [After: match found
  -> DMIC enabled]

**Step 2.3: Bug Mechanism**
- Category: (h) Hardware workaround / DMI match table entry
- The driver requires either ACPI `_WOV` / `AcpDmicConnected` properties
  or a DMI quirk match to activate. This laptop apparently lacks the
  ACPI properties, so a DMI entry is necessary.
- Record: [Hardware quirk/enablement] [Missing DMI entry prevents
  microphone from working]

**Step 2.4: Fix Quality**
- Obviously correct: identical pattern to 100+ existing entries in the
  same table
- Minimal: 7 lines, pure data addition
- Zero regression risk: only affects this specific laptop model via DMI
  matching
- Record: [Trivially correct, minimal, zero regression risk]

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- The driver was introduced in commit `fa991481b8b22a` ("ASoC: amd: add
  YC machine driver using dmic") by Vijendar Mukunda, merged around
  v5.16 era.
- The quirk table has been growing steadily since then, with dozens of
  laptop-specific entries added over time.
- Record: Driver present since ~v5.16, quirk table is mature and
  regularly updated.

**Step 3.2: No Fixes tag** - Not applicable for a quirk addition.

**Step 3.3: File History**
- The last 20 commits to this file are ALL DMI quirk additions for
  various laptop models (HP, ASUS, MSI, Acer, Lenovo, etc.). This is the
  standard pattern.
- Already 6 MSI entries in the table (Bravo 15 B7ED, Bravo 15 C7VF,
  Bravo 17 D7VEK, Bravo 17 D7VF, Bravo 15 C7UCX, and now Vector A16 HX
  A8WHG).
- Record: [Standalone commit, no prerequisites] [Follows identical
  pattern to dozens of prior commits]

**Step 3.4: Author**
- Ihor Uzlov: first commit to this subsystem (likely the laptop owner)
- Applied by Mark Brown (ASoC maintainer), confirming maintainer
  acceptance
- Record: [End-user contributor, patch accepted by subsystem maintainer]

**Step 3.5: Dependencies**
- No dependencies. Pure table entry addition. The driver, table
  structure, and `acp6x_card` all exist in stable trees going back to
  ~v5.16.
- Record: [Fully standalone, no dependencies]

## PHASE 4: MAILING LIST

**Step 4.1-4.5**: Lore.kernel.org and patch.msgid.link are behind anti-
bot protections. However, the commit has Mark Brown's Signed-off-by,
confirming the ASoC maintainer reviewed and applied it. The Link tag
confirms it went through the standard mailing list submission process.
- Record: [Could not fetch lore discussion due to anti-bot measures]
  [Maintainer acceptance confirmed via SOB]

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1**: No functions modified. Only a data table entry added.

**Step 5.2-5.4**: The `yc_acp_quirk_table` is consumed by
`dmi_first_match()` in `acp6x_probe()`. The probe function is called
during platform device enumeration. The DMI matching is a standard
kernel mechanism - each entry only matches its specific hardware.
- Record: [Table consumed by acp6x_probe -> dmi_first_match] [Only
  activates on matching hardware]

**Step 5.5**: There are 100+ similar DMI entries in this same table. The
pattern is well-established.
- Record: [Identical pattern used 100+ times in this file]

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1**: The driver and table structure exist in stable trees from
~v5.16 onward. This is a 7.0 tree, and the underlying
`yc_acp_quirk_table` and `acp6x_card` are present.
- Record: [Driver exists in all active stable trees (5.15+)]

**Step 6.2**: This patch will apply cleanly to any kernel that has this
file, as it's a pure insertion into a table. Minor context conflicts
possible depending on how many other quirk entries are present in a
given stable tree, but these are trivially resolved.
- Record: [Clean or trivially resolvable apply expected]

**Step 6.3**: No prior fix for this specific laptop model.
- Record: [No related fixes already in stable]

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**: ASoC / AMD audio drivers - IMPORTANT subsystem. Audio is
critical for laptop users.
- Record: [sound/soc/amd/yc/] [IMPORTANT - audio hardware enablement for
  laptops]

**Step 7.2**: Very active - 20 recent commits are all DMI additions,
indicating ongoing hardware enablement.
- Record: [Very active, continuous stream of hardware quirk additions]

## PHASE 8: IMPACT AND RISK

**Step 8.1**: Affects users of MSI Vector A16 HX A8WHG laptops
specifically.
- Record: [Driver-specific / laptop-model-specific]

**Step 8.2**: The trigger is deterministic - every boot on this specific
laptop hardware. Without the quirk, the built-in microphone never works.
- Record: [Always triggers on affected hardware, microphone completely
  non-functional without fix]

**Step 8.3**: Failure mode: Built-in microphone completely non-
functional. This is a significant usability issue for laptop users (no
video calls, no voice recording, etc.).
- Record: [Complete hardware functionality loss, severity: HIGH for
  affected users]

**Step 8.4**:
- BENEFIT: Enables microphone on a real shipping laptop. HIGH for
  affected users.
- RISK: 7-line data addition affecting only one specific DMI-matched
  laptop. VERY LOW.
- Record: [High benefit for affected users, very low risk universally]

## PHASE 9: SYNTHESIS

**Step 9.1: Evidence FOR backporting:**
- Pure DMI quirk table addition (7 lines, data only)
- Fixes completely broken microphone on a real shipping laptop
- Identical pattern to 100+ existing entries and dozens of prior stable-
  backported commits
- Tested by the submitter on the actual hardware
- Applied by ASoC maintainer Mark Brown
- Zero regression risk (only triggers on exact DMI match)
- No dependencies, applies standalone

**Evidence AGAINST backporting:**
- None identified.

**Step 9.2: Stable Rules Checklist:**
1. Obviously correct? YES - identical to dozens of existing entries
2. Fixes a real bug? YES - broken microphone on real hardware
3. Important issue? YES - complete hardware non-functionality
4. Small and contained? YES - 7 lines, single table entry
5. No new features? YES - enables existing driver for existing hardware
6. Can apply to stable? YES - trivially

**Step 9.3: Exception Category:**
This is a **hardware quirk/workaround** - DMI match table entry for a
specific laptop model. This is an explicit exception category that is
automatically YES for stable.

**Step 9.4: Decision:**
This is a textbook stable backport candidate. It's a trivial DMI quirk
table addition that enables a broken microphone on a real laptop,
follows an identical pattern to hundreds of similar entries already in
the file, and carries zero regression risk.

## Verification

- [Phase 1] Parsed tags: Link to mailing list, Mark Brown (ASoC
  maintainer) SOB confirming acceptance
- [Phase 2] Diff analysis: +7 lines, pure DMI table entry addition in
  `yc_acp_quirk_table[]`
- [Phase 3] git blame: Driver introduced in commit fa991481b8b22a
  (~v5.16), present in all active stable trees
- [Phase 3] git log --grep="MSI": 4 prior MSI entries in this file, same
  pattern
- [Phase 3] git log -20: All 20 recent commits are DMI quirk additions,
  confirming standard pattern
- [Phase 5] Read acp6x_probe(): Confirmed table consumed via
  `dmi_first_match(yc_acp_quirk_table)` at line 791
- [Phase 6] File and driver exist in stable trees from v5.16+
- [Phase 7] ASoC AMD YC subsystem is actively maintained with continuous
  quirk additions
- [Phase 8] Failure mode: Complete microphone non-functionality on
  specific laptop, HIGH impact for affected users
- UNVERIFIED: Could not fetch lore.kernel.org discussion due to anti-bot
  measures; however, maintainer acceptance is confirmed via SOB

**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 aa62009331825..5ee149afb022c 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -493,6 +493,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "Bravo 17 D7VF"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Vector A16 HX A8WHG"),
+		}
+	},
 	{
 		.driver_data = &acp6x_card,
 		.matches = {
-- 
2.53.0

[PATCH AUTOSEL 6.18] 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:

Error: Failed to generate final synthesis

 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 e7f7b148b40e5..c76d339009a9b 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7211,6 +7211,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.18] ALSA: hda/realtek: Add mute LED quirk for HP Pavilion 15-eg0xxx

[Sasha Levin]

From: César Montoya <sprit152009@gmail.com>

[ Upstream commit 2f388b4e8fdd6b0f27cafd281658daacfd85807e ]

The HP Pavilion 15-eg0xxx with subsystem ID 0x103c87cb uses a Realtek
ALC287 codec with a mute LED wired to GPIO pin 4 (mask 0x10). The
existing ALC287_FIXUP_HP_GPIO_LED fixup already handles this correctly,
but the subsystem ID was missing from the quirk table.

GPIO pin confirmed via manual hda-verb testing:
  hda-verb SET_GPIO_MASK 0x10
  hda-verb SET_GPIO_DIRECTION 0x10
  hda-verb SET_GPIO_DATA 0x10

Signed-off-by: César Montoya <sprit152009@gmail.com>
Link: https://patch.msgid.link/20260321153603.12771-1-sprit152009@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 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 1959adb6c5189..c782a35f9239d 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6746,6 +6746,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8788, "HP OMEN 15", ALC285_FIXUP_HP_MUTE_LED),
 	SND_PCI_QUIRK(0x103c, 0x87b7, "HP Laptop 14-fq0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
 	SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED),
+	SND_PCI_QUIRK(0x103c, 0x87cb, "HP Pavilion 15-eg0xxx", ALC287_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x87cc, "HP Pavilion 15-eg0xxx", ALC287_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x87d3, "HP Laptop 15-gw0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
 	SND_PCI_QUIRK(0x103c, 0x87df, "HP ProBook 430 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED),
-- 
2.53.0

[PATCH AUTOSEL 6.18] ASoC: SOF: topology: reject invalid vendor array size in token parser

[Sasha Levin]

From: Cássio Gabriel <cassiogabrielcontato@gmail.com>

[ Upstream commit 215e5fe75881a7e2425df04aeeed47a903d5cd5d ]

sof_parse_token_sets() accepts array->size values that can be invalid
for a vendor tuple array header. In particular, a zero size does not
advance the parser state and can lead to non-progress parsing on
malformed topology data.

Validate array->size against the minimum header size and reject values
smaller than sizeof(*array) before parsing. This preserves behavior for
valid topologies and hardens malformed-input handling.

Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://patch.msgid.link/20260319-sof-topology-array-size-fix-v1-1-f9191b16b1b7@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 sound/soc/sof/topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index b6d5c8024f8cf..4c8dba285408a 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -736,7 +736,7 @@ static int sof_parse_token_sets(struct snd_soc_component *scomp,
 		asize = le32_to_cpu(array->size);
 
 		/* validate asize */
-		if (asize < 0) { /* FIXME: A zero-size array makes no sense */
+		if (asize < sizeof(*array)) {
 			dev_err(scomp->dev, "error: invalid array size 0x%x\n",
 				asize);
 			return -EINVAL;
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] ALSA: pcm: Use pcm_lib_apply_appl_ptr() in x32 sync_ptr

[Sasha Levin]

From: Cássio Gabriel <cassiogabrielcontato@gmail.com>

[ Upstream commit 1e512ac1254c8e370dd18efe9da4dfc92492cdc5 ]

snd_pcm_ioctl_sync_ptr_x32() still handles incoming appl_ptr updates
differently from the other SYNC_PTR paths. The native handler and the
32-bit compat handler both pass appl_ptr through pcm_lib_apply_appl_ptr(),
but the x32 handler still writes control->appl_ptr directly.

That direct assignment skips the common appl_ptr validation against
runtime->boundary and also bypasses the substream ack() callback.
This makes the x32 ioctl path behave differently from the native and
compat32 cases, and it can miss the driver notification that explicit
appl_ptr synchronization relies on.

Use pcm_lib_apply_appl_ptr() for x32 too, so appl_ptr updates are
validated consistently and drivers relying on ack() notifications
see the same behavior.

Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>
Link: https://patch.msgid.link/20260321-alsa-pcm-x32-sync-ptr-v1-1-02ce655657c6@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information I need. Let me compile my complete
analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `ALSA: pcm` (sound/core PCM subsystem)
- Action verb: "Use" — indicates replacing incorrect implementation with
  the correct one
- Summary: Make x32 sync_ptr use `pcm_lib_apply_appl_ptr()` instead of
  direct assignment
Record: [ALSA: pcm] [Use] [Apply correct appl_ptr update function in x32
ioctl path]

**Step 1.2: Tags**
- `Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com>` —
  author
- `Link: https://patch.msgid.link/20260321-alsa-pcm-x32-sync-
  ptr-v1-1-02ce655657c6@gmail.com` — v1, patch 1/1 (standalone)
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>` — ALSA subsystem
  maintainer accepted the patch
- No Fixes: tag (expected for review candidates)
- No Reported-by: (found by code inspection)
Record: Patch accepted by subsystem maintainer (Takashi Iwai). Single
standalone patch.

**Step 1.3: Commit Body Analysis**
- Bug described: x32 sync_ptr handler directly writes
  `control->appl_ptr` instead of using `pcm_lib_apply_appl_ptr()`
- Consequence 1: Skips appl_ptr validation against `runtime->boundary`
- Consequence 2: Bypasses the `substream->ops->ack()` callback
- Symptom: Inconsistent behavior between x32 and native/compat32 paths;
  drivers relying on ack() won't get notifications
- The commit explicitly notes the FIXME comment that previously flagged
  this issue
Record: Missing boundary validation + missing ack() callback in x32
path. Drivers using explicit appl_ptr sync see wrong behavior.

**Step 1.4: Hidden Bug Fix Detection**
This IS a bug fix despite not using "fix" in the subject. "Use
pcm_lib_apply_appl_ptr()" means "stop skipping validation and driver
callbacks." The existing FIXME comment in the old code explicitly
acknowledged missing boundary handling.
Record: Yes, this is a real bug fix — restores missing validation and
driver notification.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- Files: `sound/core/pcm_compat.c` (+4, -3 net change)
- Function modified: `snd_pcm_ioctl_sync_ptr_x32()`
- Scope: Single-file, single-function surgical fix
Record: 1 file, ~7 lines changed, single function, minimal scope.

**Step 2.2: Code Flow Change**
Before: Inside `scoped_guard(pcm_stream_lock_irq)`:
```c
/* FIXME: we should consider the boundary for the sync from app */
if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL))
    control->appl_ptr = scontrol.appl_ptr;
else
    scontrol.appl_ptr = control->appl_ptr % boundary;
```

After:
```c
if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL)) {
    err = pcm_lib_apply_appl_ptr(substream, scontrol.appl_ptr);
    if (err < 0)
        return err;
} else {
    scontrol.appl_ptr = control->appl_ptr % boundary;
}
```

The direct assignment is replaced with `pcm_lib_apply_appl_ptr()` which:
1. Validates `appl_ptr >= runtime->boundary` → returns `-EINVAL`
2. Checks NO_REWINDS constraint
3. Assigns `runtime->control->appl_ptr = appl_ptr`
4. Calls `substream->ops->ack()` and rolls back on failure
5. Emits `trace_applptr()` tracepoint
Record: Before = raw assignment without validation. After = validated,
with ack callback and error handling.

**Step 2.3: Bug Mechanism**
Category: Logic/correctness fix — missing validation and missing
callback invocation.
- Boundary validation bypass could allow setting appl_ptr to invalid
  value
- Missing ack() means audio drivers relying on explicit sync won't
  receive DMA buffer notifications
Record: Correctness bug — missing validation + missing driver
notification on x32 ioctl path.

**Step 2.4: Fix Quality**
- Obviously correct: makes x32 match the native handler
  (pcm_native.c:3140), compat32 handler (pcm_native.c:3242), and buggy
  compat handler (pcm_compat.c:504) — all already use
  `pcm_lib_apply_appl_ptr()`
- Minimal and surgical: replaces 2 lines with 4 lines in one function
- Regression risk: Very low — the error return path is new but is the
  same pattern used by all other sync_ptr paths
Record: Fix is obviously correct by comparison with 3 other identical
code paths. Minimal. Very low regression risk.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
- The x32 handler was introduced by commit `513ace79b657e2` (Takashi
  Iwai, 2016-02-28): "ALSA: pcm: Fix ioctls for X32 ABI"
- The `scoped_guard` refactor was applied in `650224fe8d5f6d` (Takashi
  Iwai, 2024-02-27)
- The buggy direct assignment has been present since 2016
Record: Buggy code introduced in 2016 (v4.6 era). Present in all active
stable trees.

**Step 3.2: Related Fixes**
Commit `9027c4639ef1` (2017-05-25): "ALSA: pcm: Call ack() whenever
appl_ptr is updated" — introduced `pcm_lib_apply_appl_ptr()` and added
it to the native sync_ptr handler, but did NOT update the x32 handler.

Commit `2e2832562c877` (2021-07-12): "ALSA: pcm: Call substream ack()
method upon compat mmap commit" — fixed the same bug for the compat32
path. **This commit had `Fixes: 9027c4639ef1` and `Cc:
<stable@vger.kernel.org>`**, establishing precedent that this class of
bug is stable-worthy.
Record: Identical bug in compat32 was fixed (2e2832562c877) with
explicit stable nomination. x32 was missed.

**Step 3.3: File History**
Recent changes to pcm_compat.c are mostly refactoring (scoped_guard,
sync_ptr_get_user macros, kfree cleanup). No other pending fixes.
Record: Standalone fix, no dependencies on uncommitted work.

**Step 3.4: Author**
Author (Cássio Gabriel) has one other commit in the sound subsystem (SOF
topology parser). Patch was accepted by Takashi Iwai, the ALSA subsystem
maintainer.
Record: Patch reviewed and accepted by subsystem maintainer.

**Step 3.5: Dependencies**
This patch depends on the `scoped_guard` refactor (`650224fe8d5f6`, in
v6.12+) and the `snd_pcm_sync_ptr_get_user` macro refactor
(`2acd83beb4d3f`, not in any current stable). For older stable trees,
context adaptation would be needed but the core change is the same.
Record: Clean apply on v7.0. Minor context adaptation needed for older
stable trees due to locking and macro differences.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Patch Discussion**
- `b4 dig` could not find the patch by commit hash (this is a 7.0
  autosel candidate). The patch link uses msgid `20260321-alsa-
  pcm-x32-sync-ptr-v1-1-02ce655657c6@gmail.com`.
- lore.kernel.org was blocked by anti-bot protection.
- The patch is v1, patch 1/1 — a single standalone fix.
Record: Single standalone patch, v1. Could not access lore due to anti-
bot protection.

**Step 4.2: Reviewers**
- Signed-off-by Takashi Iwai (ALSA maintainer) — the most authoritative
  reviewer for this code.
Record: Subsystem maintainer reviewed and merged.

**Step 4.3: Bug Report**
No explicit bug report — found by code inspection (comparing x32 path to
native/compat32).
Record: Found by code audit comparing inconsistent ioctl paths.

**Step 4.4: Related Patches**
The earlier compat32 fix (`2e2832562c877`) explicitly requested stable
backport. This x32 fix addresses the exact same gap.
Record: Prior compat32 fix was explicitly Cc: stable.

**Step 4.5: Stable History**
The compat32 variant of this fix was backported to stable. The x32
variant was not previously submitted.
Record: Identical bug class was previously deemed stable-worthy.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: Functions Modified**
- `snd_pcm_ioctl_sync_ptr_x32()` — the only function changed
Record: Single function modified.

**Step 5.2: Callers**
`snd_pcm_ioctl_sync_ptr_x32()` is called from `snd_pcm_ioctl_compat()`
(line 594) when `in_x32_syscall()` is true and the ioctl is
`__SNDRV_PCM_IOCTL_SYNC_PTR64`. This is reachable from userspace via the
compat ioctl syscall from any x32 process using PCM.
Record: Reachable from userspace ioctl on x32 ABI.

**Step 5.3-5.4: Call Chain**
Userspace → compat_ioctl syscall → `snd_pcm_ioctl_compat()` →
`snd_pcm_ioctl_sync_ptr_x32()` → (now) `pcm_lib_apply_appl_ptr()` →
`substream->ops->ack()`.
Record: Directly reachable from userspace syscalls.

**Step 5.5: Similar Patterns**
All 3 other sync_ptr paths (native, compat32, buggy-compat) already use
`pcm_lib_apply_appl_ptr()`. The x32 path was the only outlier.
Record: 3 out of 4 sync_ptr paths already correct; this fixes the 4th.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable Trees**
- `9027c4639ef1` (introduced pcm_lib_apply_appl_ptr) is in v5.10, v5.15,
  v6.1, v6.6, and all newer trees
- `513ace79b657e2` (x32 handler) is in all stable trees since v4.6
- Therefore the bug exists in ALL active stable trees
Record: Bug present in v5.10, v5.15, v6.1, v6.6, v6.12, v6.14.

**Step 6.2: Backport Complications**
- v6.12+: `scoped_guard` present, but `snd_pcm_sync_ptr_get_user` macro
  absent → minor context conflict
- v6.6 and older: neither `scoped_guard` nor the get_user macro present
  → needs adaptation of surrounding context, but core fix is identical
Record: Minor context adaptation needed. Core semantic change is
version-independent.

**Step 6.3: Related Fixes in Stable**
The compat32 fix (`2e2832562c877`) is already in stable trees. The x32
fix is not.
Record: Compat32 variant already in stable. X32 variant missing.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem Criticality**
- ALSA PCM core — IMPORTANT. Audio is widely used; PCM is the
  fundamental audio interface.
- X32 ABI narrows the affected users but is still a supported kernel
  feature.
Record: IMPORTANT subsystem, platform-specific (x86_64 with X32 ABI).

**Step 7.2: Activity**
The sound/core/pcm_compat.c file has moderate activity with refactoring
and bug fixes.
Record: Active, maintained subsystem.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Who Is Affected**
X32 ABI users on x86-64 who use PCM audio with drivers that implement
the ack() callback. While X32 is niche, the bug causes real misbehavior.
Record: Platform-specific (X86_X32_ABI), affects audio applications
using mmap/sync_ptr.

**Step 8.2: Trigger Conditions**
Any x32 application calling `SNDRV_PCM_IOCTL_SYNC_PTR` with
`!SNDRV_PCM_SYNC_PTR_APPL` (i.e., updating appl_ptr). This is a normal
PCM operation.
Record: Normal PCM operation on x32 applications. Common trigger.

**Step 8.3: Failure Mode Severity**
- Missing ack() → audio driver doesn't know about pointer update →
  potentially incorrect DMA behavior, audio glitches, or silent audio
  failure. MEDIUM-HIGH.
- Missing boundary validation → appl_ptr could be set to invalid value →
  potential for incorrect pointer arithmetic. MEDIUM.
Record: Severity MEDIUM-HIGH — audio misbehavior/corruption for x32
users.

**Step 8.4: Risk-Benefit**
- Benefit: Makes x32 path correct and consistent. Prevents real audio
  issues for x32 users. Precedent: compat32 fix was Cc: stable.
- Risk: Very low. 4 net lines changed. Replaces direct assignment with a
  well-tested function used by all other code paths. Same pattern as 3
  existing call sites.
Record: HIGH benefit (correctness fix with stable precedent), VERY LOW
risk.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Compilation**

FOR backporting:
- Fixes a real consistency bug: x32 path skips validation and ack()
  callback
- Identical bug in compat32 was fixed with explicit `Cc:
  stable@vger.kernel.org` (commit `2e2832562c877`)
- Small, surgical fix: ~7 lines in one function
- Obviously correct: makes x32 match 3 other sync_ptr paths
- Accepted by ALSA maintainer (Takashi Iwai)
- Bug has existed since 2017 (when ack was introduced) — all stable
  trees affected
- Removes a FIXME comment that explicitly flagged the issue

AGAINST backporting:
- X32 ABI is niche (smaller user base)
- Needs minor context adaptation for older stable trees
- No explicit user report of the bug being triggered

**Step 9.2: Stable Rules Checklist**
1. Obviously correct? **YES** — identical pattern to 3 existing call
   sites
2. Fixes a real bug? **YES** — missing validation + missing driver
   callback
3. Important issue? **YES** — audio misbehavior, potential data
   corruption
4. Small and contained? **YES** — 7 lines in one function
5. No new features? **YES** — correctness fix only
6. Can apply to stable? **YES** with minor context adaptation

**Step 9.3: Exception Categories**
Not applicable — this is a standard correctness bug fix.

**Step 9.4: Decision**
The evidence strongly supports backporting. The identical bug class was
previously backported for compat32 with explicit stable nomination. The
fix is small, obviously correct, and makes the x32 path consistent with
all other sync_ptr paths.

## Verification

- [Phase 1] Parsed tags: Link with v1-1 confirms standalone patch. SOB
  from Takashi Iwai confirms maintainer acceptance.
- [Phase 2] Diff analysis: Replaces `control->appl_ptr =
  scontrol.appl_ptr` with `pcm_lib_apply_appl_ptr(substream,
  scontrol.appl_ptr)` + error check. Net +4/-3 lines.
- [Phase 3] git blame: Buggy code introduced in 513ace79b657e2 (2016).
  pcm_lib_apply_appl_ptr introduced in 9027c4639ef1 (2017).
- [Phase 3] git show 2e2832562c877: Confirmed identical compat32 fix
  with Fixes: 9027c4639ef1 and Cc: stable@vger.kernel.org.
- [Phase 3] git merge-base: 9027c4639ef1 is in v5.10, v5.15, v6.6.
  513ace79b657e2 is in v6.6. Bug exists in all active stable trees.
- [Phase 4] b4 dig -c 2e2832562c877: Found compat32 fix thread
  confirming stable intent.
- [Phase 4] Could not fetch lore for this patch (anti-bot protection).
  UNVERIFIED: specific reviewer comments.
- [Phase 5] Grep: snd_pcm_ioctl_sync_ptr_x32() called from
  snd_pcm_ioctl_compat() at line 594, reachable via compat ioctl
  syscall.
- [Phase 5] Confirmed 3 other sync_ptr paths already use
  pcm_lib_apply_appl_ptr: pcm_native.c:3140, pcm_native.c:3242,
  pcm_compat.c:504.
- [Phase 6] scoped_guard in v6.12+. sync_ptr_get_user not in any stable.
  Minor adaptation needed for backport.
- [Phase 6] Read pcm_lib_apply_appl_ptr (pcm_lib.c:2227-2268): validates
  boundary, checks NO_REWINDS, calls ack(), rolls back on failure.
- [Phase 8] Failure mode: missing ack() → audio driver not notified of
  pointer update → MEDIUM-HIGH severity.

**YES**

 sound/core/pcm_compat.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/core/pcm_compat.c b/sound/core/pcm_compat.c
index e71f393d3b018..5313f50f17da5 100644
--- a/sound/core/pcm_compat.c
+++ b/sound/core/pcm_compat.c
@@ -430,11 +430,13 @@ static int snd_pcm_ioctl_sync_ptr_x32(struct snd_pcm_substream *substream,
 	if (!boundary)
 		boundary = 0x7fffffff;
 	scoped_guard(pcm_stream_lock_irq, substream) {
-		/* FIXME: we should consider the boundary for the sync from app */
-		if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL))
-			control->appl_ptr = scontrol.appl_ptr;
-		else
+		if (!(sflags & SNDRV_PCM_SYNC_PTR_APPL)) {
+			err = pcm_lib_apply_appl_ptr(substream, scontrol.appl_ptr);
+			if (err < 0)
+				return err;
+		} else {
 			scontrol.appl_ptr = control->appl_ptr % boundary;
+		}
 		if (!(sflags & SNDRV_PCM_SYNC_PTR_AVAIL_MIN))
 			control->avail_min = scontrol.avail_min;
 		else
-- 
2.53.0

[PATCH AUTOSEL 6.18] 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:

Error: Failed to generate final synthesis

 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 7a6b4ec3a6990..feecf3e4e38b4 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2845,6 +2845,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

[PATCH AUTOSEL 7.0-5.10] ASoC: Intel: bytcr_rt5640: Fix MCLK leak on platform_clock_control error

[Sasha Levin]

From: Aravind Anilraj <aravindanilraj0702@gmail.com>

[ Upstream commit a02496a29463e7f0d1643e83aab28adb3dd03f1a ]

If byt_rt5640_prepare_and_enable_pll1() fails, the function returns
without calling clk_disable_unprepare() on priv->mclk, which was
already enabled earlier in the same code path. Add the missing
cleanup call to prevent the clock from leaking.

Signed-off-by: Aravind Anilraj <aravindanilraj0702@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20260401220507.23557-2-aravindanilraj0702@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for a comprehensive analysis. Let
me compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `ASoC: Intel: bytcr_rt5640`
- Action verb: **Fix** (explicit bug fix)
- Summary: Fix MCLK clock leak on `platform_clock_control` error path.

**Step 1.2: Tags**
- `Signed-off-by: Aravind Anilraj <aravindanilraj0702@gmail.com>` -
  Author
- `Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>` - Intel
  audio developer reviewed
- `Link: https://patch.msgid.link/20260401220507.23557-2-
  aravindanilraj0702@gmail.com` - Lore link
- `Signed-off-by: Mark Brown <broonie@kernel.org>` - Merged by ASoC
  subsystem maintainer
- No Fixes: tag (expected for this review pipeline)
- No Cc: stable (expected)

**Step 1.3: Commit Body**
The body clearly describes the bug: When
`byt_rt5640_prepare_and_enable_pll1()` fails, the function returns
without calling `clk_disable_unprepare()` on `priv->mclk`, which was
already enabled by `clk_prepare_enable()`. This is a textbook resource
leak on an error path.

**Step 1.4: Hidden Bug Fix Detection**
Not hidden — this is explicitly labeled as a fix. The word "Fix" is in
the subject, and the mechanism (clock leak) is clearly described.

Record: [ASoC Intel bytcr_rt5640] [fix] [MCLK clock leak on PLL1 enable
error path] [Not a hidden fix - explicitly labeled]

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `sound/soc/intel/boards/bytcr_rt5640.c`
- +2 lines added (only)
- Function modified: `platform_clock_control()`
- Scope: Single-file surgical fix, extremely minimal

**Step 2.2: Code Flow Change**
Before: If `byt_rt5640_prepare_and_enable_pll1()` fails at line 291,
`ret < 0`, the function falls through to line 305 and returns the error,
but `priv->mclk` remains enabled (was enabled at line 286).

After: If `byt_rt5640_prepare_and_enable_pll1()` fails,
`clk_disable_unprepare(priv->mclk)` is called immediately, releasing the
clock before the error return.

**Step 2.3: Bug Mechanism**
Category: **Error path / resource leak fix**. The clock was enabled via
`clk_prepare_enable()` but not cleaned up on failure of the subsequent
PLL1 setup. This is a classic missing-cleanup-on-error pattern.

**Step 2.4: Fix Quality**
- Obviously correct: YES. The symmetry is clear — `clk_prepare_enable()`
  succeeded, so on failure we must call `clk_disable_unprepare()`.
- Minimal/surgical: YES. Only 2 lines added.
- Regression risk: Extremely low. The added code only runs on the error
  path when PLL1 setup fails.

Record: [1 file, +2 lines, platform_clock_control()] [Resource leak fix:
MCLK left enabled on PLL1 failure] [Obviously correct, zero regression
risk]

---

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The buggy code pattern was introduced by commit `bcd9a325f0b0f4` (Hans
de Goede, 2018-05-08): "ASoC: Intel: bytcr_rt5640: Configure PLL1 before
using it". This commit added the `byt_rt5640_prepare_and_enable_pll1()`
call after `clk_prepare_enable()` but failed to add cleanup on its
failure path.

The MCLK handling was further cleaned up by commit `a15ca6e3b8a21f`
(Andy Shevchenko, 2021-10-07), which removed the `BYT_RT5640_MCLK_EN`
quirk guard but preserved the same missing-cleanup bug.

**Step 3.2: Fixes Tag**
No Fixes: tag present (expected). The root cause commit is
`bcd9a325f0b0f4` from 2018. Verified present in v6.1, v6.6, and all
active stable trees.

**Step 3.3: File History**
Recent changes to the file are mostly DMI quirk additions and cosmetic
refactoring. No conflicting changes to the `platform_clock_control()`
function.

**Step 3.4: Author**
Aravind Anilraj has no other commits in this tree — likely a new
contributor. However, the patch was reviewed by Cezary Rojewski (Intel
audio team) and merged by Mark Brown (ASoC maintainer), providing strong
quality assurance.

**Step 3.5: Dependencies**
None. The fix is 2 self-contained lines. No new functions, structures,
or APIs involved.

Record: [Bug introduced 2018 in bcd9a325f0b0f4, present in all stable
trees] [Reviewed by Intel developer, merged by ASoC maintainer]
[Standalone fix, no dependencies]

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.2**: Lore was inaccessible due to anti-bot protections.
However, the `Link:` tag confirms this was submitted and reviewed via
normal mailing list processes. The `Reviewed-by: Cezary Rojewski` (Intel
audio) confirms expert review. Mark Brown (ASoC maintainer) merged it.

**Step 4.3**: No Reported-by tag — this was found by code inspection,
not a user report.

**Step 4.4**: The same bug exists in sibling driver `bytcr_rt5651.c`
(lines 206-231) — identical pattern of `clk_prepare_enable()` followed
by `byt_rt5651_prepare_and_enable_pll1()` without cleanup on failure.
This confirms it's a systematic, real bug.

Record: [Reviewed by Intel audio developer, merged by ASoC maintainer]
[Same bug pattern confirmed in sibling driver bytcr_rt5651]

---

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1**: Function modified: `platform_clock_control()`

**Step 5.2: Callers**
`platform_clock_control` is registered as a DAPM supply widget callback:

```340:350:sound/soc/intel/boards/bytcr_rt5640.c
SND_SOC_DAPM_SUPPLY("Platform Clock", SND_SOC_NOPM, 0, 0,
                    platform_clock_control, SND_SOC_DAPM_PRE_PMU |
                    SND_SOC_DAPM_POST_PMD),
```

This is called by the DAPM framework every time audio playback/capture
starts or stops — a **common, hot path** for any Bay Trail tablet/laptop
user.

**Step 5.3-5.4**: `byt_rt5640_prepare_and_enable_pll1()` calls
`snd_soc_dai_set_pll()` and `snd_soc_dai_set_sysclk()`, both of which
can fail (e.g., codec communication error). The leak path is reachable
from normal audio usage.

**Step 5.5**: Identical bug pattern exists in `bytcr_rt5651.c`
(confirmed via grep).

Record: [platform_clock_control called on every audio start/stop via
DAPM] [Bug reachable from normal user audio usage] [Same pattern in
sibling driver]

---

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

**Step 6.1**: Verified that both the root cause commit `bcd9a325f0b0f4`
(2018) and the MCLK refactor `a15ca6e3b8a21f` (2021) are ancestors of
v6.1 and v6.6. The buggy code exists in **all active stable trees**.

**Step 6.2**: The only potential backport complication is commit
`e6995aa816557` (DAPM API conversion, Nov 2025), which changed line 276
from the old DAPM API to the new one. This commit is only in v6.19+. For
v6.1/v6.6/v6.12/v6.18, the context may differ slightly on line 276, but
the fix (+2 lines after line 291) is so localized it should apply
cleanly or with trivial fuzz.

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

Record: [Bug exists in all active stable trees v6.1+] [Clean apply or
trivial fuzz expected] [No existing fixes in stable]

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1**: Subsystem: `sound/soc/intel/boards` — Intel ASoC machine
drivers. Criticality: **IMPORTANT**. Bay Trail RT5640/RT5651 is used on
many x86 tablets and low-cost laptops (Asus T100, Lenovo IdeaPad,
various Atom-based devices).

**Step 7.2**: The file has moderate activity (DMI quirks being added
regularly, confirming active hardware user base).

Record: [ASoC Intel Bay Trail boards] [IMPORTANT — real hardware with
active users]

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1**: Affected: Users of Intel Bay Trail devices with RT5640
codec (common Atom-based tablets and laptops).

**Step 8.2**: Trigger: Every audio playback start when
`byt_rt5640_prepare_and_enable_pll1()` fails (e.g., I2C communication
error with codec). The clock leak accumulates — each failure leaves MCLK
enabled, potentially causing power management issues and preventing the
clock from being properly reused.

**Step 8.3**: Severity: **MEDIUM-HIGH**. Clock resource leak can cause:
- Power management problems (clock stays active preventing deeper sleep
  states)
- Potential clock framework warnings/errors on subsequent audio
  operations
- Accumulated leaks over time

**Step 8.4**: Risk-Benefit:
- BENEFIT: Fixes a real resource leak in a commonly-used audio driver on
  real hardware
- RISK: Extremely low — 2 lines added to an error path only, obviously
  correct symmetry with `clk_prepare_enable`/`clk_disable_unprepare`
- Ratio: **Very favorable**

Record: [Bay Trail device users] [Triggered on PLL1 failure during audio
start] [Clock leak -> power management issues] [Extremely low risk,
moderate-high benefit]

---

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes a real resource leak (clock not unprepared on error path)
- Tiny, surgical fix: only +2 lines
- Obviously correct: symmetric cleanup of `clk_prepare_enable()`
- Reviewed by Intel audio developer (Cezary Rojewski)
- Merged by ASoC maintainer (Mark Brown)
- Bug has existed since 2018, present in all stable trees
- Affects real hardware (Bay Trail tablets/laptops)
- Same bug pattern confirmed in sibling driver (bytcr_rt5651)
- No dependencies, self-contained fix

AGAINST backporting:
- No user-reported symptoms (found by code inspection)
- Minor context conflict possible on older stable trees (trivially
  resolvable)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** — reviewed by Intel, symmetric
   cleanup pattern
2. Fixes a real bug? **YES** — clock resource leak on error path
3. Important issue? **YES** — resource leak affecting power management
   on real devices
4. Small and contained? **YES** — 2 lines, single file, single function
5. No new features or APIs? **YES** — purely a bug fix
6. Can apply to stable? **YES** — clean or trivial fuzz

**Step 9.3: Exception Categories**
Not an exception case — this is a straightforward bug fix.

**Step 9.4: Decision**
This is a textbook stable-worthy fix: tiny, obviously correct, fixes a
real resource leak in a driver used on real hardware, with expert
review. The risk is near zero.

---

## Verification

- [Phase 1] Parsed tags: Reviewed-by Cezary Rojewski (Intel), Link to
  lore, Signed-off-by Mark Brown (maintainer)
- [Phase 2] Diff analysis: +2 lines in error path of
  `platform_clock_control()`, adds missing `clk_disable_unprepare()`
  after `byt_rt5640_prepare_and_enable_pll1()` failure
- [Phase 3] git blame: Bug introduced by `bcd9a325f0b0f4` (Hans de
  Goede, 2018), MCLK refactored by `a15ca6e3b8a21f` (Andy Shevchenko,
  2021)
- [Phase 3] `git merge-base --is-ancestor`: Both root cause commits
  verified present in v6.1 and v6.6
- [Phase 3] Author check: New contributor, but patch reviewed by Intel
  developer and merged by ASoC maintainer
- [Phase 4] Lore inaccessible (anti-bot), but Link: tag confirms normal
  review process
- [Phase 5] DAPM widget registration confirmed: `platform_clock_control`
  called on every audio PMU/PMD event — common path
- [Phase 5] Grep confirmed identical bug pattern in sibling
  `bytcr_rt5651.c` (lines 206-231)
- [Phase 6] `e6995aa816557` (DAPM conversion) only in v6.19+; fix
  context should apply cleanly to v6.1-v6.18 with trivial fuzz at most
- [Phase 6] No existing fixes for this issue in stable
- [Phase 8] Failure mode: Clock resource leak on audio error path,
  severity MEDIUM-HIGH

**YES**

 sound/soc/intel/boards/bytcr_rt5640.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/intel/boards/bytcr_rt5640.c b/sound/soc/intel/boards/bytcr_rt5640.c
index 103e0b445603f..e4c21c9c5b38c 100644
--- a/sound/soc/intel/boards/bytcr_rt5640.c
+++ b/sound/soc/intel/boards/bytcr_rt5640.c
@@ -289,6 +289,8 @@ static int platform_clock_control(struct snd_soc_dapm_widget *w,
 			return ret;
 		}
 		ret = byt_rt5640_prepare_and_enable_pll1(codec_dai, 48000);
+		if (ret < 0)
+			clk_disable_unprepare(priv->mclk);
 	} else {
 		/*
 		 * Set codec clock source to internal clock before
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ALSA: hda/realtek: Add quirk for HP Spectre x360 14-ea

[Sasha Levin]

From: songxiebing <songxiebing@kylinos.cn>

[ Upstream commit 882321ccaeea52dd645dff98bfea2f92b286e673 ]

HP Spectre x360 Convertible 14-ea0xxx (2021 model or so)
doesn't make produce sound,The Bang & Olufsen speaker amplifier
is not enabled.

Root causing:
The PCI subsystem ID is 103c:0000 (HP left it unset), while the codec
subsystem ID is 103c:885b. The vendor-wide catch-all
SND_PCI_QUIRK_VENDOR(0x103c, "HP", ALC269_FIXUP_HP_MUTE_LED) matches
103c:0000 before the codec SSID fallback is reached, so
ALC245_FIXUP_HP_X360_AMP never applies.

So add the quirk in alc269_fixup_tbl.

Reported-by: dzidmail <dzidmail@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221341
Signed-off-by: songxiebing <songxiebing@kylinos.cn>
Link: https://patch.msgid.link/20260413011854.96520-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:

Now I have all the information needed for a thorough analysis. Let me
compile the findings.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `ALSA: hda/realtek`
- Action: "Add quirk"
- Summary: Adding a codec SSID quirk for HP Spectre x360 14-ea to enable
  its speaker amplifier.
- Record: [ALSA/HDA/Realtek] [Add] [Hardware quirk for HP Spectre x360
  14-ea speaker amp]

**Step 1.2: Tags**
- Reported-by: dzidmail <dzidmail@gmail.com> — a real user reporting the
  issue
- Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221341 — filed bug
  report
- Signed-off-by: songxiebing <songxiebing@kylinos.cn> — author, a
  recurring HDA contributor
- Link: patch.msgid.link — lore submission link
- Signed-off-by: Takashi Iwai <tiwai@suse.de> — the HDA subsystem
  maintainer applied it
- Record: User-reported bug with bugzilla tracker. HDA maintainer
  Takashi Iwai merged it directly.

**Step 1.3: Commit Body**
- Bug: HP Spectre x360 14-ea (2021 model) produces no sound. Bang &
  Olufsen speaker amplifier is not enabled.
- Root cause explained clearly: PCI subsystem ID is `103c:0000` (HP left
  it unset). The vendor catch-all `SND_PCI_QUIRK_VENDOR(0x103c, "HP",
  ALC269_FIXUP_HP_MUTE_LED)` matches first because it checks PCI SSID,
  preventing the codec SSID fallback from ever reaching
  `ALC245_FIXUP_HP_X360_AMP`.
- Fix: Use `HDA_CODEC_QUIRK(0x103c, 0x885b, ...)` which sets
  `match_codec_ssid=true`, causing matching against codec SSID
  `103c:885b` in the primary loop, before vendor catch-all kicks in.
- Record: [No audio output] [Speaker amp not enabled] [Incorrect quirk
  applied due to unset PCI SSID]

**Step 1.4: Hidden Bug Fix?**
This is an explicit hardware quirk fix. Not hidden — it directly
addresses a broken hardware scenario. The commit explains the exact
mechanism.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `sound/hda/codecs/realtek/alc269.c`
- 1 line added: `HDA_CODEC_QUIRK(0x103c, 0x885b, "HP Spectre x360
  14-ea", ALC245_FIXUP_HP_X360_AMP),`
- Scope: Single-line surgical addition to an existing quirk table.
- Record: [+1 line in alc269_fixup_tbl quirk table] [Minimal scope]

**Step 2.2: Code Flow Change**
- Before: No entry for codec SSID `103c:885b`. The vendor catch-all
  applies `ALC269_FIXUP_HP_MUTE_LED`, which doesn't toggle the GPIO pin
  needed for the B&O speaker amp.
- After: `HDA_CODEC_QUIRK` with `match_codec_ssid=true` matches in the
  primary loop via codec SSID → `ALC245_FIXUP_HP_X360_AMP` applied →
  GPIO toggled → speaker amp enabled.

**Step 2.3: Bug Mechanism**
Category (h): Hardware workaround / codec quirk. The existing
`ALC245_FIXUP_HP_X360_AMP` fixup already exists and works for sibling
models (0x87f6, 0x87f7). This just adds the correct matching entry for a
model with an unset PCI SSID.

**Step 2.4: Fix Quality**
- Obviously correct: Uses the well-established `HDA_CODEC_QUIRK` pattern
  already present ~10 times in this same table.
- Minimal: Single table entry addition.
- Regression risk: Essentially zero. Only affects devices with codec
  SSID `103c:885b`.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: Blame**
The existing `ALC245_FIXUP_HP_X360_AMP` entries for sibling models
(0x87f6, 0x87f7) date back to commit `aeeb85f26c3bb` (2025-07-09 file
split), but originate from much earlier. The fixup function
`alc245_fixup_hp_x360_amp` exists at line 1448.

**Step 3.2: Fixes tag**
No Fixes: tag — expected for this type of quirk addition.

**Step 3.3: File History**
Recent history shows a steady stream of similar quirk additions (Lenovo
Yoga, Acer Swift, HP Laptop, Samsung, ASUS, Framework). This is routine
maintenance for this file.

**Step 3.4: Author**
songxiebing is a recurring HDA contributor with 4 other commits in this
tree. Patch was merged by Takashi Iwai, the HDA subsystem maintainer.

**Step 3.5: Dependencies**
No dependencies. All required infrastructure exists in the 7.0 tree:
- `HDA_CODEC_QUIRK` macro (verified in
  `sound/hda/common/hda_local.h:314-320`)
- `ALC245_FIXUP_HP_X360_AMP` fixup (line 4841-4846)
- `alc245_fixup_hp_x360_amp` function (line 1448)
- `match_codec_ssid` matching logic in `auto_parser.c`

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1-4.5:** Lore and bugzilla were unreachable due to anti-bot
protections. However, the commit message provides sufficient context:
- Bug reported via bugzilla.kernel.org (#221341)
- Patch submitted and applied within days by the subsystem maintainer
- The Link: tag confirms it went through normal mailing list review

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.2:** The affected function `alc245_fixup_hp_x360_amp` (line
1448) toggles GPIO pin 0x01 to enable the speaker amplifier. This is
called during HDA codec initialization. Without this quirk matching, the
amplifier stays off = no speaker output.

**Step 5.3-5.4:** The matching logic in `snd_hda_pick_fixup`
(`auto_parser.c:1066-1080`) walks the quirk table linearly. With
`match_codec_ssid=true`, the new entry is checked against codec SSID on
every probe of this codec. The call chain is: codec probe →
`snd_hda_pick_fixup` → table walk → match codec SSID → apply fixup.

**Step 5.5:** Similar `HDA_CODEC_QUIRK` entries exist for the same
purpose (ASUS, Lenovo devices with mismatched PCI/codec SSIDs). This is
a well-established pattern.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1:** The `HDA_CODEC_QUIRK` infrastructure and
`ALC245_FIXUP_HP_X360_AMP` fixup exist in the 7.0 stable tree. In older
trees (6.x), the file path would be `sound/pci/hda/patch_realtek.c` and
`HDA_CODEC_QUIRK` may need to be verified.

**Step 6.2:** For 7.0 specifically, the patch should apply with at most
minor context offset. The surrounding lines match the current tree
exactly.

**Step 6.3:** No existing fix for this specific device in the tree.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1:** ALSA/HDA is an IMPORTANT subsystem. Audio is a core user-
facing feature — no audio output is a severe usability issue.

**Step 7.2:** The file sees constant quirk additions (10+ in recent
history), and Takashi Iwai actively maintains it.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1:** Affected: Users of HP Spectre x360 14-ea (2021 model).
This is a premium consumer laptop.
**Step 8.2:** Trigger: Every boot. Device always has no speaker output.
100% reproducible.
**Step 8.3:** Severity: HIGH — complete loss of audio output from
speakers. Device is essentially broken for audio use without this quirk.
**Step 8.4:** Benefit: HIGH — restores audio on a shipping consumer
laptop. Risk: VERY LOW — single table entry, only affects devices with
codec SSID 103c:885b, uses a well-tested fixup function that already
works on sibling models.

## PHASE 9: FINAL SYNTHESIS

**Evidence FOR:**
- Fixes complete audio failure (no speaker output) on a real consumer
  laptop
- User-reported via bugzilla (#221341)
- Single-line quirk table entry — minimal, surgical, obviously correct
- Uses existing well-tested fixup (`ALC245_FIXUP_HP_X360_AMP`) already
  applied to sibling models
- Merged by HDA subsystem maintainer Takashi Iwai
- Falls into the "hardware quirk" exception category — automatically YES
  per stable rules
- All required infrastructure exists in the 7.0 tree

**Evidence AGAINST:**
- None identified.

**Stable Rules Checklist:**
1. Obviously correct and tested? YES — identical pattern to existing
   entries, user-reported fix
2. Fixes a real bug? YES — no audio output on HP Spectre x360 14-ea
3. Important issue? YES — complete loss of speaker output
4. Small and contained? YES — 1 line added
5. No new features or APIs? YES — no new features
6. Can apply to stable? YES — all infrastructure present

**Exception Category:** Hardware quirk addition — automatically
qualifies for stable.

## Verification

- [Phase 1] Parsed all tags: Reported-by user, Closes bugzilla, merged
  by Takashi Iwai (HDA maintainer)
- [Phase 2] Diff: exactly 1 line added — `HDA_CODEC_QUIRK(0x103c,
  0x885b, ...)` in `alc269_fixup_tbl`
- [Phase 3] git blame: sibling entries (0x87f6, 0x87f7) for same fixup
  present since file split (aeeb85f26c3bb)
- [Phase 3] git log author: songxiebing has 4 other HDA commits in tree
- [Phase 5] Verified `HDA_CODEC_QUIRK` macro definition at
  `hda_local.h:314-320` sets `match_codec_ssid=true`
- [Phase 5] Verified `snd_hda_pick_fixup` matching logic at
  `auto_parser.c:1067-1080` — codec SSID path
- [Phase 5] Verified guard at `auto_parser.c:1019` prevents double-
  matching
- [Phase 5] Verified vendor catch-all at `alc269.c:7834` is in separate
  `alc269_fixup_vendor_tbl[]`
- [Phase 5] Verified `alc245_fixup_hp_x360_amp` function exists at line
  1448 (toggles GPIO for speaker amp)
- [Phase 6] Verified `ALC245_FIXUP_HP_X360_AMP` and `HDA_CODEC_QUIRK`
  both exist in the 7.0 tree
- [Phase 4] UNVERIFIED: Could not access bugzilla or lore due to anti-
  bot protections; relied on commit message metadata

**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 f10ee482151f6..e50ad953b09e7 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6955,6 +6955,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8847, "HP EliteBook x360 830 G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x884b, "HP EliteBook 840 Aero G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED),
 	SND_PCI_QUIRK(0x103c, 0x884c, "HP EliteBook 840 G8 Notebook PC", ALC285_FIXUP_HP_GPIO_LED),
+	HDA_CODEC_QUIRK(0x103c, 0x885b, "HP Spectre x360 14-ea", ALC245_FIXUP_HP_X360_AMP),
 	SND_PCI_QUIRK(0x103c, 0x8862, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST),
 	SND_PCI_QUIRK(0x103c, 0x8863, "HP ProBook 445 G8 Notebook PC", ALC236_FIXUP_HP_LIMIT_INT_MIC_BOOST),
 	SND_PCI_QUIRK(0x103c, 0x886d, "HP ZBook Fury 17.3 Inch G8 Mobile Workstation PC", ALC285_FIXUP_HP_GPIO_AMP_INIT),
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.18] ALSA: usb-audio: Add quirk flags for Feaulle Rainbow

[Sasha Levin]

From: Rong Zhang <i@rong.moe>

[ Upstream commit 4f84e6caf38b05991b3b2afc0ddf4e48c2752d1d ]

Feaulle Rainbow is a wired USB-C dynamic in-ear monitor (IEM) featuring
active noise cancellation (ANC).

The supported sample rates are 48000Hz and 96000Hz at 16bit or 24bit,
but it does not support reading the current sample rate and results in
an error message printed to kmsg. Set QUIRK_FLAG_GET_SAMPLE_RATE to skip
the sample rate check.

Its playback mixer reports val = -15360/0/128. Setting -15360 (-60dB)
mutes the playback, so QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE is needed.

Add a quirk table entry matching VID/PID=0x0e0b/0xfa01 and applying
the mentioned quirk flags, so that it can work properly.

Quirky device sample:

  usb 7-1: New USB device found, idVendor=0e0b, idProduct=fa01, bcdDevice= 1.00
  usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  usb 7-1: Product: Feaulle Rainbow
  usb 7-1: Manufacturer: Generic
  usb 7-1: SerialNumber: 20210726905926

Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260409-feaulle-rainbow-v1-1-09179e09000d@rong.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed. Let me compile the complete
analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: `ALSA: usb-audio`
- **Action verb**: "Add" (quirk flags)
- **Summary**: Adds USB audio quirk table entry for the Feaulle Rainbow
  IEM device (VID 0x0e0b, PID 0xfa01)

### Step 1.2: Tags
- **Signed-off-by**: Rong Zhang `<i@rong.moe>` (author)
- **Signed-off-by**: Takashi Iwai `<tiwai@suse.de>` (ALSA subsystem
  maintainer - merged it)
- **Link**: `https://patch.msgid.link/20260409-feaulle-
  rainbow-v1-1-09179e09000d@rong.moe`
- No Fixes: tag (expected for quirk additions)
- No Reported-by: (author is the device user/tester)
- No Cc: stable (expected; that's why we're reviewing)

### Step 1.3: Commit Body Analysis
Two real issues described:
1. Device does not support reading current sample rate, producing error
   messages in kmsg. `QUIRK_FLAG_GET_SAMPLE_RATE` skips that unsupported
   operation.
2. Device's playback mixer reports val = -15360/0/128 where -15360
   (-60dB) mutes playback, but the driver treats it as minimum volume,
   not mute. `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE` correctly treats the
   minimum as mute.

The commit includes USB enumeration output proving the device exists and
has been tested.

### Step 1.4: Hidden Bug Fix Detection
This is an explicit hardware quirk addition. It fixes incorrect device
behavior without needing the word "fix" — the device doesn't work
properly without these flags.

Record: This is a hardware workaround, a well-known exception category
for stable.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 (`sound/usb/quirks.c`)
- **Lines added**: 2
- **Lines removed**: 0
- **Scope**: Single table entry addition; purely data, no logic changes

### Step 2.2: Code Flow Change
The diff adds a single `DEVICE_FLG()` entry to the `quirk_flags_table[]`
sorted array:

```c
DEVICE_FLG(0x0e0b, 0xfa01, /* Feaulle Rainbow */
           QUIRK_FLAG_GET_SAMPLE_RATE |
QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
```

Inserted in VID-sorted order between 0x0d8c and 0x0ecb entries.

### Step 2.3: Bug Mechanism
Category (h): **Hardware workarounds**. This is a device ID + quirk
flags addition to an existing quirk table. The flags are well-
established:
- `QUIRK_FLAG_GET_SAMPLE_RATE`: Causes `clock.c` to skip the unsupported
  get-sample-rate call
- `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`: Causes `mixer_quirks.c` to set
  `cval->min_mute = 1` for playback

### Step 2.4: Fix Quality
- Obviously correct: adds a table entry matching one VID/PID pair
- Minimal: 2 lines, data-only
- Zero regression risk: only affects this specific USB device
  (0x0e0b:0xfa01)
- Signed off by Takashi Iwai (ALSA maintainer)

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
The `quirk_flags_table` was introduced in commit `4d4dee0aefec3`
(2021-07-29, v5.15). The table structure has been stable for years with
entries regularly added.

### Step 3.2: Fixes Tag
No Fixes: tag — expected for a quirk/device-ID addition. Not a
regression fix; it's new hardware enablement.

### Step 3.3: File History
Recent commits to `sound/usb/quirks.c` are dominated by similar quirk
additions (Scarlett, NeuralDSP, AB17X, SPACETOUCH, etc.). This is a
well-trodden pattern.

### Step 3.4: Author
Rong Zhang is the device owner/user. The patch was accepted and merged
by Takashi Iwai, the ALSA subsystem maintainer, which is strong
validation.

### Step 3.5: Dependencies
- `QUIRK_FLAG_GET_SAMPLE_RATE`: existed since v5.15
- `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`: renamed from
  `QUIRK_FLAG_MIXER_MIN_MUTE` in v6.18 (commit `ace1817ab49b3`). Stable
  trees <6.18 would need the old flag name, which is a trivial one-word
  substitution.
- No other dependencies.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1-4.5
b4 dig could not match the commit (it's not yet in a commit the local
tree knows). Lore.kernel.org was behind anti-bot protection. The Link in
the commit message (`patch.msgid.link/20260409-feaulle-
rainbow-v1-1-09179e09000d@rong.moe`) confirms this is v1, patch 1/1 — a
standalone single-patch submission. It was merged quickly by Takashi
Iwai, indicating no review concerns.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.5
The `quirk_flags_table` is consulted via
`snd_usb_init_quirk_flags_table()` during USB audio device
initialization. The function iterates the table, matches by USB ID, and
sets `chip->quirk_flags`. These flags are then checked in:
- `sound/usb/clock.c` (line ~490): if `QUIRK_FLAG_GET_SAMPLE_RATE` is
  set, skip reading sample rate → prevents error messages
- `sound/usb/mixer_quirks.c` (line ~4649): if
  `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE`, set `cval->min_mute = 1` → makes
  the minimum volume level act as mute

Both code paths are well-exercised by the ~139 existing `DEVICE_FLG`
entries in the table.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1
The `quirk_flags_table` exists in all active stable trees since v5.15.
Both quirk flags exist (though `MIXER_PLAYBACK_MIN_MUTE` was called
`MIXER_MIN_MUTE` before v6.18).

### Step 6.2: Backport Complications
- For 6.18+ and 7.0: clean apply
- For 6.6.y, 6.1.y, 5.15.y: trivial flag rename needed
  (`QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE` → `QUIRK_FLAG_MIXER_MIN_MUTE`)
- Surrounding table context may differ slightly (nearby entries may be
  absent), but this is a simple insertion.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1
- **Subsystem**: Sound / USB audio (`sound/usb/`)
- **Criticality**: IMPORTANT — USB audio is widely used (headsets, DACs,
  IEMs, webcams)

### Step 7.2
Very active subsystem — frequent quirk additions, well-maintained by
Takashi Iwai.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
Users who own the Feaulle Rainbow USB-C IEM (VID 0x0e0b, PID 0xfa01).

### Step 8.2: Trigger Conditions
Triggers every time the device is plugged in. Without the quirk:
- Error messages appear in kmsg (sample rate read failure)
- Minimum playback volume is not treated as mute, causing incorrect
  volume behavior

### Step 8.3: Failure Mode Severity
- Without quirk: error messages in kernel log + incorrect audio mixer
  behavior (LOW-MEDIUM severity)
- With quirk: device works properly

### Step 8.4: Risk-Benefit
- **Benefit**: Makes a real USB audio device work correctly for its
  users
- **Risk**: Essentially zero — 2-line data-only addition, scoped to a
  single VID/PID, uses existing well-tested quirk infrastructure

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary
**FOR backporting:**
- Classic USB audio hardware quirk — explicitly listed as an exception
  category (always YES)
- 2 lines, data-only change, zero logic changes
- Uses well-established quirk flags present in all active stable trees
- Merged by ALSA subsystem maintainer Takashi Iwai
- Fixes real device behavior (error messages + incorrect volume
  handling)
- Zero regression risk (only affects this specific device)
- Identical pattern to dozens of previously backported quirk additions

**AGAINST backporting:**
- None

### Step 9.2: Stable Rules Checklist
1. Obviously correct? **YES** — trivial table entry
2. Fixes a real bug? **YES** — device doesn't work properly without it
3. Important issue? **YES** — hardware enablement quirk
4. Small and contained? **YES** — 2 lines, 1 file
5. No new features or APIs? **YES** — no new features
6. Can apply to stable? **YES** — trivially, with minor flag rename for
   <6.18

### Step 9.3: Exception Category
**Hardware quirk/workaround** — this is the textbook example of a
stable-appropriate quirk addition.

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by Rong Zhang (author) and Takashi
  Iwai (maintainer), Link to patch.msgid.link
- [Phase 2] Diff analysis: 2 lines added to `quirk_flags_table[]` in
  `sound/usb/quirks.c`, single DEVICE_FLG entry
- [Phase 2] Verified both flags exist: `QUIRK_FLAG_GET_SAMPLE_RATE`
  checked at `clock.c:490`, `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE` checked
  at `mixer_quirks.c:4649`
- [Phase 3] git blame: quirk_flags_table introduced in commit
  4d4dee0aefec3 (2021-07-29, v5.15)
- [Phase 3] git tag: `QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE` (renamed)
  present from v6.18+; older trees use `QUIRK_FLAG_MIXER_MIN_MUTE`
- [Phase 3] git log: recent quirks.c history shows regular quirk
  additions (identical pattern)
- [Phase 3] Author Rong Zhang has no prior commits in sound/usb/ — they
  are the device owner
- [Phase 4] b4 dig failed (commit not in local tree). Lore blocked by
  anti-bot. Patch is v1, 1/1 (standalone, no series dependencies).
- [Phase 5] `DEVICE_FLG` count: 139 existing entries in the table —
  well-established pattern
- [Phase 6] quirk_flags_table exists since v5.15 — present in all active
  stable trees
- [Phase 8] Risk: zero — data-only, single-device-scoped, well-tested
  infrastructure
- UNVERIFIED: Could not access lore.kernel.org discussion thread due to
  anti-bot protection. This does not affect the decision since the
  commit is a straightforward quirk addition signed off by the
  maintainer.

**YES**

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

diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index d3a69995c1ad5..e95a228def2f0 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2281,6 +2281,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
 		   QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
 	DEVICE_FLG(0x0d8c, 0x0014, /* C-Media */
 		   QUIRK_FLAG_CTL_MSG_DELAY_1M | QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
+	DEVICE_FLG(0x0e0b, 0xfa01, /* Feaulle Rainbow */
+		   QUIRK_FLAG_GET_SAMPLE_RATE | QUIRK_FLAG_MIXER_PLAYBACK_MIN_MUTE),
 	DEVICE_FLG(0x0ecb, 0x205c, /* JBL Quantum610 Wireless */
 		   QUIRK_FLAG_FIXED_RATE),
 	DEVICE_FLG(0x0ecb, 0x2069, /* JBL Quantum810 Wireless */
-- 
2.53.0

[PATCH AUTOSEL 6.18] ALSA: hda/realtek: add HP Laptop 15-fd0xxx mute LED quirk

[Sasha Levin]

From: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com>

[ Upstream commit faceb5cf5d7a08f4a40335d22d833bb75f05d99e ]

HP Laptop 15-fd0xxx with ALC236 codec does not handle the toggling of
the mute LED.
This patch adds a quirk entry for subsystem ID 0x8dd7 using
ALC236_FIXUP_HP_MUTE_LED_COEFBIT2 fixup, enabling correct mute LED
behavior.

Signed-off-by: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com>
Link: https://patch.msgid.link/DHAB51ISUM96.2K9SZIABIDEQ0@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 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 c782a35f9239d..0c975005793e7 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -6977,6 +6977,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x103c, 0x8da7, "HP 14 Enstrom OmniBook X", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8da8, "HP 16 Piston OmniBook X", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x103c, 0x8dd4, "HP EliteStudio 8 AIO", ALC274_FIXUP_HP_AIO_BIND_DACS),
+	SND_PCI_QUIRK(0x103c, 0x8dd7, "HP Laptop 15-fd0xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2),
 	SND_PCI_QUIRK(0x103c, 0x8de8, "HP Gemtree", ALC245_FIXUP_TAS2781_SPI_2),
 	SND_PCI_QUIRK(0x103c, 0x8de9, "HP Gemtree", ALC245_FIXUP_TAS2781_SPI_2),
 	SND_PCI_QUIRK(0x103c, 0x8dec, "HP EliteBook 640 G12", ALC236_FIXUP_HP_GPIO_LED),
-- 
2.53.0

[PATCH AUTOSEL 6.18] ALSA: hda/realtek: Add quirk for ASUS ROG Flow Z13-KJP GZ302EAC

[Sasha Levin]

From: Matthew Schwartz <matthew.schwartz@linux.dev>

[ Upstream commit 59f68dc1d8df3142cb58fd2568966a9bb7b0ed8a ]

Fixes lack of audio output on the ASUS ROG Flow Z13-KJP GZ302EAC model,
similar to the ASUS ROG Flow Z13 GZ302EA.

Signed-off-by: Matthew Schwartz <matthew.schwartz@linux.dev>
Link: https://patch.msgid.link/20260313172503.285846-1-matthew.schwartz@linux.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 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 4b06cb48252e2..1959adb6c5189 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -7065,6 +7065,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = {
 	SND_PCI_QUIRK(0x1043, 0x14e3, "ASUS G513PI/PU/PV", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x1043, 0x14f2, "ASUS VivoBook X515JA", ALC256_FIXUP_ASUS_MIC_NO_PRESENCE),
 	SND_PCI_QUIRK(0x1043, 0x1503, "ASUS G733PY/PZ/PZV/PYV", ALC287_FIXUP_CS35L41_I2C_2),
+	SND_PCI_QUIRK(0x1043, 0x1514, "ASUS ROG Flow Z13 GZ302EAC", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
 	SND_PCI_QUIRK(0x1043, 0x1533, "ASUS GV302XA/XJ/XQ/XU/XV/XI", ALC287_FIXUP_CS35L41_I2C_2),
 	SND_PCI_QUIRK(0x1043, 0x1573, "ASUS GZ301VV/VQ/VU/VJ/VA/VC/VE/VVC/VQC/VUC/VJC/VEC/VCC", ALC285_FIXUP_ASUS_HEADSET_MIC),
-- 
2.53.0