[PATCH AUTOSEL 7.0-5.10] ALSA: hda: Avoid WARN_ON() for HDMI chmap slot checks

[PATCH AUTOSEL 7.0-5.10] ALSA: hda: Avoid WARN_ON() for HDMI chmap slot checks

[Sasha Levin]

From: Takashi Iwai <tiwai@suse.de>

[ Upstream commit 077c593dacf7ee33511468e4f29417d795cf07a4 ]

At parsing the channel mapping for HDMI, the current code may spew
WARN_ON() unnecessarily for the case where only invalid (zero) channel
maps are given from the hardware.  Drop WARN_ON() and reorganize the
code a bit for avoiding the hdmi_slot over the array size.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221390
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260428061800.80527-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:

## Phase 1: Commit Message Forensics

Step 1.1 Record: subsystem is `ALSA: hda`; action verb is `Avoid`;
claimed intent is to avoid unnecessary `WARN_ON()` during HDMI channel-
map slot checks.

Step 1.2 Record: tags present are `Closes:
https://bugzilla.kernel.org/show_bug.cgi?id=221390`, `Signed-off-by:
Takashi Iwai <tiwai@suse.de>`, `Link:
https://patch.msgid.link/20260428061800.80527-1-tiwai@suse.de`, and
another `Signed-off-by: Takashi Iwai <tiwai@suse.de>` in the supplied
commit text. No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`,
`Acked-by:`, or `Cc: stable` tag was present.

Step 1.3 Record: the commit says HDMI channel-map parsing can emit
unnecessary `WARN_ON()` when hardware supplies only invalid zero channel
maps, and also says the code is reorganized to avoid `hdmi_slot` going
over the array size. The visible user symptom is kernel warning spam;
the linked Bugzilla content could not be fetched because Bugzilla
returned an Anubis bot-protection page.

Step 1.4 Record: this is a real bug fix, not just cleanup. The diff
removes a warning path reachable from bad hardware-provided mapping data
and adds an explicit bound exit before programming or storing an invalid
HDMI slot.

## Phase 2: Diff Analysis

Step 2.1 Record: one file changes: `sound/hda/core/hdmi_chmap.c`, with 7
insertions and 4 deletions. The only modified function is
`hdmi_std_setup_channel_mapping()`. Scope is a single-file surgical fix.

Step 2.2 Record: before the patch, the loop skipped empty speaker slots
using `WARN_ON(hdmi_slot >= 8)` as part of the while condition, but
after the warning fired the loop still proceeded to assign `hdmi_slot`
into `hdmi_channel_mapping`. After the patch, the outer loop stops when
`hdmi_slot` reaches 8, the inner skip loop jumps to `out` before
assignment when the slot limit is reached, and the remaining slots are
filled with the invalid ALSA channel marker as before.

Step 2.3 Record: bug category is logic/bounds handling plus spurious
warning removal. The broken mechanism is that `hdmi_slot` can reach the
8-slot HDMI limit while looking for a nonzero speaker slot, causing a
`WARN_ON()` and allowing an invalid slot number to be used in the
mapping path. The fix prevents the over-limit assignment.

Step 2.4 Record: the fix is obviously local and low-risk. It changes
only the invalid/edge path where slot scanning reaches the HDMI 8-slot
limit. It does not add APIs, data structures, or features.

## Phase 3: Git History Investigation

Step 3.1 Record: `git blame` shows the function and mapping logic came
from `2f6e8a8518f3` (`ALSA: hda - Move chmap support helpers/ops to
core`, first contained in `v4.6-rc1`), and the current
`WARN_ON(hdmi_slot >= 8)` ordering came from `960a581e22d9` (`ALSA: hda:
fix some klockwork scan warnings`, first contained in `v4.8-rc1`).

Step 3.2 Record: no `Fixes:` tag is present, so there was no tagged
introducing commit to follow. Blame identifies `960a581e22d9` as the
source of the current warning expression.

Step 3.3 Record: recent history for this file is sparse. Relevant later
changes include `c2432466f583c` HDMI/DP chmap reporting, `6278056e42d9`
input value sanity checks, and `b2660d1ebde` moving the file into
`sound/hda/core`. No prerequisite for this patch was identified.

Step 3.4 Record: author Takashi Iwai is listed in `MAINTAINERS` as a
maintainer for `SOUND`, and recent git history shows many HDA commits
authored/merged by him. This is a strong subsystem-authority signal.

Step 3.5 Record: no dependency on newer structures or helper functions
was found. The affected code pattern exists in active stable trees;
older trees before `v6.17` use the path `sound/hda/hdmi_chmap.c` instead
of `sound/hda/core/hdmi_chmap.c`.

## Phase 4: Mailing List And External Research

Step 4.1 Record: an exact candidate commit SHA was not found by subject
on the searched refs, so `b4 dig -c <candidate>` could not be run for
the candidate. Using the message-id instead, `b4 am
20260428061800.80527-1-tiwai@suse.de` found the patch, confirmed a
single patch, DKIM-signed by `suse.de`, and reported that it applies
cleanly to the current tree. `b4 am -c` found no newer revision.

Step 4.2 Record: `b4 mbox` showed the original patch was sent by Takashi
Iwai to `linux-sound@vger.kernel.org` and Cc’d `linux-
kernel@vger.kernel.org`. The fetched thread contained one message and no
code-review replies or review trailers.

Step 4.3 Record: the patch has a Bugzilla `Closes:` link, but WebFetch
for Bugzilla was blocked by Anubis. I could not verify reporter severity
or duplicates from Bugzilla content.

Step 4.4 Record: `b4 am` reported one total patch, and no series context
or newer revision was found. This appears standalone.

Step 4.5 Record: web searches did not find stable-list discussion for
the exact title. No stable-specific objection was found.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: modified function is
`hdmi_std_setup_channel_mapping()`.

Step 5.2 Record: `rg` shows `hdmi_std_setup_channel_mapping()` is called
only by `snd_hdac_setup_channel_mapping()`. That exported helper is
called from HDA HDMI setup in `sound/hda/codecs/hdmi/hdmi.c` and ASoC
HDMI codec setup in `sound/soc/codecs/hdac_hdmi.c`.

Step 5.3 Record: the affected function computes slot/channel assignments
and calls `chmap->ops.pin_set_slot_channel()`, which writes the
`AC_VERB_SET_HDMI_CHAN_SLOT` HDA verb through the codec operation.

Step 5.4 Record: the path is reachable during HDMI/DP audio setup: PCM
prepare, ELD/presence update, channel-map control update when prepared,
and ASoC DAPM pin power-up call into the infoframe setup path. This is a
real runtime hardware path, not dead code.

Step 5.5 Record: `rg` found no other `WARN_ON(hdmi_slot >= 8)` or
similar `hdmi_slot` warning pattern elsewhere in `sound/`.

## Phase 6: Cross-Referencing And Stable Tree Analysis

Step 6.1 Record: the exact `WARN_ON(hdmi_slot >= 8)` pattern exists in
active stable branches checked: `stable/linux-5.10.y`, `5.15.y`,
`6.1.y`, `6.6.y`, `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y`.

Step 6.2 Record: backport difficulty should be clean or minor. `git
apply --check` succeeds on the current `7.0.y` checkout. For `5.10.y`
through `6.12.y`, the code is effectively the same but the file path is
`sound/hda/hdmi_chmap.c`; `6.18.y+` uses `sound/hda/core/hdmi_chmap.c`.

Step 6.3 Record: searches for the exact subject and bug number in stable
history found no existing matching stable fix.

## Phase 7: Subsystem And Maintainer Context

Step 7.1 Record: subsystem is ALSA HDA HDMI channel mapping under
`sound/`. Criticality is IMPORTANT: it affects users of HDA HDMI/DP
audio hardware, not all kernel users.

Step 7.2 Record: subsystem activity is active; recent `sound/hda`
history contains HDA HDMI fixes, quirks, cleanups, and device IDs. The
touched file itself has low churn.

## Phase 8: Impact And Risk Assessment

Step 8.1 Record: affected users are driver/hardware-specific: systems
using HDA HDMI/DP audio channel mapping, especially hardware that
reports invalid zero channel-map data.

Step 8.2 Record: trigger is HDMI channel-map setup with invalid/zero
mapping data from hardware, reached during audio infoframe/channel
setup. I did not verify whether an unprivileged user can force the exact
bad hardware data; the runtime setup path itself is reachable during
normal audio/display operation.

Step 8.3 Record: failure mode is warning splat/log spam and invalid slot
handling. Severity is MEDIUM normally, and potentially higher on systems
configured with `panic_on_warn`, but I did not verify `panic_on_warn` in
the bug report.

Step 8.4 Record: benefit is medium: avoids a user-reported warning and
prevents invalid HDMI slot use on affected hardware. Risk is very low:
11-line single-function change in an edge path with no API or behavior
expansion.

## Phase 9: Final Synthesis

Step 9.1 Record: evidence for backporting: user-reported Bugzilla-linked
issue, maintainer-authored ALSA fix, small and isolated diff, removes a
spurious runtime `WARN_ON()`, adds explicit bounds handling, code exists
across active stable trees, and current-tree apply check succeeds.
Evidence against: primary verified symptom is warning/log noise rather
than confirmed crash, data corruption, or security issue; Bugzilla
details could not be fetched; older stable trees need a path-adjusted
backport because of the `sound/hda/core` rename.

Step 9.2 Record: stable rules checklist:
1. Obviously correct and tested: yes for obvious correctness by
   inspection; external testing is not evidenced by tags.
2. Fixes a real bug: yes, commit has a Bugzilla `Closes:` and fixes a
   concrete warning/bounds condition.
3. Important issue: moderate importance; warnings from hardware-
   triggered paths are stable-worthy when the fix is tiny and safe.
4. Small and contained: yes, one function, one file, 7 insertions and 4
   deletions.
5. No new features/APIs: yes.
6. Can apply to stable: yes for current path; minor path adjustment
   needed for older stable branches.

Step 9.3 Record: no automatic exception category applies. This is not a
device ID, quirk table entry, DT update, build fix, or documentation
fix.

Step 9.4 Record: decision is YES. The patch is small, maintainer-
authored, fixes a real user-reported WARN/bounds handling issue in
existing HDA HDMI code present across stable trees, and has very low
regression risk.

## Verification

- [Phase 1] Read the supplied commit message and the fetched mbox:
  confirmed subject, body, `Closes`, and `Signed-off-by`.
- [Phase 2] Read the b4-fetched patch: confirmed
  `sound/hda/core/hdmi_chmap.c`, 7 insertions, 4 deletions, one hunk in
  `hdmi_std_setup_channel_mapping()`.
- [Phase 3] Ran `git blame` on the changed region: confirmed
  `2f6e8a8518f3` and `960a581e22d9` history.
- [Phase 3] Ran `git describe --contains`: confirmed `2f6e8a8518f3`
  appears in `v4.6-rc1` ancestry and `960a581e22d9` in `v4.8-rc1`
  ancestry.
- [Phase 3] Checked file history and author history: no prerequisite
  commit identified; Takashi Iwai is active in HDA history.
- [Phase 4] `b4 am` by message-id: found the exact patch, one total
  patch, DKIM signed, applies cleanly to current tree.
- [Phase 4] `b4 am -c`: found no newer revision.
- [Phase 4] `b4 mbox`: confirmed To/Cc and that the thread has one
  message.
- [Phase 4] WebFetch for lore and Bugzilla: blocked by Anubis, so bug
  details beyond the `Closes` URL are unverified.
- [Phase 5] `rg` call tracing: confirmed caller chain through
  `snd_hdac_setup_channel_mapping()` into HDA HDMI and ASoC HDMI setup
  paths.
- [Phase 5] Read caller code: confirmed use during audio infoframe
  setup, ELD/presence handling, PCM prepare, DAPM power-up, and prepared
  chmap update paths.
- [Phase 6] `git grep` on active stable refs: confirmed the exact
  `WARN_ON(hdmi_slot >= 8)` pattern exists in checked `5.10.y` through
  `7.0.y`.
- [Phase 6] `git diff` across stable refs: confirmed older branches
  mostly differ by file rename, with `5.10.y/5.15.y` having one
  unrelated PCM runtime-state line difference.
- [Phase 6] `git apply --check`: candidate patch applies cleanly to the
  current `7.0.y` checkout.
- [Phase 7] `MAINTAINERS` search: confirmed Takashi Iwai is listed as a
  `SOUND` maintainer.
- [Phase 8] Severity/risk assessment is based on the verified diff,
  commit message, and runtime call paths.
- UNVERIFIED: exact Bugzilla reporter details, number of affected users,
  and whether the reporter hit a panic rather than warning spam.
- UNVERIFIED: exact upstream commit SHA, because the subject was not
  found on searched local refs; candidate-specific `b4 dig -c` could not
  be performed.

**YES**

 sound/hda/core/hdmi_chmap.c | 11 +++++++----
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/sound/hda/core/hdmi_chmap.c b/sound/hda/core/hdmi_chmap.c
index 7b276047f85a7..c897fc443467c 100644
--- a/sound/hda/core/hdmi_chmap.c
+++ b/sound/hda/core/hdmi_chmap.c
@@ -353,13 +353,16 @@ static void hdmi_std_setup_channel_mapping(struct hdac_chmap *chmap,
 	if (hdmi_channel_mapping[ca][1] == 0) {
 		int hdmi_slot = 0;
 		/* fill actual channel mappings in ALSA channel (i) order */
-		for (i = 0; i < ch_alloc->channels; i++) {
-			while (!WARN_ON(hdmi_slot >= 8) &&
-			       !ch_alloc->speakers[7 - hdmi_slot])
-				hdmi_slot++; /* skip zero slots */
+		for (i = 0; i < ch_alloc->channels && hdmi_slot < 8; i++) {
+			while (!ch_alloc->speakers[7 - hdmi_slot]) {
+				/* skip zero slots */
+				if (++hdmi_slot >= 8)
+					goto out;
+			}
 
 			hdmi_channel_mapping[ca][i] = (i << 4) | hdmi_slot++;
 		}
+	out:
 		/* fill the rest of the slots with ALSA channel 0xf */
 		for (hdmi_slot = 0; hdmi_slot < 8; hdmi_slot++)
 			if (!ch_alloc->speakers[7 - hdmi_slot])
-- 
2.53.0

[PATCH AUTOSEL 7.0] ASoC: spacemit: move hw constraints from hw_params to startup

[Sasha Levin]

From: Troy Mitchell <troy.mitchell@linux.spacemit.com>

[ Upstream commit 6b4afbaaa342eaa52172e0be5ef8d1fcbf9ff460 ]

Hardware constraints should be applied in the startup callback rather
than hw_params, as hw_params may be called too late for the constraints
to take effect properly.

Move the channel count and format constraints for I2S and DSP_A/DSP_B
modes into a new startup callback. This also tightens the I2S mode
channel constraint from 1-2 to exactly 2, matching the actual hardware
behavior.

Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Link: https://patch.msgid.link/20260429-k3-i2s-v1-2-2fe99db11ecb@linux.spacemit.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
Step 1.1 Record: Subsystem `ASoC: spacemit`; action verb `move`; intent
is to apply PCM hardware constraints in `.startup` instead of
`.hw_params`.

Step 1.2 Record: Tags present: `Signed-off-by: Troy Mitchell`, `Link: ht
tps://patch.msgid.link/20260429-k3-i2s-v1-2-
2fe99db11ecb@linux.spacemit.com`, `Signed-off-by: Mark Brown`. No
`Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by`, `Acked-by`, or
`Cc: stable`.

Step 1.3 Record: The body says constraints in `.hw_params` may be too
late to affect ALSA parameter negotiation, and that I2S should be
constrained to exactly 2 channels. Symptom is invalid PCM
formats/channel counts being allowed for the SpacemiT I2S mode. No crash
trace or affected kernel versions are stated.

Step 1.4 Record: This is a hidden bug fix: it is phrased as
moving/refactoring constraints, but it corrects when ALSA constraints
are installed and prevents unsupported hardware parameters.

Step 2.1 Record: One file changed, `sound/soc/spacemit/k1_i2s.c`, 32
insertions and 13 deletions. Modified functions/objects: new
`spacemit_i2s_startup`, existing `spacemit_i2s_hw_params`, and
`spacemit_i2s_dai_ops`. Scope is single-file, driver-local, surgical.

Step 2.2 Record: Before, the driver advertised broad 1-2 channel and
S16/S32 capabilities and only added mode-specific constraints inside
`.hw_params`, after parameters had already been selected. After,
`.startup` constrains I2S to 2ch/S16 and DSP_A/DSP_B to 1ch/S32 before
userspace parameter selection completes.

Step 2.3 Record: Bug category is logic/correctness in hardware parameter
negotiation. There is no memory safety, locking, refcounting, or
resource lifetime change.

Step 2.4 Record: Fix quality is good: it moves existing constraints to
the ALSA callback used for early constraints and tightens I2S channels.
Regression risk is low but not zero: unsupported mono I2S streams will
now fail earlier, which is intended if the author’s hardware statement
is correct.

Step 3.1 Record: `git blame` shows the changed constraint code was
introduced by `fce217449075d` / local full SHA
`fce217449075d59b29052b8cdac567f0f3e22641`, “ASoC: spacemit: add i2s
support for K1 SoC”, first described as contained before `v6.19-rc1`.

Step 3.2 Record: No `Fixes:` tag in this candidate, so there was no tag
to follow. I inspected the driver-introduction commit instead.

Step 3.3 Record: Recent file history contains the original driver plus
two small later fixes: failure handling for `spacemit_i2s_init_dai()`
and an `sspa_clk` error-check fix. No prerequisite refactor is needed
for this patch.

Step 3.4 Record: Author Troy Mitchell authored the original K1 I2S
driver and one related later fix, so he is directly familiar with this
driver.

Step 3.5 Record: The patch is part of a 7-patch series, but `b4` and
`git apply --check` confirmed patch 2 applies cleanly standalone to the
current tree.

Step 4.1 Record: `b4 dig` against a temporary commit matched the lore
thread at the provided patch-msgid URL. `b4 dig -a` found only v1. The
full thread shows Mark Brown applied patch 2 to `broonie/sound.git
for-7.1` as commit `6b4afbaaa342`.

Step 4.2 Record: `b4 dig -w` shows ASoC/sound maintainers and lists were
included, including Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi
Iwai, `linux-sound`, and relevant SpacemiT/RISC-V lists.

Step 4.3 Record: No separate bug report, syzbot report, or user report
was linked for this specific patch.

Step 4.4 Record: Series context: patches 1-3 are described as K1 bug
fixes/refactoring; patches 4-7 are K3 feature/binding work. Mark Brown
explicitly noted fixes and new features had no textual overlap and
applied only patches 2 and 3 from the subset.

Step 4.5 Record: Stable-specific web search was blocked by lore Anubis,
and a local pending-branch grep was stopped after timing out. No stable-
specific discussion was verified.

Step 5.1 Record: Key function added/modified: `spacemit_i2s_startup`;
key function simplified: `spacemit_i2s_hw_params`.

Step 5.2 Record: Callers verified: `.startup` is called through
`snd_soc_dai_startup()` from `__soc_pcm_open()`. `.hw_params` is called
through `snd_soc_dai_hw_params()` from `__soc_pcm_hw_params()`.

Step 5.3 Record: Key callees are `snd_pcm_hw_constraint_minmax()` and
`snd_pcm_hw_constraint_mask64()` in startup, and clock/DMA/register
setup remains in `hw_params`.

Step 5.4 Record: Reachability is via ALSA PCM open and hw_params
operations; userspace audio applications can trigger the affected
negotiation path by opening/configuring a PCM device for this DAI.

Step 5.5 Record: Similar local ASoC pattern verified: many drivers
install constraints in `.startup`, and ASoC core comments confirm
startup is part of PCM open.

Step 6.1 Record: The file is absent at `v6.18` and present with the same
blob in `v6.19`, `v7.0`, `v7.0.3`, `pending-6.19`, and `pending-7.0`.
Likely relevant stable trees start at 6.19.y.

Step 6.2 Record: Backport difficulty is low: the patch applies cleanly
to the current 7.0.3 checkout, and the file blob is identical in checked
6.19/7.0 branches.

Step 6.3 Record: No related fix for this exact subject exists in checked
stable branches; the candidate commit exists locally as `6b4afbaaa342`
but is not contained in the checked pending stable branches I verified.

Step 7.1 Record: Subsystem is ASoC platform driver under
`sound/soc/spacemit`; criticality is PERIPHERAL/driver-specific.

Step 7.2 Record: Subsystem activity is low and localized: only four
local commits under `sound/soc/spacemit`, including the original driver
and small fixes.

Step 8.1 Record: Affected population is config/platform-specific:
`CONFIG_SND_SOC_K1_I2S`, depending on `COMPILE_TEST || ARCH_SPACEMIT`,
`HAVE_CLK`, and `DMA_CMA`.

Step 8.2 Record: Trigger is normal PCM device open/parameter selection
on SpacemiT K1 I2S hardware. Unprivileged reachability depends on local
audio device permissions, which I did not verify.

Step 8.3 Record: Failure mode is unsupported audio configuration being
accepted or constrained too late, causing bad/failed audio operation
rather than a verified crash, corruption, or security issue. Severity:
MEDIUM for affected hardware users.

Step 8.4 Record: Benefit is moderate: corrects real hardware parameter
negotiation for a supported driver. Risk is low: one driver, one file,
no ABI/API change, clean apply, and maintainer-applied.

Step 9.1 Record: Evidence for backporting: real driver correctness bug,
normal userspace audio path, introduced in stable-relevant 6.19-era
driver, small contained patch, clean apply, maintainer accepted.
Evidence against: no reporter/test tag, no crash/security/data-loss
evidence, exact “I2S is 2ch only” hardware fact not independently
verified outside author/maintainer review.

Step 9.2 Record: Stable rules: obviously correct enough: yes, based on
ALSA callback ordering and existing constraints; real bug: yes;
important issue: moderate hardware functionality bug, not critical;
small/contained: yes; no new API/feature: yes; can apply: yes to checked
6.19/7.0-family trees.

Step 9.3 Record: No automatic exception category like device ID, quirk,
DT-only, build-only, or documentation-only applies.

Step 9.4 Record: Decision is to backport. The risk is low and the patch
fixes a real, user-visible hardware configuration bug in a stable-
relevant driver.

## Verification
- [Phase 1] Parsed commit `6b4afbaaa342` with `git show`; confirmed tags
  and lack of `Fixes`/reporter/stable tags.
- [Phase 2] Inspected candidate diff; confirmed only `k1_i2s.c` changes,
  adding `.startup` and moving constraints out of `.hw_params`.
- [Phase 3] Ran `git blame` on changed lines; confirmed original code
  from `fce217449075d`.
- [Phase 3] Ran file history and author history; found only localized
  SpacemiT I2S changes.
- [Phase 4] Used `b4 am`, `b4 mbox`, and `b4 dig`; confirmed v1 thread,
  maintainer application to `for-7.1`, and reviewer/maintainer
  recipients.
- [Phase 5] Read ASoC core code; confirmed startup occurs during PCM
  open and hw_params occurs later during ALSA hardware parameter setup.
- [Phase 6] Checked tags/branches and patch application; confirmed file
  presence from `v6.19` onward and clean standalone apply.
- [Phase 7] Read `Kconfig`; confirmed driver-specific SpacemiT K1 I2S
  config scope.
- [Phase 8] Assessed trigger/failure from verified ALSA call paths and
  driver-advertised constraints.
- UNVERIFIED: Independent hardware documentation proving I2S mode is
  exactly 2 channels; this claim comes from the commit author and
  maintainer-accepted patch.
- UNVERIFIED: Stable mailing-list search results, because lore WebFetch
  was blocked and one local pending-branch grep was stopped after
  timeout.

**YES**

 sound/soc/spacemit/k1_i2s.c | 45 ++++++++++++++++++++++++++-----------
 1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/sound/soc/spacemit/k1_i2s.c b/sound/soc/spacemit/k1_i2s.c
index 1cb99f1abc7cd..bb73d32a1b097 100644
--- a/sound/soc/spacemit/k1_i2s.c
+++ b/sound/soc/spacemit/k1_i2s.c
@@ -106,6 +106,37 @@ static void spacemit_i2s_init(struct spacemit_i2s_dev *i2s)
 	writel(0, i2s->base + SSINTEN);
 }
 
+static int spacemit_i2s_startup(struct snd_pcm_substream *substream,
+	struct snd_soc_dai *dai)
+{
+	struct spacemit_i2s_dev *i2s = snd_soc_dai_get_drvdata(dai);
+
+	switch (i2s->dai_fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+	case SND_SOC_DAIFMT_I2S:
+		snd_pcm_hw_constraint_minmax(substream->runtime,
+					     SNDRV_PCM_HW_PARAM_CHANNELS,
+					     2, 2);
+		snd_pcm_hw_constraint_mask64(substream->runtime,
+					     SNDRV_PCM_HW_PARAM_FORMAT,
+					     SNDRV_PCM_FMTBIT_S16_LE);
+		break;
+	case SND_SOC_DAIFMT_DSP_A:
+	case SND_SOC_DAIFMT_DSP_B:
+		snd_pcm_hw_constraint_minmax(substream->runtime,
+					     SNDRV_PCM_HW_PARAM_CHANNELS,
+					     1, 1);
+		snd_pcm_hw_constraint_mask64(substream->runtime,
+					     SNDRV_PCM_HW_PARAM_FORMAT,
+					     SNDRV_PCM_FMTBIT_S32_LE);
+		break;
+	default:
+		dev_dbg(i2s->dev, "unexpected format type");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 static int spacemit_i2s_hw_params(struct snd_pcm_substream *substream,
 				  struct snd_pcm_hw_params *params,
 				  struct snd_soc_dai *dai)
@@ -157,22 +188,9 @@ static int spacemit_i2s_hw_params(struct snd_pcm_substream *substream,
 			dma_data->maxburst = 32;
 			dma_data->addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
 		}
-
-		snd_pcm_hw_constraint_minmax(substream->runtime,
-					     SNDRV_PCM_HW_PARAM_CHANNELS,
-					     1, 2);
-		snd_pcm_hw_constraint_mask64(substream->runtime,
-					     SNDRV_PCM_HW_PARAM_FORMAT,
-					     SNDRV_PCM_FMTBIT_S16_LE);
 		break;
 	case SND_SOC_DAIFMT_DSP_A:
 	case SND_SOC_DAIFMT_DSP_B:
-		snd_pcm_hw_constraint_minmax(substream->runtime,
-					     SNDRV_PCM_HW_PARAM_CHANNELS,
-					     1, 1);
-		snd_pcm_hw_constraint_mask64(substream->runtime,
-					     SNDRV_PCM_HW_PARAM_FORMAT,
-					     SNDRV_PCM_FMTBIT_S32_LE);
 		break;
 	default:
 		dev_dbg(i2s->dev, "unexpected format type");
@@ -303,6 +321,7 @@ static int spacemit_i2s_dai_remove(struct snd_soc_dai *dai)
 static const struct snd_soc_dai_ops spacemit_i2s_dai_ops = {
 	.probe = spacemit_i2s_dai_probe,
 	.remove = spacemit_i2s_dai_remove,
+	.startup = spacemit_i2s_startup,
 	.hw_params = spacemit_i2s_hw_params,
 	.set_sysclk = spacemit_i2s_set_sysclk,
 	.set_fmt = spacemit_i2s_set_fmt,
-- 
2.53.0

[PATCH AUTOSEL 7.0-5.10] ALSA: usb-audio: apply quirk for Playstation PDP Riffmaster

[Sasha Levin]

From: Rosalie Wanders <rosalie@mailbox.org>

[ Upstream commit 110189f0268d0eb85895721526328cac5804a739 ]

This device, just like the Playstation 5's DualSense, has a volume
that's too low, hid-playstation solves this by raising the minimum
volume on the device itself by sending an output report, third party PS5
controllers/accessories do not support this output report format, so we
apply a quirk to raise the minimum volume by 6dB.

Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Link: https://patch.msgid.link/20260426025520.3985-2-rosalie@mailbox.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem is `ALSA: usb-audio`; action verb is `apply`;
intent is to add a device-specific volume quirk for PlayStation PDP
Riffmaster controllers/accessories.

Step 1.2 Record: Tags present are:
- `Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>`
- `Link:
  https://patch.msgid.link/20260426025520.3985-2-rosalie@mailbox.org`
- `Signed-off-by: Takashi Iwai <tiwai@suse.de>`
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
or `Cc: stable@vger.kernel.org` tags were present.

Step 1.3 Record: The commit says the PDP Riffmaster has too-low volume,
similar to the PS5 DualSense. It states `hid-playstation` compensates
for DualSense by sending an output report, but third-party PS5
controllers/accessories do not support that output report format, so
this patch raises the ALSA minimum volume by 6 dB. Symptom is functional
audio output being too quiet on this hardware. No affected kernel
version is stated.

Step 1.4 Record: This is not hidden as cleanup; it is explicitly a
hardware quirk/workaround. It fixes a device-specific functional
problem, not a crash, memory safety issue, or data corruption issue.

## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `sound/usb/mixer.c`, with 10
insertions and no removals. One function changed:
`volume_control_quirks()`. Scope is a single-file, single-switch-entry
hardware quirk.

Step 2.2 Record: Before, PDP Riffmaster USB IDs had no special handling,
so the device-reported volume range was used as-is. After, for USB IDs
`0x0e6f:0x024a` and `0x0e6f:0x0249`, if the ALSA control name is `PCM
Playback Volume`, the code logs the quirk and sets `cval->min = -2560`.

Step 2.3 Record: Bug category is hardware workaround / device-specific
USB-audio volume quirk. The mechanism is correcting the exposed minimum
playback-volume value before ALSA dB conversion and control
registration.

Step 2.4 Record: Fix quality is high: tiny, isolated, matches existing
nearby patterns for device-specific volume quirks, changes no API, and
is gated by exact USB IDs plus exact control name. Regression risk is
very low and limited to the two PDP Riffmaster IDs.

## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` shows `volume_control_quirks()` was
introduced by `dcaaf9f2c16b56` and is present since `v3.2-rc2~23^2~3`.
The immediate insertion context includes the Asus USB DAC quirk from
`4020d1ccbe55bd` (`v5.7~16^2~2`) and, on newer branches, MOONDROP
quirks. For this commit, the “buggy code” is effectively the absence of
a quirk for this hardware, not a bad prior line.

Step 3.2 Record: No `Fixes:` tag is present, so there is no introducing
commit to follow.

Step 3.3 Record: Recent `sound/usb/mixer.c` history contains multiple
related USB-audio volume/control fixes and quirks, including MOONDROP,
Huawei, MS LifeChat, and volume-range checking work. No prerequisite
commit was identified for the Riffmaster quirk itself.

Step 3.4 Record: `git log --author='Rosalie Wanders'` under `sound/usb`
found this one sound commit. The patch was committed by Takashi Iwai,
and `MAINTAINERS` lists Takashi Iwai and Jaroslav Kysela as `SOUND`
maintainers.

Step 3.5 Record: No functional dependencies found. The code assumes only
existing `USB_ID()` matching and `volume_control_quirks()`
infrastructure. Backport may need minor contextual placement on some
branches.

## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 110189f0268d0` found the original thread at
`https://patch.msgid.link/20260426025520.3985-2-rosalie@mailbox.org`.
`b4 dig -a` found only v1. Patchew and b4 showed Takashi Iwai replied
“Applied now. Thanks.” No objections or NAKs found.

Step 4.2 Record: `b4 dig -w` showed recipients: Rosalie Wanders,
Jaroslav Kysela, Takashi Iwai, `linux-sound@vger.kernel.org`, and
`linux-kernel@vger.kernel.org`. The appropriate sound maintainers/list
were included.

Step 4.3 Record: The only `Link:` is the patch submission itself. No
separate bugzilla, syzbot, or user report link was found.

Step 4.4 Record: The patch is standalone v1, not part of a multi-patch
series. No related Riffmaster patches were found in local
`origin/master` history.

Step 4.5 Record: Direct lore stable search was blocked by Anubis, and
web search did not find stable-list discussion for PDP Riffmaster. No
stable-specific nomination or rejection was verified.

## Phase 5: Code Semantic Analysis
Step 5.1 Record: Modified function: `volume_control_quirks()`.

Step 5.2 Record: Call path verified manually: USB probe creates streams
and mixer via `snd_usb_create_mixer()`, mixer parsing reaches
`snd_usb_mixer_controls()`, feature units call `build_feature_ctl()`,
which calls `get_min_max_with_quirks()`, which calls
`volume_control_quirks()` when a `kctl` exists.

Step 5.3 Record: Relevant callees are `usb_audio_info()` and later ALSA
dB/range handling in `get_min_max_with_quirks()`. The patch changes
`cval->min` before `dBmin`, `dBmax`, initialization, and control
registration.

Step 5.4 Record: Reachability is via USB device enumeration and ALSA
mixer creation for this specific hardware. Userspace impact is through
normal audio/mixer use after the device is connected. I did not verify
the actual device descriptor/control name on hardware.

Step 5.5 Record: Similar patterns exist in the same switch for
CM102-A+/102S+, Asus USB DAC, MOONDROP Quark2, Huawei CM-Q3, and
MOONDROP JU Jiu. A similar MOONDROP JU Jiu quirk was explicitly tagged
for stable.

## Phase 6: Stable Tree Analysis
Step 6.1 Record: Checked `remotes/stable/linux-5.10.y`, `5.15.y`,
`6.1.y`, `6.6.y`, `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y`: all contain
`volume_control_quirks()` and the call from `get_min_max_with_quirks()`.
None contained the Riffmaster IDs.

Step 6.2 Record: Current `7.0.y` working tree accepts the patch with
`git apply --check`. `git merge-tree` suggests most checked branches can
merge the addition automatically, but `5.15.y` shows a minor context
conflict around another quirk entry after the Asus DAC entry.

Step 6.3 Record: No related Riffmaster fix already present in the
checked stable branches or `origin/master` history beyond
`110189f0268d0`.

## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is ALSA USB audio under `sound/usb`.
Criticality is driver-specific/peripheral: it affects users of the PDP
Riffmaster hardware, not the whole system.

Step 7.2 Record: Recent history shows `sound/usb` is actively
maintained, with nearby fixes and quirks. The patch was committed by a
listed sound maintainer.

## Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is hardware-specific: PDP
Riffmaster PS4/PS5 users with USB-audio playback exposed as `PCM
Playback Volume`.

Step 8.2 Record: Trigger is connecting/using that hardware and its ALSA
playback volume control. This is common for affected users but
irrelevant to everyone else. Unprivileged users can observe/use ALSA
controls depending on system policy, but the patch itself runs at device
enumeration/control setup.

Step 8.3 Record: Failure mode is too-low audio volume / poor device
usability, not a crash or corruption issue. Severity is medium for
affected hardware.

Step 8.4 Record: Benefit is high for affected device users and zero-
impact for other devices. Risk is very low because the change is 10
lines, exact USB-ID gated, and follows existing quirk-table style.

## Phase 9: Final Synthesis
Step 9.1 Record:
Evidence for backporting: this is a classic hardware quirk, small and
contained, maintainer-applied, affects real hardware, and all checked
active stable branches have the infrastructure. Hardware quirks are an
accepted stable exception.
Evidence against: no `Cc: stable`, no `Tested-by`, no separate bug
report, and the failure is not crash/security/data corruption. `5.15.y`
may need minor manual placement.
Unresolved: no hardware test or descriptor dump was available to
independently verify that the device exposes the exact `PCM Playback
Volume` control.

Step 9.2 Stable rules:
1. Obviously correct and tested? Mostly yes on correctness; no explicit
   `Tested-by` or local hardware test.
2. Fixes a real bug? Yes, per commit and mailing-list submission: too-
   low volume on specific hardware.
3. Important issue? Medium severity hardware usability issue; stable
   exception applies for quirks.
4. Small and contained? Yes, 10 lines in one switch.
5. No new features/APIs? Yes, no API or broad behavior change.
6. Can apply to stable? Yes for current tree; likely minor context
   handling for at least `5.15.y`.

Step 9.3 Exception category Record: Hardware quirk/workaround for
specific USB devices. This is a stable-appropriate exception category.

Step 9.4 Decision: Backport. The technical risk is extremely low, the
change is device-specific, and stable policy explicitly allows
quirks/workarounds for real hardware problems.

## Verification
- Phase 1: Parsed `git show --format=fuller --stat --patch
  110189f0268d0`; confirmed subject, tags, commit body, author,
  committer, and 10-line diff.
- Phase 2: Verified the only code change is adding two `USB_ID()` cases
  in `volume_control_quirks()`.
- Phase 3: Ran `git blame` around the insertion context; identified
  historical context commits and version containment via `git describe
  --contains`.
- Phase 3: Ran local history searches without `--all`; found no
  prerequisite Riffmaster commits.
- Phase 4: Ran `b4 dig -c`, `b4 dig -a`, and `b4 dig -w`; confirmed one
  v1 patch, original recipients, and lore URL.
- Phase 4: Used b4 mbox and Patchew to read the thread; confirmed
  Takashi’s “Applied now. Thanks.” reply and no objections.
- Phase 4: Stable lore WebFetch was blocked by Anubis; WebSearch found
  no stable-specific Riffmaster discussion.
- Phase 5: Read `sound/usb/mixer.c`, `sound/usb/card.c`, and
  `sound/usb/quirks.c`; traced the mixer creation and feature-control
  path to `volume_control_quirks()`.
- Phase 6: Checked stable branches `5.10.y`, `5.15.y`, `6.1.y`, `6.6.y`,
  `6.12.y`, `6.18.y`, `6.19.y`, and `7.0.y`; confirmed infrastructure
  exists and Riffmaster IDs are absent.
- Phase 6: Ran `git apply --check` on current tree; passed. Ran `git
  merge-tree`; noted a minor conflict marker for `5.15.y`.
- Phase 7: Verified `MAINTAINERS` lists Jaroslav Kysela and Takashi Iwai
  for `SOUND`.
- Phase 8: Verified scope is exact-device gated by USB IDs and exact
  mixer control name.
- UNVERIFIED: Actual PDP Riffmaster USB descriptors and hardware
  behavior were not locally tested.
- UNVERIFIED: Older branches outside the checked active stable set were
  not analyzed.

**YES**

 sound/usb/mixer.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 1ced9ba8be406..75c932ea77388 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1190,6 +1190,16 @@ static void volume_control_quirks(struct usb_mixer_elem_info *cval,
 			cval->res = 1;
 		}
 		break;
+
+	case USB_ID(0x0e6f, 0x024a): /* PDP Riffmaster for PS4 */
+	case USB_ID(0x0e6f, 0x0249): /* PDP Riffmaster for PS5 */
+		if (!strcmp(kctl->id.name, "PCM Playback Volume")) {
+			usb_audio_info(chip,
+				"set volume quirk for PDP Riffmaster for PS4/PS5\n");
+			cval->min = -2560; /* Mute under it */
+		}
+		break;
+
 	case USB_ID(0x3302, 0x12db): /* MOONDROP Quark2 */
 		if (!strcmp(kctl->id.name, "PCM Playback Volume")) {
 			usb_audio_info(chip,
-- 
2.53.0

[PATCH AUTOSEL 7.0] ALSA: hda/realtek: enable mute LED support on ThinkBook 16p

[Sasha Levin]

From: Yuxuan Qiu <yuxuanqiu596@gmail.com>

[ Upstream commit 597aa74b0e73f5e0c915b5d0c95cb296774589bd ]

On ThinkBook 16p systems the platform mute LED is present and
bound to the audio-mute trigger, but it does not react to Master
mute changes.

The affected fixup chain sets up the DAC routing, but does not enable
vmaster mute LED handling. Because of that, the generic HDA code does
not mark Master Playback Switch with SNDRV_CTL_ELEM_ACCESS_SPK_LED,
and the audio-mute trigger never receives speaker mute updates.

Add a ThinkBook-specific wrapper around alc287_fixup_bind_dacs() and
enable spec->gen.vmaster_mute_led during PRE_PROBE. This keeps the
existing DAC binding logic unchanged while allowing the normal generic
LED path to drive the mute LED.

Signed-off-by: Yuxuan Qiu <yuxuanqiu596@gmail.com>
Link: https://patch.msgid.link/20260424112107.22206-1-yuxuanqiu596@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:

## Phase 1: Commit Message Forensics

Step 1.1 Record: subsystem `ALSA: hda/realtek`; action verb `enable`;
claimed intent is enabling speaker mute LED support on Lenovo ThinkBook
16p systems whose LED is already bound to `audio-mute` but not updated
by Master mute changes.

Step 1.2 Record: tags present are `Signed-off-by: Yuxuan Qiu
<yuxuanqiu596@gmail.com>`, `Link:
https://patch.msgid.link/20260424112107.22206-1-yuxuanqiu596@gmail.com`,
and `Signed-off-by: Takashi Iwai <tiwai@suse.de>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable@vger.kernel.org` tag was present.

Step 1.3 Record: the commit describes a real hardware behavior bug: the
platform mute LED exists and is registered with the `audio-mute`
trigger, but `Master Playback Switch` lacks
`SNDRV_CTL_ELEM_ACCESS_SPK_LED`, so ALSA control LED notifications never
drive the LED. No kernel crash, corruption, or security symptom is
claimed. No affected kernel version is explicitly stated.

Step 1.4 Record: this is a hardware quirk/fix disguised as an enablement
patch. It is not a new driver or new API; it enables an existing generic
HDA LED path for an existing Realtek/Lenovo fixup chain.

## Phase 2: Diff Analysis

Step 2.1 Record: one file changed, `sound/hda/codecs/realtek/alc269.c`,
with 12 insertions and 1 replacement in the submitted patch. Modified
areas are a new helper `alc287_fixup_tb_vmaster_led()` and the
`ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD` fixup table entry.
Scope is single-file and surgical.

Step 2.2 Record: before,
`ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD` directly called
`alc287_fixup_bind_dacs()`, which adjusts DAC routing and amp mute
behavior during `HDA_FIXUP_ACT_PRE_PROBE`. After, it calls a wrapper
that sets `spec->gen.vmaster_mute_led = 1` during `PRE_PROBE`, then
calls the same DAC binding function. Normal DAC binding behavior is
preserved.

Step 2.3 Record: bug category is hardware quirk / logic correctness for
LED control metadata. The broken mechanism is missing
`vmaster_mute_led`, verified in `generic.c`: when set,
`snd_hda_gen_build_controls()` adds `SNDRV_CTL_ELEM_ACCESS_SPK_LED` to
`Master Playback Switch`; the ALSA control LED layer then follows that
control and fires the `audio-mute` LED trigger.

Step 2.4 Record: the fix is obviously simple: a one-bit flag is set
before auto config parsing/building controls, and the existing fixup
function is still invoked. Main regression risk is that the changed
fixup ID is shared by several Lenovo ThinkPad/ThinkBook SSIDs, not only
ThinkBook 16p. Verified matching entries include ThinkPad P1/Z-series,
ThinkBook 16P, ThinkBook 13x, and ThinkBook 16P Gen5 on current
branches. The behavioral change is limited to LED control tagging, so
risk is low.

## Phase 3: Git History Investigation

Step 3.1 Record: `git blame` on current `v7.0.3` points changed lines to
the Realtek driver split commit `aeeb85f26c3b` because the file moved.
`git log -S` traced the actual related history: ThinkBook 16P IDs
`0x38a9/0x38ab` were added by `6214e24cae9b` in v6.8; Gen4 was switched
to the affected MG/CS35L41 fixup by `dca5f4dfa925` in v6.9; Gen5 was
switched by `34c8e74cd666` in v6.13. The affected MG/CS35L41 fixup was
introduced earlier by `d93eeca627db`.

Step 3.2 Record: no `Fixes:` tag is present, so there was no tagged
introducing commit to follow. Related history nevertheless shows the
affected ThinkBook 16P quirk chain exists in maintained stable-era
kernels.

Step 3.3 Record: recent file history shows many ALSA Realtek quirk and
mute LED fixes. Related ThinkBook commits are `dca5f4dfa925` and
`34c8e74cd666`, both fixing ThinkBook 16P volume/mute behavior by
selecting the same MG/CS35L41 fixup. No prerequisite patch for this new
wrapper was identified beyond the target tree already having
`alc287_fixup_bind_dacs()` and
`ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD`.

Step 3.4 Record: no prior local commits from Yuxuan Qiu were found under
the Realtek HDA paths. Takashi Iwai, the ALSA maintainer, applied the
patch in the mailing-list thread.

Step 3.5 Record: dependencies are minimal. Current `v7.0.3` accepts the
submitted patch with `git apply --check`. Older pre-driver-split stable
trees need a path adjustment from `sound/hda/codecs/realtek/alc269.c` to
`sound/pci/hda/patch_realtek.c`.

## Phase 4: Mailing List And External Research

Step 4.1 Record: no local commit hash for this candidate was available,
so `b4 dig -c <commit>` was not applicable. `b4 am` using message id
`20260424112107.22206-1-yuxuanqiu596@gmail.com` fetched the original
submission and reported one patch in a two-message thread. The yhbt lore
mirror confirmed the same patch text and one maintainer reply.

Step 4.2 Record: recipients verified from the mbox were Jaroslav Kysela,
Takashi Iwai, `linux-sound@vger.kernel.org`, and `linux-
kernel@vger.kernel.org`. Takashi Iwai replied “Thanks, applied now.” No
NAKs or concerns were present in the fetched thread.

Step 4.3 Record: there was no separate `Reported-by:` or bugzilla/syzbot
link in this patch. External search found the indexed patch and related
Lenovo mute LED/platform LED context, but no independent user bug report
for this exact issue.

Step 4.4 Record: the thread is a single-patch submission, not a multi-
patch series. No later revision was found by `b4 am`; the thread
contains only the patch and maintainer apply reply.

Step 4.5 Record: web search did not find a stable-specific discussion or
explicit stable request for this exact patch. Direct lore WebFetch was
blocked by Anubis, but the yhbt mirror and `b4` provided the thread
content.

## Phase 5: Code Semantic Analysis

Step 5.1 Record: modified functions/objects are
`alc287_fixup_tb_vmaster_led()` and the
`ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD` fixup table entry.

Step 5.2 Record: call path verified: `alc269_probe()` picks Realtek
fixups, applies `HDA_FIXUP_ACT_PRE_PROBE`, then runs
`alc269_parse_auto_config()`; `alc_build_controls()` later calls
`snd_hda_gen_build_controls()`. The affected code runs during codec
probe for matching Lenovo HDA SSIDs.

Step 5.3 Record: key callees are `alc287_fixup_bind_dacs()`,
`snd_hda_override_conn_list()`, and generic HDA control creation.
`generic.c` verifies `spec->vmaster_mute_led` directly controls whether
`SNDRV_CTL_ELEM_ACCESS_SPK_LED` is passed to `__snd_hda_add_vmaster()`.

Step 5.4 Record: runtime reachability is verified through hardware probe
and ALSA mixer control updates. Userspace changing `Master Playback
Switch` can trigger ALSA control LED notifications once the control has
the speaker LED access flag.

Step 5.5 Record: similar Realtek patterns exist: many HDA Realtek
commits add or fix mute LED quirks; current code also has existing
`vmaster_mute_led = 1` usage in another mute LED fixup and many
`snd_hda_gen_add_mute_led_cdev()` users.

## Phase 6: Cross-Referencing And Stable Tree Analysis

Step 6.1 Record: `v6.12` contains ThinkBook 16P `0x38a9/0x38ab` using
the affected fixup; `v6.13+` contains ThinkBook 16P Gen5 `0x38f9` using
the affected fixup. `for-greg/6.12-201` contains both ThinkBook 16P and
Gen5 using the affected fixup. `for-greg/6.6-201` contains the affected
fixup for several ThinkPad SSIDs but not the original ThinkBook 16P
`0x38a9/0x38ab`; its Gen5 `0x38f9` entry still uses
`ALC287_FIXUP_CS35L41_I2C_2`, so this exact ThinkBook 16p bug is not
fully verified there.

Step 6.2 Record: expected backport difficulty is clean for current post-
split trees such as `v7.0.3`; minor manual backport for pre-split trees
because the same code lives in `sound/pci/hda/patch_realtek.c`.

Step 6.3 Record: no alternate stable fix for this exact mute LED issue
was found. Related ThinkBook volume/mute fixup selection commits exist
and are prerequisites for branches where the ThinkBook entries use the
affected MG/CS35L41 fixup.

## Phase 7: Subsystem And Maintainer Context

Step 7.1 Record: subsystem is ALSA HDA Realtek codec quirks, under sound
drivers. Criticality is peripheral/driver-specific, affecting Lenovo
systems with these Realtek/CS35L41 configurations.

Step 7.2 Record: subsystem activity is high; recent history shows many
Realtek quirk additions and mute LED fixes. This is typical stable
material when scoped to specific hardware behavior.

## Phase 8: Impact And Risk Assessment

Step 8.1 Record: affected population is driver-specific: Lenovo
ThinkBook/ThinkPad systems matching the shared
`ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD` quirk, especially
verified ThinkBook 16P/16P Gen5 entries in newer stable trees.

Step 8.2 Record: trigger condition is ordinary Master mute changes after
boot on affected hardware. This is user-triggerable through normal audio
controls. The failure is visible as a mute LED that does not track mute
state.

Step 8.3 Record: failure severity is LOW to MEDIUM. It is not a crash or
data-loss bug, but it is a real hardware/user-visible regression in mute
state indication.

Step 8.4 Record: benefit is moderate for affected laptops: restores
expected mute LED behavior using existing ALSA trigger infrastructure.
Risk is low: one bit is set during probe and existing DAC routing logic
remains unchanged. The only meaningful concern is wider impact on all
devices sharing the fixup ID, but the added effect is LED
metadata/control-trigger handling, not audio routing or power
sequencing.

## Phase 9: Final Synthesis

Step 9.1 Record:
Evidence for backporting: real user-visible hardware bug; tiny one-file
fix; uses existing generic HDA LED path; accepted by ALSA maintainer
Takashi Iwai; current tree patch applies cleanly; stable-style hardware
quirk; related ThinkBook fixup commits are already present in maintained
stable branches.
Evidence against backporting: no crash/security/corruption; no
`Reported-by` or `Tested-by`; fixup ID is shared beyond ThinkBook 16p;
older stable branches may need path adjustment and should only receive
this where the affected fixup/IDs exist.
Unresolved: exact upstream commit SHA was not available locally; no
independent bug report beyond the patch mail was found; exact
applicability to every active stable branch must be checked branch-by-
branch.

Step 9.2 Record:
1. Obviously correct and tested? Mostly yes by inspection and maintainer
   acceptance; no explicit `Tested-by`.
2. Fixes a real bug? Yes, verified mechanism: missing `vmaster_mute_led`
   prevents `SNDRV_CTL_ELEM_ACCESS_SPK_LED` tagging.
3. Important issue? Moderate, hardware/user-visible mute LED
   correctness, not critical stability.
4. Small and contained? Yes, one helper and one fixup function pointer
   change.
5. No new feature/API? Yes in stable sense: it enables existing LED
   trigger behavior for existing hardware; no new userspace API.
6. Can apply to stable trees? Yes on current post-split trees; older
   trees need path adjustment.

Step 9.3 Record: exception category applies: hardware-specific
quirk/workaround in an existing driver.

Step 9.4 Decision: backport. This is not a critical crash fix, but ALSA
HDA hardware quirks and mute LED fixes are normal stable material. The
patch is small, preserves existing routing logic, and fixes a concrete
hardware behavior problem on affected Lenovo systems. Backport only to
trees containing the affected fixup and relevant Lenovo entries, with
pre-split path adjustment where needed.

## Verification

- [Phase 1] Parsed supplied subject/body/tags; confirmed no `Fixes:`,
  `Reported-by`, `Tested-by`, `Reviewed-by`, or stable tag.
- [Phase 2] Read local `alc269.c`; confirmed `alc287_fixup_bind_dacs()`
  adjusts DAC routing and does not set `vmaster_mute_led`.
- [Phase 2] Read `generic.h` and `generic.c`; confirmed
  `vmaster_mute_led` means “add SPK-LED flag to vmaster mute switch” and
  is used when creating `Master Playback Switch`.
- [Phase 3] `git blame` and `git log -S` traced related ThinkBook/fixup
  history to `6214e24cae9b`, `dca5f4dfa925`, `34c8e74cd666`, and
  `d93eeca627db`.
- [Phase 3] `git show` confirmed `6214e24cae9b` added ThinkBook 16P IDs,
  `dca5f4dfa925` switched Gen4 to the affected fixup, and `34c8e74cd666`
  switched Gen5 to the affected fixup.
- [Phase 3] `git log --author="Yuxuan Qiu"` under Realtek paths found no
  prior local author commits.
- [Phase 4] `b4 am` fetched the two-message thread; `b4 mbox` saved and
  verified the full thread.
- [Phase 4] WebFetch of patch.msgid.link was blocked by Anubis; yhbt
  lore mirror successfully showed the patch and Takashi Iwai’s “Thanks,
  applied now.”
- [Phase 4] WebSearch found no stable-specific request for this exact
  patch.
- [Phase 5] `rg` and file reads verified the probe path:
  `alc269_probe()` applies PRE_PROBE fixups before auto config parsing,
  and `alc_build_controls()` calls generic control creation.
- [Phase 5] Read `control_led.c`; confirmed controls tagged with speaker
  LED access update the `audio-mute` LED trigger.
- [Phase 6] `git grep` verified `v6.12` and `for-greg/6.12-201` contain
  ThinkBook entries using the affected fixup; `for-greg/6.6-201`
  contains the affected fixup but not the original ThinkBook 16P IDs.
- [Phase 6] `git apply --check` against current `v7.0.3` succeeded.
- [Phase 8] Risk assessment verified the patch changes only LED metadata
  setup and preserves the existing `alc287_fixup_bind_dacs()` call.
- UNVERIFIED: exact candidate commit SHA, because the subject was not
  found as a local commit in the checked branches and only the mailing-
  list patch was available.
- UNVERIFIED: independent user bug report outside the patch thread.
- UNVERIFIED: clean application to every older stable branch without
  manual path adjustment.

**YES**

 sound/hda/codecs/realtek/alc269.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c
index ae74e1b69eb3a..44cf78ea6dc03 100644
--- a/sound/hda/codecs/realtek/alc269.c
+++ b/sound/hda/codecs/realtek/alc269.c
@@ -3707,6 +3707,17 @@ static void alc287_fixup_lenovo_thinkpad_with_alc1318(struct hda_codec *codec,
 	spec->power_hook = alc287_s4_power_gpio3_default;
 	spec->gen.pcm_playback_hook = alc287_alc1318_playback_pcm_hook;
 }
+
+static void alc287_fixup_tb_vmaster_led(struct hda_codec *codec,
+					const struct hda_fixup *fix, int action)
+{
+	struct alc_spec *spec = codec->spec;
+
+	if (action == HDA_FIXUP_ACT_PRE_PROBE)
+		spec->gen.vmaster_mute_led = 1;
+
+	alc287_fixup_bind_dacs(codec, fix, action);
+}
 /* GPIO2: mute led GPIO3: micmute led */
 static void alc245_tas2781_spi_hp_fixup_muteled(struct hda_codec *codec,
 					  const struct hda_fixup *fix, int action)
@@ -6460,7 +6471,7 @@ static const struct hda_fixup alc269_fixups[] = {
 	},
 	[ALC287_FIXUP_MG_RTKC_CSAMP_CS35L41_I2C_THINKPAD] = {
 		.type = HDA_FIXUP_FUNC,
-		.v.func = alc287_fixup_bind_dacs,
+		.v.func = alc287_fixup_tb_vmaster_led,
 		.chained = true,
 		.chain_id = ALC287_FIXUP_CS35L41_I2C_2_THINKPAD_ACPI,
 	},
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.12] ASoC: codecs: wcd937x: fix AUX PA sequencing and mixer controls

[Sasha Levin]

From: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>

[ Upstream commit 74c876bfd71b1023029a483d7213015201f62b53 ]

Enable AUX PA sequencing during AUX DAC DAPM events and keep the
AUX-specific RX supplies enabled while the path is active.

Add the missing AUX-related mixer controls, including CLSH PA and
DSD left/right switches, so AUX playback can be routed from userspace.

Signed-off-by: Ajay Kumar Nandam <ajay.nandam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260420180221.785113-1-ajay.nandam@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Decision Summary
This is a small WCD937x codec fix for an existing AUX playback path. The
verified problem is functional: the AUX path has DAPM routing and
SoundWire channel definitions, but lacks required AUX PA
sequencing/supplies and mixer controls needed for userspace routing.
That can result in broken AUX playback on affected Qualcomm WCD937x
systems.

It is not a security/crash/data-corruption fix, and it does add visible
ALSA mixer controls, which is the main stable-policy concern. On
balance, I would backport it to stable trees that already contain the
WCD937x AUX playback code, especially `v6.12+`; it is small, driver-
local, applies cleanly to `v6.12`, and fixes existing hardware
functionality rather than adding a new driver or subsystem.

## Phase Walkthrough

### Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `ASoC: codecs: wcd937x`; action verb `fix`;
intent is to fix AUX PA sequencing and missing AUX-related mixer
controls.

Step 1.2 Record: tags found: `Signed-off-by: Ajay Kumar Nandam
<ajay.nandam@oss.qualcomm.com>`, `Link: https://patch.msgid.link/2026042
0180221.785113-1-ajay.nandam@oss.qualcomm.com`, `Signed-off-by: Mark
Brown <broonie@kernel.org>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Reviewed-by:`, or `Cc: stable`.

Step 1.3 Record: message says AUX PA sequencing must be enabled during
AUX DAC DAPM events, AUX-specific RX supplies must stay enabled while
active, and missing CLSH/DSD mixer controls prevent userspace from
routing AUX playback. No crash trace, board name, or kernel version is
stated.

Step 1.4 Record: this is a hidden functional hardware bug fix, not
cleanup. It repairs missing register sequencing and missing routing
controls for an already-present AUX playback path.

### Phase 2: Diff Analysis
Step 2.1 Record: one file, `sound/soc/codecs/wcd937x.c`, `25
insertions`, `1 deletion`. Modified functions/data:
`wcd937x_codec_aux_dac_event()`, `wcd937x_codec_enable_aux_pa()`,
`wcd937x_snd_controls[]`. Scope is single-file, driver-local, surgical.

Step 2.2 Record: `wcd937x_codec_aux_dac_event()` now sets/clears
`WCD937X_AUX_AUXPA` bit 4 with AUX DAC power-up/down.
`wcd937x_codec_enable_aux_pa()` now enables `WCD937X_ANA_RX_SUPPLIES`
bits 6 and 7 after AUX PA power-up and disables them before power-down
completes. `wcd937x_snd_controls[]` gains CLSH/DSD RX SoundWire
switches.

Step 2.3 Record: bug category is hardware sequencing plus
routing/control correctness. The affected path is normal AUX playback,
not an error path, race, memory safety issue, or refcount issue.

Step 2.4 Record: fix is small and easy to audit, but there is a
regression concern: Mark Brown noted in review that disabling RX
supplies in `SND_SOC_DAPM_PRE_PMD` before DAPM disables the PGA is “a
bit weird.” He later applied the patch anyway; no NAK or follow-up
correction was found in the thread.

### Phase 3: Git History Investigation
Step 3.1 Record: blame shows the AUX DAC/PA event code came from
`57fe69db7a015e` (“ASoC: codecs: wcd937x: add playback dapm widgets”),
first contained in `v6.11-rc1`. The base controls came from
`82be8c62a38c6a` (“add basic controls”), also first contained in
`v6.11-rc1`.

Step 3.2 Record: no `Fixes:` tag, so no tagged introducer to follow.
Manual blame identifies the relevant introducers above.

Step 3.3 Record: related history includes `041db4bbe04e8` adding a
missing `LO Switch` control, and `107a5c853eef5` relaxing the AUX PDM
watchdog. The candidate’s context includes the watchdog changes, which
are present from `v6.12`.

Step 3.4 Record: no earlier commits by Ajay Kumar Nandam touching
`sound/soc/codecs` or `wcd937x.c` were found on this branch. The patch
was applied by ASoC maintainer Mark Brown.

Step 3.5 Record: dependencies are the existing WCD937x playback widgets,
controls, SoundWire channel definitions, and for clean context the AUX
watchdog update. It applies cleanly to current `7.0` and to a checked
`v6.12` worktree.

### Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 74c876bfd71b` found the original patch at
the patch.msgid.link URL. `b4 dig -a` found only `v1`; no later
revision.

Step 4.2 Record: `b4 dig -w` showed appropriate recipients: Srinivas
Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
`linux-sound`, `linux-arm-msm`, and `linux-kernel`.

Step 4.3 Record: no separate bug report or syzbot/bugzilla link was
present. Web/lore mirror confirmed the only substantive review comment
was Mark Brown’s sequencing concern.

Step 4.4 Record: no multi-patch series was found; this is a standalone
one-patch submission.

Step 4.5 Record: direct lore stable search via `WebFetch` was blocked by
Anubis; web search did not reveal stable-specific discussion for this
exact patch.

### Phase 5: Code Semantic Analysis
Step 5.1 Record: modified functions/data are
`wcd937x_codec_aux_dac_event()`, `wcd937x_codec_enable_aux_pa()`, and
`wcd937x_snd_controls[]`.

Step 5.2 Record: `rg` found both event functions are referenced only by
DAPM widgets: `RDAC4` uses `wcd937x_codec_aux_dac_event()`, and `AUX
PGA` uses `wcd937x_codec_enable_aux_pa()`.

Step 5.3 Record: key callees are `snd_soc_component_update_bits()`,
`wcd937x_rx_clk_enable()`, `wcd_clsh_ctrl_set_state()`, `enable_irq()`,
and `disable_irq_nosync()`. Mixer controls call `wcd937x_get_swr_port()`
/ `wcd937x_set_swr_port()`.

Step 5.4 Record: call chain is userspace ALSA routing/control changes ->
ASoC DAPM powers the AUX route (`IN3_AUX` -> `RX3` -> `RDAC4` ->
`AUX_RDAC` -> `AUX PGA` -> `AUX`) -> the modified DAPM event callbacks
program the codec. The mixer control path updates SoundWire port/channel
masks used later by `wcd937x_sdw_hw_params()` and
`sdw_stream_add_slave()`.

Step 5.5 Record: similar pattern exists in the same driver history:
`041db4bbe04e8` added a missing `LO Switch` for audio playback routing.
`wcd937x-sdw.c` already defines RX channels for `WCD937X_CLSH`,
`WCD937X_DSD_L`, and `WCD937X_DSD_R`, confirming the new controls target
existing channel definitions.

### Phase 6: Stable Tree Analysis
Step 6.1 Record: `v6.1` and `v6.6` do not contain the relevant WCD937x
AUX code. `v6.11` contains the AUX widgets and channel definitions.
`v6.12` contains the watchdog context used by this patch.

Step 6.2 Record: backport difficulty is clean for `v6.12+`; verified by
creating a detached `v6.12` worktree and running `git apply --check`.
For `v6.11`, the patch may need adjustment or prerequisite
`107a5c853eef5`.

Step 6.3 Record: no alternative fix for this exact AUX PA sequencing /
CLSH+DSD control issue was found in current branch history.

### Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is ALSA SoC codec driver under
`sound/soc/codecs`; criticality is driver-specific/peripheral, affecting
systems using Qualcomm WCD937x AUX playback.

Step 7.2 Record: WCD937x is active: recent history includes
probe/resource fixes, SoundWire port fixes, OF node leak fixes, and AUX
watchdog fixes.

### Phase 8: Impact And Risk
Step 8.1 Record: affected users are WCD937x codec users with AUX
playback routes.

Step 8.2 Record: trigger is normal AUX playback setup/routing through
ALSA/ASoC; userspace can trigger routing through mixer controls. Exact
affected board population was not verified.

Step 8.3 Record: failure mode is loss of AUX playback/routing, not a
crash or memory-safety bug. Severity is medium for the kernel generally,
high for affected hardware where AUX playback is required.

Step 8.4 Record: benefit is restoring existing hardware functionality on
affected WCD937x systems. Risk is low to medium: the patch is tiny and
driver-local, but adds visible mixer controls and has one noted
sequencing concern.

### Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: fixes existing AUX playback
functionality; small single-driver patch; code and channels already
exist; applies cleanly to `v6.12`; reviewed/applied by ASoC maintainer.
Evidence against: no `Reported-by`/`Tested-by`; not a
crash/security/corruption fix; adds new ALSA controls; maintainer raised
a sequencing concern. Unresolved: exact board/user impact and whether
`v6.11` should receive a hand backport.

Step 9.2 Record: stable rules checklist: obviously correct and tested:
mostly yes by code inspection and maintainer application, but no
explicit `Tested-by`; real bug: yes, broken AUX routing/sequencing;
important issue: yes for affected hardware, though not critical system-
wide; small and contained: yes; no new feature/API: borderline because
mixer controls are user-visible, but they expose existing missing route
controls; applies to stable: yes for `v6.12+`, older active trees
without WCD937x AUX code are not applicable.

Step 9.3 Record: exception category: closest match is hardware-specific
driver functionality fix, not a pure device-ID/quirk/build/doc
exception.

Step 9.4 Record: decision is YES for stable trees containing the WCD937x
AUX playback path, especially `v6.12+`. Do not backport to trees where
the driver/path does not exist.

## Verification
- Phase 1: Read candidate commit message and tags from `git show
  74c876bfd71b` and b4-fetched mbox.
- Phase 2: Verified diff stat: one file, `25 insertions`, `1 deletion`.
- Phase 3: Ran `git blame` on AUX DAC, AUX PA, and controls blocks;
  identified `57fe69db7a015e` and `82be8c62a38c6a`.
- Phase 3: Ran `git describe --contains`; WCD937x AUX/control code
  starts in `v6.11-rc1`; watchdog context starts in `v6.12-rc6`.
- Phase 4: Ran `b4 dig -c 74c876bfd71b`, `-a`, and `-w`; found v1-only
  patch and original recipients.
- Phase 4: Fetched lore mirror; confirmed Mark Brown’s review concern
  and later ASoC application.
- Phase 5: Used `rg` and file reads to trace DAPM widget references, AUX
  route, SoundWire channel definitions, and `wcd937x_sdw_hw_params()`.
- Phase 6: Used `git grep` against `v6.1`, `v6.6`, `v6.11`, and `v6.12`;
  verified absence/presence of relevant code.
- Phase 6: Verified `git apply --check` succeeds on current tree and on
  a temporary detached `v6.12` worktree.
- Unverified: exact affected product/board list; no explicit tester or
  reporter was found.

**YES**

 sound/soc/codecs/wcd937x.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wcd937x.c b/sound/soc/codecs/wcd937x.c
index 10a2d598caa71..72a53f95d6887 100644
--- a/sound/soc/codecs/wcd937x.c
+++ b/sound/soc/codecs/wcd937x.c
@@ -546,6 +546,9 @@ static int wcd937x_codec_aux_dac_event(struct snd_soc_dapm_widget *w,
 		snd_soc_component_update_bits(component,
 					      WCD937X_DIGITAL_CDC_ANA_CLK_CTL,
 					      BIT(2), BIT(2));
+		snd_soc_component_update_bits(component,
+					      WCD937X_AUX_AUXPA,
+					      BIT(4), BIT(4));
 		snd_soc_component_update_bits(component,
 					      WCD937X_DIGITAL_CDC_DIG_CLK_CTL,
 					      BIT(2), BIT(2));
@@ -562,6 +565,9 @@ static int wcd937x_codec_aux_dac_event(struct snd_soc_dapm_widget *w,
 		snd_soc_component_update_bits(component,
 					      WCD937X_DIGITAL_CDC_ANA_CLK_CTL,
 					      BIT(2), 0x00);
+		snd_soc_component_update_bits(component,
+					      WCD937X_AUX_AUXPA,
+					      BIT(4), 0x00);
 		break;
 	}
 
@@ -730,10 +736,23 @@ static int wcd937x_codec_enable_aux_pa(struct snd_soc_dapm_widget *w,
 			snd_soc_component_update_bits(component,
 						      WCD937X_ANA_RX_SUPPLIES,
 						      BIT(1), BIT(1));
+		/* Enable AUX PA related RX supplies */
+		snd_soc_component_update_bits(component,
+					      WCD937X_ANA_RX_SUPPLIES,
+					      BIT(6), BIT(6));
+		snd_soc_component_update_bits(component,
+					      WCD937X_ANA_RX_SUPPLIES,
+					      BIT(7), BIT(7));
 		enable_irq(wcd937x->aux_pdm_wd_int);
 		break;
 	case SND_SOC_DAPM_PRE_PMD:
 		disable_irq_nosync(wcd937x->aux_pdm_wd_int);
+		snd_soc_component_update_bits(component,
+					      WCD937X_ANA_RX_SUPPLIES,
+					      BIT(6), 0x00);
+		snd_soc_component_update_bits(component,
+					      WCD937X_ANA_RX_SUPPLIES,
+					      BIT(7), 0x00);
 		break;
 	case SND_SOC_DAPM_POST_PMD:
 		usleep_range(2000, 2010);
@@ -2051,7 +2070,12 @@ static const struct snd_kcontrol_new wcd937x_snd_controls[] = {
 		       wcd937x_get_swr_port, wcd937x_set_swr_port),
 	SOC_SINGLE_EXT("LO Switch", WCD937X_LO, 0, 1, 0,
 		       wcd937x_get_swr_port, wcd937x_set_swr_port),
-
+	SOC_SINGLE_EXT("CLSH PA Switch", WCD937X_CLSH, 0, 1, 0,
+		       wcd937x_get_swr_port, wcd937x_set_swr_port),
+	SOC_SINGLE_EXT("DSD_L Switch", WCD937X_DSD_L, 0, 1, 0,
+		       wcd937x_get_swr_port, wcd937x_set_swr_port),
+	SOC_SINGLE_EXT("DSD_R Switch", WCD937X_DSD_R, 0, 1, 0,
+		       wcd937x_get_swr_port, wcd937x_set_swr_port),
 	SOC_SINGLE_EXT("ADC1 Switch", WCD937X_ADC1, 1, 1, 0,
 		       wcd937x_get_swr_port, wcd937x_set_swr_port),
 	SOC_SINGLE_EXT("ADC2 Switch", WCD937X_ADC2, 1, 1, 0,
-- 
2.53.0

[PATCH AUTOSEL 7.0-6.6] ASoC: aw88395: Fix kernel panic caused by invalid GPIO error pointer

[Sasha Levin]

From: wangdicheng <wangdicheng@kylinos.cn>

[ Upstream commit 241ee17ecb6be210f7b231b2a81bfb68871950d0 ]

In aw88395_i2c_probe(), if `devm_gpiod_get_optional()` fails, it returns
an ERR_PTR() error pointer. The current code only prints a message and
continues execution, leaving `aw88395->reset_gpio` as an invalid pointer.

Later, in `aw88395_hw_reset()`, this invalid pointer is passed to
`gpiod_set_value_cansleep()`, which dereferences it and causes a kernel
panic.

For optional GPIOs, `devm_gpiod_get_optional()` returns NULL if the GPIO
is not defined in the DT, which is safe. If it returns an ERR_PTR, it
means a real error occurred (e.g., -EPROBE_DEFER) and the probe must be
aborted.

Also, since the GPIO is optional, remove the dev_err() log in
aw88395_hw_reset() when the GPIO is missing to match the optional
semantics. This also fixes a potential NULL pointer dereference as
aw_pa is not initialized when aw88395_hw_reset() is called.

Signed-off-by: wangdicheng <wangdicheng@kylinos.cn>
Link: https://patch.msgid.link/20260428023408.46420-1-wangdich9700@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase Walkthrough
Step 1.1 Record: Subsystem `ASoC: aw88395`; action verb `Fix`; claimed
intent is preventing probe/reset crashes from invalid or missing
optional reset GPIO handling.

Step 1.2 Record: Tags found: `Signed-off-by: wangdicheng
<wangdicheng@kylinos.cn>`, `Link:
https://patch.msgid.link/20260428023408.46420-1-wangdich9700@163.com`,
`Signed-off-by: Mark Brown <broonie@kernel.org>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.

Step 1.3 Record: Commit body describes `devm_gpiod_get_optional()`
returning `ERR_PTR`, current code logging and continuing, then
`aw88395_hw_reset()` using the bad pointer. Verified an additional body
claim: `aw_pa` is uninitialized when `aw88395_hw_reset()` is called, so
the old missing-GPIO `dev_err(aw88395->aw_pa->dev, ...)` path can
dereference NULL.

Step 1.4 Record: This is a real bug fix despite also changing logging:
it fixes probe error handling and removes a pre-initialization NULL
dereference path.

Step 2.1 Record: One file changed: `sound/soc/codecs/aw88395/aw88395.c`,
4 insertions and 5 deletions. Modified functions: `aw88395_hw_reset()`
and `aw88395_i2c_probe()`. Scope is single-file surgical driver fix.

Step 2.2 Record: Hunk 1 changes missing reset GPIO from logging through
`aw88395->aw_pa->dev` to silent no-op. Hunk 2 changes
`IS_ERR(reset_gpio)` from “log and continue” to `return
dev_err_probe(...)`.

Step 2.3 Record: Bug categories: NULL pointer dereference in probe/reset
when optional GPIO is absent; probe error handling bug for `ERR_PTR`
values such as `-EPROBE_DEFER`. I could not verify the commit’s exact
claim that `gpiod_set_value_cansleep()` dereferences an `ERR_PTR`,
because current and checked stable gpiolib validate error pointers
before use.

Step 2.4 Record: Fix quality is good: minimal, contained, follows common
`devm_gpiod_get_optional()` patterns, and uses existing
`dev_err_probe()`. Regression risk is low; the behavior change is to
fail probe on real GPIO acquisition errors and stop logging through an
uninitialized pointer.

Step 3.1 Record: `git blame` shows the buggy lines were introduced by
`62fc25fbab5f4`, “ASoC: codecs: Add i2c and codec registration for
aw88395...”, first contained in `v6.3`.

Step 3.2 Record: No `Fixes:` tag, so there was no tagged introducing
commit to follow; blame identifies `62fc25fbab5f4` as the origin.

Step 3.3 Record: Recent file history shows normal aw88395 codec churn
and no prerequisite patch for this fix. On `fixes-next`, the candidate
`241ee17ecb6b` is the direct relevant change to this file.

Step 3.4 Record: `git log --author=wangdicheng` found no other local
aw88395/codecs commits by this author. Maintainer Mark Brown applied the
patch.

Step 3.5 Record: No dependent commits found. `dev_err_probe()` and the
touched code exist in the checked stable trees; the patch applies
cleanly to representative stable tags.

Step 4.1 Record: `b4 dig -c 241ee17ecb6b` matched the lore submission
`20260428023408.46420-1-wangdich9700@163.com`. `b4 dig -a` found v1 and
v2; v2 is the committed/applied version.

Step 4.2 Record: `b4 dig -w` shows recipients included Mark Brown,
Takashi Iwai, `linux-sound`, and `linux-kernel`.

Step 4.3 Record: No `Reported-by` or external bug report tag. The Link
points to the patch thread. WebFetch of lore was blocked by Anubis, but
b4 successfully retrieved the mboxes.

Step 4.4 Record: v1 changed only the `IS_ERR()` handling. Mark Brown
replied that it looked OK but noted the missing-GPIO `dev_err()` bug. v2
removed that `dev_err()` and was applied by Mark Brown to
`broonie/sound.git for-7.1` as `241ee17ecb6b`.

Step 4.5 Record: Stable-specific lore search through WebFetch was
blocked by Anubis; no stable-specific discussion was verified.

Step 5.1 Record: Modified functions are `aw88395_hw_reset()` and
`aw88395_i2c_probe()`.

Step 5.2 Record: `aw88395_hw_reset()` is called only from
`aw88395_i2c_probe()` in this file. `aw88395_i2c_probe()` is registered
as `.probe` in `aw88395_i2c_driver`.

Step 5.3 Record: Key callees include `devm_gpiod_get_optional()`,
`gpiod_set_value_cansleep()`, `devm_regmap_init_i2c()`, and later
`aw88395_init()`.

Step 5.4 Record: Call chain is I2C driver registration via
`module_i2c_driver()` -> I2C core `i2c_device_probe()` ->
`driver->probe(client)` -> `aw88395_i2c_probe()` ->
`aw88395_hw_reset()`. Trigger is device probe, not an unprivileged
syscall path.

Step 5.5 Record: Similar codec patterns usually return on
`IS_ERR(devm_gpiod_get_optional())`; `aw88166.c`, `wcd937x.c`,
`tlv320dac33.c`, and others show this local convention.

Step 6.1 Record: The driver does not exist in `v5.15` or `v6.1`. The
buggy code exists in `v6.3`, `v6.6`, `v6.12`, `v6.19`, and `v7.0`.

Step 6.2 Record: `git apply --check` passed on current `v7.0.3`;
temporary worktree checks passed cleanly on `v6.6`, `v6.12`, and
`v6.19`.

Step 6.3 Record: No related fix for this aw88395 reset GPIO issue was
found in checked `master`/file history; current stable checkout still
has the old code.

Step 7.1 Record: Subsystem is ALSA SoC codec driver under
`sound/soc/codecs`; criticality is driver-specific/peripheral, but
failure mode is severe for affected hardware.

Step 7.2 Record: aw88395 file history shows moderate ongoing maintenance
since the driver was added in v6.3.

Step 8.1 Record: Affected users are systems using the Awinic AW88395 I2C
codec driver.

Step 8.2 Record: Trigger is probe with missing optional reset GPIO, or
real GPIO acquisition failure such as deferred probe. Unprivileged users
cannot directly trigger this through a normal syscall path based on the
traced call chain.

Step 8.3 Record: Verified failure mode is probe-time NULL dereference
through `aw88395->aw_pa->dev` when `reset_gpio` is NULL before
`aw88395_init()` initializes `aw_pa`. Severity: HIGH/CRITICAL for
affected systems.

Step 8.4 Record: Benefit is high for affected hardware because it
prevents probe-time crash/misprobe. Risk is low: 9-line single-driver
change, no ABI/API changes, clean apply to representative stable trees.

Step 9.1 Record: Evidence for backporting: real NULL deref, correct
handling of `ERR_PTR`, maintainer feedback led to v2, maintainer
applied, small clean patch, affected code present in stable v6.6+.
Evidence against: no explicit reporter/test tag; exact `ERR_PTR` panic
claim was not verified because gpiolib validates error pointers.
Unresolved: no stable-specific lore discussion verified due WebFetch
blocking.

Step 9.2 Record: Stable rules: obviously correct yes; fixes real bug
yes; important issue yes, probe-time crash/oops; small and contained
yes; no new feature/API yes; applies to stable yes for checked
v6.6/v6.12/v6.19/v7.0.

Step 9.3 Record: No automatic exception category applies; this is not a
device ID, quirk, DT-only, build, or documentation patch.

Step 9.4 Record: Decision is backport. The verified NULL dereference
plus probe error handling fix outweigh the low regression risk.

## Verification
- [Phase 1] Parsed commit `241ee17ecb6be210f7b231b2a81bfb68871950d0`
  locally and confirmed tags/message.
- [Phase 2] Inspected patch and current source around
  `aw88395_hw_reset()` and `aw88395_i2c_probe()`.
- [Phase 2] Checked `drivers/gpio/gpiolib.c`: `validate_desc()` handles
  NULL and `IS_ERR()` descriptors before `gpiod_set_value_cansleep()`
  continues.
- [Phase 3] `git blame` traced both changed areas to `62fc25fbab5f4`,
  first present in `v6.3`.
- [Phase 4] `b4 dig` found v1/v2; v1 reviewer feedback from Mark Brown
  requested addressing the optional GPIO logging bug; v2 was applied.
- [Phase 5] Traced caller registration through `.probe`,
  `module_i2c_driver()`, and I2C core `driver->probe(client)`.
- [Phase 6] Verified code absent in `v5.15`/`v6.1`, present in `v6.3+`,
  and cleanly applying to `v6.6`, `v6.12`, `v6.19`, and current
  `v7.0.3`.
- [Phase 8] Verified `aw88395_malloc_init()` uses `devm_kzalloc()`, so
  `aw_pa` is NULL until later `aw88395_init()`.

**YES**

 sound/soc/codecs/aw88395/aw88395.c | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/sound/soc/codecs/aw88395/aw88395.c b/sound/soc/codecs/aw88395/aw88395.c
index 3602b5b9f7d77..dd09bac652f7f 100644
--- a/sound/soc/codecs/aw88395/aw88395.c
+++ b/sound/soc/codecs/aw88395/aw88395.c
@@ -456,8 +456,6 @@ static void aw88395_hw_reset(struct aw88395 *aw88395)
 		usleep_range(AW88395_1000_US, AW88395_1000_US + 10);
 		gpiod_set_value_cansleep(aw88395->reset_gpio, 1);
 		usleep_range(AW88395_1000_US, AW88395_1000_US + 10);
-	} else {
-		dev_err(aw88395->aw_pa->dev, "%s failed", __func__);
 	}
 }
 
@@ -522,9 +520,10 @@ static int aw88395_i2c_probe(struct i2c_client *i2c)
 	i2c_set_clientdata(i2c, aw88395);
 
 	aw88395->reset_gpio = devm_gpiod_get_optional(&i2c->dev, "reset", GPIOD_OUT_LOW);
-	if (IS_ERR(aw88395->reset_gpio))
-		dev_info(&i2c->dev, "reset gpio not defined\n");
-
+	if (IS_ERR(aw88395->reset_gpio)) {
+		return dev_err_probe(&i2c->dev, PTR_ERR(aw88395->reset_gpio),
+				"failed to get reset gpio\n");
+	}
 	/* hardware reset */
 	aw88395_hw_reset(aw88395);
 
-- 
2.53.0