[PATCH AUTOSEL 6.18-5.15] bus: fsl-mc: wait for the MC firmware to complete its boot

[PATCH AUTOSEL 6.18-5.15] bus: fsl-mc: wait for the MC firmware to complete its boot

[Sasha Levin]

From: Ioana Ciornei <ioana.ciornei@nxp.com>

[ Upstream commit 208858b1b48eba83d073542372329cf8ed606526 ]

There are use cases in which the Management Complex firmware boot
process is started by the bootloader which does not wait for the boot to
complete. This is mainly done in order to reduce the overall boot time
of a DPAA2 based SoC.

In this kind of circumstance, the fsl-mc bus driver needs to make sure
that the MC firmware boot process is finished before proceeding to the
usual operations such as interrogating the firmware to gather all
existent DPAA2 objects, creating the fsl-mc devices on the bus etc.

Add this kind of check early in the boot process of the fsl-mc bus and
defer the probe in case the firmware is still in its boot process.

Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Link: https://lore.kernel.org/r/20260401144508.3062019-1-ioana.ciornei@nxp.com
Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

### Step 1.1: Subject Line
**Record:** `[bus: fsl-mc]` `[wait]` — Ensure the Management Complex
(MC) firmware has finished booting before the fsl-mc bus driver proceeds
with DPAA2 enumeration.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Ioana Ciornei `<ioana.ciornei@nxp.com>` (author)
- **Link:** https://lore.kernel.org/r/20260401144508.3062019-1-
  ioana.ciornei@nxp.com
- **Signed-off-by:** Christophe Leroy (CS GROUP) `<chleroy@kernel.org>`
  (committer/ack)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, or Cc:
  stable tags
- Notable: NXP author, FSL maintainer committer; no fuzzer or user bug
  reports

### Step 1.3: Body Analysis
**Record:**
- **Bug:** Bootloaders on DPAA2 SoCs may start MC firmware boot
  asynchronously (to shorten boot time) without waiting for completion.
- **Symptom:** `fsl_mc_bus_probe()` talks to MC firmware (version query,
  DPRC enumeration, device creation) before firmware is ready → MC I/O
  fails.
- **Failure mode:** Without `-EPROBE_DEFER`, probe fails permanently;
  DPAA2 networking/storage/crypto does not come up.
- **Root cause:** Driver assumed MC firmware was ready at probe time; no
  GSR (Global Status Register) boot-complete check.
- **Version info:** None in message; fix targets all trees with the
  existing probe path.

### Step 1.4: Hidden Bug Fix Detection
**Record:** Yes — described as a synchronization improvement, but it
fixes a real boot race. Without it, `mc_get_version()` and later MC
portal calls run against firmware still booting, causing hard probe
failure instead of deferred retry.

---

## Phase 2: Diff Analysis

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/bus/fsl-mc/fsl-mc-bus.c` only (+46 lines, 0
  removed)
- **Functions added:** `fsl_mc_read_gsr()`, `fsl_mc_firmware_check()`
- **Function modified:** `fsl_mc_bus_probe()` — adds call after GCR1
  resume
- **Scope:** Single-file, surgical fix

### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (defines):** Adds `FSL_MC_GSR` (offset 0x8) and bit masks for
  boot-done, MCS status, and boot code.
- **Hunk 2 (`fsl_mc_firmware_check`):**
  - Before: No firmware readiness check.
  - After: Reads GSR; if boot code `0xDD` → `-EOPNOTSUPP` (DPL never
    started); if `BOOT_DONE` clear → `-EPROBE_DEFER`; if MCS error bits
    set → `-EINVAL`.
- **Hunk 3 (`fsl_mc_bus_probe`):**
  - Before: After GCR1 resume, immediately opens MC portal and calls
    `mc_get_version()`.
  - After: Calls `fsl_mc_firmware_check()` first; only proceeds on
    success.

### Step 2.3: Bug Mechanism
**Record:** **Category:** Logic / timing race (boot synchronization).
**Mechanism:** Probe races ahead of asynchronous MC firmware boot
started by the bootloader. Fix polls hardware GSR and uses
`-EPROBE_DEFER` so the driver core retries once firmware is ready.

### Step 2.4: Fix Quality
**Record:** Fix is minimal and follows established kernel patterns
(`EPROBE_DEFER`, hardware status register). Low regression risk on real
DPAA2 hardware (GSR register is part of the existing MC control register
block at `IORESOURCE_MEM` index 1). Minor note:
`fsl_mc_firmware_check()` is called outside `if (mc->fsl_mc_regs)` —
would NULL-deref if register resource 1 is absent, but all in-tree DPAA2
DT bindings provide both `reg` regions and the same resource is already
required for GCR1 pause/resume logic.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** Probe path without GSR check dates to Jakub Kicinski merge
`e7fa5c80defe0` (Jan 2021). GCR1 pause/resume added by Laurentiu Tudor
`f8cfa9bbab338b` / `8c97a4fc1b348` (Jul 2021). Buggy “assume firmware
ready” behavior has been present since probe was written; async-
bootloader scenario was never handled.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag.

### Step 3.3: Related File History
**Record:** Recent stable-tree changes to this file include error-
handling fixes (`b662f91e216fd`), UAF fix (`1d6bd6183e723`),
`platform_get_resource()` check (`25f526507b8cc`). Commit
`208858b1b48eb` is standalone (v1 only, no series). On mainline but not
yet in `stable/linux-6.18.y`.

### Step 3.4: Author Context
**Record:** Ioana Ciornei is an active NXP contributor to fsl-mc
(endpoint, userspace support, command whitelist commits visible in this
tree). Christophe Leroy is the FSL/soc maintainer who applied the patch.

### Step 3.5: Dependencies
**Record:** No prerequisites. Uses existing `mc->fsl_mc_regs`,
`platform_get_drvdata()`, and `readl()`. Applies cleanly to this tree
(`git apply --check` passed). Standalone.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:** `b4 dig -c 208858b1b48eb` →
https://patch.msgid.link/20260401144508.3062019-1-ioana.ciornei@nxp.com.
Single v1 submission (Apr 1, 2026). Maintainer reply: “Applied, thanks!”
— no NAKs, no stable nomination, no review objections.

### Step 4.2: Reviewers
**Record:** `b4 dig -w`: To/Cc included `chleroy@kernel.org`, `linuxppc-
dev@lists.ozlabs.org`, `linux-kernel@vger.kernel.org`. Appropriate
maintainers CC'd.

### Step 4.3: Bug Report
**Record:** N/A — no Reported-by or external bug link. Issue is
described as a known bootloader optimization use case from NXP.

### Step 4.4: Related Patches
**Record:** Standalone patch, not part of a multi-patch series. Related
historical context: 2021 GCR1 pause/resume series addressed the opposite
timing problem (MC running too early before IOMMU).

### Step 4.5: Stable List
**Record:** Not searched on lore stable list; no stable nomination found
in the patch thread.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `fsl_mc_firmware_check()`, `fsl_mc_read_gsr()`,
`fsl_mc_bus_probe()`

### Step 5.2: Callers
**Record:** `fsl_mc_bus_probe()` is the `platform_driver.probe` callback
for `fsl_mc_bus_driver` — invoked during platform device enumeration at
boot on DPAA2 SoCs (DT: `fsl,qoriq-mc`; ACPI: `NXP0008`).

### Step 5.3: Callees
**Record:** `readl()` on `mc->fsl_mc_regs + FSL_MC_GSR`;
`platform_get_drvdata()`; `dev_err()` / `dev_dbg()`.

### Step 5.4: Reachability
**Record:** Triggered on every boot of DPAA2 hardware when
`CONFIG_FSL_MC_BUS=y/m`. Bootloader async MC start is the trigger
condition. Affects init path, not a hot path. Userspace cannot directly
trigger, but all DPAA2 I/O depends on successful probe.

### Step 5.5: Similar Patterns
**Record:** Existing `EPROBE_DEFER` usage in same file for ACPI DMA
deferral (`f8cfa9bbab338b`, line 1053). GCR1 pause/resume in bus
notifier and probe handles complementary MC/IOMMU timing. This fix
completes the boot-synchronization story for the async-bootloader case.

---

## Phase 6: Cross-Reference Against Local Tree

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** Local tree is **v6.18.43** (`stable/linux-6.18.y`).
`fsl_mc_firmware_check` / `FSL_MC_GSR` are **not** present (grep found
no matches). `fsl_mc_bus_probe()` at lines 1069–1091 proceeds directly
from GCR1 resume to `fsl_create_mc_io()` / `mc_get_version()` with no
boot-complete check.

### Step 6.2: Backport Complications
**Record:** **Clean apply** — `git apply --check` on commit
`208858b1b48eb` succeeded with no conflicts. Probe structure matches
mainline.

### Step 6.3: Related Fixes Already Present?
**Record:** No equivalent GSR boot-check fix in this tree. Prerequisite
infrastructure (`fsl_mc_regs`, GCR1 defines, bus notifier) all present
since 2021.

---

## Phase 7: Subsystem and Maintainer Context

### Step 7.1: Subsystem Criticality
**Record:** **Subsystem:** `drivers/bus/fsl-mc` (NXP QorIQ DPAA2 bus).
**Criticality:** IMPORTANT for DPAA2 platforms — root bus for all DPAA2
objects (DPMAC networking, DPNI, DPIO, crypto, etc.). Not universal, but
essential on affected enterprise/embedded SoCs (LS1088, LS2088, LX2160,
etc.).

### Step 7.2: Subsystem Activity
**Record:** Moderately active — recent stable fixes include UAF, double-
free, error-handling. MC/IOMMU boot synchronization has been an ongoing
concern since 2021.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Platform-specific — users of NXP QorIQ DPAA2 SoCs with
bootloaders that start MC firmware boot without waiting. All
DPAA2-dependent functionality is affected when the race loses.

### Step 8.2: Trigger Conditions
**Record:** Boot-time race when bootloader optimizes boot time by not
waiting for MC firmware. Reasonably likely on newer/fast-boot
configurations. Not userspace-triggerable; not a security issue.

### Step 8.3: Failure Severity
**Record:** **Probe failure → DPAA2 subsystem non-functional** (no
network, no DPAA2 devices enumerated). Without `-EPROBE_DEFER`, failure
is permanent for that boot. **Severity: HIGH** for affected platforms
(functional boot failure of core I/O subsystem).

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH for DPAA2 users with async-boot bootloaders —
  restores reliable boot.
- **Risk:** LOW — 46 lines, hardware register read, standard defer
  pattern, applies cleanly.
- **Ratio:** Strong benefit, low risk.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Fixes real boot race on DPAA2 SoCs
- Prevents permanent probe failure and broken DPAA2 I/O
- Small, self-contained, applies cleanly to v6.18.43
- Uses standard `-EPROBE_DEFER` mechanism
- Buggy code confirmed present in this tree since 2021
- NXP developer + FSL maintainer authorship
- Analogous to prior stable-worthy MC/IOMMU boot timing fixes

**AGAINST backport:**
- Platform-specific (DPAA2 only) — but stable routinely takes such fixes
- No syzbot/user bug report — but mechanism is clear from code and
  commit message
- `fsl_mc_firmware_check()` called even when `mc->fsl_mc_regs` may be
  NULL — mitigated by all real DPAA2 bindings providing resource index 1

**Unresolved:** No independent user crash reports; impact verified by
code analysis and NXP description only.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — hardware GSR check +
   EPROBE_DEFER is standard; maintainer applied without objection.
2. Fixes a real bug? **PASS** — boot race causes MC I/O failure before
   firmware ready.
3. Important issue? **PASS** — HIGH: DPAA2 probe failure, core I/O
   broken on affected SoCs.
4. Small and contained? **PASS** — 46 lines, one file.
5. No new features/APIs? **PASS** — synchronization fix only.
6. Can apply to local tree? **PASS** — clean apply verified.

### Step 9.3: Exception Categories
**Record:** None (not device ID, quirk, DT, build, or docs). Qualifies
as a hardware boot-synchronization bug fix.

### Step 9.4: Decision Rationale
For **linux-6.18.y (v6.18.43)**, the fsl-mc bus driver lacks any MC
firmware boot-complete check. When bootloaders start MC firmware
asynchronously, probe races ahead and fails MC portal operations —
without `-EPROBE_DEFER` this is a permanent boot failure for the entire
DPAA2 subsystem. The fix is small, obviously correct, self-contained,
and applies cleanly. Platform-specific scope is normal for stable DPAA2
fixes.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from `git show
  208858b1b48eb`
- **[Phase 1]** Confirmed no Fixes:/Reported-by:/Cc: stable tags
- **[Phase 2]** Full diff analyzed: +46 lines in `fsl-mc-bus.c`, two new
  functions, one probe call site
- **[Phase 3]** `git describe HEAD` → v6.18.43; tree on
  `stable/linux-6.18.y`
- **[Phase 3]** `git blame` on probe area: core probe from
  `e7fa5c80defe0` (2021), GCR1 logic from `f8cfa9bbab338b` (2021)
- **[Phase 3]** `git log stable/linux-6.18.y..origin/master --
  drivers/bus/fsl-mc/fsl-mc-bus.c`: commit `208858b1b48eb` not in stable
- **[Phase 3]** `git apply --check` on patch: **clean apply**
- **[Phase 4]** `b4 dig -c 208858b1b48eb`: found lore thread
- **[Phase 4]** `b4 dig -a`: single v1, no revisions
- **[Phase 4]** `b4 dig -w`: chleroy, linuxppc-dev, linux-kernel CC'd
- **[Phase 4]** `b4 dig -m /tmp/fsl_mc.mbox`: maintainer “Applied,
  thanks!” — no NAKs or stable discussion
- **[Phase 5]** `grep fsl_mc_bus_probe`: only platform driver probe
  callback
- **[Phase 5]** Read current `fsl_mc_bus_probe()` lines 1014–1096:
  confirms no GSR check before `mc_get_version()`
- **[Phase 5]** DT check `fsl-lx2160a.dtsi`: two `reg` entries for fsl-
  mc (portal + control registers)
- **[Phase 6]** `grep FSL_MC_GSR fsl_mc_firmware_check`: **not present**
  in local tree
- **[Phase 6]** Confirmed buggy probe path exists at lines 1069–1091
- **[Phase 6]** Patch applies cleanly to v6.18.43
- **[Phase 7]** `Kconfig`: `FSL_MC_BUS` depends on OF && (LAYERSCAPE ||
  COMPILE_TEST)
- **[Phase 8]** Failure mode: `mc_get_version()` error → `goto
  error_cleanup_mc_io` → non-defer probe failure

**YES**

 drivers/bus/fsl-mc/fsl-mc-bus.c | 46 +++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 996379ace3764..21eb0a3c190fc 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -66,6 +66,13 @@ struct fsl_mc_addr_translation_range {
 #define GCR1_P1_STOP	BIT(31)
 #define GCR1_P2_STOP	BIT(30)
 
+#define FSL_MC_GSR		0x8
+#define FSL_MC_GSR_BOOT_DONE	BIT(0)
+#define FSL_MC_GSR_MCS_MASK	GENMASK(7, 0)
+#define FSL_MC_GSR_MCS_ERR_MASK	GENMASK(7, 1)
+#define FSL_MC_GSR_BC_MASK	GENMASK(15, 8)
+#define FSL_MC_GSR_BC_SHIFT	8
+
 #define FSL_MC_FAPR	0x28
 #define MC_FAPR_PL	BIT(18)
 #define MC_FAPR_BMT	BIT(17)
@@ -1007,6 +1014,41 @@ static int get_mc_addr_translation_ranges(struct device *dev,
 	return 0;
 }
 
+static u32 fsl_mc_read_gsr(struct fsl_mc *mc)
+{
+	return readl(mc->fsl_mc_regs + FSL_MC_GSR);
+}
+
+static int fsl_mc_firmware_check(struct platform_device *pdev)
+{
+	struct fsl_mc *mc = platform_get_drvdata(pdev);
+	u32 gsr, boot_done, boot_code, mcs;
+
+	gsr = fsl_mc_read_gsr(mc);
+	boot_code = (gsr & FSL_MC_GSR_BC_MASK) >> FSL_MC_GSR_BC_SHIFT;
+	if (boot_code == 0xDD) {
+		dev_err(&pdev->dev,
+			"fsl-mc: DPL processing was not started, DPAA2 will not work!\n");
+		return -EOPNOTSUPP;
+	}
+
+	boot_done = gsr & FSL_MC_GSR_BOOT_DONE;
+	if (!boot_done) {
+		dev_dbg(&pdev->dev,
+			"fsl-mc: DPL processing in progress, defer probe\n");
+		return -EPROBE_DEFER;
+	}
+
+	mcs = gsr & FSL_MC_GSR_MCS_MASK;
+	if (mcs & FSL_MC_GSR_MCS_ERR_MASK) {
+		dev_err(&pdev->dev,
+			"fsl-mc: MC boot completed with error 0x%x\n", mcs);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
 /*
  * fsl_mc_bus_probe - callback invoked when the root MC bus is being
  * added
@@ -1071,6 +1113,10 @@ static int fsl_mc_bus_probe(struct platform_device *pdev)
 		       mc->fsl_mc_regs + FSL_MC_GCR1);
 	}
 
+	error = fsl_mc_firmware_check(pdev);
+	if (error)
+		return error;
+
 	/*
 	 * Get physical address of MC portal for the root DPRC:
 	 */
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] powerpc/fadump: Add timeout to RTAS busy-wait loops

[Sasha Levin]

From: Adriano Vero <adri.vero.dev@gmail.com>

[ Upstream commit b3580dd1c68cec23d44a39c439e18b4686c13480 ]

The ibm,configure-kernel-dump RTAS call sites in
rtas_fadump_register(), rtas_fadump_unregister(), and
rtas_fadump_invalidate() polled indefinitely while firmware returned
a busy status. A misbehaving or hung firmware could stall these paths
forever, blocking fadump registration at boot or preventing clean
teardown.

Introduce rtas_fadump_call(), a helper that wraps the common
busy-wait pattern shared by all three sites. The helper accumulates
the total delay and returns -ETIMEDOUT if firmware keeps returning a
busy status beyond RTAS_FADUMP_MAX_WAIT_MS (60 seconds). A pr_debug()
message is emitted on each busy iteration to aid diagnosis when the
timeout is hit.

Signed-off-by: Adriano Vero <adri.vero.dev@gmail.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
[Maddy: Fixed newline after Signed-off-by]
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260506222024.30352-1-adri.vero.dev@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Both background searches finished and match the earlier analysis:

- **No timeout fix in this tree** — searches for `"upper time limit"`,
  `"rtas_fadump_call"`, and `"timeout to RTAS busy-wait"` returned
  nothing.
- The only hit from the broader `"fadump.*timeout"` search was
  unrelated: `ba608c4fa12cf` (pstore/fadump race fix).

So the unbounded RTAS busy-wait loops with the `TODO` comments are still
present in **6.18.44**, and the timeout patch would be a new backport.
The prior **YES** recommendation stands.

 arch/powerpc/platforms/pseries/rtas-fadump.c | 80 ++++++++++++--------
 arch/powerpc/platforms/pseries/rtas-fadump.h |  6 ++
 2 files changed, 53 insertions(+), 33 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/rtas-fadump.c b/arch/powerpc/platforms/pseries/rtas-fadump.c
index eceb3289383ec..3bb4ac2ab6cc3 100644
--- a/arch/powerpc/platforms/pseries/rtas-fadump.c
+++ b/arch/powerpc/platforms/pseries/rtas-fadump.c
@@ -179,9 +179,42 @@ static u64 rtas_fadump_get_bootmem_min(void)
 	return RTAS_FADUMP_MIN_BOOT_MEM;
 }
 
+/*
+ * Helper to make an ibm,configure-kernel-dump RTAS call with a bounded
+ * busy-wait loop. Returns the RTAS return code on completion, or
+ * -ETIMEDOUT if firmware keeps returning a busy status beyond
+ * RTAS_FADUMP_MAX_WAIT_MS milliseconds.
+ */
+static int rtas_fadump_call(struct fw_dump *fadump_conf, int operation,
+			    void *fdm_ptr, unsigned int fdm_size,
+			    const char *op_name)
+{
+	unsigned int wait_time, total_wait = 0;
+	int rc;
+
+	do {
+		rc = rtas_call(fadump_conf->ibm_configure_kernel_dump, 3, 1,
+			       NULL, operation, fdm_ptr, fdm_size);
+		wait_time = rtas_busy_delay_time(rc);
+		if (wait_time) {
+			pr_debug("Firmware busy during fadump %s, waiting %ums (total %ums)\n",
+				 op_name, wait_time, total_wait);
+			if (total_wait >= RTAS_FADUMP_MAX_WAIT_MS) {
+				pr_err("Timed out waiting for firmware to complete fadump %s\n",
+				       op_name);
+				return -ETIMEDOUT;
+			}
+			total_wait += wait_time;
+			mdelay(wait_time);
+		}
+	} while (wait_time);
+
+	return rc;
+}
+
 static int rtas_fadump_register(struct fw_dump *fadump_conf)
 {
-	unsigned int wait_time, fdm_size;
+	unsigned int fdm_size;
 	int rc, err = -EIO;
 
 	/*
@@ -192,16 +225,10 @@ static int rtas_fadump_register(struct fw_dump *fadump_conf)
 	fdm_size = sizeof(struct rtas_fadump_section_header);
 	fdm_size += be16_to_cpu(fdm.header.dump_num_sections) * sizeof(struct rtas_fadump_section);
 
-	/* TODO: Add upper time limit for the delay */
-	do {
-		rc =  rtas_call(fadump_conf->ibm_configure_kernel_dump, 3, 1,
-				NULL, FADUMP_REGISTER, &fdm, fdm_size);
-
-		wait_time = rtas_busy_delay_time(rc);
-		if (wait_time)
-			mdelay(wait_time);
-
-	} while (wait_time);
+	rc = rtas_fadump_call(fadump_conf, FADUMP_REGISTER, &fdm, fdm_size,
+			      "register");
+	if (rc == -ETIMEDOUT)
+		return -ETIMEDOUT;
 
 	switch (rc) {
 	case 0:
@@ -234,19 +261,12 @@ static int rtas_fadump_register(struct fw_dump *fadump_conf)
 
 static int rtas_fadump_unregister(struct fw_dump *fadump_conf)
 {
-	unsigned int wait_time;
 	int rc;
 
-	/* TODO: Add upper time limit for the delay */
-	do {
-		rc =  rtas_call(fadump_conf->ibm_configure_kernel_dump, 3, 1,
-				NULL, FADUMP_UNREGISTER, &fdm,
-				sizeof(struct rtas_fadump_mem_struct));
-
-		wait_time = rtas_busy_delay_time(rc);
-		if (wait_time)
-			mdelay(wait_time);
-	} while (wait_time);
+	rc = rtas_fadump_call(fadump_conf, FADUMP_UNREGISTER, &fdm,
+			      sizeof(struct rtas_fadump_mem_struct), "unregister");
+	if (rc == -ETIMEDOUT)
+		return -ETIMEDOUT;
 
 	if (rc) {
 		pr_err("Failed to un-register - unexpected error(%d).\n", rc);
@@ -259,19 +279,13 @@ static int rtas_fadump_unregister(struct fw_dump *fadump_conf)
 
 static int rtas_fadump_invalidate(struct fw_dump *fadump_conf)
 {
-	unsigned int wait_time;
 	int rc;
 
-	/* TODO: Add upper time limit for the delay */
-	do {
-		rc =  rtas_call(fadump_conf->ibm_configure_kernel_dump, 3, 1,
-				NULL, FADUMP_INVALIDATE, fdm_active,
-				sizeof(struct rtas_fadump_mem_struct));
-
-		wait_time = rtas_busy_delay_time(rc);
-		if (wait_time)
-			mdelay(wait_time);
-	} while (wait_time);
+	rc = rtas_fadump_call(fadump_conf, FADUMP_INVALIDATE,
+			      (void *)fdm_active,
+			      sizeof(struct rtas_fadump_mem_struct), "invalidate");
+	if (rc == -ETIMEDOUT)
+		return -ETIMEDOUT;
 
 	if (rc) {
 		pr_err("Failed to invalidate - unexpected error (%d).\n", rc);
diff --git a/arch/powerpc/platforms/pseries/rtas-fadump.h b/arch/powerpc/platforms/pseries/rtas-fadump.h
index c109abf6befd9..65fdab7b5b8d3 100644
--- a/arch/powerpc/platforms/pseries/rtas-fadump.h
+++ b/arch/powerpc/platforms/pseries/rtas-fadump.h
@@ -41,6 +41,12 @@
 #define MAX_SECTIONS				10
 #define RTAS_FADUMP_MAX_BOOT_MEM_REGS		7
 
+/*
+ * Maximum time to wait for firmware to respond to an
+ * ibm,configure-kernel-dump RTAS call before giving up.
+ */
+#define RTAS_FADUMP_MAX_WAIT_MS			60000U
+
 /* Kernel Dump section info */
 struct rtas_fadump_section {
 	__be32	request_flag;
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] powerpc/pseries: Ensure vpa,slb_shadow & dtl are unregistered during crash

[Sasha Levin]

From: Vaibhav Jain <vaibhav@linux.ibm.com>

[ Upstream commit 810d07fb4cf7577847f85a6fd6273b69cad8d580 ]

Currently pseries_kexec_cpu_down() skips unregistering vpa, slb_shadow and
dtl areas during a crash and kexec shutdown path. It was done to avoid
doing an HCALL while crashing. However recently Anushree reported that
during kernel crash while the kdump kernel was coming up, Hypervisor
reported invalid values for 'vpa.yield_count' while it dispatching L2-KVM
Guest vcpus. The error manifested as debug build Hypervisor assert
triggering to indicate possible VPA corruption.

Looking at the kexec cpu offline path it was discovered that during crash
kernel doesn't unregister the VPA/SLB-Shadow/DTL area with
Hypervisor. Instead it re-allocates and re-registers these areas
for cpus during boot. During kexec boot the previously allocated areas
can get overwritten with new content without hypervisor knowledge. This
creates a small window where while kexec kernel boots and the L2-VCPUs are
being dispatched, Hypervisor may try to read/write to a wrong memory area
which previously belonged to older VPA.

Fix this possible race and memory corruption by updating
pseries_kexec_cpu_down() to also unregister vpa,slb_shadow & dtl areas
during a kernel crash.

Signed-off-by: Vaibhav Jain <vaibhav@linux.ibm.com>
Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260708015802.274271-1-vaibhav@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `powerpc/pseries: Ensure vpa,slb_shadow &
dtl are unregistered during crash`

**Local tree:** Linux **6.18.44** (`git describe HEAD` →
`v6.18.44-2-g1b9e1abadee04`, `make kernelversion` → `6.18.44`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Parse the subject line
**Record:** `[powerpc/pseries]` `[ensure]` — During kernel crash/kdump
shutdown, unregister VPA, SLB shadow, and DTL areas with the hypervisor
instead of skipping that cleanup.

### Step 1.2: Parse all commit message tags
**Record:**
| Tag | Value |
|-----|-------|
| Signed-off-by | Vaibhav Jain \<vaibhav@linux.ibm.com\> (author) |
| Tested-by | Anushree Mathur \<anushree.mathur@linux.ibm.com\>
(reporter/tester) |
| Signed-off-by | Madhavan Srinivasan \<maddy@linux.ibm.com\> (powerpc
maintainer) |
| Link |
https://patch.msgid.link/20260708015802.274271-1-vaibhav@linux.ibm.com |

**Notable patterns:** `Tested-by` from the reporter; maintainer sign-
off; no `Fixes:` tag (expected for manual review); no `Cc: stable` tag
(expected).

### Step 1.3: Analyze commit body
**Record:**
- **Bug:** `pseries_kexec_cpu_down()` skips VPA/SLB-shadow/DTL
  unregistration when `crash_shutdown` is set (crash/kdump path).
- **Symptom:** During kernel crash while kdump boots, hypervisor reads
  invalid `vpa.yield_count` values; debug hypervisor asserts on possible
  VPA corruption while dispatching L2-KVM guest vCPUs.
- **Root cause:** Crash kernel does not unregister these areas; kdump
  kernel later reallocates and re-registers them. Hypervisor still
  references old memory for a window, so it may read/write memory that
  no longer belongs to the registered VPA.
- **Version info:** None explicit; bug is long-standing (see Phase 3).

### Step 1.4: Detect hidden bug fixes
**Record:** Not disguised — this is an explicit race/memory-corruption
fix in the kdump crash-shutdown path, not cleanup-only.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory changes
**Record:**
- **Files:** `arch/powerpc/platforms/pseries/kexec.c` only
- **Scope:** ~10 lines changed (comment rewrite + one condition change)
- **Function modified:** `pseries_kexec_cpu_down()`
- **Classification:** Single-file surgical fix

### Step 2.2: Code flow change per hunk
**Record:**
- **Hunk 1 (comment):** Before: documents intentional skip of hypervisor
  calls during crash. After: explains why unregister must still be
  attempted during crash to prevent hypervisor use of stale memory.
- **Hunk 2 (condition):** Before: `if
  (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown)` —
  unregister only on normal kexec. After: `if
  (firmware_has_feature(FW_FEATURE_SPLPAR))` — unregister on both normal
  kexec and crash/kdump paths.

### Step 2.3: Bug mechanism
**Record:**
- **Category:** Race condition / memory corruption (hypervisor–kernel
  shared state)
- **Mechanism:** Hypervisor retains pointers to VPA/SLB-shadow/DTL
  memory after crash. kdump kernel reuses that physical memory before
  re-registering new areas. Hypervisor accesses wrong content → VPA
  corruption, hypervisor asserts.

### Step 2.4: Fix quality
**Record:**
- **Quality:** Obviously correct; reuses existing, tested unregister
  path already used for normal kexec and CPU hotplug.
- **Regression risk:** Low. Failed HCALLs only emit `pr_err` warnings
  (same as today). Worst case equals current crash behavior; best case
  closes the race.
- **Red flags:** None. No API changes, no new logic beyond removing the
  crash exemption.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame changed lines
**Record:**
- `!crash_shutdown` guard present since **dce623e0827e8** (Michael
  Ellerman, 2007-02-08, “[POWERPC] Cleanup pseries kexec code”).
- Comment expanded in **499dcd41378eba** (Nicholas Piggin, 2018-02-14)
  with explicit “XXX: Why?” noting hypervisor may step on memory.
- VPA/SLB/DTL unregister on kexec added in **b1301797f30370** (Anton
  Blanchard, 2011-07-25, “Fix kexec on recent firmware versions”, `Cc:
  stable@kernel.org`).
- Buggy code verified present at tags **v5.4, v5.10, v5.15, v6.1, v6.6,
  v6.12, v6.18** in this tree.

### Step 3.2: Follow Fixes: tag
**Record:** No `Fixes:` tag. N/A.

### Step 3.3: Related file history
**Record:** `arch/powerpc/platforms/pseries/kexec.c` history at v5.4
shows long-stable kexec/VPA handling; no related prerequisite series
identified. Standalone one-commit fix.

### Step 3.4: Author context
**Record:** Vaibhav Jain is an IBM powerpc contributor. Madhavan
Srinivasan (maintainer) signed off. Fix commit not yet present in this
6.18.44 checkout.

### Step 3.5: Dependencies
**Record:** No dependencies. `unregister_vpa()`,
`unregister_slb_shadow()`, `unregister_dtl()` exist in
`arch/powerpc/include/asm/plpar_wrappers.h`. Applies standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original patch discussion
**Record:** `b4 dig -c HEAD` matched unrelated commit. `b4 shazam` could
not find this patch on lore (likely not yet indexed/merged). `WebFetch`
of lore URL blocked by bot protection. **Link tag present but thread
content unverified.**

### Step 4.2: Reviewers
**Record:** `b4 dig -w` not usable without matching commit. Maintainer
SOB (Madhavan Srinivasan) verified in commit message.

### Step 4.3: Bug report
**Record:** Reported by Anushree Mathur (IBM) per commit message;
hypervisor assert on invalid `vpa.yield_count` during kdump with L2-KVM
guests. `Tested-by` from same person. Real-world IBM Power LPAR/kdump
scenario.

### Step 4.4: Related patches/series
**Record:** Standalone fix; not part of a multi-patch series.

### Step 4.5: Stable mailing list history
**Record:** Not searched successfully (lore inaccessible). Prior related
fix (b1301797f30370, 2011) was explicitly `Cc: stable@kernel.org` for
kexec/VPA unregister issues on pseries.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `pseries_kexec_cpu_down()` — only function modified.

### Step 5.2: Callers
**Record:**
| Caller | `crash_shutdown` | Context |
|--------|------------------|---------|
| `arch/powerpc/kexec/crash.c:105` | `1` | Secondary CPU in crash/kdump
path |
| `arch/powerpc/kexec/crash.c:400` | `1` | Panic CPU after crash
shutdown handlers |
| `arch/powerpc/kexec/core_64.c:159,269,287` | `0` | Normal kexec CPU
shutdown |

Registered via `ppc_md.kexec_cpu_down = pseries_kexec_cpu_down` in
`setup.c:1162` under `CONFIG_KEXEC_CORE`.

### Step 5.3: Callees
**Record:** `unregister_dtl()`, `unregister_slb_shadow()`,
`unregister_vpa()` → `plpar_hcall_norets(H_REGISTER_VPA, ...)`. Also
`xive_teardown_cpu()` / `xics_kexec_teardown_cpu()` (unchanged, run
regardless of `crash_shutdown`).

### Step 5.4: Call chain / reachability
**Record:** Triggered on kernel panic with kdump configured
(`CONFIG_CRASH_DUMP`). Requires `FW_FEATURE_SPLPAR` (IBM LPAR). Not
userspace-triggerable directly, but panic/kdump is a critical enterprise
path on Power systems.

### Step 5.5: Similar patterns
**Record:** `pseries_cpu_offline_self()` in `hotplug-cpu.c:73-74` always
calls `unregister_slb_shadow()` and `unregister_vpa()` — confirming
unregister is normal/expected. Only crash path was exempted.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE

### Step 6.1: Does buggy code exist?
**Record:** **YES.** Current `kexec.c:28`:

```28:28:arch/powerpc/platforms/pseries/kexec.c
        if (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown)
{
```

Bug present since at least v5.4 in this repository; long-standing.

### Step 6.2: Backport complications
**Record:** **Clean apply expected.** Single condition change and
comment update; no structural differences between v6.18 and current HEAD
in this file.

### Step 6.3: Related fixes already present?
**Record:** No equivalent fix found. `git log --grep="Ensure vpa"`
returns nothing. Fix not yet applied to 6.18.44.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem criticality
**Record:** `arch/powerpc/platforms/pseries/` — **IMPORTANT** (IBM Power
LPAR platform code). kdump/crash recovery is critical for enterprise
deployments.

### Step 7.2: Subsystem activity
**Record:** Active maintenance in 6.18.y (recent pseries fixes for papr-
hvpipe, MSI, cmm). Platform is actively supported.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** **Platform-specific, config-specific:** IBM Power LPAR
(`FW_FEATURE_SPLPAR`) systems with kdump (`CONFIG_CRASH_DUMP` /
`CONFIG_KEXEC_CORE`). Especially visible with nested KVM (L2 guests),
but underlying stale-VPA race exists whenever kdump runs after panic.

### Step 8.2: Trigger conditions
**Record:** Kernel panic → kdump kernel boot sequence. Not every boot;
but any panic on affected systems. Requires SPLPAR + kdump. Unprivileged
users can trigger panic indirectly, but this is primarily a reliability
fix for crash recovery, not a direct syscall security issue.

### Step 8.3: Failure mode severity
**Record:** Hypervisor reads/writes stale VPA/SLB/DTL memory → VPA
corruption, hypervisor asserts, potential kdump boot interference.
**Severity: HIGH** (crash-recovery corruption; can affect guest VMs on
same LPAR).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH for Power LPAR + kdump users; closes a real
  hypervisor/kernel race during crash recovery.
- **Risk:** LOW — minimal diff, reuses existing unregister path;
  failures are non-fatal warnings.
- **Ratio:** Strongly favors backport.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real bug with IBM reporter and `Tested-by`
- Race causes hypervisor VPA corruption during kdump
- Long-standing bug (since 2007); present in 6.18.44
- Tiny, surgical, obviously correct fix
- Maintainer signed off
- Prior analogous kexec/VPA fix (2011) was stable material
- kdump reliability is critical for enterprise Power

**AGAINST backport:**
- Platform-limited (powerpc/pseries SPLPAR only)
- Making hypervisor calls during crash was originally avoided
  intentionally
- Lore review thread not accessible for independent verification

**Unresolved:** Full mailing-list review thread not retrieved (lore bot
protection).

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — logic is sound; `Tested-by`
   from reporter.
2. Fixes a real bug affecting users? **PASS** — IBM-reported
   kdump/hypervisor VPA corruption.
3. Important issue? **PASS** — memory corruption in crash-recovery path;
   hypervisor asserts; guest impact.
4. Small and contained? **PASS** — one file, one condition, comment
   update.
5. No new features or APIs? **PASS**.
6. Can apply to local tree? **PASS** — buggy code identical; clean apply
   expected.

### Step 9.3: Exception categories
**Record:** None (standard bug fix, not device ID/quirk/DT/build/doc).

### Step 9.4: Problem summary for stable users
On IBM Power LPAR systems with kdump enabled, a kernel panic leaves
VPA/SLB-shadow/DTL areas registered with the hypervisor. While the kdump
kernel boots and reallocates that memory, the hypervisor can still
access the old addresses, causing VPA corruption. This was observed as
hypervisor asserts during L2-KVM vCPU dispatch. The fix runs the same
unregister calls during crash shutdown that already run on normal kexec,
closing the race window.

---

## Verification

- **[Phase 1]** Parsed subject, tags (`Tested-by`, `Link`, maintainer
  SOB); no `Fixes:` tag.
- **[Phase 2]** Read diff: removes `&& !crash_shutdown`, updates comment
  in `pseries_kexec_cpu_down()`.
- **[Phase 2]** Read current `arch/powerpc/platforms/pseries/kexec.c` —
  buggy `!crash_shutdown` guard at line 28.
- **[Phase 3]** `git blame v5.4`: `!crash_shutdown` since dce623e0827e8
  (2007); comment from 499dcd41378eba (2018).
- **[Phase 3]** `git show 499dcd41378eba`: Piggin expanded “XXX” comment
  questioning crash skip.
- **[Phase 3]** `git show b1301797f30370`: 2011 kexec VPA unregister fix
  had `Cc: stable@kernel.org`.
- **[Phase 3]** Verified buggy code at tags v5.4, v5.10, v5.15, v6.1,
  v6.6, v6.12, v6.18.
- **[Phase 4]** `b4 dig -c HEAD`: unrelated match only.
- **[Phase 4]** `b4 shazam`: patch not found on lore.
- **[Phase 4]** `WebFetch` lore URL: blocked (bot protection).
  **UNVERIFIED:** full review thread.
- **[Phase 5]** `grep kexec_cpu_down`: callers in `crash.c`
  (crash_shutdown=1) and `core_64.c` (crash_shutdown=0).
- **[Phase 5]** Read `plpar_wrappers.h`: unregister_* are inline
  hypervisor calls.
- **[Phase 5]** Read `hotplug-cpu.c:73-74`: always unregisters on CPU
  offline.
- **[Phase 6]** `git describe HEAD` / `make kernelversion`: tree is
  6.18.44.
- **[Phase 6]** Buggy code confirmed present; fix not yet applied.
- **[Phase 6]** `git show` across tags: identical `!crash_shutdown`
  guard — clean backport expected.
- **[Phase 8]** Failure mode: hypervisor VPA corruption during kdump —
  severity HIGH for affected systems.

**YES**

 arch/powerpc/platforms/pseries/kexec.c | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/kexec.c b/arch/powerpc/platforms/pseries/kexec.c
index 431be156ca9bb..29f7c97ff1932 100644
--- a/arch/powerpc/platforms/pseries/kexec.c
+++ b/arch/powerpc/platforms/pseries/kexec.c
@@ -20,12 +20,15 @@
 void pseries_kexec_cpu_down(int crash_shutdown, int secondary)
 {
 	/*
-	 * Don't risk a hypervisor call if we're crashing
-	 * XXX: Why? The hypervisor is not crashing. It might be better
-	 * to at least attempt unregister to avoid the hypervisor stepping
-	 * on our memory.
+	 * Ensure vpa/slb_shadow/dtl cleanup even while we are crashing.
+	 * Why? The hypervisor is not crashing so at least attempt unregister to
+	 * avoid the hypervisor stepping on our memory. If hypervisor or kexec
+	 * kernel steps on the old memory allocated to these areas before the
+	 * new kexec-kernel happens to allocate and register new areas,
+	 * the hypervisor will see invalid content which may cause
+	 * unexpected behavior.
 	 */
-	if (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown) {
+	if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
 		int ret;
 		int cpu = smp_processor_id();
 		int hwcpu = hard_smp_processor_id();
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] ASoC: fsl-asoc-card: reduce WM8904 PLL ratio to meet frequency limit

[Sasha Levin]

From: Shengjiu Wang <shengjiu.wang@nxp.com>

[ Upstream commit 99b5316f08f390a5e1ea2239ecca8e2b4ef70ac6 ]

WM8904 has a 27 MHz PLL frequency limit. The current S24_LE PLL ratio
of 384 exceeds this at high sample rates (96 kHz × 384 = 36.864 MHz).

Reduce the ratio to 192 for WM8904, keeping PLL within limits at all
supported rates (96 kHz × 192 = 18.432 MHz).

Add codec-specific pll_ratio_s24 field, default 384, override to 192
for WM8904.

Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/20260429100028.2739711-6-shengjiu.wang@nxp.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 1: Commit Message Forensics

### Step 1.1: Subject Line
**Record:** `[ASoC: fsl-asoc-card]` `[reduce]` — Lower WM8904 S24_LE PLL
ratio so FLL output stays within the codec’s frequency limit.

### Step 1.2: Commit Message Tags
**Record:**
- **Signed-off-by:** Shengjiu Wang `<shengjiu.wang@nxp.com>` (author,
  NXP)
- **Link:** https://patch.msgid.link/20260429100028.2739711-6-
  shengjiu.wang@nxp.com
- **Signed-off-by:** Mark Brown `<broonie@kernel.org>` (ASoC maintainer,
  applied the series)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, or Cc: stable tags
- Part of **[PATCH v2 5/5]** in series “ASoC: fsl-asoc-card: Add some
  improvements”

### Step 1.3: Commit Body Analysis
**Record:**
- **Bug:** WM8904 FLL/PLL output is limited to 27 MHz. With the
  hardcoded S24_LE ratio of 384, high sample rates exceed that (96 kHz ×
  384 = 36.864 MHz).
- **Symptom:** FLL programmed out of spec → audio fails or is unreliable
  at high rates with S24_LE on WM8904 boards.
- **Root cause:** `fsl-asoc-card.c` uses a single 384 multiplier for all
  codecs with PLL enabled; WM8904 needs 192.
- **Fix:** Add per-codec `pll_ratio_s24` (default 384), set 192 for
  `fsl,imx-audio-wm8904`.

### Step 1.4: Hidden Bug Fix Detection
**Record:** Yes — despite “reduce ratio,” this is a hardware correctness
fix (codec clock out of spec), not a cosmetic cleanup.

---

## Phase 2: Diff Analysis

### Step 2.1: Change Inventory
**Record:**
- **File:** `sound/soc/fsl/fsl-asoc-card.c` (+7 / −1)
- **Functions:** `fsl_asoc_card_hw_params()`, `fsl_asoc_card_probe()`
- **Structs:** `codec_priv` (+1 field)
- **Scope:** Single-file, surgical fix

### Step 2.2: Code Flow Changes
**Record:**
- **Hunk 1 (struct):** Adds `pll_ratio_s24` to `codec_priv` with
  documentation.
- **Hunk 2 (`hw_params`):** `pll_out = sample_rate * 384` → `pll_out =
  sample_rate * codec_priv->pll_ratio_s24` for S24_LE.
- **Hunk 3 (`probe` init):** Default `pll_ratio_s24 = 384` for all
  codecs.
- **Hunk 4 (WM8904 branch):** Override to `pll_ratio_s24 = 192` for
  `fsl,imx-audio-wm8904`.

**Before → After:** WM8904 at 96 kHz S24_LE requests 36.864 MHz FLL
output → 18.432 MHz (within 27 MHz limit).

### Step 2.3: Bug Mechanism
**Record:**
- **Category:** Hardware workaround / logic correctness (wrong clock
  ratio for a specific codec).
- **Mechanism:** Generic 384× ratio violates WM8904’s 27 MHz PLL limit
  at rates above ~70 kHz with S24_LE (e.g. 88.2 kHz × 384 = 33.9 MHz, 96
  kHz × 384 = 36.9 MHz).

### Step 2.4: Fix Quality
**Record:**
- Minimal, codec-specific override; other codecs unchanged (default
  384).
- Low regression risk; only affects WM8904 machine configs using PLL
  path.
- NXP-authored, ASoC-maintainer-applied.

---

## Phase 3: Git History Investigation

### Step 3.1: Blame
**Record:** In this 6.18.43 tree, the hardcoded `384` at line 225 and
WM8904 probe block at lines 833–838 are present. Stable history is
flattened, but `imx-audio-wm8904` support is in the tree since at least
Linux 6.18-rc7 (`ac3fd01e4c1ef`).

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag.

### Step 3.3: Related File History
**Record:** Patch is **[5/5]** in a series; patches 1–4 cover ASRC DPCM,
CS42888 constraints, and WM8960/WM8962 format limits — unrelated to this
WM8904 PLL fix. This patch is self-contained.

### Step 3.4: Author Context
**Record:** Shengjiu Wang is an active NXP/i.MX audio contributor with
multiple stable-worthy ASoC fixes in this tree.

### Step 3.5: Dependencies
**Record:** No prerequisites. Applies standalone; only needs existing
`fsl,imx-audio-wm8904` support and PLL code path already in 6.18.43.

---

## Phase 4: Mailing List and External Research

### Step 4.1: Original Discussion
**Record:** `b4 mbox` retrieved thread from lore (7 messages). Patch v2
5/5 submitted 2026-04-29. Mark Brown applied entire series to
`broonie/sound` for-7.2 on 2026-04-30. This patch:
https://git.kernel.org/broonie/sound/c/99b5316f08f3. No stable
nomination or NAK found in thread.

### Step 4.2: Reviewers
**Record:** CC’d: broonie@kernel.org, lgirdwood@gmail.com,
perex@perex.cz, tiwai@suse.com, linux-sound@vger.kernel.org. Mark Brown
applied with “Thanks!”

### Step 4.3: Bug Report
**Record:** No external bug tracker. Issue found during NXP board
testing per cover letter (“During testing several issues were
identified”).

### Step 4.4: Series Context
**Record:** 5-patch series; this patch is independent of patches 1–4.

### Step 4.5: Stable List History
**Record:** UNVERIFIED — lore stable search blocked by bot protection;
no stable discussion found in mbox thread.

---

## Phase 5: Code Semantic Analysis

### Step 5.1: Key Functions
**Record:** `fsl_asoc_card_hw_params()`, `fsl_asoc_card_probe()`,
`wm8904_set_fll()` (codec callee).

### Step 5.2: Callers
**Record:** `fsl_asoc_card_hw_params` registered as `.hw_params` in card
DAI ops (line 295) — invoked on every PCM open/hw_params for
playback/capture.

### Step 5.3: Callees
**Record:** `snd_soc_dai_set_pll()` → `wm8904_set_fll()` →
`fll_factors()` configures WM8904 FLL registers. `wm8904.c` does not
validate Fout against 27 MHz; it can succeed in software while hardware
is out of spec (Fvco computed up to ~147 MHz at 36.864 MHz Fout).

### Step 5.4: Reachability
**Record:** Userspace opens PCM stream on imx8mp Hummingboard Pulse (and
related boards) with WM8904 → `hw_params` → PLL programmed. WM8904
advertises `SNDRV_PCM_FMTBIT_S24_LE` and rates up to 96 kHz — the broken
path is reachable from normal audio use.

### Step 5.5: Similar Patterns
**Record:** Other codecs on the same driver (WM8962, WM8994, NAU8822)
keep default 384; only WM8904 needs the lower ratio — consistent with
codec-specific hardware limits.

---

## Phase 6: Cross-Reference Against Local Tree (6.18.43)

### Step 6.1: Buggy Code Present?
**Record:** **YES.** Local tree is `v6.18.43` (stable/linux-6.18.y).
Buggy hardcoded `384` at line 225; WM8904 config at lines 833–838
without ratio override. `imx8mp-hummingboard-pulse-codec.dtsi` uses
`fsl,imx-audio-wm8904`. Multiple DTBs build from that DTSI.

### Step 6.2: Backport Complications
**Record:** Clean apply expected — patch matches current file structure
(index `44083d15f6e5` in submission aligns with local tree).

### Step 6.3: Related Fixes Already Present?
**Record:** `pll_ratio_s24` not in tree; fix not yet applied.

---

## Phase 7: Subsystem Context

### Step 7.1: Subsystem and Criticality
**Record:** **ASoC / sound/soc/fsl** — IMPORTANT for i.MX embedded
platforms; not core kernel, but affects real shipped hardware.

### Step 7.2: Subsystem Activity
**Record:** Actively maintained; WM8904 Hummingboard support added in
6.18 cycle.

---

## Phase 8: Impact and Risk Assessment

### Step 8.1: Who Is Affected
**Record:** Users of i.MX boards with `fsl,imx-audio-wm8904` (SolidRun
imx8mp Hummingboard Pulse/Pro/Mate/Ripple variants).
CONFIG_SND_SOC_FSL_ASOC_CARD + WM8904.

### Step 8.2: Trigger Conditions
**Record:** PCM stream with `SNDRV_PCM_FORMAT_S24_LE` at sample rates
where `rate × 384 > 27 MHz` — notably 88.2 kHz and 96 kHz. Common for
hi-res audio. Unprivileged users via standard ALSA/PulseAudio/PipeWire.

### Step 8.3: Failure Severity
**Record:** **MEDIUM-HIGH** for affected hardware — broken or unreliable
audio (FLL out of spec), not a kernel crash. Real functional defect on
supported boards.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** Restores correct audio at high sample rates on WM8904
  boards already supported in 6.18.y.
- **Risk:** Very low — 7-line change, WM8904-only override, defaults
  preserved for other codecs.
- **Ratio:** Strong benefit, minimal risk.

---

## Phase 9: Final Synthesis

### Step 9.1: Evidence Summary

**FOR backport:**
- Real hardware bug on boards in this tree
- Vendor-authored, maintainer-applied fix
- Small, self-contained, standalone within series
- Buggy code confirmed present in 6.18.43
- Hardware quirk / workaround category (stable-appropriate)
- Affects user-visible audio functionality

**AGAINST backport:**
- Not a crash/security/data-corruption issue
- Limited to one machine driver + one codec variant
- WM8904 fsl-asoc-card support is relatively new in 6.18

**Unresolved:** No independent Tested-by; no explicit stable nomination
in mailing list.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — math verified; NXP + Mark
   Brown; identified in board testing.
2. Fixes real bug affecting users? **PASS** — broken hi-rate S24_LE
   audio on WM8904 imx boards.
3. Important issue? **PASS (MEDIUM)** — functional hardware defect, not
   crash-level.
4. Small and contained? **PASS** — 7 lines, one file.
5. No new features/APIs? **PASS** — internal driver parameter only.
6. Can apply to local tree? **PASS** — code exists, clean apply
   expected.

### Step 9.3: Exception Category
**Record:** Hardware quirk/workaround — codec-specific clock ratio
correction.

### Step 9.4: Decision Rationale
For **linux-6.18.y (6.18.43)**: the buggy WM8904 PLL configuration is
present, real imx8mp Hummingboard hardware is supported, and the fix is
minimal and codec-specific. This is appropriate stable material as a
hardware correctness fix for boards already enabled in this tree.

---

## Verification

- [Phase 1] Parsed subject, tags, body from provided commit message and
  mbox
- [Phase 2] Diff analysis: 7 lines in `fsl-asoc-card.c`, 2 functions
  modified
- [Phase 3] `git describe HEAD` → v6.18.43; `git blame` line 225 shows
  hardcoded 384
- [Phase 3] `git log stable/linux-6.18.y -S "imx-audio-wm8904"` →
  present since 6.18-rc7
- [Phase 3] Confirmed patch 5/5 is standalone within series (mbox cover
  letter)
- [Phase 4] `b4 mbox` → 7-message thread; Mark Brown applied series
  2026-04-30
- [Phase 4] No stable/CC/stable or NAK in mbox thread
- [Phase 4] UNVERIFIED: lore stable list search (bot-blocked)
- [Phase 5] `fsl_asoc_card_hw_params` called from `.hw_params` DAI ops
  (line 295)
- [Phase 5] `wm8904_set_fll`/`fll_factors` reviewed — no 27 MHz Fout
  validation in driver
- [Phase 5] WM8904 supports S24_LE and up to 96 kHz (`wm8904.c` lines
  2023–2026)
- [Phase 6] Buggy code confirmed at line 225; WM8904 probe at lines
  833–838
- [Phase 6] `imx8mp-hummingboard-pulse-codec.dtsi` uses `fsl,imx-audio-
  wm8904`
- [Phase 6] Multiple DTBs include pulse codec DTSI (Makefile lines 211,
  pro/mate/ripple)
- [Phase 8] 96 kHz × 384 = 36.864 MHz > 27 MHz; 96 kHz × 192 = 18.432
  MHz < 27 MHz
- [Phase 8] 88.2 kHz × 384 = 33.87 MHz also exceeds limit

**YES**The background git history checks are done. They confirm:

- **`imx-audio-wm8904` support is in the 6.18.y tree** (present since at
  least Linux 6.18-rc7), including the Hummingboard Pulse DTS and the
  hardcoded `384` PLL ratio.
- **The fix is not in this tree yet** — `pll_ratio_s24` does not appear
  on master or stable.
- **History is flattened** in this checkout, so individual introduction
  commits are hard to isolate, but the buggy WM8904 path is clearly
  present in 6.18.43.

That supports the earlier **YES** verdict: this is a small, standalone
hardware fix for boards already supported in linux-6.18.y.

 sound/soc/fsl/fsl-asoc-card.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 71113886e494b..dcf2e495ad19f 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -48,6 +48,9 @@
  * @mclk_id: MCLK (or main clock) id for set_sysclk()
  * @fll_id: FLL (or secordary clock) id for set_sysclk()
  * @pll_id: PLL id for set_pll()
+ * @pll_ratio_s24: PLL output ratio for S24_LE format (PLL_freq = sample_rate × ratio)
+ *                 Default is 384, but some codecs (e.g., WM8904) require lower values
+ *                 to stay within PLL frequency limits
  */
 struct codec_priv {
 	struct clk *mclk;
@@ -56,6 +59,7 @@ struct codec_priv {
 	u32 mclk_id;
 	int fll_id;
 	int pll_id;
+	int pll_ratio_s24;
 };
 
 /**
@@ -222,7 +226,7 @@ static int fsl_asoc_card_hw_params(struct snd_pcm_substream *substream,
 
 		if (codec_priv->pll_id >= 0 && codec_priv->fll_id >= 0) {
 			if (priv->sample_format == SNDRV_PCM_FORMAT_S24_LE)
-				pll_out = priv->sample_rate * 384;
+				pll_out = priv->sample_rate * codec_priv->pll_ratio_s24;
 			else
 				pll_out = priv->sample_rate * 256;
 
@@ -742,6 +746,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 	for (codec_idx = 0; codec_idx < 2; codec_idx++) {
 		priv->codec_priv[codec_idx].fll_id = -1;
 		priv->codec_priv[codec_idx].pll_id = -1;
+		priv->codec_priv[codec_idx].pll_ratio_s24 = 384;
 	}
 
 	/* Diversify the card configurations */
@@ -835,6 +840,7 @@ static int fsl_asoc_card_probe(struct platform_device *pdev)
 		priv->codec_priv[0].mclk_id = WM8904_FLL_MCLK;
 		priv->codec_priv[0].fll_id = WM8904_CLK_FLL;
 		priv->codec_priv[0].pll_id = WM8904_FLL_MCLK;
+		priv->codec_priv[0].pll_ratio_s24 = 192;
 		priv->dai_fmt |= SND_SOC_DAIFMT_CBP_CFP;
 	} else if (of_device_is_compatible(np, "fsl,imx-audio-spdif")) {
 		ret = fsl_asoc_card_spdif_init(codec_np, cpu_np, codec_dai_name, priv);
-- 
2.53.0

[PATCH AUTOSEL 6.18] fbdev: Wrap user-invoked calls to fb_set_var() in helper

[Sasha Levin]

From: Thomas Zimmermann <tzimmermann@suse.de>

[ Upstream commit 6f611e5e5f3327cf2e2daabe6ee5acac58cc784e ]

Handle fbcon during display updates in fb_set_var_from_user(). Check
with fbcon if the mode change is possible, update hardware state and
finally update fbcon. Update all callers.

Only the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other
mode-changes callers in sysfs and driver code are missing fbcon-related
steps.

With the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain
fbcon state themselves.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `fbdev: Wrap user-invoked calls to
fb_set_var() in helper`

**Local tree:** `v6.18.44` (6.18.y stable)
**Commit under review:** `6f611e5e5f3327cf2e2daabe6ee5acac58cc784e` (not
in HEAD; present as git object, applies cleanly)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[fbdev]` `[wrap/consolidate]` — Introduce
`fb_set_var_from_user()` helper and route all user-invoked mode-change
paths through it.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Thomas Zimmermann `<tzimmermann@suse.de>` (author)
- **Signed-off-by:** Helge Deller `<deller@gmx.de>` (fbdev maintainer)
- No `Fixes:`, `Reported-by:`, `Cc: stable@vger.kernel.org`, `Link:`,
  `Reviewed-by:`, `Tested-by:`, or `Acked-by:` tags

Notable: maintainer sign-off; absence of stable tag is expected for
manual review.

### Step 1.3: Body analysis
**Record:**
- **Bug described:** Only `FBIOPUT_VSCREENINFO` ioctl performs the full
  fbcon sequence (`fbcon_modechange_possible` → `fb_set_var` →
  `fbcon_update_vcs`). Sysfs mode-change paths and driver ioctl/reconfig
  paths skip the `fbcon_modechange_possible` check.
- **Symptom/failure mode:** Incomplete fbcon synchronization on mode
  changes; missing validation that resolution is not smaller than
  console font size.
- **Version info:** None in message.
- **Root cause:** Inconsistent fbcon handling across user-facing entry
  points after the ioctl-only fix from 2022.

### Step 1.4: Hidden bug fix detection
**Record:** Yes — despite refactor-style wording, this completes a real
correctness/safety gap. The original `fbcon_modechange_possible()`
commit (`e64242caef18b`, 2022) explicitly warned that undersized
resolutions cause character rendering to access memory outside the
graphics region. That check was ioctl-only; sysfs and driver paths
remained vulnerable.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Change inventory
**Record:**
| File | Change |
|------|--------|
| `fb_chrdev.c` | −5/+1 |
| `fbcon.c` | −2 (remove exports) |
| `fbmem.c` | +13 (new helper) |
| `fbsysfs.c` | −3/+1 |
| `ps3fb.c` | −4/+1 |
| `sh_mobile_lcdcfb.c` | −4/+1 |
| `include/linux/fb.h` | +2 |

**Functions modified:** `do_fb_ioctl()`, `activate()`,
`fb_set_var_from_user()` (new), `ps3fb_ioctl()`,
`sh_mobile_fb_reconfig()`
**Scope:** Small, multi-file but tightly focused consolidation.

### Step 2.2: Code flow per hunk
**Record:**
1. **`fb_chrdev.c` / `FBIOPUT_VSCREENINFO`:** Three-step inline sequence
   → single `fb_set_var_from_user()` call. Behavior unchanged.
2. **`fbmem.c`:** New helper encapsulates the three-step sequence.
3. **`fbsysfs.c` / `activate()`:** Before: `fb_set_var` +
   `fbcon_update_vcs` (no validation). After: `fb_set_var_from_user`
   (adds `fbcon_modechange_possible`).
4. **`ps3fb.c`:** Same — gains validation via helper; drops direct
   `fbcon.h` usage.
5. **`sh_mobile_lcdcfb.c`:** Before: `fb_set_var` then separate
   `fbcon_update_vcs`. After: single helper call with validation.
6. **`fbcon.c`:** Removes `EXPORT_SYMBOL` / `EXPORT_SYMBOL_GPL` from
   `fbcon_update_vcs` and `fbcon_modechange_possible`.

### Step 2.3: Bug mechanism
**Record:**
- **Category:** Memory safety / logic correctness (OOB access prevention
  + fbcon state consistency).
- **Mechanism:** `fbcon_modechange_possible()` rejects resolutions where
  font width/height exceeds effective `xres`/`yres` (with rotation).
  Sysfs (`store_mode`, `store_rotate`, `store_virtual`, `store_bpp` via
  `activate()`) and ps3fb/sh_mobile paths bypassed this check.
  Undersized modes could proceed to `fb_set_var` and fbcon rendering,
  risking out-of-bounds framebuffer access — the same failure mode
  documented in `e64242caef18b`.

### Step 2.4: Fix quality
**Record:**
- Fix is obviously correct: extracts ioctl’s already-proven three-step
  pattern.
- Minimal, no unrelated changes.
- **Regression risk:** Low for in-tree code. Removing exports of
  `fbcon_update_vcs` / `fbcon_modechange_possible` could affect out-of-
  tree GPL modules; in-tree users (`ps3fb`, `sh_mobile_lcdcfb`) are
  updated in the same patch. ps3fb/sh_mobile may now reject mode changes
  that previously succeeded but were unsafe — intentional behavior
  change.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:**
- `fb_chrdev.c:88-92`: Added in `588b35634a5aa` (Thomas Zimmermann,
  2023) with full three-step sequence.
- `fbsysfs.c:23-25`: `fb_set_var` since 2005; `fbcon_update_vcs` added
  in `d88ca7e1a27eb` (2020, syzbot OOB fix); never gained
  `fbcon_modechange_possible`.
- **Bug introduced:** Gap since `e64242caef18b` (Jun 2022) when
  validation was ioctl-only.

### Step 3.2: Fixes tag
**Record:** N/A — no `Fixes:` tag. Related fix `e64242caef18b` is in
this tree (`git merge-base --is-ancestor` confirms).

### Step 3.3: Related file history
**Record:**
- `e64242caef18b` — ioctl-only font-size validation (Cc: stable # v5.4+)
- `d88ca7e1a27eb` — syzbot OOB in `vc_do_resize`, pulled
  `fbcon_update_vcs` out of `fb_set_var`
- Recent stable-relevant fbcon fixes in tree: OOB/null-ptr fixes
  (`076b1aa65f77a`, `6617df8c24631`)
- **Standalone:** Patch 1/4 of “Internalize fbcon” series; does not
  require patches 2–4 to function.

### Step 3.4: Author context
**Record:** Thomas Zimmermann is active fbdev/fbcon maintainer. Helge
Deller (co-author of original `fbcon_modechange_possible`) signed off.

### Step 3.5: Dependencies
**Record:** No prerequisite commits required.
`fbcon_modechange_possible` and `fbcon_update_vcs` exist in tree. `git
apply --check` passes cleanly on 6.18.44.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:**
- **b4 dig URL:**
  https://patch.msgid.link/20260527151551.258659-2-tzimmermann@suse.de
- **Series revisions:** v1 (2026-05-20), v2 (2026-05-22), v3
  (2026-05-27) — committed version is v3.
- **WebFetch of lore:** Blocked by Anubis bot protection; could not read
  full thread.
- **From search snippets:** AI review noted ps3fb gains
  `fbcon_modechange_possible` check as intentional behavioral change.

### Step 4.2: Reviewers
**Record:** CC list includes Helge Deller, Geert Uytterhoeven, Simona
Vetter, airlied, linux-fbdev, dri-devel, linuxppc-dev — appropriate
subsystem coverage.

### Step 4.3: Bug reports
**Record:** No direct bug report in this commit. Underlying issue
matches `e64242caef18b` rationale (OOB framebuffer access). Related
syzbot fix `d88ca7e1a27eb` addressed a different fbcon/OOB path.

### Step 4.4: Series context
**Record:** Part of 4-patch “fbdev: Internalize fbcon” series. Patches
2–4 handle `fb_blank_from_user` and unexporting fbcon symbols more
broadly. This patch is self-contained for the `fb_set_var` path.

### Step 4.5: Stable list history
**Record:** UNVERIFIED — could not search lore stable list due to fetch
blocking. Original `e64242caef18b` was explicitly nominated `Cc:
stable@vger.kernel.org # v5.4+`.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `fb_set_var_from_user()` (new), `activate()`,
`do_fb_ioctl()`, `ps3fb_ioctl()`, `sh_mobile_fb_reconfig()`.

### Step 5.2: Callers
**Record:**
- `activate()` ← `store_mode`, `store_bpp`, `store_rotate`,
  `store_virtual` (sysfs, root-writable framebuffer attributes)
- `do_fb_ioctl()` ← `FBIOPUT_VSCREENINFO` (userspace ioctl on
  `/dev/fb*`)
- `ps3fb_ioctl()` ← `PS3FB_IOCTL_SETMODE` (PS3 platform)
- `sh_mobile_fb_reconfig()` ← `sh_mobile_lcdc_release()` on display
  hotplug/reconfig (SH Mobile embedded)

### Step 5.3: Callees
**Record:** `fbcon_modechange_possible()` → `fb_set_var()` →
`fbcon_update_vcs()`. Requires `console_lock()` + `lock_fb_info()` at
all call sites (already present).

### Step 5.4: Reachability
**Record:**
- Sysfs paths: reachable by privileged users (root) on any system with
  framebuffer sysfs nodes.
- Ioctl: reachable by users with framebuffer device access.
- ps3fb/sh_mobile: platform-specific but real hardware paths.
- **Userspace triggerable:** Yes (sysfs/ioctl, privileged).

### Step 5.5: Similar patterns
**Record:** ioctl path in `fb_chrdev.c` already had the correct three-
step pattern since 2022/2023. Sysfs and drivers were the inconsistent
outliers.

---

## PHASE 6: CROSS-REFERENCE AGAINST LOCAL TREE (6.18.44)

### Step 6.1: Buggy code present?
**Record:** **Yes.** Current tree at `fbsysfs.c:23-25` calls
`fb_set_var` + `fbcon_update_vcs` without `fbcon_modechange_possible`.
Same gap in `ps3fb.c:833-835` and `sh_mobile_lcdcfb.c:1768-1772`. Commit
`6f611e5` is **NOT** in HEAD.

### Step 6.2: Backport complications
**Record:** `git apply --check` on commit patch: **clean apply**. No
structural conflicts observed.

### Step 6.3: Related fixes already present?
**Record:** `e64242caef18b` (ioctl-only validation) is in tree. No
`fb_set_var_from_user` or equivalent consolidation. Gap remains open.

---

## PHASE 7: SUBSYSTEM CONTEXT

### Step 7.1: Subsystem criticality
**Record:** `drivers/video/fbdev` / `fbcon` — **IMPORTANT** (framebuffer
console on servers, embedded, legacy platforms; less universal than
mm/net but affects console stability).

### Step 7.2: Activity
**Record:** Actively maintained — recent fixes include UAF, null-ptr-
deref, and OOB fixes in fbdev/fbcon on this branch.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** Users of fbdev with active fbcon text console who change
modes via sysfs or affected drivers (not only ioctl). Embedded (SH
Mobile), PS3, and general framebuffer sysfs users.

### Step 8.2: Trigger conditions
**Record:** Set framebuffer mode/rotation/virtual resolution via sysfs
to a value smaller than current console font dimensions while fbcon is
active in text mode. Requires privileged access. Not everyday, but
realistic for admin tooling and embedded hotplug scenarios.

### Step 8.3: Failure mode severity
**Record:** Out-of-bounds framebuffer memory access during console
character rendering → potential kernel oops, memory corruption.
**Severity: HIGH** (same class as the 2022 ioctl fix that went to
stable).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** HIGH — closes a known validation gap left by incomplete
  application of `e64242caef18b`.
- **Risk:** LOW — ~37 lines, behavior matches existing ioctl path;
  applies cleanly.
- **Ratio:** Strong benefit, low risk.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Fixes real OOB/corruption-class bug (documented in `e64242caef18b`)
- Completes ioctl-only fix from 2022 across sysfs and driver paths
- Small, surgical, applies cleanly to 6.18.44
- Maintainer sign-off (Helge Deller)
- Same bug class previously deemed stable-worthy (`Cc: stable` on
  original)
- Privileged userspace can trigger via sysfs

**AGAINST backport:**
- Adds new exported helper `fb_set_var_from_user` (kernel-internal, not
  userspace API)
- Removes exports of `fbcon_update_vcs` / `fbcon_modechange_possible`
  (minor ABI concern for OOT modules)
- Part of larger “internalize fbcon” series (but functionally
  standalone)
- No syzbot/user bug report for this specific gap

**Unresolved:** Full lore review thread content (fetch blocked).

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — logic mirrors proven ioctl
   path; maintainer SOB.
2. Fixes real bug affecting users? **PASS** — sysfs/driver paths lack
   font-size validation.
3. Important issue? **PASS** — OOB memory access / potential crash or
   corruption (**HIGH**).
4. Small and contained? **PASS** — 7 files, ~37 lines net.
5. No new features/APIs? **PASS** (with nuance) — new kernel helper
   export only; no userspace API; behavior fix not feature addition.
6. Can apply to local tree? **PASS** — `git apply --check` succeeds.

### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build, or docs). Qualifies
as a correctness/memory-safety bug fix.

### Step 9.4: Problem summary for stable users
When the 2022 fix added `fbcon_modechange_possible()` to prevent console
font rendering past framebuffer bounds, it was wired only into the
`FBIOPUT_VSCREENINFO` ioctl. Sysfs mode/rotation/virtual-resolution
writes and ps3fb/sh_mobile driver paths still allowed undersized modes,
risking the same out-of-bounds access. This commit routes all user-
invoked `fb_set_var` paths through one helper that performs validation,
hardware update, and fbcon refresh — closing that gap on 6.18.y.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body; no Reported-by/syzbot/Fixes
  tags.
- **[Phase 1]** Identified hidden bug fix via cross-reference to
  `e64242caef18b` message.
- **[Phase 2]** Diff inventory: 7 files, functions listed; bug = missing
  `fbcon_modechange_possible` on non-ioctl paths.
- **[Phase 3]** `git describe HEAD` → `v6.18.44`; `make kernelversion` →
  `6.18.44`.
- **[Phase 3]** `git blame` on `fb_chrdev.c:86-92` and
  `fbsysfs.c:16-26`.
- **[Phase 3]** `git show e64242caef18b` — original OOB rationale and
  ioctl-only placement confirmed.
- **[Phase 3]** `git merge-base --is-ancestor e64242caef18b HEAD` → in
  tree.
- **[Phase 3]** `git merge-base --is-ancestor 6f611e5 HEAD` → NOT in
  tree.
- **[Phase 3]** `git log -S fbcon_modechange_possible` — introduced
  `e64242caef18b`, ioctl placement `588b35634a5aa`.
- **[Phase 4]** `b4 dig -c 6f611e5` → lore URL found; v1/v2/v3 revisions
  listed.
- **[Phase 4]** `b4 dig -w` → CC list with Deller, Geert, linux-fbdev,
  dri-devel.
- **[Phase 4]** WebFetch lore URL → blocked (Anubis); thread content
  UNVERIFIED.
- **[Phase 5]** `grep` callers: `activate()` used by `store_mode`,
  `store_bpp`, `store_rotate`, `store_virtual`.
- **[Phase 5]** `grep` for `fbcon_update_vcs` /
  `fbcon_modechange_possible` — only fbdev core + ps3fb + sh_mobile.
- **[Phase 6]** Read current `fbsysfs.c`, `fb_chrdev.c`, `ps3fb.c`,
  `sh_mobile_lcdcfb.c` — buggy pattern confirmed.
- **[Phase 6]** `git show 6f611e5 | git apply --check` → clean apply.
- **[Phase 6]** `grep fb_set_var_from_user` → not in tree.
- **[Phase 8]** Failure mode from `e64242caef18b`: OOB graphics memory
  access; severity HIGH.

**YES****Verdict for 6.18.44:** **YES** — backport this commit.

It closes a real gap left by the 2022 ioctl-only
`fbcon_modechange_possible()` fix: sysfs mode/rotation/virtual writes
and ps3fb/sh_mobile paths could still set resolutions smaller than the
console font, risking out-of-bounds framebuffer access. The patch is
small (~37 lines), applies cleanly, and mirrors the ioctl path’s
existing three-step sequence.

**Commit:** `6f611e5e5f3327cf2e2daabe6ee5acac58cc784e` (not yet in this
tree).

 drivers/video/fbdev/core/fb_chrdev.c   |  6 +-----
 drivers/video/fbdev/core/fbcon.c       |  2 --
 drivers/video/fbdev/core/fbmem.c       | 13 +++++++++++++
 drivers/video/fbdev/core/fbsysfs.c     |  4 +---
 drivers/video/fbdev/ps3fb.c            |  5 +----
 drivers/video/fbdev/sh_mobile_lcdcfb.c |  5 +----
 include/linux/fb.h                     |  2 ++
 7 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/video/fbdev/core/fb_chrdev.c b/drivers/video/fbdev/core/fb_chrdev.c
index 4ebd16b7e3b8d..54f926fb411bd 100644
--- a/drivers/video/fbdev/core/fb_chrdev.c
+++ b/drivers/video/fbdev/core/fb_chrdev.c
@@ -85,11 +85,7 @@ static long do_fb_ioctl(struct fb_info *info, unsigned int cmd,
 		var.activate &= ~FB_ACTIVATE_KD_TEXT;
 		console_lock();
 		lock_fb_info(info);
-		ret = fbcon_modechange_possible(info, &var);
-		if (!ret)
-			ret = fb_set_var(info, &var);
-		if (!ret)
-			fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
+		ret = fb_set_var_from_user(info, &var);
 		unlock_fb_info(info);
 		console_unlock();
 		if (!ret && copy_to_user(argp, &var, sizeof(var)))
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index df1ecbf3f5d02..35210f2bb7b2b 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2754,7 +2754,6 @@ void fbcon_update_vcs(struct fb_info *info, bool all)
 	else
 		fbcon_modechanged(info);
 }
-EXPORT_SYMBOL(fbcon_update_vcs);
 
 /* let fbcon check if it supports a new screen resolution */
 int fbcon_modechange_possible(struct fb_info *info, struct fb_var_screeninfo *var)
@@ -2782,7 +2781,6 @@ int fbcon_modechange_possible(struct fb_info *info, struct fb_var_screeninfo *va
 
 	return 0;
 }
-EXPORT_SYMBOL_GPL(fbcon_modechange_possible);
 
 int fbcon_mode_deleted(struct fb_info *info,
 		       struct fb_videomode *mode)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 30a2c0d47e5c8..1533d43a0a0c9 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -346,6 +346,19 @@ fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
 }
 EXPORT_SYMBOL(fb_set_var);
 
+int fb_set_var_from_user(struct fb_info *info, struct fb_var_screeninfo *var)
+{
+	int ret = fbcon_modechange_possible(info, var);
+
+	if (!ret)
+		ret = fb_set_var(info, var);
+	if (!ret)
+		fbcon_update_vcs(info, var->activate & FB_ACTIVATE_ALL);
+
+	return ret;
+}
+EXPORT_SYMBOL(fb_set_var_from_user);
+
 static void fb_lcd_notify_blank(struct fb_info *info)
 {
 	int power;
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index fe8bd33e64ab1..d363f94207c3e 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -20,9 +20,7 @@ static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
 	var->activate |= FB_ACTIVATE_FORCE;
 	console_lock();
 	lock_fb_info(fb_info);
-	err = fb_set_var(fb_info, var);
-	if (!err)
-		fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
+	err = fb_set_var_from_user(fb_info, var);
 	unlock_fb_info(fb_info);
 	console_unlock();
 	if (err)
diff --git a/drivers/video/fbdev/ps3fb.c b/drivers/video/fbdev/ps3fb.c
index dbcda307f6a67..1376d19b19aeb 100644
--- a/drivers/video/fbdev/ps3fb.c
+++ b/drivers/video/fbdev/ps3fb.c
@@ -29,7 +29,6 @@
 #include <linux/freezer.h>
 #include <linux/uaccess.h>
 #include <linux/fb.h>
-#include <linux/fbcon.h>
 #include <linux/init.h>
 
 #include <asm/cell-regs.h>
@@ -830,9 +829,7 @@ static int ps3fb_ioctl(struct fb_info *info, unsigned int cmd,
 				/* Force, in case only special bits changed */
 				var.activate |= FB_ACTIVATE_FORCE;
 				par->new_mode_id = val;
-				retval = fb_set_var(info, &var);
-				if (!retval)
-					fbcon_update_vcs(info, var.activate & FB_ACTIVATE_ALL);
+				retval = fb_set_var_from_user(info, &var);
 				console_unlock();
 			}
 			break;
diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index dd950e4ab5ceb..6038f217ab427 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -15,7 +15,6 @@
 #include <linux/ctype.h>
 #include <linux/dma-mapping.h>
 #include <linux/delay.h>
-#include <linux/fbcon.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <linux/ioctl.h>
@@ -1765,11 +1764,9 @@ static void sh_mobile_fb_reconfig(struct fb_info *info)
 	var.height = ch->display.height;
 	var.activate = FB_ACTIVATE_NOW;
 
-	if (fb_set_var(info, &var) < 0)
+	if (fb_set_var_from_user(info, &var) < 0)
 		/* Couldn't reconfigure, hopefully, can continue as before */
 		return;
-
-	fbcon_update_vcs(info, true);
 }
 
 /*
diff --git a/include/linux/fb.h b/include/linux/fb.h
index da2fdabd18cb3..f622f5f520cf0 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -541,6 +541,8 @@ extern int fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var);
 extern int fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var);
 extern int fb_blank(struct fb_info *info, int blank);
 
+int fb_set_var_from_user(struct fb_info *info, struct fb_var_screeninfo *var);
+
 /*
  * Helpers for framebuffers in I/O memory
  */
-- 
2.53.0

[PATCH AUTOSEL 6.18] ppc/fadump: invoke kmsg_dump in fadump panic path

[Sasha Levin]

From: Shivang Upadhyay <shivangu@linux.ibm.com>

[ Upstream commit 6ed8332639853b77329594a241eb99fc36d591a2 ]

fadump is registered in panic_notifier_list and gets triggered before
kmsg_dump_desc() in the panic path. As a result, kmsg_dumpers such as
pstore are not executed during fadump crashes.

This is problematic because pstore provides a critical fallback mechanism
for crash analysis. When fadump fails to successfully reboot the system
or capture a dump, pstore logs may be the only available information from
the crashed kernel. Without invoking kmsg_dump_desc() in the fadump path,
we lose this valuable diagnostic data.

Invoke kmsg_dump_desc() from the fadump panic handler, but only when
fadump is actually registered (checked via should_fadump_crash()). This
ensures kmsg_dumpers are called without duplicating the call that occurs
later in panic() when fadump is not active.

The call is placed before crash_fadump() to ensure logs are captured
before the system attempts to trigger the firmware-assisted dump.

Reported-by: Shirisha G <shirisha@linux.ibm.com>
Suggested-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Shivang Upadhyay <shivangu@linux.ibm.com>
Tested-by: Shirisha G <shirisha@linux.ibm.com>
Reviewed-by: Mahesh Salgaonkar <mahesh@linux.ibm.com>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260412113057.46090-1-shivangu@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `ppc/fadump: invoke kmsg_dump in fadump
panic path`

**Local tree:** Linux **6.18.44** (`git describe HEAD` → `v6.18.44`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[ppc/fadump]` `[invoke]` — Ensure `kmsg_dump` (e.g. pstore)
runs on the fadump panic path before firmware takes over.

### Step 1.2: Tags
**Record:**
| Tag | Value |
|-----|-------|
| Fixes: | *(none)* |
| Reported-by: | Shirisha G \<shirisha@linux.ibm.com\> |
| Suggested-by: | Sourabh Jain \<sourabhjain@linux.ibm.com\> |
| Tested-by: | Shirisha G \<shirisha@linux.ibm.com\> |
| Reviewed-by: | Mahesh Salgaonkar, Sourabh Jain (IBM fadump
maintainers) |
| Signed-off-by: | Shivang Upadhyay, Madhavan Srinivasan |
| Link: |
https://patch.msgid.link/20260412113057.46090-1-shivangu@linux.ibm.com |
| Cc: stable | *(none — expected for pipeline candidates)* |

**Notable:** IBM fadump subsystem reporters/reviewers; no syzbot; no NAK
indicators in message.

### Step 1.3: Body analysis
**Record:**
- **Bug:** `ppc_panic_fadump_handler` is registered on
  `panic_notifier_list` with `INT_MAX` priority and runs **before**
  `panic()` reaches `kmsg_dump_desc()`. When fadump triggers firmware-
  assisted dump (`rtas_os_term` / OPAL MPIPL reboot), execution
  typically never returns to `panic()`, so pstore and other kmsg dumpers
  never run.
- **Symptom:** On fadump-configured POWER systems, panic logs are not
  saved to pstore; if fadump also fails, administrators may have **no**
  kernel log from the crash.
- **Root cause:** Ordering gap between early fadump panic notifier and
  later `kmsg_dump_desc()` in `panic()`.
- **Fix approach:** Call `kmsg_dump_desc(KMSG_DUMP_PANIC, …)` in
  `ppc_panic_fadump_handler()` when `should_fadump_crash()` is true,
  **before** `crash_fadump()`.

### Step 1.4: Hidden bug fix?
**Record:** No — this is an explicit, well-described functional bug fix
(missing kmsg dump invocation), not disguised cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `arch/powerpc/kernel/setup-common.c` (+1 include, +7 lines
  in handler)
- **Functions:** `ppc_panic_fadump_handler()`
- **Scope:** Single-file, surgical (~10 lines)

### Step 2.2: Code flow change
**Record:**

| Hunk | Before | After |
|------|--------|-------|
| Include | No `kmsg_dump.h` | Adds `#include <linux/kmsg_dump.h>` |
| `ppc_panic_fadump_handler()` | `hard_irq_disable()` → `crash_fadump()`
| `hard_irq_disable()` → `kmsg_dump_desc()` (if fadump registered) →
`crash_fadump()` |

**Path affected:** Kernel panic on PowerPC with `CONFIG_FA_DUMP` and
fadump registered.

### Step 2.3: Bug mechanism
**Record:**
- **Category:** Logic / ordering bug on crash path (missing diagnostic
  dump invocation).
- **Mechanism:** Verified in `kernel/panic.c` —
  `atomic_notifier_call_chain(&panic_notifier_list, …)` at line 520 runs
  **before** `kmsg_dump_desc(KMSG_DUMP_PANIC, buf)` at line 524. Fadump
  notifier runs first (`INT_MAX` priority in `setup-common.c` line 780).
  `crash_fadump()` → `fadump_trigger()` calls `rtas_os_term()` (pseries)
  or `opal_cec_reboot2(OPAL_REBOOT_MPIPL)` (powernv), which
  terminate/reboot and normally do not return to `panic()`.

### Step 2.4: Fix quality
**Record:**
- **Obviously correct:** Yes — mirrors the existing system-reset path in
  `traps.c:474` (`kmsg_dump()` before `crash_fadump()`).
- **Minimal:** Yes.
- **Regression risk:** Very low. `should_fadump_crash()` guard avoids
  extra dump when fadump is inactive. If `fadump_trigger()` fails and
  returns (e.g. OPAL `OPAL_UNSUPPORTED`), `panic()` may call
  `kmsg_dump_desc()` again — redundant but harmless for pstore.
- **Uses `kmsg_dump_desc` with panic message pointer:** Better than bare
  `kmsg_dump()` — matches `panic()` behavior.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:**
- `ppc_panic_fadump_handler` / `crash_fadump()` call: **ab9dbf771ff9b6**
  (David Gibson, Dec 2017) — fadump panic notifier restored.
- Handler structure/priority: **e2aa34ce80a26** (Guilherme Piccoli, Apr
  2022) — split notifiers, fadump runs early with `INT_MAX` priority.
- Bug present since fadump panic notifier runs before `kmsg_dump_desc()`
  in `panic()` — long-standing on 6.18.y.

### Step 3.2: Fixes: tag
**Record:** N/A — no `Fixes:` tag. Related prior fix: **e7ca44ed3ba77**
(2019) fixed the **same pstore gap** on the **system reset** path in
`traps.c`, not the `panic()` notifier path.

### Step 3.3: Related file history
**Record:**
- `e7ca44ed3ba77` — "powerpc: dump kernel log before carrying out fadump
  or kdump" (traps.c system-reset path).
- `e2aa34ce80a26` — panic notifier refactor (made fadump run earliest).
- Standalone 1-patch fix; not part of a series.

### Step 3.4: Author context
**Record:** Shivang Upadhyay / IBM team; reviewed by Mahesh Salgaonkar
and Sourabh Jain (long-time fadump maintainers). Same subsystem as 2019
pstore/fadump fix.

### Step 3.5: Dependencies
**Record:** None. All symbols exist in this tree:
- `should_fadump_crash()` — `arch/powerpc/kernel/fadump.c:227`
- `kmsg_dump_desc()` — `kernel/printk/printk.c:4765`
- `linux/kmsg_dump.h` — present
- Applies standalone to 6.18.44.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1–4.5
**Record:**
- **b4 dig:** Could not run — patch commit not in local tree (`b4 dig
  -c` requires commitish).
- **WebFetch lore / patch.msgid.link:** Blocked by Anubis bot protection
  — could not read thread.
- **Commit message Link:** Present but content unverified externally.
- **Stable list search:** Not performed (lore blocked).
- **Inference from commit message only:** IBM-internal report; tested
  and reviewed by fadump maintainers. No evidence of NAKs in commit
  message.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `ppc_panic_fadump_handler()`, `should_fadump_crash()`,
`crash_fadump()`, `kmsg_dump_desc()`

### Step 5.2: Callers
**Record:**
- `ppc_panic_fadump_handler` — registered via `setup_panic()` →
  `atomic_notifier_chain_register(&panic_notifier_list,
  &ppc_fadump_block)` (line 795).
- Invoked from `panic()` → `atomic_notifier_call_chain()`
  (`kernel/panic.c:520`).
- **Context:** Panic path only; all CPUs eventually panic.

### Step 5.3: Callees
**Record:** `hard_irq_disable()`, `should_fadump_crash()`,
`kmsg_dump_desc()` → iterates registered dumpers (pstore, etc.),
`crash_fadump()` → `fadump_trigger()` → firmware reboot.

### Step 5.4: Reachability
**Record:**
- Triggered on any kernel panic when fadump is registered
  (`fw_dump.dump_registered` and `fw_dump.fadumphdr_addr` set).
- Common on IBM POWER LPARs / PowerNV with fadump enabled.
- Not userspace-triggerable directly, but panics are the exact scenario
  this code handles.

### Step 5.5: Similar patterns
**Record:** `arch/powerpc/kernel/traps.c:474` already does
`kmsg_dump(KMSG_DUMP_OOPS)` before `crash_fadump()` on system-reset dump
path — this patch closes the analogous gap on the **panic notifier**
path.

---

## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE (6.18.44)

### Step 6.1: Buggy code exists?
**Record:** **YES.** Current `setup-common.c:738-751` has no
`kmsg_dump_desc()` call. Fix is **not** present in v6.18.44.

### Step 6.2: Backport complications
**Record:** **Clean apply expected** — single hunk, no structural
conflicts; file unchanged for fadump handler since 2022 refactor.

### Step 6.3: Related fixes already present?
**Record:** System-reset path fix (e7ca44ed3ba77) is present in
`traps.c`. Panic-notifier path fix is **missing** — this commit fills
that gap.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
**Record:** `arch/powerpc` / fadump crash dump — **IMPORTANT** for IBM
POWER enterprise; **PERIPHERAL** globally (architecture- and config-
specific: `CONFIG_FA_DUMP`).

### Step 7.2: Activity
**Record:** Fadump actively maintained in 6.18.y (recent commits: param
area, CMA init, hugetlb interaction, etc.).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** IBM POWER (pseries/PowerNV) systems with firmware-assisted
dump enabled and pstore (or other kmsg dumpers) configured.

### Step 8.2: Trigger conditions
**Record:** Kernel panic while fadump is registered. Common crash
scenario on servers using fadump. Not unprivileged attack vector; crash-
path diagnostic issue.

### Step 8.3: Failure mode severity
**Record:** **MEDIUM-HIGH** for affected users — loss of pstore panic
logs when fadump takes over or fails; no normal-runtime impact.
Operationally critical when fadump is the primary dump mechanism and
fails (exact scenario described in commit and in e7ca44ed3ba77).

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Restores last-resort crash diagnostics (pstore) on fadump
  panic path; same rationale as 2019 stable-class fix.
- **Risk:** Very low — ~10 lines, guarded by `should_fadump_crash()`,
  tested by IBM.
- **Ratio:** Strong benefit for POWER/fadump users; negligible risk.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real, verifiable ordering bug in panic path
- Buggy code present in 6.18.44; fix not yet applied
- Small, self-contained, reviewed/tested by fadump maintainers
- Direct precedent: e7ca44ed3ba77 fixed same pstore gap on system-reset
  path
- Important for IBM POWER crash diagnostics when fadump is active

**AGAINST backport:**
- Platform/config specific (not all stable users)
- Fixes diagnostic data loss, not runtime crash/corruption/deadlock
- Mailing list discussion unverified (lore blocked)

**Unresolved:** Full lore thread content; whether reviewers explicitly
nominated for stable.

### Step 9.2: Stable rules checklist

| Criterion | Result |
|-----------|--------|
| 1. Obviously correct and tested? | **PASS** — clear ordering fix;
Tested-by + Reviewed-by IBM maintainers |
| 2. Fixes real bug affecting users? | **PASS** — pstore not invoked on
fadump panic path |
| 3. Important issue? | **PASS (borderline)** — crash-path diagnostic
loss on enterprise POWER; fallback when fadump fails |
| 4. Small and contained? | **PASS** — ~10 lines, one file |
| 5. No new features/APIs? | **PASS** — invokes existing kmsg_dump
infrastructure |
| 6. Applies to local tree? | **PASS** — all prerequisites present;
clean apply |

### Step 9.3: Exception categories
**Record:** None (not device ID, quirk, DT, build, or docs). Standard
bug fix.

### Step 9.4: Decision rationale
On **6.18.44**, fadump’s early panic notifier prevents `panic()` from
ever reaching `kmsg_dump_desc()`, leaving pstore empty when firmware
takes over — precisely when those logs are most needed as a fallback.
The fix is minimal, matches an established pattern already used on the
system-reset path, and is low risk. Diagnostic loss on the crash path
for a supported enterprise platform meets stable backport criteria under
the “important issue” umbrella, especially given prior acceptance of the
same class of fix in 2019.

---

## Verification

- **[Phase 1]** Parsed commit message tags and body from user-provided
  content
- **[Phase 2]** Read diff; verified `panic()` ordering in
  `kernel/panic.c:520-524`
- **[Phase 2]** Read `ppc_panic_fadump_handler` at `setup-
  common.c:738-780`; confirmed no `kmsg_dump_desc` call
- **[Phase 2]** Read `crash_fadump()` and `fadump_trigger`
  implementations (`fadump.c`, `rtas-fadump.c:555-559`, `opal-
  fadump.c:581-600`)
- **[Phase 2]** Read `kmsg_dump_desc()` in
  `kernel/printk/printk.c:4765-4788`
- **[Phase 3]** `git describe HEAD` → v6.18.44; Makefile VERSION 6.18.44
- **[Phase 3]** `git blame` on handler lines → ab9dbf771ff9b6 (2017),
  e2aa34ce80a26 (2022)
- **[Phase 3]** `git show e2aa34ce80a26` — fadump notifier INT_MAX
  priority
- **[Phase 3]** `git show e7ca44ed3ba77` — prior pstore/fadump fix on
  system-reset path
- **[Phase 3]** `git log --oneline -20 -- arch/powerpc/kernel/setup-
  common.c`
- **[Phase 4]** `b4 dig -c` — failed (no commit in tree)
- **[Phase 4]** WebFetch lore.kernel.org and patch.msgid.link — blocked
  (Anubis)
- **[Phase 5]** Grep callers: `setup_panic()` registers notifier;
  `panic()` invokes chain
- **[Phase 5]** Verified `traps.c:474` kmsg_dump before crash_fadump on
  system-reset path
- **[Phase 6]** Confirmed buggy code present; fix absent in v6.18.44
- **[Phase 6]** Verified `should_fadump_crash()`, `kmsg_dump_desc`,
  `linux/kmsg_dump.h` exist
- **UNVERIFIED:** Lore thread review comments and explicit stable
  nominations

**YES**

 arch/powerpc/kernel/setup-common.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 68d47c53876c6..28186f9ec8da0 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -68,6 +68,7 @@
 #include <asm/kasan.h>
 #include <asm/mce.h>
 #include <asm/systemcfg.h>
+#include <linux/kmsg_dump.h>
 
 #include "setup.h"
 
@@ -744,6 +745,13 @@ static int ppc_panic_fadump_handler(struct notifier_block *this,
 	 */
 	hard_irq_disable();
 
+	/*
+	 * Invoke kmsg_dump (e.g., pstore) before crash_fadump() as fadump
+	 * runs before panic()'s kmsg_dump_desc() call.
+	 */
+	if (should_fadump_crash())
+		kmsg_dump_desc(KMSG_DUMP_PANIC, (char *)ptr);
+
 	/*
 	 * If firmware-assisted dump has been registered then trigger
 	 * its callback and let the firmware handles everything else.
-- 
2.53.0