[PATCH AUTOSEL 6.18-5.10] ASoC: Intel: catpt: Complete coredump handling
From: Sasha Levin
Date: Mon Aug 31 2026 - 10:14:13 EST
From: Cezary Rojewski <cezary.rojewski@xxxxxxxxx>
[ Upstream commit 7e5d59f407bc39d43b350cc45f7880647429eb5d ]
An exception may occur during the firmware booting procedure. In such
case the firmware sends COREDUMP_REQUESTS and expects the driver to dump
relevant information and finish with the COREDUMP_RELEASE write.
To distinguish such situation from generic timeout, always signal
fw_ready completion when a coredump request is received and translate
it to -EREMOTEIO in catpt_boot_firmware().
The "FW READY" print makes the success clearly visible even when
the event-traces are not enabled.
Signed-off-by: Cezary Rojewski <cezary.rojewski@xxxxxxxxx>
Link: https://patch.msgid.link/20260528083444.1439233-2-cezary.rojewski@xxxxxxxxx
Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
# Stable Backport Analysis: ASoC: Intel: catpt: Complete coredump
handling
**Local tree:** `v6.18.44` (6.18.44 stable)
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject line
**Record:** `[ASoC: Intel: catpt]` `[Complete]` — finish incomplete
firmware coredump protocol handling during firmware boot failure.
### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Cezary Rojewski `<cezary.rojewski@xxxxxxxxx>`
(author)
- **Signed-off-by:** Mark Brown `<broonie@xxxxxxxxxx>` (ASoC maintainer
merge)
- **Link:** `https://patch.msgid.link/20260528083444.1439233-2-
cezary.rojewski@xxxxxxxxx` (patch 2 of a series, per Message-ID)
- No `Fixes:`, `Reported-by:`, `Cc: stable@xxxxxxxxxxxxxxx`, `Tested-
by:`, or `Reviewed-by:` tags
- Notable: maintainer merge sign-off; no fuzzer/user bug report
### Step 1.3: Body analysis
**Record:**
- **Bug:** On firmware boot exception, firmware sends `COREDUMP_REQUEST`
and expects the driver to dump state then write `COREDUMP_RELEASE`.
Current code dumps but never releases or signals boot completion.
- **Symptom:** Boot thread waits the full `FW_READY_TIMEOUT_MS` (250
ms), returns `-ETIMEDOUT` instead of a firmware-failure error;
coredump protocol is incomplete.
- **Root cause:** `CATPT_GLB_REQUEST_CORE_DUMP` handler calls
`catpt_coredump()` but does not write `COREDUMP_RELEASE` or
`complete(&cdev->fw_ready)`.
- **Fix approach:** Release firmware from coredump state, complete
`fw_ready`, and return `-EREMOTEIO` from `catpt_boot_firmware()` when
woken but `ipc->ready` is false.
### Step 1.4: Hidden bug fix?
**Record:** Yes. Subject says "Complete" rather than "fix", but this is
incomplete error-path/protocol handling: missing firmware handshake step
and incorrect boot error classification.
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Inventory
**Record:**
- `sound/soc/intel/catpt/ipc.c` (+10 lines): coredump path completion,
debug print on FW ready
- `sound/soc/intel/catpt/loader.c` (+3 lines): distinguish coredump
wakeup from success
- `sound/soc/intel/catpt/registers.h` (+12 lines): coredump register
constants and DRAM I/O helpers
- **Functions modified:** `catpt_dsp_process_response()`,
`catpt_boot_firmware()`
- **Scope:** Single-driver, 3 files, ~25 net lines — surgical fix
### Step 2.2: Code flow changes
**Record:**
- **Hunk 1 (`ipc.c` fw_ready path):** Adds `dev_dbg("FW READY ...")`
before arming IPC — diagnostic only.
- **Hunk 2 (`ipc.c` coredump path):** After `catpt_coredump()`, reads
DRAM coredump register; if `CATPT_COREDUMP_REQUEST`, writes
`CATPT_COREDUMP_RELEASE`; then `complete(&cdev->fw_ready)`.
- **Hunk 3 (`loader.c`):** After successful
`wait_for_completion_timeout`, if `!cdev->ipc.ready`, return
`-EREMOTEIO` instead of continuing boot.
- **Hunk 4 (`registers.h`):** Adds `CATPT_DRAM_COREDUMP`,
request/release values, `catpt_dram_addr`,
`catpt_readl_dram`/`catpt_writel_dram` macros.
### Step 2.3: Bug mechanism
**Record:** **Category:** Logic/correctness fix on firmware error path +
incomplete protocol handshake.
- **Before:** Coredump during boot → dump created, `ipc->ready = false`,
no completion, no RELEASE → 250 ms timeout → `-ETIMEDOUT`.
- **After:** Coredump during boot → dump + conditional RELEASE +
`fw_ready` completion → immediate wakeup → `-EREMOTEIO`.
- **Runtime path:** Same coredump handler is used for non-boot
exceptions; RELEASE is also missing today on that path.
### Step 2.4: Fix quality
**Record:** Obviously correct and minimal. RELEASE is guarded by a
register read. Boot cannot proceed on failure because `ipc->ready`
remains false. Low regression risk; no API changes.
---
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: Blame
**Record:** Coredump case in `ipc.c` introduced in `64b9b1b005743` (Sep
2020, "Add IPC message handlers"). Boot wait logic in `a9aa6fb3eb6c7`
(Sep 2020, "Firmware loading and context restore"). Bug present since
initial coredump support (~5.9 era).
### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag in commit message.
### Step 3.3: Related file history
**Record:** Recent catpt commits in this tree include init and hw_params
fixes (`7af2d06ec25b5`, `a2f79598c6c1f`). No prior coredump-completion
fix. This commit is **not** yet in the local tree (buggy code still
present).
### Step 3.4: Author context
**Record:** Cezary Rojewski is the original catpt author (2020). Recent
catpt work in-tree is maintenance/fixes. Mark Brown merged.
### Step 3.5: Dependencies
**Record:** Message-ID suffix `-2` suggests a 2-patch series; patch 1
not found in workspace mbox files. The diff is self-contained (adds its
own register definitions and helpers). **UNVERIFIED:** whether patch 1
of the series is required; nothing in the diff references symbols from
an unseen prerequisite.
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1: Original discussion
**Record:** **UNVERIFIED** — `b4 dig` requires a commit hash (not
available; commit not in tree). Lore and patch.msgid.link returned
403/bot protection. Could not read review thread.
### Step 4.2: Reviewers
**Record:** **UNVERIFIED** — `b4 dig -w` not run (no commitish).
### Step 4.3: Bug report
**Record:** N/A — no `Reported-by:` or syzbot link.
### Step 4.4: Series context
**Record:** Message-ID indicates patch 2/2. Coredump infrastructure
(`catpt_coredump()`, `CATPT_GLB_REQUEST_CORE_DUMP`) already exists in
this tree from 2020; this patch completes protocol handling rather than
introducing coredump support.
### Step 4.5: Stable list discussion
**Record:** **UNVERIFIED** — lore stable search inaccessible.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: Key functions
**Record:** `catpt_dsp_process_response()`, `catpt_boot_firmware()`,
`catpt_coredump()` (called, not modified).
### Step 5.2: Callers
**Record:**
- `catpt_dsp_process_response()` ← `catpt_dsp_irq_thread()` (IRQ thread,
interrupt bottom half)
- `catpt_boot_firmware()` ← `catpt_first_boot_firmware()` (probe) and
`catpt_resume()` (resume after suspend)
- Probe failure path: `catpt_probe_components()` →
`catpt_first_boot_firmware()` → on error, `catpt_dsp_power_down()`
### Step 5.3: Callees
**Record:** Coredump path uses `catpt_coredump()` → `dev_coredumpv()`;
new path uses `readl`/`writel` on DRAM via `host_dram_offset` (present
in `core.h` and device specs).
### Step 5.4: Reachability
**Record:** Triggered when ADSP firmware crashes/exceptions during boot
or runtime. Boot path is hit on every driver probe and resume.
Unprivileged users cannot directly trigger it, but normal suspend/resume
and module load are common.
### Step 5.5: Similar patterns
**Record:** No other coredump RELEASE handling exists in catpt today.
`grep` shows no `CATPT_COREDUMP` symbols in the tree before this patch.
---
## PHASE 6: CROSS-REFERENCE WITH LOCAL TREE (v6.18.44)
### Step 6.1: Buggy code present?
**Record:** **Yes.** Current `ipc.c` lines 214–218 handle coredump
without RELEASE or `complete()`. Current `loader.c` returns only
`-ETIMEDOUT` on timeout with no `ipc->ready` check. Driver present since
2020; `CONFIG_SND_SOC_INTEL_CATPT` targets Haswell/Broadwell.
### Step 6.2: Backport difficulty
**Record:** Clean apply expected — no conflicting recent changes in
these hunks. New macros use existing `host_dram_offset` field.
### Step 6.3: Related fixes already present?
**Record:** No — `git log --grep=coredump -- sound/soc/intel/catpt/`
returns empty.
---
## PHASE 7: SUBSYSTEM CONTEXT
### Step 7.1: Subsystem criticality
**Record:** `sound/soc/intel/catpt` — **IMPORTANT** (audio driver), but
hardware-specific (older Intel Haswell/Broadwell platforms). Not core
kernel.
### Step 7.2: Activity
**Record:** Moderate maintenance activity; recent stable backports
include init and hw_params fixes.
---
## PHASE 8: IMPACT AND RISK
### Step 8.1: Who is affected
**Record:** Users with `CONFIG_SND_SOC_INTEL_CATPT` on Haswell/Broadwell
systems when ADSP firmware fails during boot or at runtime.
### Step 8.2: Trigger conditions
**Record:** Firmware exception during boot (probe/resume) or operation.
Uncommon but real; not timing-dependent race.
### Step 8.3: Failure severity
**Record:**
- **Without fix:** Incomplete firmware handshake (no
`COREDUMP_RELEASE`); boot waits 250 ms then reports misleading
`-ETIMEDOUT`; firmware may remain in coredump state; audio non-
functional.
- **With fix:** Immediate failure detection, correct `-EREMOTEIO`,
protocol completed.
- **Severity:** **MEDIUM-HIGH** for affected hardware — device
recovery/protocol correctness, not kernel oops/UAF. Audio is already
broken when triggered, but firmware can be left in a bad state without
RELEASE.
### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** MEDIUM — completes mandatory firmware protocol,
faster/correct boot failure handling, better runtime coredump cleanup
- **Risk:** LOW — ~25 lines, guarded RELEASE write, explicit
`ipc->ready` check prevents false-success boot
- **Ratio:** Favorable
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence summary
**FOR backport:**
- Real bug since 2020: incomplete coredump protocol (missing
`COREDUMP_RELEASE`)
- Boot path misreports failure as timeout instead of remote I/O error
- Unnecessary 250 ms wait on known firmware failure
- Small, self-contained, maintainer-authored fix
- Buggy code confirmed present in v6.18.44
- Applies to both probe and resume boot paths
**AGAINST backport:**
- No kernel crash, UAF, security issue, or data corruption
- Trigger requires firmware failure (uncommon)
- Niche older hardware
- Device is already non-functional when bug triggers
- Probe failure calls `catpt_dsp_power_down()` (DSP reset), which may
mitigate stuck state
- Mailing list review/stable nomination not verified
- Possible patch 1/2 series dependency unverified
**Unresolved:** Lore review thread; whether patch 1 is required;
explicit stable nomination.
### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — logic is clear; no `Tested-
by` but maintainer merged
2. Fixes a real bug affecting users? **PASS** — incomplete firmware
protocol on error path
3. Important issue? **PASS (MEDIUM)** — firmware stuck in coredump
state, misleading errors, delayed failure detection on probe/resume;
not kernel crash级别
4. Small and contained? **PASS** — 3 files, ~25 lines
5. No new features/APIs? **PASS** — completes existing coredump handling
6. Can apply to local tree? **PASS** — driver and buggy code present;
clean apply expected
### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build, or docs fix).
### Step 9.4: Decision rationale
This is a genuine, long-standing protocol bug in the Intel catpt driver.
When firmware exceptions occur, the driver partially handles coredump
but never completes the handshake the firmware expects
(`COREDUMP_RELEASE`), and the boot path misinterprets the situation as a
generic timeout. While the device is already broken when this triggers,
leaving firmware in coredump state without release is a real correctness
defect that can impede recovery, and the fix is minimal with very low
regression risk. It meets stable criteria for a contained driver bug fix
on an error path affecting probe and resume.
---
## Verification
- [Phase 1] Parsed subject, tags, body from provided commit message
- [Phase 1] Confirmed Message-ID indicates patch 2 of series
(`1439233-2`)
- [Phase 2] Read current `ipc.c`, `loader.c`, `registers.h` — buggy code
present, matches pre-patch state
- [Phase 2] Confirmed `FW_READY_TIMEOUT_MS` is 250 ms in `loader.c`
- [Phase 3] `git describe HEAD` → `v6.18.44`; `make kernelversion` →
`6.18.44`
- [Phase 3] `git blame` on coredump case → `64b9b1b005743` (Sep 2020)
- [Phase 3] `git blame` on boot wait → `a9aa6fb3eb6c7` (Sep 2020)
- [Phase 3] `git log --oneline -20 -- sound/soc/intel/catpt/` — no
coredump fix present
- [Phase 3] `git merge-base --is-ancestor 4fac9b31d0b9d HEAD` → catpt
driver in tree
- [Phase 4] `b4 dig` — requires commitish; not available (commit not in
tree)
- [Phase 4] WebFetch lore/patch.msgid.link — blocked (403/bot
protection)
- [Phase 4] Grep workspace `*.mbx` for series — no match
- [Phase 5] Traced callers: `catpt_boot_firmware` from probe/resume;
`catpt_dsp_process_response` from IRQ thread
- [Phase 5] Read `catpt_coredump()` in `dsp.c` — dumps via
`dev_coredumpv()`
- [Phase 5] Read `catpt_ipc_arm()` — sets `ipc->ready = true` only on
successful FW ready
- [Phase 5] Confirmed `host_dram_offset` exists in `core.h` and device
specs
- [Phase 6] Grep `CATPT_COREDUMP` — not present (fix not applied)
- [Phase 6] Read probe error path in `device.c` —
`catpt_dsp_power_down()` on boot failure
- [Phase 7] Read `Kconfig` — `SND_SOC_INTEL_CATPT` for Haswell/Broadwell
- [Phase 8] Assessed failure modes from code flow analysis
- **UNVERIFIED:** Mailing list review feedback and stable nominations
- **UNVERIFIED:** Whether patch 1 of the series is a prerequisite
**YES**
sound/soc/intel/catpt/ipc.c | 8 ++++++++
sound/soc/intel/catpt/loader.c | 3 +++
sound/soc/intel/catpt/registers.h | 12 ++++++++++++
3 files changed, 23 insertions(+)
diff --git a/sound/soc/intel/catpt/ipc.c b/sound/soc/intel/catpt/ipc.c
index d26863249097f..952c26e5d0e6c 100644
--- a/sound/soc/intel/catpt/ipc.c
+++ b/sound/soc/intel/catpt/ipc.c
@@ -205,6 +205,7 @@ static void catpt_dsp_process_response(struct catpt_dev *cdev, u32 header)
memcpy_fromio(&config, cdev->lpe_ba + off, sizeof(config));
trace_catpt_ipc_payload((u8 *)&config, sizeof(config));
+ dev_dbg(cdev->dev, "FW READY 0x%08x\n", header);
catpt_ipc_arm(ipc, &config);
complete(&cdev->fw_ready);
return;
@@ -215,6 +216,13 @@ static void catpt_dsp_process_response(struct catpt_dev *cdev, u32 header)
dev_err(cdev->dev, "ADSP device coredump received\n");
ipc->ready = false;
catpt_coredump(cdev);
+
+ if (catpt_readl_dram(cdev, COREDUMP) == CATPT_COREDUMP_REQUEST) {
+ dev_dbg(cdev->dev, "releasing firmware from the coredump state\n");
+ catpt_writel_dram(cdev, COREDUMP, CATPT_COREDUMP_RELEASE);
+ }
+
+ complete(&cdev->fw_ready);
/* TODO: attempt recovery */
break;
diff --git a/sound/soc/intel/catpt/loader.c b/sound/soc/intel/catpt/loader.c
index 696d84314eeb5..680efad5f458d 100644
--- a/sound/soc/intel/catpt/loader.c
+++ b/sound/soc/intel/catpt/loader.c
@@ -626,6 +626,9 @@ int catpt_boot_firmware(struct catpt_dev *cdev, bool restore)
if (!ret) {
dev_err(cdev->dev, "firmware ready timeout\n");
return -ETIMEDOUT;
+ /* Wake up does not mean FW is ready, an exception could occur. */
+ } else if (!cdev->ipc.ready) {
+ return -EREMOTEIO;
}
/* update sram pg & clock once done booting */
diff --git a/sound/soc/intel/catpt/registers.h b/sound/soc/intel/catpt/registers.h
index 6c1ad28c6d692..64bd534a76ff4 100644
--- a/sound/soc/intel/catpt/registers.h
+++ b/sound/soc/intel/catpt/registers.h
@@ -124,6 +124,11 @@
#define CATPT_SSCR2_DEFAULT 0x0
#define CATPT_SSPSP2_DEFAULT 0x0
+/* Coredump register and its states */
+#define CATPT_DRAM_COREDUMP 0x1F4
+#define CATPT_COREDUMP_REQUEST UINT_MAX
+#define CATPT_COREDUMP_RELEASE 0
+
/* Physically the same block, access address differs between host and dsp */
#define CATPT_DSP_DRAM_OFFSET 0x400000
#define catpt_to_host_offset(offset) ((offset) & ~(CATPT_DSP_DRAM_OFFSET))
@@ -137,6 +142,8 @@
/* registry I/O helpers */
+#define catpt_dram_addr(cdev) \
+ ((cdev)->lpe_ba + (cdev)->spec->host_dram_offset)
#define catpt_shim_addr(cdev) \
((cdev)->lpe_ba + (cdev)->spec->host_shim_offset)
#define catpt_dma_addr(cdev, dma) \
@@ -151,6 +158,11 @@
#define catpt_writel_ssp(cdev, ssp, reg, val) \
writel(val, catpt_ssp_addr(cdev, ssp) + (reg))
+#define catpt_readl_dram(cdev, reg) \
+ readl(catpt_dram_addr(cdev) + CATPT_DRAM_##reg)
+#define catpt_writel_dram(cdev, reg, val) \
+ writel(val, catpt_dram_addr(cdev) + CATPT_DRAM_##reg)
+
#define catpt_readl_shim(cdev, reg) \
readl(catpt_shim_addr(cdev) + CATPT_SHIM_##reg)
#define catpt_writel_shim(cdev, reg, val) \
--
2.53.0