[PATCH AUTOSEL 6.18-6.12] spi: nxp-fspi: disable runtime PM on probe failures

[PATCH AUTOSEL 6.18-6.12] spi: nxp-fspi: disable runtime PM on probe failures

[Sasha Levin]

From: Jiawen Liu <1298662399@qq.com>

[ Upstream commit 5d14285d60ba95561609a293064654a0c7d7d928 ]

nxp_fspi_probe() enables runtime PM and autosuspend before
several operations that can fail.

Some failure paths returned directly before the devm cleanup
action was installed, leaving runtime PM enabled.

Route those failures through a common runtime PM cleanup path.
Use pm_runtime_resume_and_get() for the initial clock enable.

Signed-off-by: Jiawen Liu <1298662399@qq.com>
Link: https://patch.msgid.link/tencent_8FC0B8DFAF4AE67AEBA20548045D53A77707@qq.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have enough to decide: the leak is in this 6.18 tree, the fix is small
and self-contained, and it does not depend on later rework.

## Phase 1: Commit message forensics

**Step 1.1: Subject line**
Record: **[spi: nxp-fspi]** **[disable]** disable runtime PM on probe
failures. Action is a cleanup of leftover runtime PM after
`nxp_fspi_probe()` fails.

**Step 1.2: Tags**
Record:
- `Signed-off-by: Jiawen Liu <1298662399@qq.com>` (author)
- `Link: https://patch.msgid.link/tencent_8FC0B8DFAF4AE67AEBA20548045D53
  A77707@qq.com`
- `Signed-off-by: Mark Brown <broonie@kernel.org>` (SPI maintainer
  applied it)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
  by:`, or `Cc: stable` (absence is expected)
- Pipeline `Signed-off-by: Sasha Levin` / `[Upstream commit
  5d14285d60ba...]` ignored as candidate-prep markers

**Step 1.3: Body**
Record:
- **Bug:** `nxp_fspi_probe()` calls `pm_runtime_enable()` + autosuspend,
  then can fail before `devm_add_action_or_reset(..., nxp_fspi_cleanup,
  ...)`.
- **Symptom:** runtime PM left enabled after a failed probe; no
  `nxp_fspi_cleanup()` to disable it.
- **Root cause:** early `return` on clock get/put, IRQ request, and
  mutex init.
- **Fix:** common `err_disable_pm` path; switch initial get to
  `pm_runtime_resume_and_get()`.
- **Version info in message:** none.

**Step 1.4: Hidden bug fix?**
Record: Not hidden. This is an explicit probe error-path resource-leak
fix.

## Phase 2: Diff analysis

**Step 2.1: Inventory**
Record:
- File: `drivers/spi/spi-nxp-fspi.c` (+22 / −9)
- Function: `nxp_fspi_probe()` only
- Scope: single-file surgical error-path fix

**Step 2.2: Code flow**
Record (verified against parent of `03a9171de3f13`):

Before:
1. `pm_runtime_enable` / `use_autosuspend`
2. `pm_runtime_get_sync()` — on error, **return** (RPM stays enabled;
   usage count stays incremented because `get_sync` increments even on
   failure)
3. `pm_runtime_put_sync()` — on error, **return** (RPM stays enabled)
4. `devm_request_irq()` — on error, **return**
5. `devm_mutex_init()` — on error, **return**
6. Only later `devm_add_action_or_reset(..., nxp_fspi_cleanup)` disables
   RPM

After: those four failures `goto err_disable_pm`, which does
`pm_runtime_dont_use_autosuspend()` + `pm_runtime_disable()`. Initial
get uses `pm_runtime_resume_and_get()` so a failed resume does **not**
leave the usage count up.

`devm_add_action_or_reset` failure still returns directly: on add
failure that helper already runs `nxp_fspi_cleanup()`, which disables
RPM. That path is correct as-is.

**Step 2.3: Bug mechanism**
Record: **Error-path resource leak** (runtime PM left enabled; usage-
count leak on failed `get_sync`). Also a small **correctness** change:
`get_sync` → `resume_and_get`, matching the kernel header guidance that
`get_sync` leaves the counter incremented on error.

**Step 2.4: Fix quality**
Record: Obviously correct and minimal. Regression risk is low: only
probe-failure paths plus the get API swap. Remaining gaps (unchecked
`nxp_fspi_default_setup()`, unchecked get in `nxp_fspi_cleanup()`) are
pre-existing and not introduced here.

## Phase 3: Git history

**Step 3.1: Blame**
Record: The buggy `pm_runtime_enable` / `get_sync` / early returns come
from `97be4b919a609` ("spi: spi-nxp-fspi: enable runtime pm for fspi",
Haibo Chen, 2025-04-28). Present in v6.16 and in this tree. Cleanup
action is `9f7cd1bcb6363` ("use devm instead of remove"), also in this
tree.

**Step 3.2: Fixes: tag**
Record: No `Fixes:` tag. Introducer is `97be4b919a609` (verified via
blame). `git merge-base --is-ancestor 97be4b919a609 v6.18` succeeds.

**Step 3.3: File history**
Record: Recent work is SoC clock/DTR features, not RPM probe cleanup. No
later commit on this file after the candidate. Standalone vs this file.

**Step 3.4: Author**
Record: Jiawen Liu submitted a 4-patch SPI PM error-path series
(atcspi200, bcmbca-hsspi, fsl-dspi, nxp-fspi). Not the driver
maintainer; NXP people (Han Xu, Haibo Chen) maintain this driver. Mark
Brown applied the series.

**Step 3.5: Dependencies**
Record: Cover letter says the four patches are independent. This hunk
only needs `pm_runtime_enable`/`use_autosuspend` (present) and
`pm_runtime_resume_and_get()` (present in `include/linux/pm_runtime.h`).
Can apply standalone. Applies cleanly to this tree’s probe function.

## Phase 4: Mailing list

**Step 4.1: Original discussion**
Record:
- `b4 dig -c 5d14285d60ba95561609a293064654a0c7d7d928` → https://patch.m
  sgid.link/tencent_8FC0B8DFAF4AE67AEBA20548045D53A77707@qq.com
- Series: `[PATCH 0/4] spi: fix PM error handling in several drivers`
  (2026-06-20), **v1 only** for this commit
- Cover letter: patches are independent; local error paths only
- Frank Li: style comment only — use `PM_RUNTIME_ACQUIRE` instead of
  `goto` (not a NAK of the leak fix)
- Mark Brown applied the series to `for-7.3` as-is, including `[4/4]` as
  `5d14285d60ba`
- sashiko-bot: this patch still leaves clocks on if `put_sync` fails;
  also flagged pre-existing `default_setup` / cleanup get issues. Those
  did **not** block merge.

**Step 4.2: Recipients (`b4 dig -w`)**
Record: Mark Brown, linux-spi, Han Xu, Haibo Chen, Yogesh Gaur,
imx@lists.linux.dev, linux-arm-kernel. Right maintainers were on Cc.

**Step 4.3: Bug report**
Record: No user/syzbot report. Found by code review of probe error
paths.

**Step 4.4: Related series**
Record: Later `[PATCH v2 0/3] spi: nxp-fspi: fix runtime PM error
handling` (2026-07-28) *reworks* this fix with
`devm_pm_runtime_enable()` / `PM_RUNTIME_ACQUIRE_AUTOSUSPEND()`, plus
`default_setup` and cleanup checks. That follow-up is **not** in this
tree (`rg` found no `devm_pm_runtime_enable` in the driver). Haibo Chen
rejected `PM_RUNTIME_ACQUIRE` in cleanup. The later series is extra
hardening/style, not a revert of this leak fix.

**Step 4.5: Stable list**
Record: lore.kernel.org search returned 403; no stable-thread evidence
obtained. UNVERIFIED whether anyone nominated this on stable@
separately.

## Phase 5: Semantic analysis

**Step 5.1: Functions**
Record: `nxp_fspi_probe()` only.

**Step 5.2: Callers**
Record: Platform `.probe = nxp_fspi_probe` in this file. Runs at device
bind / deferred probe, not from a syscall hot path.

**Step 5.3: Callees**
Record: `pm_runtime_resume_and_get`, `pm_runtime_put_sync`,
`devm_request_irq`, `devm_mutex_init`,
`pm_runtime_dont_use_autosuspend`, `pm_runtime_disable`. Runtime resume
enables clocks via `nxp_fspi_clk_prep_enable()`.

**Step 5.4: Reachability**
Record: Yes, from device probe on `CONFIG_SPI_NXP_FLEXSPI`
(i.MX8/i.MX9/Layerscape FlexSPI). Trigger is a **failed** probe after
RPM enable (clock resume fail, put fail, IRQ request fail, mutex init
fail). Not unprivileged userspace on a working board.

**Step 5.5: Similar patterns**
Record: Same author fixed other SPI PM error paths. `spi-rockchip.c`
already has `err_disable_pm_runtime`. This is a known driver pattern.

## Phase 6: Local tree (this checkout)

**Step 6.1: Does the bug exist here?**
Record:
- Tree: `v6.18.53-5049-g0f0bdc2b0dffb`, `Makefile` 6.18.53, branch
  `autosel`
- Buggy sequence exists in `03a9171de3f13^` (`pm_runtime_get_sync` +
  early returns after `pm_runtime_enable`)
- Introduced by `97be4b919a609`, ancestor of v6.18
- Driver file and RPM enablement are present

**Step 6.2: Backport difficulty**
Record: **Clean apply**. Context matches this tree (`device_set_node`
and DTR caps are already here). `pm_runtime_resume_and_get()` exists.

**Step 6.3: Related fixes already here?**
Record: No other probe RPM-disable fix. Later v2 rework is not present.
`nxp_fspi_cleanup()` still disables RPM only after successful
`devm_add_action_or_reset`.

## Phase 7: Subsystem context

**Step 7.1:** `drivers/spi/` — NXP FlexSPI (`CONFIG_SPI_NXP_FLEXSPI`).
Criticality: **IMPORTANT** for i.MX/Layerscape boards (often the
boot/SPI-NOR controller), **PERIPHERAL** for everyone else.

**Step 7.2:** Actively maintained (clock/DTR/DLL work through
2025–2026). RPM itself is from 6.16-era, so the leak has been in 6.18
for the life of this driver feature.

## Phase 8: Impact and risk

**Step 8.1: Who is affected**
Record: Users of NXP FlexSPI (`nxp,imx8mm-fspi`, `imx8mp`, `imx8ulp`,
`imx93`, `imx95`, `lx2160a-fspi`, etc.) when probe fails after RPM is
enabled.

**Step 8.2: Trigger**
Record: Failed probe after `pm_runtime_enable()`. Not every boot. Clock
resume failure is the important case: old `get_sync` leaves `usage_count
> 0` and RPM enabled, so a later bind hits `pm_runtime_enable()` on an
already-enabled device (WARN). IRQ/mutex failures after a successful put
leave RPM enabled on an unbound device.

Cannot be triggered by an unprivileged user on a healthy probe path.

**Step 8.3: Failure mode**
Record:
- Runtime PM enabled after failed bind
- Failed `get_sync`: usage-count leak, device stuck “active”
- Re-probe: `pm_runtime_enable()` WARN
- Autosuspend still armed if put succeeded before a later failure

Severity: **MEDIUM** (probe error path, not a success-path
crash/corruption). Still a real leak/WARN class that stable regularly
takes.

**Step 8.4: Risk-benefit**
Record:
- **Benefit:** Medium for i.MX/Layerscape; stops leftover RPM state and
  usage-count leak on failed probe.
- **Risk:** Low (~20 lines, error path only, recommended PM helper).
- Ratio supports backport.

## Phase 9: Synthesis

**Step 9.1: Evidence**

FOR:
- Real probe error-path leak: RPM enabled before `nxp_fspi_cleanup` is
  installed
- `pm_runtime_get_sync()` on failure leaks the usage count;
  `resume_and_get` + disable is the right fix
- Small, obviously correct, no new API
- Bug present since RPM was added (`97be4b919a609`), which is in this
  6.18 tree
- SPI maintainer applied it; cover letter says the series is independent
- Driver is used on common NXP boards

AGAINST:
- No crash/syzbot/user report; probe-failure only
- Incomplete vs later review (ignored `nxp_fspi_default_setup()`,
  cleanup get)
- Frank Li preferred helpers over `goto` (style; not a functional NAK)

UNRESOLVED:
- Could not fetch lore.kernel.org (403); discussion recovered via `b4
  dig -m` and lkml.iu.edu
- No stable@ thread found

**Step 9.2: Stable rules**
1. Obviously correct and tested? **PASS** — maintainer applied; logic
   matches PM docs
2. Real user-visible bug? **PASS** — leftover RPM / usage-count leak /
   re-probe WARN
3. Important? **PASS** — resource leak that can WARN and leave PM state
   wrong; not a success-path panic, but standard driver-core leak
4. Small and contained? **PASS** — one function, +22/−9
5. No new features/APIs? **PASS**
6. Applies to this tree? **PASS** — buggy code and helpers are here

**Step 9.3: Exception category**
Record: Not a device-ID/quirk/DT/build/docs exception. Ordinary error-
path leak fix.

**Step 9.4: Decision**
This 6.18 tree has the leak. The patch is a small, correct disable of
runtime PM on probe failures, with the right `resume_and_get` pairing.
Later optional rework is not a reason to skip this.

### What it solves for stable users
On NXP FlexSPI, probe currently enables runtime PM, then can return on
clock/IRQ/mutex failure before the devm cleanup action. That leaves RPM
enabled (and, with `get_sync`, an elevated usage count). A later bind
can WARN. The patch disables RPM on those paths.

### Risk vs benefit
Low risk, clear benefit on a widely used embedded SPI-NOR controller. No
prerequisites beyond code already in 6.18.

---

Verification:
- [Phase 1] Parsed tags: author Jiawen Liu, Link msgid, SOB Mark Brown;
  no Fixes/Reported-by/Cc stable
- [Phase 2] Diff: `nxp_fspi_probe()` +22/−9; four early returns →
  `err_disable_pm`; `get_sync` → `resume_and_get`
- [Phase 2] Confirmed `pm_runtime_get_sync` increments usage even on
  error (`include/linux/pm_runtime.h`); `resume_and_get` does not
- [Phase 3] `git describe HEAD` / `make kernelversion`: **6.18.53**,
  branch `autosel`
- [Phase 3] `git blame` on parent: leak from `97be4b919a609`
  (2025-04-28)
- [Phase 3] `git merge-base --is-ancestor 97be4b919a609 v6.18`: yes
  (also in v6.16)
- [Phase 3] Parent probe still has `get_sync` + bare returns after
  `pm_runtime_enable`
- [Phase 4] `b4 dig -c 5d14285d60ba`: PATCH 4/4, lore msgid above
- [Phase 4] `b4 dig -a`: v1 only for this commit
- [Phase 4] `b4 dig -w`: Mark Brown, Han Xu, Haibo Chen, linux-spi, imx
  list
- [Phase 4] mbox: Frank Li style comment; Mark Brown applied 4/4 to
  for-7.3; cover letter says independent
- [Phase 4] Later v2 rework (Jul 2026) not in this tree
- [Phase 5] Probe is platform `.probe`; Kconfig `SPI_NXP_FLEXSPI` for
  i.MX/Layerscape
- [Phase 6] `pm_runtime_resume_and_get` exists; patch context matches
  local probe
- [Phase 8] Failure mode: RPM leak / usage-count leak / re-probe WARN,
  not a hot-path oops
- UNVERIFIED: lore.kernel.org HTTP 403; no dedicated stable@ discussion
  found

**YES**

 drivers/spi/spi-nxp-fspi.c | 31 ++++++++++++++++++++++---------
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/drivers/spi/spi-nxp-fspi.c b/drivers/spi/spi-nxp-fspi.c
index b504a5c86692a..0300f4ae1455d 100644
--- a/drivers/spi/spi-nxp-fspi.c
+++ b/drivers/spi/spi-nxp-fspi.c
@@ -1426,9 +1426,11 @@ static int nxp_fspi_probe(struct platform_device *pdev)
 	pm_runtime_use_autosuspend(dev);
 
 	/* enable clock */
-	ret = pm_runtime_get_sync(f->dev);
-	if (ret < 0)
-		return dev_err_probe(dev, ret, "Failed to enable clock");
+	ret = pm_runtime_resume_and_get(f->dev);
+	if (ret < 0) {
+		ret = dev_err_probe(dev, ret, "Failed to enable clock");
+		goto err_disable_pm;
+	}
 
 	/* Clear potential interrupts */
 	reg = fspi_readl(f, f->iobase + FSPI_INTR);
@@ -1438,18 +1440,24 @@ static int nxp_fspi_probe(struct platform_device *pdev)
 	nxp_fspi_default_setup(f);
 
 	ret = pm_runtime_put_sync(dev);
-	if (ret < 0)
-		return dev_err_probe(dev, ret, "Failed to disable clock");
+	if (ret < 0) {
+		ret = dev_err_probe(dev, ret, "Failed to disable clock");
+		goto err_disable_pm;
+	}
 
 	init_completion(&f->c);
 	ret = devm_request_irq(dev, irq,
 			nxp_fspi_irq_handler, 0, pdev->name, f);
-	if (ret)
-		return dev_err_probe(dev, ret, "Failed to request irq\n");
+	if (ret) {
+		ret = dev_err_probe(dev, ret, "Failed to request irq\n");
+		goto err_disable_pm;
+	}
 
 	ret = devm_mutex_init(dev, &f->lock);
-	if (ret)
-		return dev_err_probe(dev, ret, "Failed to initialize lock\n");
+	if (ret) {
+		ret = dev_err_probe(dev, ret, "Failed to initialize lock\n");
+		goto err_disable_pm;
+	}
 
 	ctlr->bus_num = -1;
 	ctlr->num_chipselect = NXP_FSPI_MAX_CHIPSELECT;
@@ -1467,6 +1475,11 @@ static int nxp_fspi_probe(struct platform_device *pdev)
 		return ret;
 
 	return devm_spi_register_controller(&pdev->dev, ctlr);
+
+err_disable_pm:
+	pm_runtime_dont_use_autosuspend(dev);
+	pm_runtime_disable(dev);
+	return ret;
 }
 
 static int nxp_fspi_runtime_suspend(struct device *dev)
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] clk: imx: imx8qxp: add missing MODULE_DEVICE_TABLE()

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit cd21fdcbef3fb32136f72075ab668b075423b3f6 ]

The driver has a match table for the of bus wired into its driver
structure, but the table is not exported with MODULE_DEVICE_TABLE().

Add the missing MODULE_DEVICE_TABLE() entry so module alias information
is generated for automatic module loading.

This is a source-level fix.  It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the driver registration structure, and the missing module alias
publication.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://patch.msgid.link/20260705001705.70400-1-pengpeng@iscas.ac.cn
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit message forensics

**Step 1.1 — Subject**
Record: **[clk/imx]** **[add]** missing `MODULE_DEVICE_TABLE()` so the
i.MX8QXP SCU clock driver’s OF match table is exported as module
aliases.

**Step 1.2 — Tags**
Record:
- `Reviewed-by: Brian Masney <bmasney@redhat.com>`
- `Link:
  https://patch.msgid.link/20260705001705.70400-1-pengpeng@iscas.ac.cn`
- `Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>` (author)
- `Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>` (clk/imx
  maintainer)
- No `Fixes:`, `Reported-by:`, `Tested-by:`, `Acked-by:`, or `Cc:
  stable` (absence of the last two is expected for this review)

**Step 1.3 — Body**
Record: The driver already has `imx8qxp_match[]` wired as
`of_match_table`, but it never called `MODULE_DEVICE_TABLE(of, …)`.
Without that, modpost/`file2alias` does not emit `of:N*T*C…` aliases, so
udev/`modprobe`/initramfs tools cannot autoload `clk-imx-scu` from DT
compatible strings. Failure mode: modular `CONFIG_CLK_IMX8QXP=m` does
not bind on `fsl,scu-clk` / `fsl,imx8qxp-clk` / `fsl,imx8qm-clk` /
`fsl,imx8dxl-clk`. The author presents this as a source-level
correctness fix, not a live hardware repro. No version range is given.

**Step 1.4 — Hidden bug fix?**
Record: Not disguised. It is an explicit completeness fix for module
alias publication. That is a real functional bug for `=m` builds, not
style cleanup.

---

## Phase 2: Diff analysis

**Step 2.1 — Inventory**
Record: One file, `drivers/clk/imx/clk-imx8qxp.c`, **+1 / -0**. One
insertion after `imx8qxp_match[]`. Surgical single-file change.

**Step 2.2 — Code flow**
Record: **Before:** `imx8qxp_match[]` is only referenced by
`imx8qxp_clk_driver.driver.of_match_table` (bind-time matching if the
module is already loaded). **After:** the same table is also aliased for
modpost (`__mod_device_table__kmod_*__of__imx8qxp_match`), which
produces OF module aliases. No probe, init, or error-path logic changes.

**Step 2.3 — Bug mechanism**
Record: **Hardware/module-autoload omission** (same class as missing
device IDs). The OF table existed; aliases were not published.
`MODULE_DEVICE_TABLE` is the required export so
`scripts/mod/file2alias.c` `do_of_entry()` can emit aliases.

**Step 2.4 — Fix quality**
Record: Obviously correct: same pattern as `clk-imx8mm.c`
(`MODULE_DEVICE_TABLE(of, imx8mm_clk_of_match)`) and the sibling LPCG
driver. Minimal, no API/data-structure change. Regression risk is
essentially none: for `=y` the extra alias symbol is unused at runtime;
for `=m` it only adds `modules.alias` entries.

---

## Phase 3: Git history

**Step 3.1 — Blame**
Record: Match table introduced in `c2cccb6d0b33b` (2018, original
driver). Modular build introduced in `e0d0d4d86c766` (“Support building
i.MX8QXP clock driver as module”, 2020-08-22, first in **v5.9**). That
is when `MODULE_DEVICE_TABLE` became necessary and was omitted. Bug is
long-standing, not recent.

**Step 3.2 — Fixes: tag**
Record: None. The introducing commit is `e0d0d4d86c766`; it is an
ancestor of this HEAD.

**Step 3.3 — File history**
Record: Immediate neighbor `e89485455ac49` (`clk: imx: imx8qxp-lpcg: add
missing MODULE_DEVICE_TABLE()`) is the same author/pattern on the LPCG
sibling. Independent 1-line fix; this patch does not depend on it. Other
recent file history (`aadb7d1f2ca0f` softdep on `scu_pd`) is unrelated.

**Step 3.4 — Author**
Record: Pengpeng Hou submitted a cluster of clk `MODULE_DEVICE_TABLE`
additions (imx8qxp, imx8qxp-lpcg, mediatek mt6735). Not the clk/imx
maintainer. Maintainer Abel Vesa applied it; Brian Masney reviewed.

**Step 3.5 — Dependencies**
Record: None. Needs only `imx8qxp_match[]` and `MODULE_DEVICE_TABLE`
from `<linux/module.h>`, both present. Standalone.

---

## Phase 4: Mailing list / external research

**Step 4.1 — Original discussion**
Record: `b4 dig -c cd21fdcbef3fb` →
https://patch.msgid.link/20260705001705.70400-1-pengpeng@iscas.ac.cn
`b4 dig -a`: single **v1**, no later revisions.
Thread (gnuweeb mirror; lore.kernel.org returned 403): Brian Masney
`Reviewed-by`; Abel Vesa “Applied, thanks!” as `cd21fdcbef3fb`. No NAK,
no stable nomination, no risk flags.

**Step 4.2 — Recipients (`b4 dig -w`)**
Record: Abel Vesa, Peng Fan, Stephen Boyd, Michael Turquette, Frank Li,
Sascha Hauer, Fabio Estevam, linux-clk, imx@lists.linux.dev, linux-arm-
kernel. Correct maintainers and lists.

**Step 4.3 — Bug report**
Record: No `Reported-by` / syzbot / bugzilla. Evidence is the match
table vs missing export. Pull text for clk-imx 7.3 lists “Add missing
MODULE_DEVICE_TABLE() declarations for i.MX8QXP clock drivers.”

**Step 4.4 — Series**
Record: Standalone `[PATCH]`, not `N/M`. Sibling LPCG patch is parallel
and not a prerequisite.

**Step 4.5 — Stable list**
Record: gnuweeb `/stable/?q=imx8qxp+MODULE_DEVICE_TABLE` did not show a
dedicated discussion of this patch (hits were unrelated imx8 noise).
lore.kernel.org/stable returned 403.

---

## Phase 5: Code semantics

**Step 5.1 — Functions**
Record: No function body changed. Data: `imx8qxp_match[]`. Related:
`imx8qxp_clk_driver`, `imx8qxp_clk_init()`, `imx8qxp_clk_probe()`.

**Step 5.2 — Callers**
Record: `imx8qxp_clk_init()` (`module_init`) →
`platform_driver_register(&imx8qxp_clk_driver)`. Probe runs when OF
compatible matches. Autoload is what was broken: without aliases the
module may never load, so probe never runs.

**Step 5.3 — Callees**
Record: Probe calls `imx_clk_scu_init()`, many
`imx_clk_scu`/`imx_clk_scu2`, `of_clk_add_hw_provider()`. Unchanged.

**Step 5.4 — Reachability**
Record: Userspace-reachable only in the sense that missing aliases
prevent the module from being requested. Affects i.MX8QXP/QM/DXL boards
with `CONFIG_CLK_IMX8QXP=m`. DT compatibles: `fsl,scu-clk`,
`fsl,imx8dxl-clk`, `fsl,imx8qxp-clk`, `fsl,imx8qm-clk`.

**Step 5.5 — Similar patterns**
Record: Other imx clk files already had `MODULE_DEVICE_TABLE(of, …)`
(`clk-imx8mm.c`, `clk-imx8mn.c`, `clk-imx8mp.c`, `clk-imx8mq.c`, `clk-
imx8-acm.c`, etc.). This file was the omission.

---

## Phase 6: Local tree

**Step 6.1 — Does the buggy code exist here?**
Record: Local tree is **v7.3-rc4** (`git describe` =
`v7.3-rc4-27-gf0100363d8c37`, `VERSION=7 PATCHLEVEL=3 SUBLEVEL=0
EXTRAVERSION=-rc4`). `CLK_IMX8QXP` is **tristate**. File has
`imx8qxp_match[]`, `module_init`/`module_exit`, and (after this commit)
`MODULE_DEVICE_TABLE`. The omission existed from v5.9 until this 7.3-era
commit. `git merge-base --is-ancestor cd21fdcbef3fb HEAD` is true — the
fix is already in this checkout; the underlying driver and match table
are present.

**Step 6.2 — Backport difficulty**
Record: Clean apply: one line after the sentinel of `imx8qxp_match[]`.
No refactor of that region.

**Step 6.3 — Related fixes already here?**
Record: Sibling LPCG table already has `MODULE_DEVICE_TABLE`. No earlier
equivalent for `clk-imx8qxp.c`. No competing fix.

---

## Phase 7: Subsystem / maintainer

**Step 7.1**
Record: **clk / i.MX SoC clocks**. **IMPORTANT** for i.MX8QXP/QM/DXL
(clock provider for the SoC), not core mm/vfs. Peripheral relative to
the whole kernel, critical on those boards.

**Step 7.2**
Record: Actively maintained (`clk-imx-7.3` pull by Abel Vesa). The
missing alias is old; the rest of the file is mature.

---

## Phase 8: Impact and risk

**Step 8.1 — Who is affected**
Record: **Platform/config-specific**: NXP i.MX8QXP/QM/DXL with
`CONFIG_CLK_IMX8QXP=m`. Built-in (`=y`) is unchanged.

**Step 8.2 — Trigger**
Record: Modular kernel + DT node with those compatibles + autoload via
aliases (udev, `request_module`, dracut/mkinitramfs). Common for distro
`=m` configs. Unprivileged users do not trigger it; boot/device-probe
does.

**Step 8.3 — Failure mode**
Record: Module never autoloads → SCU clocks never register → consumers
fail to probe (UART, net, display, etc.). **MEDIUM–HIGH** on affected
boards; not a panic/UAF. For `=y`, **no effect**.

**Step 8.4 — Risk vs benefit**
Record: **Benefit:** restores documented autoload for a supported
tristate clock driver. **Risk:** very low (1 line, no runtime path).
Ratio is strongly favorable.

---

## Phase 9: Synthesis

**Step 9.1 — Evidence**

FOR:
- Real bug: OF match table not exported; aliases missing for a
  `tristate` driver with `module_init`.
- Same pattern already used throughout `drivers/clk/imx/`.
- 1-line, obviously correct; maintainer applied; Reviewed-by Brian
  Masney.
- Zero runtime change when built-in.
- Analogous to device-ID additions (exception category: make existing
  hardware/driver work).
- Bug present since v5.9 modular support (`e0d0d4d86c766`).
- Applies cleanly to this tree’s `imx8qxp_match[]`.

AGAINST:
- No crash/syzbot/user report; source-level only.
- Impact limited to `CLK_IMX8QXP=m` (many images use `=y`).
- Not a security/UAF/deadlock class bug.

UNRESOLVED:
- Could not fetch lore.kernel.org (403); used b4 + gnuweeb/LKML mirrors
  instead.
- No dedicated stable-list thread found.

**Step 9.2 — Stable rules**
1. Obviously correct and tested? **PASS** — 1-line standard macro;
   reviewed and applied by clk/imx.
2. Real bug affecting users? **PASS** — `=m` autoload/initramfs alias
   generation is broken without it.
3. Important? **PASS** — SoC clock provider failing to load breaks the
   platform; severity is functional, not panic, but that is enough for
   this class of fix.
4. Small and contained? **PASS** — +1 line, one file.
5. No new features/APIs? **PASS** — publishes existing table.
6. Can apply to this tree? **PASS** — match table, `linux/module.h`, and
   modular Kconfig are all here.

**Step 9.3 — Exception category**
Record: Closest match is **device-ID / module-alias enablement** for an
existing driver (not a new driver).

**Step 9.4 — Decision**
This tree is mainline **7.3-rc4**. The driver, OF table, and tristate
module support are here; the fix is a one-line alias export with no
runtime risk. That meets stable criteria for this checkout.

---

### Problem and why it matters
`clk-imx8qxp.c` can be `=m` since v5.9 and already matches DT via
`imx8qxp_match[]`, but never published that table with
`MODULE_DEVICE_TABLE()`. Users with modular i.MX8QXP/QM/DXL kernels do
not get `of:` aliases, so the clock module may not autoload and
consumers never get clocks.

### Stable rules
Small, obviously correct, no new API, real autoload bug, applies to this
tree.

### Risk vs benefit
Benefit is correct module loading on a supported config; risk is
negligible.

### Concerns
No hardware repro and no `Fixes:` tag; neither blocks this pattern.
Sibling LPCG patch is independent.

---

Verification:
- [Phase 1] Parsed tags: Reviewed-by Brian Masney; Link
  patch.msgid.link/20260705001705.70400-1-pengpeng@iscas.ac.cn; SOBs Hou
  and Abel Vesa; no Fixes/Reported-by/Cc:stable
- [Phase 2] Diff: +1 line `MODULE_DEVICE_TABLE(of, imx8qxp_match)` in
  `drivers/clk/imx/clk-imx8qxp.c`; no function body change
- [Phase 3] `git blame`: table from `c2cccb6d0b33b` (2018); modular
  support `e0d0d4d86c766` (v5.9) introduced the need for aliases
- [Phase 3] `git merge-base --is-ancestor e0d0d4d86c766 HEAD`: yes; `git
  merge-base --is-ancestor cd21fdcbef3fb HEAD`: yes
- [Phase 3] Neighbor `e89485455ac49` is independent LPCG
  MODULE_DEVICE_TABLE add
- [Phase 4] `b4 dig -c cd21fdcbef3fb`: matched v1 at that msgid; `-a`
  only v1; `-w` listed clk/imx and linux-clk recipients
- [Phase 4] gnuweeb thread: Masney Reviewed-by; Vesa Applied as
  cd21fdcbef3fb; no NAK
- [Phase 4] lore.kernel.org fetch: 403; used mirrors
- [Phase 5] `CLK_IMX8QXP` is tristate in `drivers/clk/imx/Kconfig`;
  built as `clk-imx-scu` via Makefile; `module_init(imx8qxp_clk_init)`
  registers the platform driver
- [Phase 5] `scripts/mod/file2alias.c` `do_of_entry()` emits
  `of:N*T*C<compatible>` from MODULE_DEVICE_TABLE
- [Phase 5] Sibling `clk-imx8mm.c` already uses the same macro
- [Phase 6] `git describe HEAD`: v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion`: 7.3.0-rc4; file currently contains the added line
- [Phase 6] Apply difficulty: one line after existing `imx8qxp_match[]`
- [Phase 8] Failure mode: modular clock provider not autoloaded;
  severity MEDIUM–HIGH on those SoCs, none if `=y`
- UNVERIFIED: live udev/initramfs failure on hardware (author did not
  claim a runtime repro); stable-list discussion beyond the gnuweeb
  search

**YES**

 drivers/clk/imx/clk-imx8qxp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
index 3ae162625bb1a..15b08fc02f920 100644
--- a/drivers/clk/imx/clk-imx8qxp.c
+++ b/drivers/clk/imx/clk-imx8qxp.c
@@ -337,6 +337,7 @@ static const struct of_device_id imx8qxp_match[] = {
 	{ .compatible = "fsl,imx8qm-clk", &imx_clk_scu_rsrc_imx8qm, },
 	{ /* sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, imx8qxp_match);
 
 static struct platform_driver imx8qxp_clk_driver = {
 	.driver = {
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] firmware: imx: scu: manage mailbox channels and global handle

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit 55c748d596f841a18cf659ce0999f64029a5c88c ]

imx_scu_probe() requests mailbox channels with the non-managed
mbox_request_channel_byname() helper and then publishes sc_ipc through
the global imx_sc_ipc_handle.  Later probe failures, including child
population failure, can leave the channels and global handle live after
the probe has failed.

Register devres actions to free each mailbox channel and clear the global
handle.  Also depopulate partially created child devices when
devm_of_platform_populate() reports an error.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit message forensics

**Step 1.1:** Record: `[firmware/imx SCU] [manage] Register managed
cleanup for mailbox channels and the global IPC handle, and depopulate
children if probe fails.`

**Step 1.2:** Tags present:
- `Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>` (author)
- `Signed-off-by: Frank Li <Frank.Li@nxp.com>` (i.MX maintainer who
  applied it)

No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable`. Absence of those tags is expected for this
review and is not treated as a negative signal.

**Step 1.3:** Record:
- **Bug:** `imx_scu_probe()` uses unmanaged
  `mbox_request_channel_byname()` and then publishes `sc_ipc` via the
  global `imx_sc_ipc_handle`. Later probe failures, including
  `devm_of_platform_populate()`, leave channels allocated and the global
  handle set.
- **Symptom:** Leaked mailbox channels after a failed probe; a live
  global handle to an object that `devm_kzalloc` then frees; partial
  child devices left behind.
- **Version info:** None in the message. Driver originated in v4.20
  (`edbee095fafb4`).
- **Root cause:** Non-devm mailbox requests plus a global pointer with
  no rollback on the remaining error paths.

**Step 1.4:** Record: This is an explicit probe-error-path resource-leak
/ dangling-pointer fix, not a disguised cleanup. The wording matches the
diff.

## Phase 2: Diff analysis

**Step 2.1:** Record:
- File: `drivers/firmware/imx/imx-scu.c` (+24 / −1)
- Functions added: `imx_scu_free_mbox_chan()`, `imx_scu_clear_handle()`
- Function modified: `imx_scu_probe()`
- Scope: single-file surgical fix

**Step 2.2:** Before → after:
1. After a successful `mbox_request_channel_byname()`, the channel was
   never registered with devres. Mid-loop failure (`-EPROBE_DEFER`,
   `-ENOMEM` from `kasprintf`, later channel failure) returned without
   `mbox_free_channel()`. After: each channel is wrapped in
   `devm_add_action_or_reset(..., imx_scu_free_mbox_chan, ch)`.
2. `imx_sc_ipc_handle = sc_ipc` was published with no undo. After: a
   matching `devm_add_action_or_reset(..., imx_scu_clear_handle,
   sc_ipc)` NULLs it on unwind if it still points at this object.
3. `return devm_of_platform_populate(dev)` could fail after
   `of_platform_populate()` had already created some children
   (`devm_of_platform_populate()` does **not** depopulate on failure; it
   only `devres_free()`s the tracking pointer). After: explicit
   `of_platform_depopulate(dev)` on that error.

**Step 2.3:** Record: `[error-path resource leak + dangling global
pointer]`
- Mailbox leak: unmanaged `mbox_request_channel_byname()` with no free
  on later probe failure.
- Retry hazard: `__mbox_bind_client()` returns `-EBUSY` if `chan->cl` is
  already set, so a later probe retry can stick forever.
- Handle leak / UAF: `sc_ipc` is `devm_kzalloc`’d; probe failure
  releases it while `imx_sc_ipc_handle` still points at it. Other i.MX
  drivers call `imx_scu_get_handle()`.
- Child leak: failed `of_platform_populate()` still sets
  `OF_POPULATED_BUS` and can leave partial children.

**Step 2.4:** Record: The mailbox and handle `devres` actions are
obviously correct (`devm_add_action_or_reset` runs the action
immediately if registration fails). Calling `of_platform_depopulate()`
only on populate failure is the right API:
`devm_of_platform_depopulate()` would `WARN` because the managed
resource was never added. Regression risk is low. Remaining related
leaks (`gip3`, `soc_device`, secondary static handles) are pre-existing
and not introduced here.

## Phase 3: Git history

**Step 3.1:** Record: Unmanaged `mbox_request_channel_byname()` and
`imx_sc_ipc_handle = sc_ipc` come from `edbee095fafb4` (“firmware: imx:
add SCU firmware driver support”, 2018-10-08), first contained in
**v4.20-rc1**. The bug is long-standing.

**Step 3.2:** No `Fixes:` tag. Not applicable.

**Step 3.3:** Related commits on this file:
- `89f12d6509bff` — kasprintf leak in the same probe loop (same class of
  bug)
- `fbf10b86f6057` — OF node leak in probe
- `97a07dd2b559d` — `devm_mutex_init` (adjacent context; not a
  functional prerequisite)
- `ff79af939d847` — `suppress_bind_attrs = true`

This is a standalone v1 patch, not part of a series. No follow-ups to
this file after `55c748d596f84`.

**Step 3.4:** Pengpeng Hou has only this commit in
`drivers/firmware/imx/`. Frank Li (NXP i.MX maintainer) applied it.
Author is a contributor; the applying maintainer is the subsystem owner.

**Step 3.5:** No hard dependencies. `devm_add_action_or_reset()` is in
`include/linux/device/devres.h` in this tree. Applies standalone.

## Phase 4: Mailing list and external research

**Step 4.1:** Record:
- Lore / msgid:
  https://patch.msgid.link/20260616005902.11634-1-pengpeng@iscas.ac.cn
- Series: v1 only (`b4 dig -a`)
- Maintainer apply: Frank Li, “Applied, thanks!” (24 Jul 2026), commit
  `55c748d596f84`
- No NAK. No `Cc: stable` suggestion in the thread.
- Sashiko bot flagged **pre-existing** incomplete cleanup (`gip3`,
  `soc_device`, secondary handles, RPC timeout). Those are not
  regressions from this patch.

**Step 4.2:** Recipients (`b4 dig -w`): Frank Li, Sascha Hauer,
Pengutronix, Fabio Estevam, `imx@lists.linux.dev`, `linux-arm-kernel`,
`linux-kernel`. Appropriate i.MX maintainers were on To/Cc.

**Step 4.3:** No bugzilla / syzbot / user `Reported-by`. Bug is from
code inspection of the probe error path.

**Step 4.4:** Standalone 1/1 patch. No series dependencies.

**Step 4.5:** Record: UNVERIFIED for lore.kernel.org/stable (Anubis bot
wall). Original imx thread has no stable discussion.

## Phase 5: Code semantic analysis

**Step 5.1:** Record: `imx_scu_free_mbox_chan`, `imx_scu_clear_handle`,
`imx_scu_probe`.

**Step 5.2:** `imx_scu_probe()` is the platform probe for `fsl,imx-scu`.
`imx_scu_get_handle()` is called from clk-scu, scu-pd, thermal, rtc,
pinctrl, nvmem, GPIO, reset, FEC, FlexCAN, remoteproc, DRM, SOF, and
others. Impact is every i.MX8QM/QXP SCU consumer.

**Step 5.3:** Probe allocates `sc_ipc`, requests MU mailbox channels,
publishes the global handle, then populates child devices. Callees:
`mbox_request_channel_byname`, `mbox_free_channel`,
`devm_of_platform_populate`, `of_platform_depopulate`.

**Step 5.4:** Reachable at boot on SCU SoCs (`subsys_initcall_sync`).
Not a syscall, but it is the firmware IPC path those boards need to
bring up clocks, power domains, and peripherals. Unprivileged userspace
cannot poke it directly.

**Step 5.5:** Same driver already had a kasprintf leak fix in this
probe. `imx_scu_enable_general_irq_channel()` still requests unmanaged
`gip3` (pre-existing, not this patch).

## Phase 6: Local tree

**Step 6.1:** Local tree is **7.3.0-rc4** (`git describe HEAD` =
`v7.3-rc4-27-gf0100363d8c37`). Buggy pattern was introduced in v4.20 and
is in this lineage. `git merge-base --is-ancestor 55c748d596f84 HEAD`
succeeds. Pre-fix probe is in `55c748d596f84^`.

**Step 6.2:** Expected apply: clean on this tree (`devm_mutex_init`
context matches).

**Step 6.3:** No alternate fix for mailbox/handle cleanup. Prior leak
fixes (`89f12d6509bff`, `fbf10b86f6057`) do not cover this.

## Phase 7: Subsystem context

**Step 7.1:** Record: `[drivers/firmware/imx] [IMPORTANT]` — i.MX8QM/QXP
System Controller IPC. Not core mm/net, but it is the firmware bus those
SoCs use for clocks, PD, pinmux, thermal, RTC.

**Step 7.2:** Mature driver (2018), occasional probe-correctness fixes.
Not a new subsystem.

## Phase 8: Impact and risk

**Step 8.1:** i.MX8QM/QXP (and similar SCU) users with `CONFIG_IMX_SCU`.
Driver-specific / SoC-specific.

**Step 8.2:** Trigger is probe failure **after** some channels were
requested: mid-loop `kasprintf` `-ENOMEM`, a later
`mbox_request_channel_byname()` failure, `devm_mutex_init()` failure, or
`devm_of_platform_populate()` failure. First-channel `-EPROBE_DEFER`
does **not** leak (nothing held yet). Not userspace-triggerable except
via boot / driver bind.

**Step 8.3:** Failure mode:
- Leaked MU channels → retry gets `-EBUSY` → SCU never probes →
  clocks/PD/peripherals fail (**HIGH**, can make the board unusable)
- Dangling `imx_sc_ipc_handle` after `devm` frees `sc_ipc` (**HIGH** UAF
  if another driver then calls `imx_scu_get_handle()`)
- Orphan child devices after failed populate (**MEDIUM**)

Happy-path probe is unchanged.

**Step 8.4:** Benefit: prevents stuck SCU probe and a global-handle UAF
on real error paths. Risk: ~24 lines, probe error path only, standard
`devres` pattern. Ratio: favorable.

## Phase 9: Synthesis

**Evidence FOR:**
- Real leak of exclusive mailbox channels; `__mbox_bind_client()`
  returning `-EBUSY` can permanently break SCU probe retry.
- Global handle left pointing at `devm`-freed `sc_ipc` after populate
  failure (UAF for every `imx_scu_get_handle()` caller).
- `of_platform_depopulate()` on failed `devm_of_platform_populate()` is
  correct (verified against `drivers/of/platform.c`).
- Small, single-file, no new API.
- Applied by the i.MX maintainer; v1 accepted as-is.
- Same probe function already needed leak fixes; this is the
  mailbox/handle analogue.
- Code and helpers exist in this 7.3-rc4 tree; no missing prerequisites.

**Evidence AGAINST:**
- No user/syzbot report; author-found error-path bug.
- Trigger is uncommon (not the first-channel `-EPROBE_DEFER` case).
- Incomplete: `gip3`, `soc_device`, and secondary IPC statics still leak
  (pre-existing).
- Affects SCU i.MX8 platforms only.

**Unresolved:** lore.kernel.org/stable search blocked (Anubis). Thread
via `b4 dig` had no stable nomination.

**Stable rules:**
1. Obviously correct and tested? **PASS** — standard `devres` unwind;
   maintainer applied it; no NAK.
2. Real bug affecting users? **PASS** — leaked exclusive channels and a
   dangling global IPC handle on failed probe.
3. Important (crash/security/corruption/deadlock)? **PASS** — `-EBUSY`
   probe stall can prevent SCU bring-up; dangling handle is a UAF.
   Severity HIGH, not a happy-path panic.
4. Small and contained? **PASS** — 24 insertions, one file.
5. No new features/APIs? **PASS**
6. Can apply to this tree? **PASS** — context matches; helpers present.

**Exception category:** none; this is a normal error-path leak/UAF fix.

The local tree is 7.3-rc4. The SCU driver and the buggy unmanaged
mailbox/handle pattern are in this lineage (since v4.20). The fix is a
small, correct rollback of probe resources. Remaining gip3/soc_dev gaps
are not a reason to keep the main channel/handle leak.

Verification:
- [Phase 1] Parsed tags: only author + Frank Li SOBs; no Fixes/Reported-
  by/Cc: stable
- [Phase 2] Diff: +24/−1 in `imx_scu_probe()`;
  `devm_add_action_or_reset` for mbox + handle; `of_platform_depopulate`
  on populate failure
- [Phase 2] `devm_of_platform_populate()` on failure does
  `devres_free(ptr)` without depopulate; `of_platform_populate()` still
  sets `OF_POPULATED_BUS` — explicit depopulate is required and not a
  double-free
- [Phase 2] `__mbox_bind_client()` returns `-EBUSY` if `chan->cl` is set
  — verified in `drivers/mailbox/mailbox.c`
- [Phase 3] Blame: bug from `edbee095fafb4` (v4.20-rc1); `git merge-base
  --is-ancestor 55c748d596f84 HEAD` true
- [Phase 3] No Fixes: tag; no follow-up commits on this file
- [Phase 4] `b4 dig -c 55c748d596f84`:
  https://patch.msgid.link/20260616005902.11634-1-pengpeng@iscas.ac.cn
- [Phase 4] `b4 dig -a`: v1 only; `b4 dig -w`: Frank Li / Sascha Hauer /
  imx list CC’d
- [Phase 4] mbox: Frank Li “Applied, thanks!”; Sashiko noted pre-
  existing gaps, no NAK
- [Phase 4] lore.kernel.org/stable: UNVERIFIED (bot challenge)
- [Phase 5] Callers of `imx_scu_get_handle()` span clk, pd, net,
  thermal, rtc, drm, etc.
- [Phase 6] `git describe HEAD`: v7.3-rc4-27-gf0100363d8c37; `make
  kernelversion`: 7.3.0-rc4; buggy probe exists in parent of this commit
- [Phase 8] Failure mode: mailbox leak → stuck probe / dangling handle
  UAF; severity HIGH

**YES**

 drivers/firmware/imx/imx-scu.c | 25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
index 8c28e25ddc8a6..28d745ae06067 100644
--- a/drivers/firmware/imx/imx-scu.c
+++ b/drivers/firmware/imx/imx-scu.c
@@ -82,6 +82,17 @@ static int imx_sc_linux_errmap[IMX_SC_ERR_LAST] = {
 
 static struct imx_sc_ipc *imx_sc_ipc_handle;
 
+static void imx_scu_free_mbox_chan(void *data)
+{
+	mbox_free_channel(data);
+}
+
+static void imx_scu_clear_handle(void *data)
+{
+	if (imx_sc_ipc_handle == data)
+		imx_sc_ipc_handle = NULL;
+}
+
 static inline int imx_sc_to_linux_errno(int errno)
 {
 	if (errno >= IMX_SC_ERR_NONE && errno < IMX_SC_ERR_LAST)
@@ -321,6 +332,11 @@ static int imx_scu_probe(struct platform_device *pdev)
 		dev_dbg(dev, "request mbox chan %s\n", chan_name);
 		/* chan_name is not used anymore by framework */
 		kfree(chan_name);
+
+		ret = devm_add_action_or_reset(dev, imx_scu_free_mbox_chan,
+					       sc_chan->ch);
+		if (ret)
+			return ret;
 	}
 
 	sc_ipc->dev = dev;
@@ -328,6 +344,9 @@ static int imx_scu_probe(struct platform_device *pdev)
 	init_completion(&sc_ipc->done);
 
 	imx_sc_ipc_handle = sc_ipc;
+	ret = devm_add_action_or_reset(dev, imx_scu_clear_handle, sc_ipc);
+	if (ret)
+		return ret;
 
 	ret = imx_scu_soc_init(dev);
 	if (ret)
@@ -340,7 +359,11 @@ static int imx_scu_probe(struct platform_device *pdev)
 
 	dev_info(dev, "NXP i.MX SCU Initialized\n");
 
-	return devm_of_platform_populate(dev);
+	ret = devm_of_platform_populate(dev);
+	if (ret)
+		of_platform_depopulate(dev);
+
+	return ret;
 }
 
 static const struct of_device_id imx_scu_match[] = {
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18-5.10] firmware: imx: scu: manage mailbox channels and global handle

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] firmware: imx: scu: missing irq channel cleanup in imx_scu_probe()
- [High] firmware: imx: scu: unmanaged soc_device in imx_scu_soc_init()
--

commit b4c62f6aa45071e2c25e829dc030f6a6f0c1e4ec
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>

firmware: imx: scu: manage mailbox channels and global handle

This commit registers devres actions in imx_scu_probe() to release
requested mailbox channels and clear imx_sc_ipc_handle on probe failure,
and depopulates child devices if devm_of_platform_populate() fails.

> diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
> index 8c28e25ddc8a6..28d745ae06067 100644
> --- a/drivers/firmware/imx/imx-scu.c
> +++ b/drivers/firmware/imx/imx-scu.c
[ ... ]
> @@ -328,6 +344,9 @@ static int imx_scu_probe(struct platform_device *pdev)
>  	init_completion(&sc_ipc->done);
>  
>  	imx_sc_ipc_handle = sc_ipc;
> +	ret = devm_add_action_or_reset(dev, imx_scu_clear_handle, sc_ipc);
> +	if (ret)
> +		return ret;
>  
>  	ret = imx_scu_soc_init(dev);
>  	if (ret)

[Severity: High]
If devm_of_platform_populate(dev) fails later in imx_scu_probe(), does
imx_scu_soc_init(dev) leave behind an unmanaged soc_device whose attributes
point to freed devm memory?

In drivers/firmware/imx/imx-scu-soc.c, imx_scu_soc_init() caches sc_ipc in
imx_sc_soc_ipc_handle, allocates soc_dev_attr, soc_dev_attr->revision, and
soc_dev_attr->serial_number using devm on the SCU device, and registers the
SoC device with the unmanaged soc_device_register():

drivers/firmware/imx/imx-scu-soc.c:imx_scu_soc_init() {
	ret = imx_scu_get_handle(&imx_sc_soc_ipc_handle);
	if (ret)
		return ret;

	soc_dev_attr = devm_kzalloc(dev, sizeof(*soc_dev_attr),
				    GFP_KERNEL);
	...
	soc_dev_attr->revision = devm_kasprintf(dev, GFP_KERNEL, "%d.%d",
						(val >> 4) & 0xf, val & 0xf);
	...
	soc_dev_attr->serial_number = devm_kasprintf(dev, GFP_KERNEL,
						     "%016llX", uid);
	...
	soc_dev = soc_device_register(soc_dev_attr);
}

In drivers/base/soc.c, soc_device_register() stores the soc_dev_attr pointer
directly in soc_dev->attr.

When devm_of_platform_populate(dev) fails, devres_release_all(dev) frees
soc_dev_attr, revision, serial_number, and sc_ipc while soc_dev remains
registered on soc_bus_type and imx_sc_soc_ipc_handle stays set to the freed
sc_ipc. Reading /sys/bus/soc/devices/socX/* via soc_info_show() or calling
soc_device_match() will then dereference freed memory.

Should imx_scu_soc_init() also register devres cleanup to call
soc_device_unregister(soc_dev) and clear imx_sc_soc_ipc_handle?

> @@ -340,7 +359,11 @@ static int imx_scu_probe(struct platform_device *pdev)
>  
>  	dev_info(dev, "NXP i.MX SCU Initialized\n");
>  
> -	return devm_of_platform_populate(dev);
> +	ret = devm_of_platform_populate(dev);
> +	if (ret)
> +		of_platform_depopulate(dev);
> +
> +	return ret;
>  }

[Severity: High]
Similarly, when devm_of_platform_populate(dev) fails here after
imx_scu_enable_general_irq_channel(dev) has succeeded, doesn't the
unmanaged state in drivers/firmware/imx/imx-scu-irq.c remain active while
its devm-allocated backing structures are freed?

Before devm_of_platform_populate(dev) is called, imx_scu_probe() invokes
imx_scu_enable_general_irq_channel(dev):

drivers/firmware/imx/imx-scu-irq.c:imx_scu_enable_general_irq_channel() {
	ret = imx_scu_get_handle(&imx_sc_irq_ipc_handle);
	if (ret)
		return ret;

	cl = devm_kzalloc(dev, sizeof(*cl), GFP_KERNEL);
	if (!cl)
		return -ENOMEM;

	cl->dev = dev;
	cl->rx_callback = imx_scu_irq_callback;

	/* SCU general IRQ uses general interrupt channel 3 */
	ch = mbox_request_channel_byname(cl, "gip3");
	...
	INIT_WORK(&imx_sc_irq_work, imx_scu_irq_work_handler);

	if (!of_parse_phandle_with_args(dev->of_node, "mboxes",
				       "#mbox-cells", 0, &spec))
		i = of_alias_get_id(spec.np, "mu");
	...
	wakeup_obj = kobject_create_and_add("scu_wakeup_source", firmware_kobj);
	...
	ret = sysfs_create_file(wakeup_obj, &wakeup_source_attr.attr);
}

If devm_of_platform_populate(dev) fails, devres frees cl and sc_ipc and
clears imx_sc_ipc_handle, but nothing tears down the state created in
imx_scu_enable_general_irq_channel():

1. The "gip3" mailbox channel ch is not freed with mbox_free_channel(ch),
   leaving chan->cl pointing to the freed mbox_client cl (which causes a
   use-after-free in imx_scu_irq_callback() on a gip3 interrupt and causes
   __mbox_bind_client() to return -EBUSY on any later probe retry), and
   imx_sc_irq_work is not cancelled.

2. imx_sc_irq_ipc_handle remains non-NULL and points to the freed sc_ipc, so
   callers such as imx_scu_irq_group_enable() pass the
   !imx_sc_irq_ipc_handle check and dereference freed memory in
   imx_scu_call_rpc().

3. wakeup_obj and wakeup_source_attr are leaked under
   /sys/firmware/scu_wakeup_source (in addition to spec.np from
   of_parse_phandle_with_args() never being released with of_node_put()).

Could imx_scu_enable_general_irq_channel() register devres actions to
clean up the gip3 channel, imx_sc_irq_work, imx_sc_irq_ipc_handle, and
wakeup_obj when probe fails?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-392-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18] spi: fsl-dspi: clean up after failed suspend and resume

[Sasha Levin]

From: Jiawen Liu <1298662399@qq.com>

[ Upstream commit 2543355f3da56a297e3803ccb5d29f4dce5f18f1 ]

dspi_suspend() disabled the IRQ before spi_controller_suspend(),
but ignored a suspend failure and kept tearing the device down.
Restore the IRQ and return the error if suspend fails.

dspi_resume() also left the clock prepared if controller resume or
hardware init failed. Route those failures through clock cleanup.

Signed-off-by: Jiawen Liu <1298662399@qq.com>
Link: https://patch.msgid.link/tencent_427FA55E3D59112524886E9C931CA0F92F06@qq.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I compared the pre-image to v6.18.53: the buggy suspend/resume path is
there unchanged, so this is a standalone fix for this tree.

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: PARSE THE SUBJECT LINE**
- Record: `[spi: fsl-dspi:] [clean up] [restore IRQ / clocks after
  failed suspend and resume]`
- Subsystem is Freescale DSPI. The verb is “clean up”, but the body
  describes ignored errors and missing rollback.

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
- Record:
  - `Signed-off-by: Jiawen Liu <1298662399@qq.com>` (author)
  - `Link: https://patch.msgid.link/tencent_427FA55E3D59112524886E9C931C
    A0F92F06@qq.com`
  - `Signed-off-by: Mark Brown <broonie@kernel.org>` (SPI maintainer)
  - No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-
    by:`, or `Cc: stable` (absence of those last two is expected for
    this review)
  - Pipeline-added `Signed-off-by: Sasha Levin` / `[ Upstream commit
    2543355f3da5... ]` ignored per instructions

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
- Record: **Bug:** `dspi_suspend()` calls `disable_irq()` then
  `spi_controller_suspend()` but ignores a non-zero return and still
  disables the clock and selects the sleep pin state. **Symptom:** on a
  failed controller suspend the IRQ stays off, clocks are gated, pins go
  to sleep, and suspend is reported as success. **Resume bug:**
  `clk_prepare_enable()` is not undone if `spi_controller_resume()` or
  `dspi_init()` fails. **Root cause:** missing error checks and missing
  rollback. No version range in the message.

**Step 1.4: DETECT HIDDEN BUG FIXES**
- Record: Yes. “Clean up” is error-path recovery: re-enable IRQ and
  return the error on suspend failure; `clk_disable_unprepare()` on
  resume failure. That is a leak/imbalance fix, not style.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: INVENTORY THE CHANGES**
- Record: `drivers/spi/spi-fsl-dspi.c` only; **+18 / −3**. Functions:
  `dspi_suspend()`, `dspi_resume()`. Single-file surgical PM error-path
  fix.

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
- Record:
  - **suspend before:** disable IRQ → ignore `spi_controller_suspend()`
    → always `clk_disable_unprepare()` → sleep pinctrl → return 0.
  - **suspend after:** disable IRQ → if `spi_controller_suspend()`
    fails, `enable_irq()` and return `ret` (clocks/pinctrl untouched).
  - **resume before:** enable clock → ignore `spi_controller_resume()` →
    on `dspi_init()` failure return with clock still prepared.
  - **resume after:** those failures go to `disable_clk`
    (`clk_disable_unprepare()` + return `ret`). IRQ is still enabled
    only on the success path.

**Step 2.3: IDENTIFY THE BUG MECHANISM**
- Record: **Error-path / resource-leak / IRQ imbalance.**
  `spi_controller_suspend()` can return `-EBUSY` from `spi_stop_queue()`
  after a 5s wait (`drivers/spi/spi.c`). Continuing then gates the clock
  under a live controller and leaves the IRQ disabled. Resume can leak a
  prepared clock.

**Step 2.4: ASSESS THE FIX QUALITY**
- Record: Minimal and obviously correct; matches other SPI drivers that
  already check these returns. Regression risk is low: only error paths
  change. Idle suspend still returns 0 after stop-queue succeeds. Pre-
  existing IRQ-before-stop-queue ordering is not introduced here
  (Sashiko noted it as pre-existing). Resume still does not undo
  `spi_controller_resume()` on later `dspi_init()` failure;
  `dspi_init()` only fails on invalid `trans_mode` after a successful
  probe, so that path is essentially dead.

## PHASE 3: GIT HISTORY INVESTIGATION

**Step 3.1: BLAME THE CHANGED LINES**
- Record: On v6.18.53, suspend/resume blame is `c5412ec5f68773`
  (“Reinitialize DSPI regs after resuming for S32G”, 2025-05-22), which
  kept the ignore-error pattern. That pattern already existed before
  S32G (`git show c5412ec5f68773^`). Original driver `349ad66c0ab0b`
  (Vybrid VF610) already ignored `spi_master_suspend()` and always
  disabled the clock. Bug is old, not post-6.18.

**Step 3.2: FOLLOW THE FIXES: TAG**
- Record: No `Fixes:` tag. Not applicable beyond that.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
- Record: Related: `3d87b613d6a3c` (“Fix external abort on interrupt in
  resume or exit paths”) added `disable_irq()` in suspend because a
  shared IRQ after clocks-off caused an external abort on Vybrid. That
  makes restoring the IRQ on suspend failure required. `9bd77a9ce31dd`
  only fixed a NULL drvdata in PM. This patch is standalone; later
  autosel `b6d8099e44987` only switches PM macros.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
- Record: Jiawen Liu is not the SPI maintainer. Same series on this
  tree: `spi: atcspi200`, `spi: bcmbca-hsspi`, `spi: bcm-qspi`, `spi:
  bcm63xx-hsspi`, `spi: bcm63xx`, plus `spi: nxp-fspi` probe RPM. Each
  driver is independent. Mark Brown applied the series.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
- Record: No new helpers. Uses `spi_controller_suspend`/`resume`,
  `enable_irq`/`disable_irq`, `clk_disable_unprepare` already in 6.18.
  Standalone. Series 3/4 does not need 1/4 or 2/4 for this file.

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
- Record: `b4 dig -c 2543355f3da5` → https://patch.msgid.link/tencent_42
  7FA55E3D59112524886E9C931CA0F92F06@qq.com
- Series: v1 only, `[PATCH 3/4]`. Mark Brown applied all four to
  `broonie/spi.git for-7.3`. No NAK on this patch. Sashiko flagged two
  **pre-existing** ordering issues (IRQ before stop-queue; resume queue
  before `dspi_init()`), not regressions from this diff. No reviewer
  `Cc: stable`. Direct lore fetch returned 403; thread recovered via `b4
  dig -m`.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
- Record: `b4 dig -w`: To Mark Brown; Cc linux-spi, linux-kernel, linux-
  arm-kernel, imx@, NXP (olteanv, han.xu, haibo.chen). No human
  Reviewed-by on this patch. Maintainer applied it.

**Step 4.3: SEARCH FOR THE BUG REPORT**
- Record: No Reported-by / bugzilla / syzbot. Bug is from code
  inspection of ignored returns.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
- Record: 1/4 atcspi200, 2/4 bcmbca-hsspi, 3/4 this, 4/4 nxp-fspi
  (different bug: probe RPM). This hunk does not depend on the others.
  Frank Li replied only to 4/4.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
- Record: lore.kernel.org/stable search via WebFetch returned 403.
  UNVERIFIED whether stable@ discussed this SHA. No in-tree evidence it
  was rejected.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1: IDENTIFY KEY FUNCTIONS**
- Record: `dspi_suspend()`, `dspi_resume()`. Callees of interest:
  `spi_controller_suspend()`, `spi_controller_resume()`, `dspi_init()`.

**Step 5.2: TRACE CALLERS**
- Record: Only `SIMPLE_DEV_PM_OPS(dspi_pm, dspi_suspend, dspi_resume)`
  on v6.18.53 → system-sleep PM for this platform device. Not a syscall
  hot path; triggered by suspend/resume on i.MX / Vybrid / LS1021A / S32
  / ColdFire DSPI.

**Step 5.3: TRACE CALLEES**
- Record: `spi_controller_suspend()` → `spi_stop_queue()` (up to 500 ×
  ~10ms, then `-EBUSY`) then `__spi_mark_suspended()`.
  `dspi_transfer_one_message()` waits on `dspi->xfer_done` when
  `dspi->irq` is set; completion is from `dspi_interrupt()`. DMA mode
  waits on DMA completions, not that IRQ.

**Step 5.4: FOLLOW THE CALL CHAIN**
- Record: Userspace/system suspend → driver PM → `dspi_suspend()`.
  Reachable whenever this hardware is present and `CONFIG_PM_SLEEP`. In-
  flight IRQ-mode transfer at suspend can make `spi_stop_queue()` fail;
  that is the interesting path.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
- Record: Many SPI drivers already check `spi_controller_suspend()`
  (omap2-mcspi, atmel, qup, rockchip, stm32, …). Same author fixed the
  ignored-return pattern in several Broadcom SPI drivers. Systematic,
  not one-off.

## PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
- Record: Local tree is **6.18.53** (`git describe HEAD` →
  `v6.18.53-5049-g0f0bdc2b0dffb`, `VERSION=6 PATCHLEVEL=18
  SUBLEVEL=53`). At **v6.18.53**, `dspi_suspend()` still ignores the
  suspend return and `dspi_resume()` still returns from `dspi_init()`
  failure without `clk_disable_unprepare()`. Candidate `1248ec26ed99f`
  is **not** an ancestor of `v6.18.53`. Bug present.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
- Record: Pre-image on v6.18.53 matches the patch (including `#ifdef
  CONFIG_PM_SLEEP` / `SIMPLE_DEV_PM_OPS`). Expected apply: **clean**.
  `git apply --check` on current autosel HEAD fails only because the
  candidate is already sitting on this working branch.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
- Record: `3d87b613d6a3c` (IRQ disable in suspend) **is** in v6.18.53.
  No other fix for ignored `spi_controller_suspend()` on this file.

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
- Record: `drivers/spi/spi-fsl-dspi.c`. **IMPORTANT** (common
  NXP/Freescale SPI; not core mm/vfs). `SPI_FSL_DSPI` depends on
  `ARCH_MXC || ARCH_NXP || M5441x || COMPILE_TEST`. Kconfig: S32, VF610,
  LS1021A, ColdFire.

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
- Record: File still gets platform and DMA work (S32G series in 2025).
  PM error handling itself is old and stale.

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: DETERMINE WHO IS AFFECTED**
- Record: Driver-specific: boards with Freescale DSPI that suspend.
  Embedded/i.MX/Layerscape/S32 population, not all Linux systems.

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
- Record: System suspend while `spi_stop_queue()` cannot drain
  (busy/queued messages for ~5s). IRQ-mode in-flight transfer is a
  realistic trigger because `disable_irq()` runs first and
  `dspi_transfer_one_message()` uses
  `wait_for_completion(&dspi->xfer_done)`. Unprivileged users do not
  call this directly; a suspend with SPI activity can. Resume clock
  leak: `spi_controller_resume()` `-EBUSY` or `dspi_init()` `-EINVAL`
  (latter essentially unreachable after probe).

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
- Record: Failed suspend that still gates clocks: possible MMIO abort /
  hang (this driver already hit “external abort on non-linefetch” when
  the IRQ ran after clocks off — `3d87b613d6a3c`). IRQ left disabled
  while the device is still active: SPI completions never fire → hung
  transfers. Resume clock leak: extra power / unbalanced clk prepare.
  **Severity: HIGH** on the suspend path (hang / abort), **MEDIUM** on
  the resume leak.

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
- Record: **Benefit:** high for DSPI suspend users — fail suspend
  instead of disabling clocks/IRQ incorrectly. **Risk:** low — 21 lines,
  error paths only, no API/struct change. If stop-queue fails, aborting
  suspend is the intended PM policy.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real ignored-error bug: teardown after failed
  `spi_controller_suspend()`.
- IRQ not restored → hung SPI (completion in `dspi_interrupt()`).
- Clock gated while the controller may still be busy → abort/hang; same
  class as the already-stable `3d87b613d6a3c` abort fix.
- Resume path clock leak on error.
- Small, local, obviously correct; SPI maintainer applied it.
- Buggy code is in v6.18.53; no extra prerequisites.
- Same class of SPI PM error-path fixes already common in-tree.

AGAINST:
- No user/syzbot report.
- Worded as “clean up”; failure is an error path, not every suspend.
- `dspi_init()` resume failure is almost unreachable.
- Sashiko pre-existing ordering notes (not introduced here).
- Incomplete undo of `spi_controller_resume()` if `dspi_init()` failed
  (dead in practice).

UNRESOLVED:
- lore.kernel.org HTTP 403; stable@ discussion not independently fetched
  (thread was recovered with b4).

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — mechanical error-return
   handling; applied by Mark Brown.
2. Fixes a real bug that affects users? **PASS** — IRQ/clock teardown on
   failed suspend; clk leak on resume.
3. Important issue? **PASS** — hang / possible bus abort, not a style
   nit.
4. Small and contained? **PASS** — +18/−3, one file.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS** — v6.18.53 pre-image matches.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
- Record: Not a device-ID/quirk/DT/build/doc exception. Qualifies as a
  normal bugfix.

**Step 9.4: DECISION**

This should be backported to **this 6.18.53 tree**. The important part
is suspend: do not disable clocks and leave the IRQ off when
`spi_controller_suspend()` fails. That is a real stability bug on a
production NXP SPI controller, small enough for stable, and it applies
cleanly here.

### What the commit solves for stable users
On Freescale DSPI, suspend currently disables the IRQ, then ignores
`spi_controller_suspend()`. If the message queue does not stop
(`-EBUSY`), the driver still turns off the clock and puts pins to sleep
while reporting success. The IRQ stays disabled. That can hang in-flight
transfers (`wait_for_completion` never completes) or MMIO-abort if the
hardware is still live. Resume can also leave `clk_prepare_enable()`
unbalanced. The patch stops teardown on suspend failure and unwinds the
clock on resume failure.

### Risk vs benefit
Benefit is preventing a broken/hung SPI device and possible abort after
a failed controller suspend. Risk is confined to those error returns;
successful idle suspend is unchanged.

### Concerns
No extra commits are required. Do not confuse autosel already having
this SHA with “already selected for 6.18.y”; `v6.18.53` still has the
bug.

Verification:
- [Phase 1] Subject/body/tags from `git log -1` / `git show
  1248ec26ed99f`: no Fixes/Reported-by; Link msgid; SOB Jiawen Liu +
  Mark Brown
- [Phase 2] Diff: +18/−3 in `dspi_suspend`/`dspi_resume` only
- [Phase 3] `git blame` on v6.18.53: `c5412ec5f68773`; ignore-error PM
  since `349ad66c0ab0b`; `3d87b613d6a3c` in this tree
- [Phase 3] `git merge-base --is-ancestor 1248ec26ed99f v6.18.53` → no;
  ancestor of HEAD (autosel) → yes
- [Phase 3] Author series: several independent SPI PM error-path patches
- [Phase 4] `b4 dig -c 2543355f3da5`: patch 3/4 v1, lore msgid, applied
  to broonie for-7.3; Sashiko pre-existing notes only; no NAK
- [Phase 4] WebFetch lore/stable: 403 — UNVERIFIED stable@ thread
- [Phase 5] `spi_controller_suspend` → `spi_stop_queue` `-EBUSY`; DSPI
  IRQ path `wait_for_completion` / `dspi_interrupt`; PM ops only callers
- [Phase 6] `git describe HEAD` / Makefile: 6.18.53; v6.18.53 file
  matches patch pre-image
- [Phase 7] `SPI_FSL_DSPI` on ARCH_MXC/NXP
- [Phase 8] Failure: hung SPI / possible external abort; severity HIGH
  on suspend error path

**YES**

 drivers/spi/spi-fsl-dspi.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 83ea296597e94..1283a193b6fcc 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1464,10 +1464,18 @@ static int dspi_init(struct fsl_dspi *dspi)
 static int dspi_suspend(struct device *dev)
 {
 	struct fsl_dspi *dspi = dev_get_drvdata(dev);
+	int ret;
 
 	if (dspi->irq)
 		disable_irq(dspi->irq);
-	spi_controller_suspend(dspi->ctlr);
+
+	ret = spi_controller_suspend(dspi->ctlr);
+	if (ret) {
+		if (dspi->irq)
+			enable_irq(dspi->irq);
+		return ret;
+	}
+
 	clk_disable_unprepare(dspi->clk);
 
 	pinctrl_pm_select_sleep_state(dev);
@@ -1485,12 +1493,15 @@ static int dspi_resume(struct device *dev)
 	ret = clk_prepare_enable(dspi->clk);
 	if (ret)
 		return ret;
-	spi_controller_resume(dspi->ctlr);
+
+	ret = spi_controller_resume(dspi->ctlr);
+	if (ret)
+		goto disable_clk;
 
 	ret = dspi_init(dspi);
 	if (ret) {
 		dev_err(dev, "failed to initialize dspi during resume\n");
-		return ret;
+		goto disable_clk;
 	}
 
 	dspi_set_mtf(dspi);
@@ -1499,6 +1510,10 @@ static int dspi_resume(struct device *dev)
 		enable_irq(dspi->irq);
 
 	return 0;
+
+disable_clk:
+	clk_disable_unprepare(dspi->clk);
+	return ret;
 }
 #endif /* CONFIG_PM_SLEEP */
 
-- 
2.53.0

Re: [PATCH AUTOSEL 6.18] spi: fsl-dspi: clean up after failed suspend and resume

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] spi: fsl-dspi: premature disable_irq() and unroll gap in dspi_suspend()
--

commit 7e693362fffc058a6e36cb3136ecf18f7eb1c968
Author: Jiawen Liu <1298662399@qq.com>

spi: fsl-dspi: clean up after failed suspend and resume

This commit checks the return values of spi_controller_suspend() in
dspi_suspend() and spi_controller_resume() in dspi_resume(), restoring the
IRQ or disabling the clock if an error occurs.

Link: https://patch.msgid.link/tencent_427FA55E3D59112524886E9C931CA0F92F06@qq.com

> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 83ea296597e94..1283a193b6fcc 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -1464,10 +1464,18 @@ static int dspi_init(struct fsl_dspi *dspi)
>  static int dspi_suspend(struct device *dev)
>  {
>  	struct fsl_dspi *dspi = dev_get_drvdata(dev);
> +	int ret;
>  
>  	if (dspi->irq)
>  		disable_irq(dspi->irq);
> -	spi_controller_suspend(dspi->ctlr);
> +
> +	ret = spi_controller_suspend(dspi->ctlr);
> +	if (ret) {
> +		if (dspi->irq)
> +			enable_irq(dspi->irq);
> +		return ret;
> +	}

[Severity: High]
When dspi_suspend() takes this new error return path after
spi_controller_suspend() fails, does it leave SPI_CONTROLLER_SUSPENDED
permanently set on dspi->ctlr->flags?

In drivers/spi/spi-fsl-dspi.c, dspi_suspend() calls disable_irq(dspi->irq)
before calling spi_controller_suspend(dspi->ctlr). On platforms using
DSPI_XSPI_MODE with an IRQ, in-flight or queued transfers in
dspi_transfer_one_message() wait for dspi_interrupt() to signal
dspi->xfer_done:

drivers/spi/spi-fsl-dspi.c:dspi_transfer_one_message() {
    ...
			if (dspi->irq)
				reinit_completion(&dspi->xfer_done);

			dspi_fifo_write(dspi);

			if (dspi->irq)
				wait_for_completion(&dspi->xfer_done);
			else
				dspi_poll(dspi);
    ...
}

Because disable_irq(dspi->irq) has already disabled the interrupt line, an
in-flight IRQ-driven transfer cannot complete while spi_controller_suspend()
waits in spi_stop_queue() for the queue to drain, causing spi_stop_queue()
to time out after 5 seconds with -EBUSY.

In drivers/spi/spi.c, spi_controller_suspend() still calls
__spi_mark_suspended(ctlr) unconditionally even when spi_stop_queue() fails:

drivers/spi/spi.c:spi_controller_suspend() {
    ...
	if (ctlr->queued) {
		ret = spi_stop_queue(ctlr);
		if (ret)
			dev_err(&ctlr->dev, "queue stop failed\n");
	}

	__spi_mark_suspended(ctlr);
	return ret;
}

When dspi_suspend() returns -EBUSY to device_suspend(),
dev->power.is_suspended is not set, so device_resume() skips calling
dspi_resume() during suspend-abort recovery. With nothing calling
spi_controller_resume(dspi->ctlr) to clear SPI_CONTROLLER_SUSPENDED,
wouldn't all subsequent synchronous SPI transfers in __spi_sync() fail with
-ESHUTDOWN?

Should disable_irq(dspi->irq) be called after spi_controller_suspend()
succeeds, or should the failure path also call spi_controller_resume()?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261019135441.1420968-426-sashal@kernel.org?part=1

[PATCH AUTOSEL 6.18-5.10] clk: imx: imx8qxp-lpcg: add missing MODULE_DEVICE_TABLE()

[Sasha Levin]

From: Pengpeng Hou <pengpeng@iscas.ac.cn>

[ Upstream commit e89485455ac49925565061733c0d73d568333fc0 ]

The driver has a match table for the of bus wired into its driver
structure, but the table is not exported with MODULE_DEVICE_TABLE().

Add the missing MODULE_DEVICE_TABLE() entry so module alias information
is generated for automatic module loading.

This is a source-level fix.  It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the driver registration structure, and the missing module alias
publication.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Link: https://patch.msgid.link/20260704150344.59563-1-pengpeng@iscas.ac.cn
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Local tree

This checkout is **v7.3-rc4-27-gf0100363d8c37** (`VERSION=7 PATCHLEVEL=3
SUBLEVEL=0 EXTRAVERSION=-rc4`). The candidate is `e89485455ac49` (`clk:
imx: imx8qxp-lpcg: add missing MODULE_DEVICE_TABLE()`). The file and
match table exist here; the one-line fix applies as written.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1 — Subject**
- Record: `[clk: imx: imx8qxp-lpcg] [add] [export OF match table via
  MODULE_DEVICE_TABLE so module aliases are generated]`

**Step 1.2 — Tags**
- Record:
  - `Reviewed-by: Frank Li <Frank.Li@nxp.com>` (i.MX)
  - `Reviewed-by: Brian Masney <bmasney@redhat.com>` (Red Hat / clk)
  - `Reviewed-by: Peng Fan <peng.fan@nxp.com>` (i.MX clk)
  - `Link: https://patch.msgid.link/20260704150344.59563-1-
    pengpeng@iscas.ac.cn`
  - `Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>` (author)
  - `Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>` (clk-imx
    maintainer, applied it)
  - No `Fixes:`, no `Reported-by:`, no `Cc: stable` (absence expected)
  - Ignore any Sasha Levin SOB if present (none on the real commit)

**Step 1.3 — Body**
- Record: The OF match table is wired into `platform_driver` but not
  published with `MODULE_DEVICE_TABLE()`. Without that, modpost does not
  emit `of:` aliases, so kmod/udev cannot autoload the module from DT
  compatible strings.
- Symptom: `CONFIG_CLK_IMX8QXP=m` → LPCG clock module does not load from
  DT; consumers never get those clocks unless the module is loaded by
  hand.
- Version info: none in the message.
- Root cause: missing alias publication, not a runtime logic bug. Author
  states it is a source-level finding, not a live hardware repro.

**Step 1.4 — Hidden bug fix?**
- Record: Not disguised. It is a real autoload/modalias bug stated
  plainly. The “source-level” wording means it was found by inspection,
  not that it is theoretical: the table is used and not exported.

---

## PHASE 2: DIFF ANALYSIS

**Step 2.1 — Inventory**
- Record: `drivers/clk/imx/clk-imx8qxp-lpcg.c` — **+1 / −0**. One line
  after `imx8qxp_lpcg_match[]`. Surgical, single-file.

**Step 2.2 — Flow**
- Record: Before: `imx8qxp_lpcg_match` is only `of_match_table` (used
  after the module is already loaded). After: same table is also a
  `MODULE_DEVICE_TABLE(of, …)` so file2alias/modpost emits aliases at
  build time. No probe/runtime path change.

**Step 2.3 — Bug mechanism**
- Record: **Hardware/module autoload (OF alias publication)**. Match
  table exists (`fsl,imx8qxp-lpcg-adma/conn/lsio` and `fsl,imx8qxp-
  lpcg`) but is not exported. Same class as adding device IDs: userspace
  cannot match hardware to the module.

**Step 2.4 — Fix quality**
- Record: Obviously correct; matches every other i.MX clk driver that
  already has `MODULE_DEVICE_TABLE(of, …)` (`clk-imx8qxp.c`, `clk-
  imx8mm.c`, etc.). No API, locking, or structural change. Regression
  risk is negligible: `=y` ignores aliases; `=m` only adds autoload.

---

## PHASE 3: GIT HISTORY

**Step 3.1 — Blame**
- Record: Match table from `1e3121bfe51a3` (“clk: imx: add imx8qxp lpcg
  driver”, 2018, in **v5.0-rc1**). Module metadata from `e0d0d4d86c766`
  (“Support building i.MX8QXP clock driver as module”, **v5.10-rc1**).
  `builtin_platform_driver` → `module_platform_driver` in
  `eee377b8f44e7` (2021, Fixes: that module-support commit). The hole
  has been there for the whole modular lifetime of the driver.

**Step 3.2 — Fixes: tag**
- Record: None. Buggy omission is the module-support work
  (`e0d0d4d86c766` / `eee377b8f44e7`). Both are in this tree.

**Step 3.3 — File history**
- Record: Recent file commits are unrelated (pm_runtime, ioremap).
  Sibling `cd21fdcbef3fb` does the same for `clk-imx8qxp.c`. Standalone;
  not “patch X/Y”.

**Step 3.4 — Author**
- Record: Pengpeng Hou also added the same fix for `clk-imx8qxp.c` and
  MediaTek mt6735 clocks. Not the clk-imx maintainer; Abel Vesa applied
  it with three subsystem/vendor reviews.

**Step 3.5 — Dependencies**
- Record: Needs `imx8qxp_lpcg_match`, `module_platform_driver`, and
  `<linux/module.h>`. All present here. Applies as a single line.

---

## PHASE 4: MAILING LIST / EXTERNAL

**Step 4.1 — Original thread**
- Record: `b4 dig -c e89485455ac49` →
  https://patch.msgid.link/20260704150344.59563-1-pengpeng@iscas.ac.cn
- `b4 dig -a`: **v1 only**, 2026-07-04.
- Review: Peng Fan, Brian Masney, Frank Li: Reviewed-by only. Abel Vesa:
  “Applied, thanks!” No NAK, no stable tag, no risk discussion.

**Step 4.2 — Recipients (`b4 dig -w`)**
- Record: Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd, Frank
  Li, Sascha Hauer, Fabio Estevam; `linux-clk`, `imx@lists.linux.dev`,
  `linux-arm-kernel`, `linux-kernel`. Right maintainers and lists.

**Step 4.3 — Bug report**
- Record: No Reported-by / bugzilla / syzbot. Inspection-only, as the
  commit says.

**Step 4.4 — Series**
- Record: Standalone 1/1. Related but independent sibling on `clk-
  imx8qxp.c`.

**Step 4.5 — Stable list**
- Record: Thread has no stable nomination. Direct lore.kernel.org
  fetches returned **403**; no separate stable-list discussion verified.

---

## PHASE 5: CODE SEMANTICS

**Step 5.1 — Functions**
- Record: No C function changed. Macro `MODULE_DEVICE_TABLE(of,
  imx8qxp_lpcg_match)` next to the existing `of_device_id` table. Driver
  still uses `module_platform_driver(imx8qxp_lpcg_clk_driver)`.

**Step 5.2 — “Callers”**
- Record: Build-time: `scripts/mod/file2alias.c` looks up
  `__mod_device_table__` and emits `of:` aliases. Runtime: kmod/udev on
  DT `compatible`. Probe path unchanged. Makefile: `clk-imx-lpcg-
  scu-$(CONFIG_CLK_IMX8QXP)` → aliases belong to `clk-imx-lpcg-scu.ko`.

**Step 5.3 — Callees**
- Record: None at runtime. Macro only creates an aliased copy of the
  table for modpost.

**Step 5.4 — Reachability**
- Record: Yes, from userspace/DT: i.MX8QXP/8QM DTS uses `fsl,imx8qxp-
  lpcg` (e.g. `arch/arm64/boot/dts/freescale/imx8qm-ss-*.dtsi`). With
  `=m`, udev should load the module from that compatible. `arm64
  defconfig` has `CONFIG_CLK_IMX8QXP=y`, so the default distro/defconfig
  path is unaffected; custom/distro `=m` is the affected path.

**Step 5.5 — Similar patterns**
- Record: Same missing-table pattern fixed in `clk-imx8qxp.c` and
  several other `drivers/clk/imx/*` files already have
  `MODULE_DEVICE_TABLE`. This was the LPCG outlier.

---

## PHASE 6: THIS TREE

**Step 6.1 — Buggy code here?**
- Record: Yes. Pre-commit parent still has the table without
  `MODULE_DEVICE_TABLE`. Module support is in this tree. Bug dates to
  v5.10 module support (autoload hole after v5.16
  `module_platform_driver`).

**Step 6.2 — Backport difficulty**
- Record: **Clean apply**. Context around the match table matches the
  hunk.

**Step 6.3 — Already fixed another way?**
- Record: No other autoload fix on this file. This commit *is* the fix
  (already upstream in 7.3-rc). No substitute.

---

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1**
- Record: `[drivers/clk/imx — i.MX8QXP LPCG] [IMPORTANT for
  i.MX8QXP/8QM; PERIPHERAL vs core kernel]`. Clock provider: if the
  module never loads, LPCG-gated peripherals fail probe.

**Step 7.2**
- Record: clk-imx is active (7.3 pulls). This driver itself is mature
  (2018).

---

## PHASE 8: IMPACT AND RISK

**Step 8.1 — Who**
- Record: Config- and platform-specific: `CONFIG_CLK_IMX8QXP=m` on
  i.MX8QXP/8QM/8DXL SCU clocks. Not universal. Defconfig `=y` does not
  need aliases.

**Step 8.2 — Trigger**
- Record: Boot/enumeration with LPCG DT nodes and the driver as a
  module. Unprivileged users cannot trigger it; it is bring-up/udev.
  Common on modular distro kernels, uncommon on typical vendor `=y`
  images.

**Step 8.3 — Failure mode**
- Record: Module not autoloaded → LPCG clocks missing → dependent
  devices fail probe (UART/DMA/etc. depending on board). Not an
  oops/UAF. Severity **MEDIUM** (functional miss for `=m`), **HIGH** on
  those boards if clocks are modular.

**Step 8.4 — Risk vs benefit**
- Record: Benefit: modular i.MX8QXP clocks actually bind. Risk: **very
  low** (one line of metadata). Ratio favors taking it; same rationale
  as the “add a device ID” stable exception.

---

## PHASE 9: SYNTHESIS

**Step 9.1 — Evidence**

For:
- Real autoload bug: match table used, aliases not published.
- One line, obviously correct, reviewed by NXP i.MX and Red Hat.
- DT hardware uses these compatibles.
- Driver is tristate (`CLK_IMX8QXP`); `module_platform_driver` is
  intentional.
- Same pattern as device-ID publication, which stable explicitly allows.
- Applies cleanly; no new API; no runtime behavior change for `=y`.

Against:
- No user/syzbot report; source-level only.
- Not crash/corruption/security.
- `arm64 defconfig` is `=y`.
- No `Cc: stable` (not a negative by itself).

Unresolved:
- Could not search lore.kernel.org/stable (HTTP 403). Original thread
  had no stable discussion.

**Step 9.2 — Stable rules**
1. Obviously correct and tested? **PASS** — one-line, three reviews,
   maintainer applied.
2. Real bug that affects users? **PASS** — `=m` does not autoload; DTS
   uses the IDs.
3. Important? **PASS** (as device-ID/autoload class; not a panic).
   Missing clocks on modular i.MX8 is user-visible, not trivia.
4. Small and contained? **PASS** — +1 line, one file.
5. No new features/APIs? **PASS** — metadata only.
6. Can apply to this tree? **PASS** —
   file/table/`module_platform_driver` all present.

**Step 9.3 — Exceptions**
- Record: Device-ID / module-alias publication for an existing driver
  (stable exception #1 in spirit).

**Step 9.4 — Decision**
This is a one-line, reviewed autoload fix for a long-standing modular
i.MX8QXP LPCG driver. It matches what stable already takes for device
IDs: hardware described in DT can bind without a manual `modprobe`. Risk
is negligible on this tree.

---

## What the commit solves for this tree

Without `MODULE_DEVICE_TABLE()`, `clk-imx-lpcg-scu.ko` has no
`of:N*T*Cfsl,imx8qxp-lpcg*` aliases. kmod will not load it from DT. LPCG
is a clock provider, so that shows up as missing clocks and failed
consumer probe, not as a crash. The fix only publishes the table the
driver already uses.

It meets the stable bar: obviously correct, tiny, no new API, real
modular-load bug, applies here.

Risk vs benefit: benefit is correct autoload for `CONFIG_CLK_IMX8QXP=m`;
risk is essentially zero.

Concerns: no live repro, default `=y`. That does not outweigh a one-line
alias export that other i.MX clk drivers already have.

---

## Verification
- [Phase 1] `git log -1 e89485455ac49`: tags as above; no
  Fixes/Reported-by/Cc:stable.
- [Phase 2] `git show e89485455ac49`: +1 `MODULE_DEVICE_TABLE(of,
  imx8qxp_lpcg_match)`.
- [Phase 2] Read `clk-imx8qxp-lpcg.c`: table used as `.of_match_table`;
  `module_platform_driver`.
- [Phase 2] `include/linux/module.h`: macro creates `__mod_device_table`
  alias for modpost.
- [Phase 3] `git blame` 350–370: table `1e3121bfe51a3` (v5.0); line
  `e89485455ac49`.
- [Phase 3] `e0d0d4d86c766` in v5.10-rc1 (tristate); `eee377b8f44e7`
  switches to `module_platform_driver`.
- [Phase 3] `git merge-base --is-ancestor e89485455ac49 HEAD` succeeded.
- [Phase 3] Parent file confirmed missing `MODULE_DEVICE_TABLE`.
- [Phase 4] `b4 dig -c/-a/-w` and `b4 dig -m`: v1 thread, three R-b,
  Abel applied; To/Cc = clk + i.MX lists.
- [Phase 4] lore HTTP 403; stable-list search **UNVERIFIED**.
- [Phase 5] `Kconfig`: `CLK_IMX8QXP` tristate; Makefile builds `clk-imx-
  lpcg-scu`.
- [Phase 5] DTS: `fsl,imx8qxp-lpcg` in imx8qm-ss-*.dtsi.
- [Phase 5] defconfig: `CONFIG_CLK_IMX8QXP=y`.
- [Phase 6] `git describe HEAD` / `make kernelversion`: 7.3.0-rc4; buggy
  table present; clean apply.
- [Phase 6] Sibling `cd21fdcbef3fb` is a different file; not required
  for this hunk.
- [Phase 8] Failure mode: no autoload when `=m` — verified from code and
  MODULE_DEVICE_TABLE semantics, not from a hardware log.
- UNVERIFIED: live `=m` boot on i.MX8QXP; lore.kernel.org/stable
  contents.

**YES**

 drivers/clk/imx/clk-imx8qxp-lpcg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/imx/clk-imx8qxp-lpcg.c b/drivers/clk/imx/clk-imx8qxp-lpcg.c
index 1dae3410ee99a..f0cf6cf918992 100644
--- a/drivers/clk/imx/clk-imx8qxp-lpcg.c
+++ b/drivers/clk/imx/clk-imx8qxp-lpcg.c
@@ -354,6 +354,7 @@ static const struct of_device_id imx8qxp_lpcg_match[] = {
 	{ .compatible = "fsl,imx8qxp-lpcg", NULL },
 	{ /* sentinel */ }
 };
+MODULE_DEVICE_TABLE(of, imx8qxp_lpcg_match);
 
 static struct platform_driver imx8qxp_lpcg_clk_driver = {
 	.driver = {
-- 
2.53.0

[PATCH AUTOSEL 6.18-6.12] i2c: imx-lpi2c: properly unwind resources on probe failure

[Sasha Levin]

From: Carlos Song <carlos.song@nxp.com>

[ Upstream commit cbd043b00ee3f542c115c8809c4d9a67465c07d5 ]

When probe fails at devm_clk_rate_exclusive_get() or clk_get_rate(),
which occur before runtime PM is initialized, the clocks enabled by
clk_bulk_prepare_enable() are never disabled.

When probe fails after runtime PM is initialized, the previous error
path called pm_runtime_put_sync(), which triggers the runtime suspend
callback. However, due to different clock management strategies on
different SoCs[1] (to avoid deadlocks between the global prepare_lock
and runtime PM), the callback may only disable clocks without
unpreparing them, causing an incomplete unwind.

Introduce a new error label 'clk_disable' to explicitly invoke
clk_bulk_disable_unprepare(). Replace pm_runtime_put_sync() with the
sequence of pm_runtime_disable(), pm_runtime_set_suspended() and
pm_runtime_put_noidle() to bypass the runtime suspend callback during
error recovery. During the LPI2C driver probe phase, clock APIs are
used exclusively to manage clocks. Once probing succeeds, clock
management is handed over to the runtime PM core.

[1] https://lore.kernel.org/all/20251125084718.2156168-1-carlos.song@nxp.com/

Signed-off-by: Carlos Song <carlos.song@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20260716071957.2670263-2-carlos.song@oss.nxp.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local tree is **6.12.111** (`pending-6.12`). The buggy probe unwind
is present here; the later SoC-specific clock strategy is not. The leak
is real and the fix is a small error-path change.

===============================================================
PHASE 1: COMMIT MESSAGE FORENSICS
===============================================================

Step 1.1: PARSE THE SUBJECT LINE
Record: **[i2c: imx-lpi2c]** **[properly unwind]** probe resources are
not released when `lpi2c_imx_probe()` fails. “Properly unwind” is fix
language (missing cleanup), not a feature.

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- **Fixes:** none (expected for this review queue)
- **Reported-by / Tested-by / Acked-by / Cc: stable:** none
- **Reviewed-by:** Frank Li &lt;Frank.Li@nxp.com&gt;
- **Signed-off-by:** Carlos Song &lt;carlos.song@nxp.com&gt; (author);
  Andi Shyti &lt;andi.shyti@kernel.org&gt; (I2C maintainer, merger)
- **Link:** https://lore.kernel.org/r/20260716071957.2670263-2-
  carlos.song@oss.nxp.com
- **Inline [1]:** https://lore.kernel.org/all/20251125084718.2156168-1-
  carlos.song@nxp.com/ (later SoC clock/IRQ RPM split)
- Ignore any pipeline SOBs / “Upstream commit” markers

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- **Bug:** After `clk_bulk_prepare_enable()`, two classes of probe
  failure leak clocks.
  1. Failures **before** RPM init (`devm_clk_rate_exclusive_get()`,
     `clk_get_rate()`): early `return` leaves clocks prepared **and**
     enabled.
  2. Failures **after** RPM init: `pm_runtime_put_sync()` runs
     `lpi2c_runtime_suspend()`, which on this tree only
     `clk_bulk_disable()`s (no unprepare), so the prepare count is left
     elevated.
- **Symptom:** Unbalanced clock prepare/enable. On `-EPROBE_DEFER` the
  prepare count grows on every retry.
- **Root cause:** Probe uses clock APIs; after success, RPM owns
  enable/disable. Error paths mixed the two and did not fully unwind.
- **Version info in message:** none for 6.12. `[1]` is the later
  i.MX8QXP/8QM RPM split (`949f647eff76a`, **not** in this tree).

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not hidden. Explicit resource-leak / incomplete error-path
unwind. Not style cleanup.

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

Step 2.1: INVENTORY THE CHANGES
Record:
- **File:** `drivers/i2c/busses/i2c-imx-lpi2c.c` (+14 / −7)
- **Function:** `lpi2c_imx_probe()` only
- **Scope:** single-file, error-path only

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- **Hunk 1 (pre-RPM errors):** `return dev_err_probe(...)` after
  exclusive-get / `clk_get_rate()` failure → `goto clk_disable` so
  `clk_bulk_disable_unprepare()` runs.
- **Hunk 2 (post-RPM errors):** `rpm_disable` no longer
  `pm_runtime_put_sync()`. It now `pm_runtime_disable()`,
  `pm_runtime_set_suspended()`, `pm_runtime_put_noidle()`, then falls
  through to `clk_disable` for `clk_bulk_disable_unprepare()`.
- **Success path:** unchanged (`pm_runtime_put_autosuspend()` still
  hands clocks to RPM).

Step 2.3: IDENTIFY THE BUG MECHANISM
Record: **Error-path resource leak (clock prepare/enable).**
- Missing `clk_bulk_disable_unprepare()` on early probe failure.
- RPM suspend used as unwind, but in **this** tree
  `lpi2c_runtime_suspend()` is only `clk_bulk_disable()` (since
  `fa39065833dbd`), so prepare is never reversed.
- `clk_disable` is an added put/unprepare, not a double-free: RPM
  suspend is skipped, then clocks are disabled and unprepared once.

Step 2.4: ASSESS THE FIX QUALITY
Record: Surgical and correct for this tree. Same pattern as other probe-
fail RPM unwinds. Success path untouched. Regression risk is low; the
only real risk is pairing `put_sync` with `disable_unprepare` (double-
disable). This patch removes `put_sync` and does one explicit unwind.

===============================================================
PHASE 3: GIT HISTORY INVESTIGATION
===============================================================

Step 3.1: BLAME THE CHANGED LINES
Record (this checkout):
- Early leak: `4268254a39484` (“Avoid calling clk_get_rate during
  transfer”, 2024-05-06) — **in v6.12**.
- RPM enable/disable-only callbacks: `fa39065833dbd` (2023) — **in
  v6.12**.
- `rpm_disable` + `put_sync`: `4f4388a55019d` / upstream `b1852c5de2f2a`
  (“Fix clock count when probe defers”) — **already in this 6.12 tree**.
  That only fixed the **enable** count; prepare still leaks.
- `-EPROBE_DEFER` from recovery pinctrl: `188542964e782` — **in this
  tree**.

Step 3.2: FOLLOW THE FIXES: TAG
Record: No `Fixes:` tag. Bug-introducing history above is in this tree.
`cbd043b00ee3f` is **not** an ancestor of HEAD.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record: Latest local change is `4f4388a55019d` (the incomplete enable-
count fix). This commit is the missing prepare-count half of that
unwind. Standalone for 6.12; does not need DMA, `hwdata`, or
`need_prepare_unprepare_clk`.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Carlos Song is an NXP LPI2C contributor (GPIO recovery in this
tree). Frank Li reviewed. Andi Shyti merged. Series v6 patch 2
(`a4c419356a333`, controller reset) is independent and not required.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record: Message cites later SoC clock strategies (`949f647eff76a`,
2026-01-19) — **not in 6.12**. The **code** of this fix does not use
`hwdata` / `need_prepare_unprepare_clk`. Needed APIs
(`clk_bulk_disable_unprepare`, `pm_runtime_put_noidle`,
`pm_runtime_set_suspended`) exist in 6.12. **Can be backported
standalone** with context tweaks.

===============================================================
PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
===============================================================

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- SHA: `cbd043b00ee3f542c115c8809c4d9a67465c07d5`
- `b4 dig -c`: https://patch.msgid.link/20260716071957.2670263-2-
  carlos.song@oss.nxp.com
- Series: **v6 1/2** “fix probe error handling and reset controller”
  (v4/v5/v6 of the same subject)
- Andi Shyti: merged to `i2c/i2c-2` (2026-07-28). No NAK.
- Cover letter: v3 replaced `put_sync` with disable + set_suspended +
  put_noidle specifically to avoid the suspend callback during error
  recovery.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record (`b4 dig -w`): linux-i2c, imx@lists, linux-arm-kernel; Andi
Shyti; Dong Aisheng (LPI2C maintainer in MAINTAINERS); Frank Li
(Reviewed-by); Pengutronix i.MX folks. Right audience.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No syzbot/bugzilla. Bug is from code review / NXP analysis, not
a crash report. Still a concrete leak with a documented `-EPROBE_DEFER`
path.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Patch 2/2 (reset in probe) is a separate hang-on-boot issue; not
a dependency. Earlier `b1852c5`/`4f4388a55019d` is the related
incomplete stable fix already here.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: lore.kernel.org/stable returned HTTP 403. No stable nomination
on the patch itself. Related defer clock-count fix **was** `Cc: stable #
v4.16+` and is already in this tree.

===============================================================
PHASE 5: CODE SEMANTIC ANALYSIS
===============================================================

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: `lpi2c_imx_probe()` only. Unwind interacts with
`lpi2c_runtime_suspend()` (not edited).

Step 5.2: TRACE CALLERS
Record: `.probe = lpi2c_imx_probe` on the platform driver. Called from
driver core on DT devices (`fsl,imx7ulp-lpi2c`) and on deferred retry.
Not a syscall hot path.

Step 5.3: TRACE CALLEES
Record: `clk_bulk_prepare_enable` / `clk_bulk_disable_unprepare`,
`devm_clk_rate_exclusive_get`, `clk_get_rate`, RPM helpers,
`lpi2c_imx_init_recovery_info()` (`devm_pinctrl_get` → `-EPROBE_DEFER`),
`i2c_add_adapter()`.

Step 5.4: FOLLOW THE CALL CHAIN
Record: Reachable at boot and on probe defer.
`lpi2c_imx_init_recovery_info()` is a real `-EPROBE_DEFER` source when
pinctrl is not ready. Unprivileged userspace does not need to trigger
it.

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record: Other I2C drivers use `clk_disable:` /
`clk_bulk_disable_unprepare` on probe fail (`i2c-qcom-geni.c`,
`i2c-qcom-cci.c`). This driver was the odd one out after RPM callbacks
stopped unpreparing.

===============================================================
PHASE 6: CROSS-REFERENCING AGAINST THE LOCAL TREE
===============================================================

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record: **Yes.** `lpi2c_imx_probe()` in `drivers/i2c/busses/i2c-imx-
lpi2c.c` still does:

```609:625:drivers/i2c/busses/i2c-imx-lpi2c.c
        ret = clk_bulk_prepare_enable(lpi2c_imx->num_clks,
lpi2c_imx->clks);
        if (ret)
                return ret;
        ...
        if (ret)
                return dev_err_probe(...);  /* exclusive_get: leak */
        ...
        if (!lpi2c_imx->rate_per)
                return dev_err_probe(...);  /* rate 0: leak */
```

```654:657:drivers/i2c/busses/i2c-imx-lpi2c.c
rpm_disable:
        pm_runtime_dont_use_autosuspend(&pdev->dev);
        pm_runtime_put_sync(&pdev->dev);
        pm_runtime_disable(&pdev->dev);
```

```672:679:drivers/i2c/busses/i2c-imx-lpi2c.c
static int __maybe_unused lpi2c_runtime_suspend(struct device *dev)
{
        ...
        clk_bulk_disable(lpi2c_imx->num_clks, lpi2c_imx->clks);
```

No `hwdata` / `need_prepare_unprepare_clk` here, so **every** SoC only
disables in RPM. The prepare leak on `rpm_disable` is unconditional.

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: **`git apply --check` fails** because context includes
`hwdata->need_prepare_unprepare_clk` and later DMA probe code. Logical
change maps 1:1 onto this probe (same exclusive-get returns, same
`rpm_disable` + `put_sync`). Difficulty: **minor context backport**, not
a rewrite.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: `4f4388a55019d` is here and only switched `pm_runtime_put()` to
`put_sync()`. It does **not** unprepare. No other unwind of this leak in
this tree.

===============================================================
PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
===============================================================

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: I2C bus driver for i.MX LPI2C (`CONFIG_I2C_IMX_LPI2C`,
`ARCH_MXC`). **IMPORTANT** for i.MX boards (PMIC, audio, sensors on that
bus), not core MM/VFS. Maintainer: Dong Aisheng; I2C maintainer merged
it.

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Mature driver (since ~2016). This tree’s recent churn is small
fixes, not a rewrite. The big SoC RPM split landed after 6.12.

===============================================================
PHASE 8: IMPACT AND RISK ASSESSMENT
===============================================================

Step 8.1: DETERMINE WHO IS AFFECTED
Record: **Driver-specific / platform-specific** — i.MX systems using
LPI2C. Common on i.MX7ULP / i.MX8 class boards, not all Linux users.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record:
- Exclusive-get / zero clock rate: uncommon hard errors.
- **`-EPROBE_DEFER` from pinctrl in recovery init:** normal boot race;
  retries leak another prepare each time.
- `i2c_add_adapter()` failure: less common.
- Not a userspace-triggered security path.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record: Clock prepare leak (and enable leak on the pre-RPM returns).
Repeated defer can unbalance the clock tree, keep parents prepared, and
block low power. Not an oops/corruption/CVE. **Severity: MEDIUM**,
higher if defer retries pile up.

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- **Benefit:** Completes the unwind that `4f4388a55019d` only half-
  fixed; stops prepare-count growth on defer. Medium benefit for i.MX
  LPI2C users.
- **Risk:** ~20-line error-path change; success path unchanged. Low risk
  if backported without keeping `put_sync`.
- **Ratio:** Favorable.

===============================================================
PHASE 9: FINAL SYNTHESIS
===============================================================

Step 9.1: COMPILE THE EVIDENCE

**FOR backporting:**
- Real clock leak on probe failure, including a documented
  `-EPROBE_DEFER` path.
- Buggy code is in this 6.12 tree (exclusive-get + disable-only RPM +
  `put_sync` unwind).
- This tree already took the enable-count half (`4f4388a55019d`); this
  is the remaining prepare-count fix.
- Small, probe-error only; reviewed and merged by the I2C maintainer.
- No new API/feature; no `hwdata` dependency in the changed lines.

**AGAINST:**
- Does not apply with `git apply` as-is (later DMA/`hwdata` context).
- Not a crash/security/corruption bug.
- No `Cc: stable` / syzbot / user crash report.
- Message talks about later per-SoC clock strategies that 6.12 does not
  have (the leak is still real here, and simpler).

**UNRESOLVED:**
- Stable list search was blocked (HTTP 403). Unverified whether anyone
  already NAK’d this for stable.

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — explicit unwind; merged
   after v4–v6 review.
2. Fixes a real bug that affects users? **PASS** — clock leak on probe
   fail/defer.
3. Important issue? **PASS** at medium — not panic-level, but resource
   leak on a normal defer path; sister fix already went to stable.
4. Small and contained? **PASS** — one function, error labels only.
5. No new features or APIs? **PASS**.
6. Can apply to the local tree? **PASS with backport** — code is here;
   context needs a small edit. Not “code missing / bug introduced after
   branch.”

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: None (not an ID/quirk/DT/build/docs exception). Qualifies as a
normal small bugfix.

Step 9.4: MAKE YOUR DECISION
Backport to **this** 6.12 tree. The later SoC RPM split is not required.
Drop `hwdata`/DMA context and apply the same `goto clk_disable` + RPM-
bypass + `clk_bulk_disable_unprepare()` sequence to `lpi2c_imx_probe()`.

Verification:
- [Phase 1] Tags: Reviewed-by Frank Li; SOB Andi Shyti; Link to v6 1/2;
  no Fixes/Cc:stable/syzbot
- [Phase 2] Diff: +14/−7 in `lpi2c_imx_probe()`; two early returns →
  `clk_disable`; `put_sync` → disable/set_suspended/put_noidle +
  `clk_bulk_disable_unprepare`
- [Phase 3] Blame: leak from `4268254a39484` (in v6.12); RPM disable-
  only from `fa39065833dbd` (in v6.12); incomplete enable fix
  `4f4388a55019d` already in HEAD
- [Phase 3] `git merge-base --is-ancestor cbd043b00ee3f HEAD` → not in
  this tree
- [Phase 3] `949f647eff76a` (`need_prepare_unprepare_clk`) → **not** in
  this tree
- [Phase 4] `b4 dig -c cbd043b00ee3f`: lore v6 1/2; Andi merged to
  i2c-2; no NAK
- [Phase 4] Cover: v3 introduced the RPM-bypass unwind; patch 2/2 is
  independent
- [Phase 4] UNVERIFIED: stable@ lore (403)
- [Phase 5] Probe is platform `.probe`; `-EPROBE_DEFER` from
  `devm_pinctrl_get` in recovery init
- [Phase 6] `git describe` / Makefile: 6.12.111; buggy returns and
  `rpm_disable` present; `git apply --check` fails on `hwdata` context
- [Phase 8] Failure mode: clock prepare leak, worse on deferred probe;
  severity MEDIUM; risk low

The leak exists on this 6.12 branch, the fix is small and correct, and
it finishes an unwind this tree already started.

**YES**

 drivers/i2c/busses/i2c-imx-lpi2c.c | 21 ++++++++++++++-------
 1 file changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
index 24c70ea371bb9..7c560a4f68319 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -1500,14 +1500,18 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 	 * each transfer
 	 */
 	ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk);
-	if (ret)
-		return dev_err_probe(&pdev->dev, ret,
-				     "can't lock I2C peripheral clock rate\n");
+	if (ret) {
+		ret = dev_err_probe(&pdev->dev, ret,
+				    "can't lock I2C peripheral clock rate\n");
+		goto clk_disable;
+	}
 
 	lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk);
-	if (!lpi2c_imx->rate_per)
-		return dev_err_probe(&pdev->dev, -EINVAL,
-				     "can't get I2C peripheral clock rate\n");
+	if (!lpi2c_imx->rate_per) {
+		ret = dev_err_probe(&pdev->dev, -EINVAL,
+				    "can't get I2C peripheral clock rate\n");
+		goto clk_disable;
+	}
 
 	pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_TIMEOUT);
 	pm_runtime_use_autosuspend(&pdev->dev);
@@ -1545,8 +1549,11 @@ static int lpi2c_imx_probe(struct platform_device *pdev)
 
 rpm_disable:
 	pm_runtime_dont_use_autosuspend(&pdev->dev);
-	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+	pm_runtime_put_noidle(&pdev->dev);
+clk_disable:
+	clk_bulk_disable_unprepare(lpi2c_imx->num_clks, lpi2c_imx->clks);
 
 	return ret;
 }
-- 
2.53.0