[PATCH AUTOSEL 6.18-5.10] iommu/rockchip: Clear stale page faults before enabling stall

[PATCH AUTOSEL 6.18-5.10] iommu/rockchip: Clear stale page faults before enabling stall

[Sasha Levin]

From: Jiaxing Hu <gahing@gahingwoo.com>

[ Upstream commit b10d5920cafa292ee3cab9c20f813da4fe4f00b8 ]

Boot firmware can leave an IOMMU bank in PAGE_FAULT_ACTIVE before the
driver has configured paging:

  PAGE_FAULT_ACTIVE=1  STALL_ACTIVE=0  IDLE=1

Such a bank ignores CMD_ENABLE_STALL and never reaches STALL_ACTIVE, so
rk_iommu_enable_stall()'s readx_poll_timeout() spins until it times out
(seen on the RK3576 NPU, whose MMUs share this poll across banks).

Rather than special-casing these banks in the stall path, acknowledge the
stale fault with CMD_PAGE_FAULT_DONE before enabling stall, so every bank
starts from a clean state and the normal stall sequence applies to all of
them.  Banks without a pending fault are untouched.

Signed-off-by: Jiaxing Hu <gahing@gahingwoo.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The local checkout is mainline **7.3-rc4**. The stall-timeout path is in
this tree, and the 13-line firmware leftover workaround is a real IOMMU
enable failure, not a new API.

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

**Step 1.1: PARSE THE SUBJECT LINE**
Record: **[iommu/rockchip] [Clear] [acknowledge leftover
PAGE_FAULT_ACTIVE so stall enable does not poll-timeout]**

**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
Record:
- Signed-off-by: Jiaxing Hu \<gahing@gahingwoo.com\> (author)
- Signed-off-by: Will Deacon \<will@kernel.org\> (IOMMU maintainer;
  applied the patch)
- No Fixes:, Reported-by:, Tested-by:, Reviewed-by:, Acked-by:, Link:,
  or Cc: stable (absence of Fixes/Cc:stable is expected for this review)

**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
Record:
- **Bug:** Boot firmware can leave an IOMMU bank in
  `PAGE_FAULT_ACTIVE=1`, `STALL_ACTIVE=0`, `IDLE=1` before the driver
  configures paging.
- **Symptom:** That bank ignores `CMD_ENABLE_STALL` and never reaches
  `STALL_ACTIVE`. `rk_iommu_enable_stall()`’s `readx_poll_timeout()`
  fails. Observed on the RK3576 NPU, whose MMUs share the stall poll
  across banks (`rk_iommu_is_stall_active()` ANDs every bank).
- **Root cause:** Stale firmware page-fault state blocks the stall
  command.
- **Fix:** Issue `CMD_PAGE_FAULT_DONE` on any bank that still has
  `PAGE_FAULT_ACTIVE`, then use the normal stall sequence. Banks without
  a pending fault are untouched.
- **Version info in message:** none beyond RK3576 NPU.

**Step 1.4: DETECT HIDDEN BUG FIXES**
Record: Not disguised. This is an explicit hardware/firmware leftover
workaround that prevents a stall-enable timeout.

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

**Step 2.1: INVENTORY THE CHANGES**
Record:
- File: `drivers/iommu/rockchip-iommu.c` — **+13 / -0**
- Function: `rk_iommu_enable_stall()`
- Scope: single-file surgical fix

**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
Record:
- **Before:** If stall is not already active and paging is enabled,
  broadcast `CMD_ENABLE_STALL` and poll until every bank reports
  `STALL_ACTIVE` (1 ms timeout, `RK_MMU_POLL_TIMEOUT_US=1000`). One
  stuck bank fails the whole poll.
- **After:** Same path, but first walk each bank; if
  `RK_MMU_STATUS_PAGE_FAULT_ACTIVE` is set, write
  `RK_MMU_CMD_PAGE_FAULT_DONE` to that bank’s command register, then
  enable stall as before.
- Path: initialization / attach / resume (`rk_iommu_enable` →
  `rk_iommu_enable_stall`), and also disable/suspend (return value
  ignored there).

**Step 2.3: IDENTIFY THE BUG MECHANISM**
Record: **[Hardware workaround / logic correctness]** Firmware leaves
`PAGE_FAULT_ACTIVE`. Hardware ignores `CMD_ENABLE_STALL` in that state.
`rk_iommu_enable()` treats stall timeout as fatal (`if (ret) goto
out_disable_clocks`), so the IOMMU never reaches
`rk_iommu_force_reset()` / paging setup and **device attach fails**. The
fix acks the leftover fault with the same command the IRQ handler
already uses (`RK_MMU_CMD_PAGE_FAULT_DONE`).

**Step 2.4: ASSESS THE FIX QUALITY**
Record: Minimal and readable. Gated on `PAGE_FAULT_ACTIVE`, so idle
banks are unchanged. Uses the existing command encoding. Regression risk
is low; the only flagged concern is not also writing `RK_MMU_INT_CLEAR`
(see Phase 4), which is incomplete-ack, not a new deadlock or API
change.

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

**Step 3.1: BLAME THE CHANGED LINES**
Record:
- `rk_iommu_enable_stall()` introduced in **c68a292152d32**
  (`iommu/rockchip: rk3288 iommu driver`, 2014) — contained in
  **v3.19-rc1**.
- Multi-bank `num_mmu` loop: **cd6438c5f8446**, contained in
  **v4.6-rc1**.
- `readx_poll_timeout`: **0416bf6479acef**, contained in **v4.17-rc1**.
- The 13-line ack loop is this commit (**b10d5920cafa2**).

**Step 3.2: FOLLOW THE FIXES: TAG**
Record: No Fixes: tag. Not applicable. Buggy interaction is firmware
leftover vs stall path that has existed for years.

**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Record:
- Immediate parent on the file: **841363ebb5082** `iommu/rockchip: Take
  all DT clocks` — same author, same RFC series (patch 4/8). Different
  problem (extra clocks so DTE_ADDR writes land). **Not a code
  dependency** of the stall ack.
- No later commits on this file after b10d5920cafa2 in this tree.
- Standalone IOMMU change; Will applied 4/8 and 5/8 without the rest of
  the NPU series.

**Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS**
Record: Jiaxing Hu is not the IOMMU maintainer. In this tree, two
rockchip-iommu commits (clocks + this). Will Deacon applied both.

**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
Record: Diff only needs `rk_iommu_enable_stall`, `num_mmu`,
`RK_MMU_STATUS_PAGE_FAULT_ACTIVE`, `RK_MMU_CMD_PAGE_FAULT_DONE` — all
present long before 7.3. **Can apply standalone.**

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

**Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION**
Record:
- Lore (via b4):
  https://patch.msgid.link/20260718031146.3368811-6-gahing@gahingwoo.com
- Series: **[RFC PATCH v2 0/8] accel/rocket: RK3576 NPU (RKNN)
  enablement**
- This patch is **v2 5/8**. v1 had two “skip orphaned-fault banks”
  patches; v2 replaced them with this fault-ack after Chaoyi Chen asked
  whether clearing the fault avoids skipping banks.
- Will Deacon (2026-07-26): “Applied driver changes to iommu (rockchip)”
  for 4/8 and 5/8. No NAK on this patch.
- Cover letter: NPU bring-up is still incomplete (“full inference is not
  correct yet”). This IOMMU fix was still taken on its own.
- v3 of the wider series was not out when Will applied this; applied
  version is the latest for this hunk.

**Step 4.2: CHECK WHO REVIEWED THE PATCH**
Record: Recipients included Will Deacon, Joerg Roedel, Robin Murphy,
Heiko Stuebner, iommu@lists.linux.dev, linux-rockchip. No human
Reviewed-by on 5/8 in the thread. Will applied it. Sashiko bot
(automated) commented.

**Step 4.3: SEARCH FOR THE BUG REPORT**
Record: No syzbot/bugzilla. Author hit it on a Radxa ROCK 4D while
bringing up the RK3576 NPU IOMMUs. Cover letter lists “clearing a stale
firmware page fault” as required for those IOMMUs to come up.

**Step 4.4: CHECK FOR RELATED PATCHES AND SERIES**
Record: RFC 8-patch NPU enablement. Only the two IOMMU driver patches
were merged. NPU DT/driver patches are **not** in this tree (no NPU
IOMMU nodes in `rk3576.dtsi`). This stall patch does not depend on them.

**Step 4.5: CHECK STABLE MAILING LIST HISTORY**
Record: lore.kernel.org/stable search returned HTTP 403. **UNVERIFIED**
whether stable@ discussed this. No in-tree grep hit except this commit.

Sashiko bot concern (verified from mbox): `CMD_PAGE_FAULT_DONE` without
`RK_MMU_INT_CLEAR` might leave a raw IRQ pending. On `rockchip,disable-
mmu-reset` instances (in-tree: px30, rk3288, rk3368, rk3399, rk356x,
rk3576 vdec), `rk_iommu_force_reset()` is skipped, then
`RK_MMU_INT_MASK` is programmed in `rk_iommu_enable()`. A leftover raw
bit could fire a page-fault IRQ. The existing IRQ handler already logs,
optionally `report_iommu_fault()`, zaps cache, issues `PAGE_FAULT_DONE`,
and clears INT_STATUS. That is a possible spurious IRQ/log, not a
verified panic. No follow-up commit addressed it; Will still applied the
patch.

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

**Step 5.1: IDENTIFY KEY FUNCTIONS**
Record: `rk_iommu_enable_stall()` (modified). Helpers used:
`rk_iommu_read`, `rk_iommu_is_stall_active`,
`rk_iommu_is_paging_enabled`, `rk_iommu_command`.

**Step 5.2: TRACE CALLERS**
Record:
- `rk_iommu_disable()` line 928 — detach / runtime suspend. Return
  ignored.
- `rk_iommu_enable()` line 950 — attach / runtime resume. **Failure
  aborts enable.**
- `rk_iommu_enable()` called from `rk_iommu_attach_device()` (line 1064)
  and `rk_iommu_resume()` (line 1349).

**Step 5.3: TRACE CALLEES**
Record: MMIO status/command. No allocation, no new locks.
`writel(RK_MMU_CMD_PAGE_FAULT_DONE, base + RK_MMU_COMMAND)` matches
`rk_iommu_base_command()`.

**Step 5.4: FOLLOW THE CALL CHAIN**
Record: Userspace/DMA attach or runtime PM resume →
`rk_iommu_attach_device` / `rk_iommu_resume` → `rk_iommu_enable` →
`rk_iommu_enable_stall`. Reachable on Rockchip SoCs with
`CONFIG_ROCKCHIP_IOMMU`. Trigger is firmware leftover + paging already
enabled. Not a syscall fuzz path; it is device bring-up.

**Step 5.5: SEARCH FOR SIMILAR PATTERNS**
Record: IRQ path already does `RK_MMU_CMD_PAGE_FAULT_DONE` (line 642)
plus `RK_MMU_INT_CLEAR`. No other stall-path fault ack. In-tree RK3576
`vdec_mmu` is two-bank (`reg` two regions), so the AND-poll issue is not
NPU-only in principle.

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

**Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?**
Record: **Yes.** Local tree: `git describe HEAD` =
**v7.3-rc4-27-gf0100363d8c37**, `make kernelversion` = **7.3.0-rc4**.
`rk_iommu_enable_stall()` is present; this commit is already an ancestor
of HEAD (`git merge-base --is-ancestor b10d5920cafa2 HEAD` succeeded).
Landed via `iommu-updates-v7.3` (not in v7.2). Stall path itself dates
to v3.19.

**Step 6.2: CHECK FOR BACKPORT COMPLICATIONS**
Record: Hunk is a contiguous insert after the paging-enabled check.
Expected apply: **clean** on trees that have the 2016 multi-bank
`num_mmu` loop (v4.6+). No conflicting later edits on this function in
this checkout.

**Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE**
Record: This is the only “stale page fault” commit. No alternate fix.
Sibling clocks change is independent.

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

**Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY**
Record: **drivers/iommu/rockchip-iommu.c** — Rockchip IOMMU.
Criticality: **IMPORTANT** (platform IOMMU for multimedia/NPU DMA; not
core mm/VFS, but attach failure takes down the consumer device).

**Step 7.2: ASSESS SUBSYSTEM ACTIVITY**
Record: Mature driver (2014), still receiving Rockchip bring-up fixes.
Joerg’s v7.3 pull: “Rework Rockchip state handling and fix clock, probe
and stale-fault handling.”

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

**Step 8.1: DETERMINE WHO IS AFFECTED**
Record: **driver-specific / platform-specific** —
`CONFIG_ROCKCHIP_IOMMU` on Rockchip. Practical trigger reported on
RK3576 NPU MMUs (those DT nodes are **not** in this tree). Any multi-
bank instance whose firmware leaves `PAGE_FAULT_ACTIVE` can hit the same
poll (e.g. in-tree RK3576 `vdec_mmu` has two banks).

**Step 8.2: DETERMINE THE TRIGGER CONDITIONS**
Record: Boot firmware leftover fault, then first stall enable while
paging is still enabled. Timing: probe/attach or resume, not a hot path.
Unprivileged users do not trigger it directly; it is firmware × driver
init. No public reproducer beyond the author’s ROCK 4D bring-up.

**Step 8.3: DETERMINE THE FAILURE MODE SEVERITY**
Record: **IOMMU enable fails after a 1 ms poll**
(`RK_MMU_POLL_TIMEOUT_US=1000`). Attach returns error; the DMA device
does not get a working IOMMU. **Not** a panic, hang, UAF, or corruption.
Severity: **HIGH** for the affected device (non-functional), **MEDIUM**
system-wide (1 ms timeout + error, rest of the machine continues).

**Step 8.4: CALCULATE RISK-BENEFIT RATIO**
Record:
- **Benefit:** Hardware/firmware workaround so stall enable succeeds;
  IOMMU attach can proceed. High for RK3576 NPU users; modest for other
  Rockchip boards unless firmware leaves the same bit.
- **Risk:** 13 lines, status-gated. Theoretical spurious IRQ if
  INT_STATUS is not cleared on `disable-mmu-reset` devices. No new
  locks/APIs.
- **Ratio:** Benefit outweighs risk. Same class as other hardware
  leftover/quirk fixes.

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

**Step 9.1: COMPILE THE EVIDENCE**

FOR:
- Real, explained failure: stall poll times out, `rk_iommu_enable()`
  aborts, device attach fails.
- Small (+13), contained, status-gated.
- Same command the IRQ handler already uses.
- Will Deacon applied it independently of the unfinished NPU RFC.
- v7.3 IOMMU pull listed stale-fault handling as a fix.
- Driver and stall path exist in this tree since v3.19 / v4.6.
- Hardware/firmware workaround (stable exception category).
- No new APIs or features.

AGAINST:
- Originated in an RFC series to enable RK3576 NPU; NPU IOMMU DT is
  still not in this tree.
- Observed on that NPU, not reported on long-shipped VOP/VDEC.
- Not crash/security/corruption; 1 ms timeout then enable failure.
- Sashiko noted missing `INT_CLEAR`; unaddressed.
- No Fixes:/Cc:stable (not a negative by itself).

UNRESOLVED:
- lore.kernel.org/stable search HTTP 403.
- Whether in-tree vdec/vop firmware also leaves `PAGE_FAULT_ACTIVE`
  (author only cited NPU).
- Whether a leftover INT_STATUS after `PAGE_FAULT_DONE` actually fires
  on `disable-mmu-reset` hardware.

**Step 9.2: APPLY THE STABLE RULES CHECKLIST**
1. Obviously correct and tested? **PASS** — logic matches the described
   hardware state; author tested on ROCK 4D; IOMMU maintainer applied
   it.
2. Fixes a real bug that affects users? **PASS** — stall timeout
   prevents IOMMU enable/attach.
3. Important issue? **PASS** — device IOMMU never comes up (not a panic,
   but hardware non-functional). Severity HIGH for that device.
4. Small and contained? **PASS** — 13 lines, one function.
5. No new features or APIs? **PASS**
6. Can apply to the local tree? **PASS** — stall path and symbols are
   here; hunk is a clean insert.

**Step 9.3: CHECK FOR EXCEPTION CATEGORIES**
Record: **Hardware quirk/workaround** — firmware leftover
`PAGE_FAULT_ACTIVE` so stall commands work. Not a new driver, not a new
userspace API.

**Step 9.4: MAKE YOUR DECISION**

This tree is 7.3-rc4; the stall path is old and the bug is a firmware
leftover vs that path, not a 7.3-only feature. The patch is a small,
maintainer-acked workaround that stops IOMMU attach from failing. Origin
in an unfinished NPU RFC does not make it a new API; Will merged it as a
standalone IOMMU fix. Missing `INT_CLEAR` is a residual IRQ-ack concern,
not a reason to drop a stall-timeout fix that already uses the
documented fault-done command.

Verification:
- [Phase 1] Parsed tags: only author SOB + Will Deacon SOB; no
  Fixes/Reported-by/Cc:stable
- [Phase 1] Body: PAGE_FAULT_ACTIVE leftover → ENABLE_STALL ignored →
  poll timeout on RK3576 NPU multi-bank poll
- [Phase 2] Diff: +13 in `rk_iommu_enable_stall()`; loop acks
  `PAGE_FAULT_ACTIVE` with `CMD_PAGE_FAULT_DONE`
- [Phase 2] `rk_iommu_enable()` returns on stall timeout before
  `force_reset` (line 950-952) — attach fails
- [Phase 3] git blame: function from c68a292152d32 (v3.19); poll from
  0416bf6479acef (v4.17); multi-mmu cd6438c5f8446 (v4.6)
- [Phase 3] git merge-base --is-ancestor b10d5920cafa2 HEAD: yes; not in
  v7.2; in v7.3-rc1
- [Phase 3] Sibling 841363ebb5082 is clocks-only; not required for this
  hunk
- [Phase 4] b4 dig -c b10d5920cafa2:
  https://patch.msgid.link/20260718031146.3368811-6-gahing@gahingwoo.com
- [Phase 4] b4 dig -a: RFC v1 (skip banks) → v2 (this ack); Will applied
  v2 4/8 and 5/8
- [Phase 4] b4 dig -w: iommu maintainers + rockchip list on CC
- [Phase 4] mbox: Will “Applied driver changes to iommu (rockchip)”;
  Sashiko INT_CLEAR warning; no human NAK
- [Phase 4] lore.kernel.org WebFetch/curl: HTTP 403 — stable-list
  discussion UNVERIFIED
- [Phase 5] Callers: disable (unchecked) and enable (fatal); enable from
  attach_device and resume
- [Phase 5] IRQ handler already issues PAGE_FAULT_DONE at line 642
- [Phase 6] git describe HEAD: v7.3-rc4-27-gf0100363d8c37; Makefile
  7.3.0-rc4; file present
- [Phase 6] No NPU IOMMU nodes in
  arch/arm64/boot/dts/rockchip/rk3576.dtsi; vdec_mmu is two-bank +
  disable-mmu-reset
- [Phase 7] iommu-updates-v7.3 merge text: “fix clock, probe and stale-
  fault handling”
- [Phase 8] Failure: 1 ms poll then IOMMU enable/attach failure; not
  oops/UAF
- UNVERIFIED: whether firmware leaves this bit on in-tree vdec/vop;
  whether INT_STATUS spurious IRQ reproduces; stable@ thread

The fix is small, surgical, and meets the stable criteria as a hardware
leftover workaround in a long-lived driver.

**YES**

 drivers/iommu/rockchip-iommu.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 309ba78e27d4f..982ea9cafee1b 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -422,6 +422,19 @@ static int rk_iommu_enable_stall(struct rk_iommu *iommu)
 	if (!rk_iommu_is_paging_enabled(iommu))
 		return 0;
 
+	/*
+	 * Boot firmware can leave a bank in PAGE_FAULT_ACTIVE with no handler
+	 * (PAGE_FAULT_ACTIVE & !STALL_ACTIVE & IDLE).  Such a bank ignores
+	 * CMD_ENABLE_STALL and never reaches STALL_ACTIVE, timing out the poll
+	 * below.  Acknowledge any stale fault first so every bank starts clean.
+	 */
+	for (i = 0; i < iommu->num_mmu; i++) {
+		if (rk_iommu_read(iommu->bases[i], RK_MMU_STATUS) &
+		    RK_MMU_STATUS_PAGE_FAULT_ACTIVE)
+			writel(RK_MMU_CMD_PAGE_FAULT_DONE,
+			       iommu->bases[i] + RK_MMU_COMMAND);
+	}
+
 	rk_iommu_command(iommu, RK_MMU_CMD_ENABLE_STALL);
 
 	ret = readx_poll_timeout(rk_iommu_is_stall_active, iommu, val,
-- 
2.53.0


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

[PATCH AUTOSEL 6.18-5.10] drm/rockchip: dw_hdmi: Use resume_early pm ops for system suspend

[Sasha Levin]

From: Jonas Karlman <jonas@kwiboo.se>

[ Upstream commit af3a9eadc11896f6677bcb7102bfb7c84be48d2d ]

rockchip_drm_sys_resume()/drm_mode_config_helper_resume() is called
before the resume pm ops of dw-hdmi. This result in an atomic_enable()
before dw_hdmi_rockchip_resume()/dw_hdmi_resume() is called.

Resume (without changes):
- rockchip_drm_sys_resume()
  - drm_mode_config_helper_resume()
    - atomic_enable()
- dw_hdmi_rockchip_resume()
  - dw_hdmi_resume()
    - dw_hdmi_init_hw()

Change to use resume_early pm ops for system suspend to ensure pm ops
for dw-hdmi is run before rockchip-drm pm ops. Also fix a possible NULL
pointer dereference timing issue while at it.

Resume (with changes):
- dw_hdmi_rockchip_resume_early()
  - dw_hdmi_resume()
    - dw_hdmi_init_hw()
- rockchip_drm_sys_resume()
  - drm_mode_config_helper_resume()
    - atomic_enable()

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Heiko Stuebner <heiko@sntech.de> #rk3328
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patch.msgid.link/20260518193748.2482823-12-jonas@kwiboo.se
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

I have the 6.18.y picture: the buggy resume path is in v6.18.53, the
patch is self-contained, and the DSI sibling already uses the same
late/early PM ordering. Compiling the full nine-phase verdict next.

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

Step 1.1: PARSE THE SUBJECT LINE
Record: [drm/rockchip: dw_hdmi] [Use] [switch HDMI system-resume
callback to resume_early so dw-hdmi re-inits before rockchip-drm
atomic_enable]

Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
Record:
- Tested-by: Heiko Stuebner <heiko@sntech.de> #rk3328 (Rockchip DRM
  maintainer; hardware-tested)
- Signed-off-by: Jonas Karlman <jonas@kwiboo.se> (author)
- Signed-off-by: Heiko Stuebner <heiko@sntech.de> (subsystem maintainer
  applied it)
- Link:
  https://patch.msgid.link/20260518193748.2482823-12-jonas@kwiboo.se
- No Fixes:, Reported-by, Reviewed-by, Acked-by, or Cc: stable (absence
  expected)
- Ignore pipeline tags: [Upstream commit
  af3a9eadc11896f6677bcb7102bfb7c84be48d2d], Signed-off-by: Sasha Levin

Notable: maintainer Tested-by on real RK3328 hardware.

Step 1.3: ANALYZE THE COMMIT BODY TEXT
Record:
- Bug: on system resume, `rockchip_drm_sys_resume()` →
  `drm_mode_config_helper_resume()` → atomic enable runs before
  `dw_hdmi_resume()` → `dw_hdmi_init_hw()`.
- Symptom: HDMI hardware (DDC I2C, HPD, interrupt mutes) is restored
  after DRM has already tried to re-enable the display pipeline.
- Secondary: “possible NULL pointer dereference timing issue” — resume
  can run with NULL drvdata.
- No stack trace, syzbot report, or CVE. Author gave simulated-suspend
  (`pm_test`) and `rtcwake` test steps in the mailing-list version.

Step 1.4: DETECT HIDDEN BUG FIXES
Record: Not disguised. It is an explicit PM-ordering fix plus a NULL
check. It was patch 11/11 of a series titled “Misc cleanup and propagate
bus format”, and was added in v2; the other patches are unrelated
cleanups/prep. This hunk is a standalone bug fix.

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

Step 2.1: INVENTORY THE CHANGES
Record:
- File: `drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c` (+4/-3, 7 lines)
- Functions: `dw_hdmi_rockchip_resume` renamed to
  `dw_hdmi_rockchip_resume_early`; `dw_hdmi_rockchip_pm` table
- Scope: single-file surgical PM-ops change

Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
Record:
- Before: `.resume` (normal phase) unconditionally calls
  `dw_hdmi_resume(hdmi->hdmi)`.
- After: `.resume_early` (early phase) calls it only if
  `dev_get_drvdata()` is non-NULL.
- `SET_SYSTEM_SLEEP_PM_OPS(NULL, resume)` →
  `SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, resume_early)`.
- Suspend remains NULL. Hibernation thaw/restore move from thaw/restore
  to thaw_early/restore_early, matching the same ordering intent.

Resume phase order is resume_noirq → resume_early → resume. HDMI
therefore always re-inits before rockchip-drm’s `.resume`.

Step 2.3: IDENTIFY THE BUG MECHANISM
Record:
- Primary: logic/correctness + hardware resume ordering. Sibling `dw-
  mipi-dsi-rockchip.c` already uses `SET_LATE_SYSTEM_SLEEP_PM_OPS` with
  the comment that it must run before `rockchip_drm_drv` re-enables
  panels.
- Secondary: memory safety — NULL check before `hdmi->hdmi` dereference
  when the platform device has probed (`component_add`) but not bound
  (`platform_set_drvdata` is in bind, not probe).

Step 2.4: ASSESS THE FIX QUALITY
Record:
- Obviously correct: Linux PM runs all `resume_early` callbacks before
  any `.resume`. That is the standard way to order a component ahead of
  the DRM master.
- Minimal; no API or data-structure change.
- Regression risk low: same pattern as the in-tree DSI sibling; only
  resume is registered; `dw_hdmi_init_hw()` only re-inits mutes, DDC
  I2C, and HPD.
- NULL check does not cover `hdmi->hdmi` being `ERR_PTR` after a failed
  bind; that is a leftover hole, not a regression from this patch.

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

Step 3.1: BLAME THE CHANGED LINES
Record:
- Buggy resume path introduced by `27c9130baef543` (“drm/rockchip:
  dw_hdmi: Handle suspend/resume”, Douglas Anderson, 2019-06-04), first
  in v5.3-rc1.
- That commit is an ancestor of this tree.
- That commit already documented the failure on rk3288 Chromebooks (HDMI
  HPD and DDC I2C stop working after suspend) and that Chrome OS 3.14
  used late/early PM ops because VOP sometimes resumed before dw-hdmi.
  Mainline used normal `.resume` because the author could not reproduce
  it then. This patch is the proper late/early fix for that known issue.

Step 3.2: FOLLOW THE FIXES: TAG
Record: No Fixes: tag. The introducing commit is `27c9130baef543`,
present here.

Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Record:
- Only two resume-related commits on this file: 27c9130baef543 (add
  resume) and this one.
- Recent 6.18.y file history is unrelated (SCLIN mask, FIELD_PREP,
  whitespace).
- Series-local neighbors (output_port, whitespace, empty helpers) are
  not functional prerequisites of this hunk.

Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Record: Jonas Karlman is a regular Rockchip HDMI/dw-hdmi contributor.
Heiko Stuebner (maintainer) applied the series and tested it on rk3328.

Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
Record:
- Series v2 11/11; cover letter says patches 1–10 are cleanup / YCbCr-
  Deep Color prep. Patch 11 only changes PM ops.
- `SET_LATE_SYSTEM_SLEEP_PM_OPS` exists in this tree’s
  `include/linux/pm.h`.
- `dw_hdmi_resume()` exists in `drivers/gpu/drm/bridge/synopsys/dw-
  hdmi.c`.
- Applies standalone. No missing helpers.

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

Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Record:
- b4 dig:
  https://patch.msgid.link/20260518193748.2482823-12-jonas@kwiboo.se
- v1 (2026-05-10): 10 patches, no resume_early change
- v2 (2026-05-18): this patch added (“v2: New patch”)
- Applied by Heiko 2026-06-02 as
  `af3a9eadc11896f6677bcb7102bfb7c84be48d2d`
- No NAK. No reviewer asked for further revisions of this hunk.
- Author included CONFIG_PM_DEBUG / rtcwake test instructions and noted
  a separate RK356x EHCI/OHCI clock issue, not this bug.

Step 4.2: CHECK WHO REVIEWED THE PATCH
Record: Recipients included Heiko Stuebner, Sandy Huang, Andy Yan, DRM
maintainers, dri-devel, linux-rockchip. Heiko tested and applied. No
other Acked-by/Reviewed-by on this patch.

Step 4.3: SEARCH FOR THE BUG REPORT
Record: No syzbot/bugzilla link. Real-world grounding is the 2019
Chromebook report in 27c9130baef543 plus Heiko’s rk3328 Tested-by.

Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
Record: Standalone vs the rest of the v2 series. DSI sibling
`e584cdc154993` (“drm/rockchip: dsi: Reconfigure hardware on resume()”)
used the same late PM ops and had Cc: stable.

Step 4.5: CHECK STABLE MAILING LIST HISTORY
Record: UNVERIFIED. lore.kernel.org/stable returned an Anubis bot-check
page; WebFetch to lore returned 403.

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

Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
Record: `dw_hdmi_rockchip_resume_early` (was `dw_hdmi_rockchip_resume`);
`dw_hdmi_rockchip_pm`.

Step 5.2: TRACE CALLERS
Record: Invoked by the PM core as `dev_pm_ops.resume_early` on the
`dwhdmi-rockchip` platform driver. Triggered by system suspend/resume
(and freeze/thaw/restore via LATE_SYSTEM_SLEEP_PM_OPS). Not a syscall
hot path; it is the Chromebook/SBC sleep path.

Step 5.3: TRACE CALLEES
Record: `dev_get_drvdata` → `dw_hdmi_resume` → `dw_hdmi_init_hw` →
`initialize_hdmi_ih_mutes`, `dw_hdmi_i2c_init`, optional
`phy.ops->setup_hpd`.

Step 5.4: FOLLOW THE CALL CHAIN
Record:
- Userspace: `echo mem > /sys/power/state` / rtcwake / systemd suspend.
- DRM side: `rockchip_drm_sys_resume` → `drm_mode_config_helper_resume`
  → `drm_atomic_helper_resume` (atomic commit / enable).
- HDMI platform device is a component, not a child of the DRM device;
  sibling `.resume` order is not guaranteed. `platform_set_drvdata` is
  in `dw_hdmi_rockchip_bind`, while probe only does `component_add`, so
  resume-before-bind can see NULL drvdata.
- Reachable on any Rockchip board with this HDMI IP and CONFIG_PM_SLEEP
  (RK3288/RK3328/RK3399/RK3568, including Chromebooks).

Step 5.5: SEARCH FOR SIMILAR PATTERNS
Record:
- `dw-mipi-dsi-rockchip.c` already uses
  `SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, dw_mipi_dsi_rockchip_resume)` in
  this tree for the same reason.
- `dw_hdmi_qp-rockchip.c` still uses `SET_SYSTEM_SLEEP_PM_OPS`
  (different HDMI QP IP, not this patch).
- imx8mp and meson dw-hdmi glue still use normal SYSTEM_SLEEP PM ops.

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

Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
Record:
- Local tree: `git describe HEAD` = v6.18.53-5049-g0f0bdc2b0dffb; `make
  kernelversion` = 6.18.53 (6.18.y).
- v6.18.53 still has:
  `SET_SYSTEM_SLEEP_PM_OPS(NULL, dw_hdmi_rockchip_resume)`
  and `dw_hdmi_resume(hdmi->hdmi)` with no NULL check
  at `drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c`.
- Bug present since v5.3 (2019), long before 6.18 branched.
- Upstream commit `af3a9eadc11896` is not an ancestor of HEAD (`git
  merge-base --is-ancestor` failed); this is a backport candidate, not
  already in 6.18.y proper.

Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
Record: Clean apply. The resume function in v6.18.53 is identical to the
parent of this change. `SET_LATE_SYSTEM_SLEEP_PM_OPS` and
`dw_hdmi_resume()` already exist here. Surrounding unbind/bridge-ref
changes from later series patches are not required.

Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
Record: No other resume-ordering fix on this file. DSI already has the
analogous LATE PM ops. No earlier version of this HDMI fix in 6.18.53.

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

Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
Record: DRM Rockchip HDMI glue (`drivers/gpu/drm/rockchip/`). IMPORTANT
(common SoC display, not core mm/fs). Affects
RK3288/RK3328/RK3399/RK356x HDMI (Chromebooks, SBCs, TV boxes).

Step 7.2: ASSESS SUBSYSTEM ACTIVITY
Record: Mature driver (HDMI glue since ~2015). Resume path untouched
from 2019 until this patch. Low churn on the PM ops themselves.

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

Step 8.1: DETERMINE WHO IS AFFECTED
Record: Driver-specific / platform-specific. Users of Rockchip dw-hdmi
who suspend the system. CONFIG_PM_SLEEP. Not universal, but a well-used
platform class in Android, Chromebook, and ARM SBCs.

Step 8.2: DETERMINE THE TRIGGER CONDITIONS
Record:
- Trigger: system suspend/resume with this HDMI driver bound (and the
  NULL path if probed but unbound).
- Common on laptops/Chromebooks; less so on always-on appliances.
- Unprivileged users typically cannot suspend; the HPD/I2C break is
  still a real admin/user-visible failure after lid-close/sleep.

Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
Record:
- Primary: HDMI HPD and DDC I2C not restored before DRM atomic enable →
  hotplug/EDID/output broken after resume. HIGH for affected hardware
  (display not coming back is a serious functional bug), not a kernel
  panic.
- Secondary: NULL deref if resume runs before bind → oops. Less common.
  HIGH if hit, MEDIUM likelihood.
- Overall: HIGH (suspend/resume display breakage on real hardware).

Step 8.4: CALCULATE RISK-BENEFIT RATIO
Record:
- Benefit: high for Rockchip HDMI suspend users; restores the ordering
  Chrome OS already needed.
- Risk: very low (7 lines, established LATE PM pattern already in the
  same DRM driver).
- Ratio: favor backport.

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

Step 9.1: COMPILE THE EVIDENCE
FOR:
- Real resume-ordering bug: DRM atomic enable before
  `dw_hdmi_init_hw()`.
- User-visible: HDMI HPD/DDC broken after sleep (documented on rk3288
  Chromebooks in 2019; re-tested on rk3328 in 2026).
- Same fix already used by dw-mipi-dsi-rockchip in this tree, and that
  DSI change went to stable with Cc: stable.
- Possible NULL deref on resume before bind.
- 7-line surgical change; applies cleanly to v6.18.53.
- Maintainer Tested-by and Signed-off-by.
- Buggy code has been in this tree since v5.3; no missing prerequisites.

AGAINST:
- No Fixes:/Cc: stable (expected for this pipeline; not a negative).
- Buried as 11/11 in a cleanup series (but the hunk is independent and
  was added specifically in v2).
- Not a panic/corruption/CVE; display-after-suspend rather than a crash.
- No extra Reviewed-by besides maintainer apply/test.
- UNVERIFIED whether stable@ already discussed rejecting it.

UNRESOLVED:
- lore.kernel.org/stable search blocked (Anubis/403).
- Incomplete NULL check if bind failed and left `hdmi->hdmi` as ERR_PTR
  (pre-existing).

Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? PASS — PM phase ordering is well-
   defined; Heiko tested on rk3328.
2. Fixes a real bug that affects users? PASS — HDMI not correctly re-
   inited before DRM resume; Chromebook-class hardware.
3. Important issue (crash, security, corruption, deadlock)? PASS —
   suspend/resume display breakage plus a possible oops; hardware resume
   workaround, same class as the DSI stable fix.
4. Small and contained? PASS — 7 lines, one file.
5. No new features or APIs? PASS.
6. Can apply to the local tree? PASS — v6.18.53 has the old resume
   function and the LATE PM macro.

Step 9.3: CHECK FOR EXCEPTION CATEGORIES
Record: Hardware suspend/resume workaround on an existing driver (quirk-
class). Not a new driver, ID, or API.

Step 9.4: MAKE YOUR DECISION
This belongs on 6.18.y. The buggy `.resume` path is in this checkout,
the switch to `resume_early` is the same proven pattern as the in-tree
DSI sibling, and the patch is tiny with maintainer hardware testing.

What it solves for stable users: after system sleep on Rockchip dw-hdmi
boards, DRM can re-enable the pipeline before HDMI DDC/HPD/init, so
hotplug and HDMI output fail. Moving the callback to `resume_early`
forces `dw_hdmi_init_hw()` first, and skips a NULL drvdata deref if the
component never bound.

Risk is low; benefit is a real resume fix on shipping SoCs. No series
dependencies are required for this hunk.

Verification:
- [Phase 1] Parsed tags: Tested-by Heiko (rk3328), SOB Jonas + Heiko,
  Link msgid ...-12; no Fixes/Reported-by/Cc:stable
- [Phase 1] Cover letter via b4 mbox: patch 11/11 of v2 “Misc cleanup”;
  “v2: New patch”; Heiko “Series: Tested-by” and Applied
- [Phase 2] Diff: rename resume→resume_early, add `if (hdmi)`,
  SET_SYSTEM_SLEEP→SET_LATE_SYSTEM_SLEEP; +4/-3
- [Phase 2] Confirmed LATE_SYSTEM_SLEEP_PM_OPS maps resume_fn to
  `.resume_early` in include/linux/pm.h:321-327,350-351
- [Phase 2] Confirmed rockchip_drm_drv.c:260-262 still uses
  SET_SYSTEM_SLEEP_PM_OPS for sys_resume
- [Phase 2] drm_mode_config_helper_resume() calls
  drm_atomic_helper_resume() (drm_modeset_helper.c:250)
- [Phase 3] git blame parent: resume added in 27c9130baef543 (Douglas
  Anderson, 2019)
- [Phase 3] git show 27c9130baef543: documented Chromebook HPD/I2C break
  and Chrome OS late/early PM ops
- [Phase 3] git describe --contains 27c9130baef543 → v5.3-rc1; git
  merge-base --is-ancestor 27c9130baef543 HEAD → yes
- [Phase 3] git log --oneline --grep resume_early --
  drivers/gpu/drm/rockchip/ → only this commit
- [Phase 4] b4 dig -c af3a9eadc11896: lore thread found; v1 had no this
  patch; v2 added it; applied as af3a9eadc11896
- [Phase 4] b4 dig -a: v1 2026-05-10, v2 2026-05-18
- [Phase 4] b4 dig -w: Heiko, dri-devel, linux-rockchip CC’d
- [Phase 4] b4 dig -m /tmp/thread.mbox: no NAKs; Heiko tested+applied
- [Phase 4] lore.kernel.org WebFetch 403; stable search Anubis-blocked →
  UNVERIFIED stable@ discussion
- [Phase 5] Callers: PM core resume_early on dwhdmi-rockchip; callees
  dw_hdmi_resume→dw_hdmi_init_hw
- [Phase 5] platform_set_drvdata in bind (line 580), probe only
  component_add — NULL drvdata on unbound resume is real
- [Phase 5] Sibling dw-mipi-dsi-rockchip.c:1346 already
  SET_LATE_SYSTEM_SLEEP_PM_OPS in this tree; introduced by e584cdc154993
  with Cc: stable
- [Phase 6] git describe HEAD: v6.18.53-5049-g0f0bdc2b0dffb; make
  kernelversion 6.18.53
- [Phase 6] git show v6.18.53:dw_hdmi-rockchip.c has
  SET_SYSTEM_SLEEP_PM_OPS + unchecked dw_hdmi_resume
- [Phase 6] git merge-base --is-ancestor af3a9eadc11896 HEAD → no (not
  in 6.18.y proper)
- [Phase 6] Resume hunk in v6.18.53 identical to parent of this change;
  SET_LATE and dw_hdmi_resume exist in v6.18.53
- [Phase 8] Failure mode: HDMI broken after suspend (HIGH); possible
  NULL oops (HIGH if hit)
- UNVERIFIED: whether stable@ previously rejected this patch (lore
  blocked)

**YES**

 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 727cdf768161a..ff34aeef3a6ff 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -635,17 +635,18 @@ static void dw_hdmi_rockchip_remove(struct platform_device *pdev)
 	component_del(&pdev->dev, &dw_hdmi_rockchip_ops);
 }
 
-static int __maybe_unused dw_hdmi_rockchip_resume(struct device *dev)
+static int __maybe_unused dw_hdmi_rockchip_resume_early(struct device *dev)
 {
 	struct rockchip_hdmi *hdmi = dev_get_drvdata(dev);
 
-	dw_hdmi_resume(hdmi->hdmi);
+	if (hdmi)
+		dw_hdmi_resume(hdmi->hdmi);
 
 	return 0;
 }
 
 static const struct dev_pm_ops dw_hdmi_rockchip_pm = {
-	SET_SYSTEM_SLEEP_PM_OPS(NULL, dw_hdmi_rockchip_resume)
+	SET_LATE_SYSTEM_SLEEP_PM_OPS(NULL, dw_hdmi_rockchip_resume_early)
 };
 
 struct platform_driver dw_hdmi_rockchip_pltfm_driver = {
-- 
2.53.0


_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip