[PATCH AUTOSEL 6.18] ASoC: rt1320: run the initialisation preset on the first hardware init

[Sasha Levin]

From: Sergey Lebedev <lsa.uz@xxxxx>

[ Upstream commit 9b30521074f01aff856f539c1241a48342b69f7c ]

rt1320_io_init() applies the vendor initialisation preset only when the
amplifier's SDCA function status has FUNCTION_NEEDS_INITIALIZATION set:

	if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION)) {

Its two sibling drivers guard the same write differently, also running
the preset on the first hardware init:

  rt712-sdca.c:  if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION) ||
                     (!rt712->first_hw_init)) {
  rt722-sdca.c:  if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION) ||
                     (!rt722->first_hw_init)) {

On the Microsoft Surface Pro 11 (Intel) the RT1320 never sets that bit.
Its function status reads back 0x41 on every boot, cold or warm:

  rt1320-sdca sdw:0:0:025d:1320:01: rt1320_io_init amp func_status=0x41

which is NEWLY_ATTACHED | FUNCTION_HAS_BEEN_RESET: the function reports
that it has been reset and does not consider itself in need of
initialisation. Bit 5 is never set, so the preset never runs,
rt1320_vc_preset() and the MCU patch load are skipped, and the amplifier
is left unprogrammed. rt712 and rt722 would have run it via their
first_hw_init fallback.

Add the same fallback. With it rt1320_vc_preset() executes and the
amplifier reports RT1320_KR0_INT_READY=0x1f where previously it did not.

Signed-off-by: Sergey Lebedev <lsa.uz@xxxxx>
Link: https://patch.msgid.link/20260804225853.31585-2-lsa.uz@xxxxx
Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject line
**Record:** `[ASoC: rt1320]` `[run]` — run the vendor initialization
preset on first hardware init.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Sergey Lebedev `<lsa.uz@xxxxx>` (author)
- **Link:** https://patch.msgid.link/20260804225853.31585-2-lsa.uz@xxxxx
- **Signed-off-by:** Mark Brown `<broonie@xxxxxxxxxx>` (ASoC maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable@xxxxxxxxxxxxxxx`
- Notable: maintainer sign-off; real hardware report (Surface Pro 11);
  no syzbot/fuzzer involvement

### Step 1.3: Body analysis
**Record:**
- **Bug:** `rt1320_io_init()` only runs the vendor preset when
  `FUNCTION_NEEDS_INITIALIZATION` is set; on Surface Pro 11 RT1320
  reports `0x41` (`NEWLY_ATTACHED | FUNCTION_HAS_BEEN_RESET`), never bit
  5
- **Symptom:** `rt1320_vc_preset()` and MCU patch load are skipped;
  amplifier stays unprogrammed; speakers silent
- **Root cause:** RT1320 lacks the `first_hw_init` fallback that sibling
  drivers `rt712-sdca` and `rt722-sdca` already use
- **Version info:** Surface Pro 11 (Intel, Lunar Lake); tested on
  7.1.0-rc7 per cover letter

### Step 1.4: Hidden bug fix?
**Record:** Yes — not disguised cleanup. This is a clear
logic/correctness fix restoring driver behavior that existed at
introduction and was accidentally dropped.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **Files:** `sound/soc/codecs/rt1320-sdw.c` (+1 / -1)
- **Function:** `rt1320_io_init()`
- **Scope:** Single-file, one-line surgical fix

### Step 2.2: Code flow change
**Record:**
- **Before:** Preset runs only if `amp_func_status &
  FUNCTION_NEEDS_INITIALIZATION`
- **After:** Also runs when `!rt1320->first_hw_init` (first hardware
  init)
- **Path:** Normal probe via `rt1320_update_status()` →
  `rt1320_io_init()` on `SDW_SLAVE_ATTACHED`

### Step 2.3: Bug mechanism
**Record:**
- **Category:** Logic/correctness (hardware workaround)
- **Mechanism:** Some RT1320 parts never set
  `FUNCTION_NEEDS_INITIALIZATION`; without the `first_hw_init` fallback,
  `rt1320_vc_preset()` / `rt1320_load_mcu_patch()` never execute and the
  amp is left uninitialized

### Step 2.4: Fix quality
**Record:**
- Obviously correct: matches `rt712-sdca.c` and `rt722-sdca.c`, and
  restores original `rt1320` behavior from `bad0a07a7e61a`
- Minimal, no unrelated changes
- **Regression risk:** Very low — restores long-standing pattern; only
  affects first init

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:**
- Buggy condition from `f465d10cd7318` (Sep 2, 2024, "ASoC: rt1320: Add
  support for version C")
- That commit **removed** `|| (!rt1320->first_hw_init)` that existed
  since `bad0a07a7e61a` (May 21, 2024)
- Regression present since v6.12 (first tag containing `f465d10`)

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag. Regression commit is `f465d10cd7318`,
confirmed in this tree.

### Step 3.3: Related file history
**Record:**
- Part of a 3-patch series: "ASoC: fix audio on the Microsoft Surface
  Pro 11 (Intel)"
- Patches 2/3 and 3/3 address phantom ACPI entries; **this patch is
  standalone** for RT1320 init
- Recent rt1320 fixes in tree: mute issue, speaker noise, RT1321 support
  — unrelated

### Step 3.4: Author context
**Record:** Sergey Lebedev — Surface Pro 11 reporter/fixer; no prior
sound commits in this tree. Mark Brown committed upstream.

### Step 3.5: Dependencies
**Record:** None for this change. `first_hw_init` already exists in
`rt1320_sdw_priv` and is initialized to `false` at probe. Applies
standalone.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original discussion
**Record:**
- **URL:** https://patch.msgid.link/20260804225853.31585-2-lsa.uz@xxxxx
- **Series:** v1 only (no v2/v3)
- Cover letter: full Surface Pro 11 audio needs all 3 patches; patch 1/3
  is codec-specific and one line
- No explicit stable nomination in thread
- No NAKs found in mbox

### Step 4.2: Reviewers
**Record:** CC'd to Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi
Iwai, Realtek/Intel SOF maintainers, `linux-sound@`, `sound-open-
firmware@`, `linux-kernel@`

### Step 4.3: Bug report
**Record:** Hardware testing on Surface Pro 11 for Business (Intel Core
Ultra 7 268V, Lunar Lake). Symptom: silent speakers despite successful
probe. Severity: complete audio failure on affected hardware.

### Step 4.4: Related patches
**Record:** Patches 2/3 (`sdw_utils`) and 3/3 (SOF Intel HDA amp
indexing) are separate; needed for full SP11 fix but not prerequisites
for this one-line driver fix.

### Step 4.5: Stable list
**Record:** No stable-specific discussion found in mbox.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key functions
**Record:** `rt1320_io_init()`, `rt1320_vc_preset()`,
`rt1320_update_status()`

### Step 5.2: Callers
**Record:**
- `rt1320_update_status()` — SoundWire slave status callback
  (`.update_status` in `rt1320_sdw_slave_driver`)
- Triggered on `SDW_SLAVE_ATTACHED` during SoundWire enumeration
- Common device probe path for RT1320-equipped Intel SOF machines

### Step 5.3: Callees
**Record:** `rt1320_vab_preset()`, `rt1320_vc_preset()`,
`rt1321_preset()`, `regmap_read/write`, `rt1320_load_mcu_patch()`
(inside `rt1320_vc_preset()`)

### Step 5.4: Reachability
**Record:** Reachable on every boot for RT1320 SoundWire devices when
`CONFIG_SND_SOC_RT1320_SDW` is enabled (implied by Intel SOF ACPI
matches). Not userspace-triggered, but affects all audio on affected
machines.

### Step 5.5: Similar patterns
**Record:** Identical `first_hw_init` fallback in `rt712-sdca.c:1837`
and `rt722-sdca.c:1400`. Original `rt1320` driver at
`bad0a07a7e61a:1699` had the same pattern.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy code exists?
**Record:**
- **Tree:** `stable/linux-6.18.y` at `v6.18.44`
- **Buggy line present:** `sound/soc/codecs/rt1320-sdw.c:941` — `if
  ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION))`
- RT1320 driver (`bad0a07a7e61a`) and version C support
  (`f465d10cd7318`) are both ancestors of HEAD
- Fix (`9b30521074f01` / `4ff3319b43e07`) is **not** in this tree

### Step 6.2: Backport complications
**Record:** Clean one-line apply at line 941; no conflicts expected.
Stable tree file matches autosel backport diff base.

### Step 6.3: Related fixes already present?
**Record:** No equivalent fix found. Other rt1320 fixes (mute, noise)
address different issues.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem criticality
**Record:** `sound/soc/codecs` — ASoC codec driver. **IMPORTANT** for
Intel SOF + SoundWire laptop users (LNL/PTL/ARL platforms with RT1320).

### Step 7.2: Subsystem activity
**Record:** Actively maintained; multiple rt1320 ACPI machine entries
and driver fixes in 6.18.y.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who is affected
**Record:** Users with RT1320 amplifiers on Intel SOF SoundWire
platforms where the chip does not set `FUNCTION_NEEDS_INITIALIZATION` —
confirmed on Surface Pro 11; potentially any RT1320 since the v6.12
regression. Config-specific: `CONFIG_SND_SOC_RT1320_SDW`.

### Step 8.2: Trigger conditions
**Record:** Every cold/warm boot on affected hardware. Not timing-
dependent. Unprivileged users cannot trigger directly, but all users on
affected machines lose speaker output.

### Step 8.3: Failure mode severity
**Record:** Amplifier never initialized → **silent speakers** (complete
audio failure on affected machines). Severity: **HIGH** for affected
hardware (not a kernel crash, but total loss of primary audio output).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH for RT1320 users — restores working audio
- **Risk:** VERY LOW — one-line restoration of original + sibling-driver
  pattern
- **Ratio:** Strongly favors backport

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence summary

**FOR backport:**
- Real regression introduced by `f465d10` (removed `first_hw_init`
  fallback present since driver introduction)
- Confirmed hardware impact (Surface Pro 11 — silent speakers)
- One-line fix matching proven rt712/rt722 pattern
- Self-contained, no dependencies
- ASoC maintainer sign-off
- RT1320 driver and platform ACPI support present in 6.18.y

**AGAINST backport:**
- Full Surface Pro 11 audio may also need patches 2/3 and 3/3 (separate
  commits)
- No explicit stable nomination or `Fixes:` tag (expected for manual
  review)

**Unresolved:** Whether other RT1320 platforms besides Surface Pro 11
hit this path (likely, given regression since v6.12).

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — restores original logic;
   tested on real hardware per cover letter
2. Fixes a real bug? **PASS** — amplifier left unprogrammed
3. Important issue? **PASS** — complete audio failure on affected
   laptops
4. Small and contained? **PASS** — 1 line, 1 file
5. No new features/APIs? **PASS** — behavior restoration only
6. Can apply to local tree? **PASS** — buggy code present, clean apply

### Step 9.3: Exception category
**Record:** Hardware workaround / quirk — RT1320 does not set
`FUNCTION_NEEDS_INITIALIZATION`; driver must initialize on first hw init
regardless.

### Step 9.4: Decision rationale

For **linux-6.18.y** (`v6.18.44`): this is a regression fix restoring
driver behavior accidentally removed in v6.12. The RT1320 driver, the
buggy code, and affected platform support are all present. The fix is
one line, matches sibling drivers, and fixes silent speakers on real
hardware. It is self-contained and low risk.

---

## Verification

- [Phase 1] Parsed subject, tags, body from commit `9b30521074f01` /
  `4ff3319b43e07`
- [Phase 2] Diff: 1-line change in `rt1320_io_init()` at line 941
- [Phase 3] `git blame`: regression in `f465d10cd7318`; original
  fallback in `bad0a07a7e61a`
- [Phase 3] `git show f465d10`: confirmed removal of `||
  (!rt1320->first_hw_init)`
- [Phase 3] `git show bad0a07a7e61a`: confirmed original driver had
  fallback
- [Phase 3] `git merge-base --is-ancestor`: driver, version C, and fix
  presence verified
- [Phase 4] `b4 dig -c 4ff3319b43e07`: found lore thread; v1 series;
  cover letter read from mbox
- [Phase 4] `b4 dig -w`: Mark Brown and sound maintainers CC'd
- [Phase 4] No stable/Reviewed-by/Tested-by in mbox
- [Phase 5] `grep rt1320_io_init`: called from `rt1320_update_status()`
  on attach
- [Phase 5] Compared with `rt712-sdca.c:1837` and `rt722-sdca.c:1400`
  patterns
- [Phase 6] `git describe HEAD`: `v6.18.44` on `stable/linux-6.18.y`
- [Phase 6] Buggy code at `rt1320-sdw.c:941`; fix not in tree
- [Phase 6] `git show 4ff3319b43e07 -p`: clean apply to current tree
- [Phase 7] RT1320 ACPI matches present in `soc-acpi-intel-lnl-match.c`,
  `ptl-match.c`, `arl-match.c`
- [Phase 8] Failure mode: unprogrammed amplifier → silent speakers

**YES**The analysis is complete for **linux-6.18.y** (`v6.18.44`).

This is a one-line regression fix: `f465d10` ("Add support for version
C") dropped the `first_hw_init` fallback that existed since the RT1320
driver was introduced. On hardware like the Surface Pro 11, the amp
never sets `FUNCTION_NEEDS_INITIALIZATION`, so the preset and MCU patch
load are skipped and speakers stay silent. The fix restores the same
pattern already used in `rt712-sdca` and `rt722-sdca`.

The buggy code is present in this tree, the patch applies cleanly, and
it is self-contained (patches 2/3 and 3/3 in the series are separate
Surface Pro 11 ACPI issues).

**YES**

 sound/soc/codecs/rt1320-sdw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/rt1320-sdw.c b/sound/soc/codecs/rt1320-sdw.c
index e1bd991a823a4..a08e20bfe9c86 100644
--- a/sound/soc/codecs/rt1320-sdw.c
+++ b/sound/soc/codecs/rt1320-sdw.c
@@ -938,7 +938,7 @@ static int rt1320_io_init(struct device *dev, struct sdw_slave *slave)
 	dev_dbg(dev, "%s amp func_status=0x%x\n", __func__, amp_func_status);
 
 	/* initialization write */
-	if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION)) {
+	if ((amp_func_status & FUNCTION_NEEDS_INITIALIZATION) || !rt1320->first_hw_init) {
 		switch (rt1320->dev_id) {
 		case RT1320_DEV_ID:
 			if (rt1320->version_id < RT1320_VC)
-- 
2.53.0