[PATCH AUTOSEL 6.18-5.15] mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC

[PATCH AUTOSEL 6.18-5.15] mmc: renesas_sdhi: Add OF entry for RZ/G2E SoC

[Sasha Levin]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

[ Upstream commit ebf7f2198ac4817bd2929cf83c697cefa8bf36a9 ]

The RZ/G2E (R8A774C0) SoC was previously handled via the generic
"renesas,rcar-gen3-sdhi" fallback compatible string. However, because
the SDHI IP on RZ/G2E is identical with the R-Car E3 (R8A77990), it
requires the specific quirks and configuration defined in
`of_r8a77990_compatible` rather than the generic Gen3 data.

Add the explicit "renesas,sdhi-r8a774c0" match entry to map it correctly.
Note that the DT binding file renesas,sdhi.yaml does not need an update
as the entry for this SoC is already present.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## Phase 1: Commit Message Forensics

**Step 1.1 — Subject line**
Record: `[mmc: renesas_sdhi] [Add] Add OF entry for RZ/G2E SoC — maps
RZ/G2E (R8A774C0) SDHI to correct SoC-specific quirks data`

**Step 1.2 — Tags**
Record:
- Fixes: — absent (expected for manual review)
- Reported-by: — none
- Tested-by: — none
- Reviewed-by: Geert Uytterhoeven, Wolfram Sang
- Acked-by: — none
- Link: — none in commit message
- Cc: stable@vger.kernel.org — absent in upstream commit (present on
  patch 1/3 of the series only)
- Signed-off-by: Lad Prabhakar, Ulf Hansson

Notable: reviewed by Renesas/MMC subsystem experts; part of a 3-patch
series.

**Step 1.3 — Body analysis**
Record:
- Bug: RZ/G2E SDHI was matched via generic `renesas,rcar-gen3-sdhi`
  fallback instead of SoC-specific quirks
- Symptom: missing R-Car E3 (R8A77990) quirks — HS400 calibration table
  and manual tap correction
- Root cause: DTS uses `renesas,sdhi-r8a774c0` as primary compatible,
  but driver OF table lacked that entry
- Version info: none explicit; binding already documents
  `renesas,sdhi-r8a774c0`

**Step 1.4 — Hidden bug fix?**
Record: Yes — presented as “add OF entry” but fixes incorrect hardware
configuration. Cover letter documents measured eMMC HS400 bandwidth
improvements on RZ/G2E (read 159472 → 180781 KB/s, write 126355 → 127725
KB/s).

---

## Phase 2: Diff Analysis

**Step 2.1 — Inventory**
Record:
- Files: `drivers/mmc/host/renesas_sdhi_internal_dmac.c` (+1 line)
- Function: `renesas_sdhi_internal_dmac_of_match[]` (static OF match
  table)
- Scope: single-file, surgical (1 line)

**Step 2.2 — Code flow**
Record:
- Before: `renesas,sdhi-r8a774c0` not in table → OF match falls through
  to `renesas,rcar-gen3-sdhi` → `of_rcar_gen3_compatible` (no quirks)
- After: `renesas,sdhi-r8a774c0` → `of_r8a77990_compatible` (R-Car E3
  quirks: `sdhi_quirks_r8a77990`)
- Path: device probe during MMC controller initialization on RZ/G2E
  boards

**Step 2.3 — Bug mechanism**
Record:
- Category: (h) Hardware workaround / quirk mapping
- Mechanism: wrong `of_device_id` → wrong `quirks` pointer → missing
  `hs400_calib_table` and `manual_tap_correction` in
  `renesas_sdhi_probe()`

**Step 2.4 — Fix quality**
Record: Obviously correct — RZ/G2E SDHI IP is identical to R-Car E3;
same mapping pattern as already-backported G2H fix. Minimal regression
risk.

---

## Phase 3: Git History Investigation

**Step 3.1 — Blame**
Record: `of_r8a77990_compatible` introduced in `71b7597c63d2d`
(2021-07-29, Yoshihiro Shimoda). Present in v6.18.44.

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

**Step 3.3 — Related changes**
Record:
- `77223211f44db` (2018): added SDHI nodes to `r8a774c0.dtsi` with
  `renesas,sdhi-r8a774c0` compatible
- `535ff092b6860`: G2H sibling fix already backported to v6.18.44 with
  `Cc: stable@vger.kernel.org`
- Series on master: G2H (`f48ee497`), G2N (`5ce500d31a162`), G2E
  (`ebf7f2198ac48`) — patches are independent one-liners
- G2N OF entry not in stable; G2E not in stable

**Step 3.4 — Author context**
Record: Lad Prabhakar — Renesas contributor; same author as G2H fix
already in stable.

**Step 3.5 — Dependencies**
Record: Standalone. `of_r8a77990_compatible` and `sdhi_quirks_r8a77990`
exist in tree. Backport adds one line; in 6.18.44 (no `r8a774b1` entry)
it fits after `sdhi-mmc-r8a77470` and before `sdhi-r8a774e1`.

---

## Phase 4: Mailing List and External Research

**Step 4.1 — Discussion**
Record:
- URL:
  https://patch.msgid.link/20260519135342.623943-4-prabhakar.mahadev-
  lad.rj@bp.renesas.com
- Series: v2 0/3 — “Add OF entries for RZ/G2H, RZ/G2N, and RZ/G2E SoCs”
- Cover letter documents HS400 eMMC test results on all three SoCs
- No NAKs found; reviewed by Wolfram Sang and Geert Uytterhoeven

**Step 4.2 — Reviewers**
Record: Ulf Hansson (MMC maintainer), Wolfram Sang, Geert Uytterhoeven,
linux-mmc@, linux-renesas-soc@ CC’d.

**Step 4.3 — Bug report**
Record: No external bug report; author-provided benchmark data in cover
letter.

**Step 4.4 — Series context**
Record: 3 independent patches; G2H (1/3) already backported to 6.18.44;
G2E (3/3) is self-contained.

**Step 4.5 — Stable list**
Record: `Cc: stable@vger.kernel.org` on patch 1/3 (G2H) only; series
author intended stable consideration for the family of fixes.

---

## Phase 5: Code Semantic Analysis

**Step 5.1 — Key functions**
Record: `renesas_sdhi_internal_dmac_of_match[]`,
`renesas_sdhi_internal_dmac_probe()` → `renesas_sdhi_probe()`

**Step 5.2 — Callers**
Record: platform driver probe during device enumeration; triggered when
RZ/G2E SDHI nodes are enabled (e.g. EK874 `sdhi0`, `sdhi3`).

**Step 5.3 — Callees**
Record: `of_device_get_match_data()` → quirks applied in
`renesas_sdhi_probe()` for HS400 calibration (`hs400_calib_table`) and
tap correction (`manual_tap_correction`).

**Step 5.4 — Reachability**
Record: Boot-time probe on RZ/G2E boards with SD/MMC enabled. EK874
enables `sdhi0` (SD UHS) and `sdhi3` (SDIO WLAN). Userspace cannot
directly trigger, but all storage I/O on these interfaces is affected.

**Step 5.5 — Similar patterns**
Record: Same pattern as G2H (`r8a774e1` → `of_r8a7795_compatible`),
already backported to this tree.

---

## Phase 6: Cross-Reference Against Local Tree (v6.18.44)

**Step 6.1 — Buggy code exists?**
Record: Yes. `r8a774c0.dtsi` SDHI nodes use `renesas,sdhi-r8a774c0`
since 2018; driver OF table in v6.18.44 lacks this entry. Commit
`ebf7f2198ac48` not in tree.

**Step 6.2 — Backport complications**
Record: Clean apply — one line. Insert before existing `r8a774e1` entry
(G2H backport already present).

**Step 6.3 — Related fixes present?**
Record: G2H fix (`535ff092b6860`) backported; G2E fix absent.

---

## Phase 7: Subsystem Context

**Step 7.1 — Subsystem**
Record: `drivers/mmc/host` — IMPORTANT (MMC/SD/eMMC storage on embedded
Renesas RZ/G2E)

**Step 7.2 — Activity**
Record: Actively maintained; recent G2H backport shows ongoing stable
attention for this driver.

---

## Phase 8: Impact and Risk Assessment

**Step 8.1 — Who is affected**
Record: RZ/G2E (R8A774C0) users — EK874, CAT874 boards and derivatives.
Config: `CONFIG_MMC`, Renesas SDHI internal DMAC.

**Step 8.2 — Trigger conditions**
Record: Any boot with SDHI enabled on RZ/G2E. Common on reference
boards. Not userspace-triggerable but affects all MMC I/O.

**Step 8.3 — Failure mode severity**
Record: Suboptimal HS400/HS200 operation — measured ~13% read bandwidth
loss on eMMC; missing tap correction risks data integrity at high
speeds. Severity: MEDIUM-HIGH for embedded storage reliability.

**Step 8.4 — Risk-benefit**
Record: Benefit HIGH for RZ/G2E users (proven performance fix, correct
hardware quirks). Risk VERY LOW (1 line, uses existing data structures,
precedent with G2H backport).

---

## Phase 9: Final Synthesis

**Evidence FOR:**
- Fixes real hardware misconfiguration on shipping RZ/G2E boards
- Documented eMMC HS400 performance improvement
- 1-line, obviously correct hardware quirk mapping
- Same pattern as G2H fix already backported to v6.18.44
- Reviewed by subsystem maintainers
- `of_r8a77990_compatible` prerequisite exists in tree since 2021
- DTS binding and nodes already present since 2018

**Evidence AGAINST:**
- Performance-focused rather than crash/corruption explicitly reported
  (but HS400 without proper calibration can cause silent errors)
- G2E patch lacks explicit `Cc: stable` (G2H had it)
- Part of a 3-patch series (but each patch is independent)

**Stable rules checklist:**
1. Obviously correct and tested? **PASS** — reviewed, benchmarked
2. Fixes real bug affecting users? **PASS** — wrong quirks on RZ/G2E
   since 2018
3. Important issue? **PASS** — storage performance/reliability on
   embedded platform
4. Small and contained? **PASS** — 1 line
5. No new features/APIs? **PASS** — maps to existing quirks
6. Can apply to local tree? **PASS** — clean one-line backport

**Exception category:** Hardware quirk/workaround (OF match → correct
quirks table)

---

## Verification

- [Phase 1] Parsed commit `ebf7f2198ac48` on master; tags: Reviewed-by
  Geert, Wolfram; no Fixes/Reported-by
- [Phase 2] Diff: +1 line in `renesas_sdhi_internal_dmac_of_match[]`
- [Phase 3] `git describe HEAD`: v6.18.44; `of_r8a77990_compatible` from
  `71b7597c63d2d` (2021)
- [Phase 3] SDHI DTS nodes since `77223211f44db` (2018); G2H backport
  `535ff092b6860` in stable
- [Phase 3] `ebf7f2198ac48` not ancestor of HEAD (not in stable)
- [Phase 4] `b4 dig -c ebf7f2198ac48`: lore thread found; v2 3/3 series
- [Phase 4] Cover letter: HS400 benchmark data for RZ/G2E
- [Phase 4] `Cc: stable` only on patch 1/3 (G2H)
- [Phase 5] Verified `sdhi_quirks_r8a77990` has `hs400_calib_table` +
  `manual_tap_correction`
- [Phase 5] EK874 DTS: `sdhi0` and `sdhi3` enabled
- [Phase 6] `r8a774c0` in driver OF table: absent; in DTS: present
- [Phase 6] Current stable OF table read at lines 279–295 confirms
  missing `r8a774c0` entry

This commit should be backported to the v6.18.44 stable tree. It
corrects a long-standing hardware quirk mapping bug for RZ/G2E SDHI,
follows the same pattern as the already-backported G2H fix, and is a
minimal one-line change with demonstrated user impact.

**YES****Verdict: YES** — backport to v6.18.44.

This is a one-line OF match-table fix for RZ/G2E (R8A774C0) SDHI.
Without it, the driver falls back to generic Gen3 quirks instead of the
R-Car E3-specific ones (`of_r8a77990_compatible`), which hurts HS400
eMMC performance and tuning on boards like EK874.

It matches the G2H fix already in this stable tree (`535ff092b6860`), is
small and self-contained, and should apply cleanly as a single line
before the existing `r8a774e1` entry.

 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 8bc1c3209edb0..6cca38e32b991 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -280,6 +280,7 @@ static const struct of_device_id renesas_sdhi_internal_dmac_of_match[] = {
 	{ .compatible = "renesas,sdhi-r7s9210", .data = &of_rza2_compatible, },
 	{ .compatible = "renesas,sdhi-mmc-r8a77470", .data = &of_rcar_gen3_compatible, },
 	{ .compatible = "renesas,sdhi-r8a774b1", .data = &of_r8a77965_compatible, },
+	{ .compatible = "renesas,sdhi-r8a774c0", .data = &of_r8a77990_compatible, },
 	{ .compatible = "renesas,sdhi-r8a774e1", .data = &of_r8a7795_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7795", .data = &of_r8a7795_compatible, },
 	{ .compatible = "renesas,sdhi-r8a77961", .data = &of_r8a77961_compatible, },
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.15] mmc: renesas_sdhi: Add OF entry for RZ/G2N SoC

[Sasha Levin]

From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>

[ Upstream commit 5ce500d31a1625d8fe7ede950201b8df076bdd48 ]

The RZ/G2N (R8A774B1) SoC was previously handled via the generic
"renesas,rcar-gen3-sdhi" fallback compatible string. However, because
the SDHI IP on RZ/G2N is identical with the R-Car M3-N (R8A77965), it
requires the specific quirks and configuration defined in
`of_r8a77965_compatible` rather than the generic Gen3 data.

Add the explicit "renesas,sdhi-r8a774b1" match entry to map it correctly.
Note that the DT binding file renesas,sdhi.yaml does not need an update
as the entry for this SoC is already present.

Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `mmc: renesas_sdhi: Add OF entry for RZ/G2N
SoC`

**Local tree:** `v6.18.44` (stable/linux-6.18.y)
**Upstream commit:** `5ce500d31a1625d8fe7ede950201b8df076bdd48`

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
**Record:** `[mmc/renesas_sdhi]` `[Add]` — Add explicit OF device-tree
match entry for RZ/G2N (R8A774B1) SoC SDHI controller.

### Step 1.2: Tags
**Record:**
- **Signed-off-by:** Lad Prabhakar, Ulf Hansson (MMC maintainer)
- **Reviewed-by:** Wolfram Sang (Renesas SDHI maintainer), Geert
  Uytterhoeven (Renesas DT maintainer)
- **No Fixes:** tag
- **No Reported-by:** tag
- **No Cc: stable** in the committed upstream message (present in
  mailing-list submission for the series)
- **No Link:** tags

Notable: Both subsystem maintainers reviewed; this is patch 2/3 of a
series nominating all three RZ/G2 patches for stable.

### Step 1.3: Body Analysis
**Record:**
- **Bug:** RZ/G2N SDHI nodes use `"renesas,sdhi-r8a774b1"` as primary
  compatible, but the driver lacked an explicit OF match entry. Matching
  fell through to the generic `"renesas,rcar-gen3-sdhi"` fallback
  (`of_rcar_gen3_compatible`), which has **no SoC-specific quirks**.
- **Symptom:** Missing `sdhi_quirks_r8a77965` (HS400 tap correction,
  bad-tap avoidance, calibration table) that R-Car M3-N (R8A77965) — the
  IP-identical counterpart — requires.
- **Root cause:** OF match table gap; hardware needs M3-N quirks, not
  generic Gen3 data.
- **Version info:** RZ/G2N DTS SDHI nodes have existed since v5.5
  (2019); bug present whenever quirk-based OF matching has been used.

### Step 1.4: Hidden Bug Fix?
**Record:** Yes. Despite "Add OF entry" wording, this is a **hardware
quirk/workaround fix**. Without it, HS400 eMMC operates with wrong (or
no) tap calibration. Series cover letter documents measured failures:
RZ/G2N read bandwidth 46,680 KB/s → 104,731 KB/s after fix, validated
with `mmc_test` 1000 iterations on HS400 eMMC.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **Files:** `drivers/mmc/host/renesas_sdhi_internal_dmac.c` (+1 line)
- **Functions modified:** None (data table only:
  `renesas_sdhi_internal_dmac_of_match[]`)
- **Scope:** Single-file, surgical, 1-line addition

### Step 2.2: Code Flow Change
**Record:**
- **Before:** `"renesas,sdhi-r8a774b1"` not in OF table →
  `of_device_get_match_data()` matches fallback `"renesas,rcar-
  gen3-sdhi"` → `of_rcar_gen3_compatible` (`.quirks = NULL`).
- **After:** Primary compatible matches → `of_r8a77965_compatible` →
  `sdhi_quirks_r8a77965` with `hs400_bad_taps`, `hs400_calib_table`,
  `manual_tap_correction`.
- **Path affected:** Device probe / initialization for all RZ/G2N SDHI
  instances (sdhi0–sdhi3).

### Step 2.3: Bug Mechanism
**Record:** **Category (h): Hardware workaround / logic correctness
fix.**
- `sdhi_quirks_r8a77965` enables HS400 tap correction in
  `renesas_sdhi_core.c` (`manual_tap_correction`, `hs400_bad_taps`,
  `hs400_calib_table` code paths).
- Without quirks, HS400 mode runs without proper tap tuning — degraded
  performance and risk of unreliable eMMC transfers.

### Step 2.4: Fix Quality
**Record:** Obviously correct — maps RZ/G2N to already-existing, tested
M3-N quirks. Minimal diff, zero API changes. Regression risk: very low
(only affects r8a774b1 match; identical IP to r8a77965).

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** OF match table introduced incrementally.
`of_r8a77965_compatible` added in `71b7597c63d2dd` (2021). RZ/G2N DTS
SDHI nodes added in `6317736729acb` (2019, v5.5). The explicit r8a774b1
OF entry was never added until this 2026 commit. Bug has been latent
since quirk-based OF matching was refactored.

### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag. Original DTS commit `6317736729acb` is
in this tree.

### Step 3.3: Related Changes
**Record:**
- Part of v2 3-patch series: RZ/G2H, RZ/G2N, RZ/G2E (patches 1/3, 2/3,
  3/3).
- **RZ/G2H sibling already backported** to this tree as `535ff092b6860`
  (with `Cc: stable@vger.kernel.org`, Greg Kroah-Hartman SOB).
- RZ/G2N and RZ/G2E patches from the same series are **not yet** in
  6.18.44.
- Standalone: no other patches required; only adds one table row
  referencing existing data.

### Step 3.4: Author Context
**Record:** Lad Prabhakar — active Renesas contributor; same author as
RZ/G2H backport already in tree. Ulf Hansson (MMC maintainer) committed.

### Step 3.5: Dependencies
**Record:** No dependencies. `of_r8a77965_compatible` and
`sdhi_quirks_r8a77965` already exist in 6.18.44. `r8a774b1.dtsi` SDHI
nodes with `"renesas,sdhi-r8a774b1"` compatible present. Patch applies
cleanly (insert after r8a77470 line, before r8a774e1 which is already
present).

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original Discussion
**Record:** `b4 dig -c 5ce500d31a162` →
https://patch.msgid.link/20260519135342.623943-3-prabhakar.mahadev-
lad.rj@bp.renesas.com
Series v2 (0/3 + 3 patches). Latest revision applied to mainline. No
NAKs found.

### Step 4.2: Reviewers
**Record:** `b4 dig -w` — CC'd to linux-mmc, linux-renesas-soc, Wolfram
Sang, Ulf Hansson, Geert Uytterhoeven. Both Renesas and MMC maintainers
reviewed.

### Step 4.3: Bug Report
**Record:** No external bug report. Author-provided benchmark data in
cover letter (v2 0/3): RZ/G2N HS400 eMMC read 46,680 → 104,731 KB/s,
write 73,393 → 74,298 KB/s after fix, tested 1000 iterations with
`mmc_test`.

### Step 4.4: Series Context
**Record:** 3-patch series for RZ/G2H/G2N/G2E. Each patch is independent
(one line each). RZ/G2H already backported to this tree; RZ/G2N is
logically identical in nature.

### Step 4.5: Stable List History
**Record:** Individual patches in the series included `Cc:
stable@vger.kernel.org` in mailing-list submissions. RZ/G2H was
subsequently backported to 6.18.y, establishing precedent for this
series.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
**Record:** `renesas_sdhi_internal_dmac_of_match[]` (data), consumed by
`renesas_sdhi_internal_dmac_probe()`.

### Step 5.2: Callers
**Record:** OF core matches compatible at `platform_driver` probe time.
Affects every RZ/G2N board with SDHI enabled (HiHope RZ/G2N, Beacon
RZ/G2N Kit, etc.).

### Step 5.3: Callees
**Record:** `of_device_get_match_data()` → `quirks` pointer passed to
`renesas_sdhi_probe()` → used throughout `renesas_sdhi_core.c` for HS400
tuning.

### Step 5.4: Reachability
**Record:** Triggered at boot when SDHI platform devices probe on RZ/G2N
hardware. Common embedded/industrial path; affects eMMC rootfs on these
boards.

### Step 5.5: Similar Patterns
**Record:** Identical pattern to already-backported RZ/G2H fix
(`r8a774e1` → `of_r8a7795_compatible`) at line 282 in current tree. Same
series, same mechanism.

---

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

### Step 6.1: Buggy Code Present?
**Record:** **Yes.** `r8a774b1.dtsi` has four SDHI nodes with
`"renesas,sdhi-r8a774b1"` primary compatible. Driver OF table lacks this
entry (verified: no `r8a774b1` in `renesas_sdhi_internal_dmac.c`). Falls
back to generic gen3 without quirks.

### Step 6.2: Backport Complications
**Record:** **Clean apply expected.** File structure matches upstream
diff context. RZ/G2H entry already inserted at same location; RZ/G2N
entry slots in alphabetically before r8a774e1.

### Step 6.3: Related Fixes Already Present?
**Record:** RZ/G2H fix (`535ff092b6860`) present. RZ/G2N fix **not**
present. No alternate fix for r8a774b1.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem Criticality
**Record:** `drivers/mmc/host` — IMPORTANT (block storage / eMMC).
Platform-specific (Renesas RZ/G2N arm64).

### Step 7.2: Subsystem Activity
**Record:** Actively maintained; recent Renesas SDHI OF entries added
(RZ/G2H, RZ/V2H, RZ/G2L family).

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who Is Affected
**Record:** RZ/G2N (R8A774B1) platform users — embedded/industrial
boards (HiHope, Beacon, etc.) using SDHI/eMMC.

### Step 8.2: Trigger Conditions
**Record:** Every boot with SDHI enabled on RZ/G2N. Not timing-
dependent; deterministic misconfiguration. Unprivileged users interact
via eMMC I/O on these systems.

### Step 8.3: Failure Mode Severity
**Record:** **HIGH** — HS400 eMMC runs without required tap calibration.
Cover letter shows ~2× read bandwidth loss; wrong tap settings risk
transfer errors/data corruption on eMMC. Not a kernel crash, but storage
reliability and performance are seriously impacted.

### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** HIGH for affected hardware — restores correct HS400
  quirks, validated performance improvement.
- **Risk:** VERY LOW — 1-line table entry, maps to existing tested
  quirks, identical pattern to already-backported RZ/G2H fix.
- **Ratio:** Strongly favors backport.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backport:**
- Fixes real hardware misconfiguration on RZ/G2N since v5.5
- Hardware quirk/workaround (explicit stable exception category)
- 1-line, surgical, reviewed by subsystem maintainers
- Tested on real hardware (mmc_test, 1000 iterations, HS400)
- Sibling RZ/G2H patch from same series already in 6.18.44
- Series nominated for stable on mailing list
- All prerequisites present in tree

**AGAINST backport:**
- No user crash report or CVE
- Platform-specific (not universal)
- RZ/G2E patch from same series also missing (incomplete series, but
  each patch is independent)

**Unresolved:** None material to the decision.

### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — maps to existing M3-N
   quirks; benchmarked on hardware.
2. Fixes a real bug affecting users? **PASS** — wrong SDHI quirks on
   RZ/G2N boards.
3. Important issue? **PASS** — eMMC HS400 reliability/performance (HIGH
   severity for affected platforms).
4. Small and contained? **PASS** — 1 line, 1 file.
5. No new features or APIs? **PASS** — existing quirks, new OF table row
   only.
6. Can apply to local tree? **PASS** — prerequisites present, clean
   apply expected.

### Step 9.3: Exception Category
**Record:** Hardware quirk/workaround — maps SoC to correct existing
quirks table entry. Same category as the already-backported RZ/G2H fix.

### Step 9.4: Decision Rationale

This commit fixes a long-standing gap where RZ/G2N SDHI hardware was
probed without the M3-N-specific HS400 tuning quirks it requires. The
bug exists in 6.18.44: DTS uses the specific compatible string, but the
driver lacks the matching OF entry. The identical RZ/G2H fix from the
same series is already in this stable tree, establishing clear
precedent. The fix is trivial, reviewed, tested, and addresses real eMMC
performance and reliability on RZ/G2N hardware.

---

## Verification

- **[Phase 1]** Parsed commit message and tags from `git show
  5ce500d31a162`
- **[Phase 1]** Confirmed no Fixes:/Reported-by: in upstream commit
- **[Phase 2]** Verified diff: +1 line in
  `renesas_sdhi_internal_dmac_of_match[]`
- **[Phase 2]** Read `of_r8a77965_compatible` and `sdhi_quirks_r8a77965`
  at lines 204–248
- **[Phase 2]** Read `renesas_sdhi_internal_dmac_probe()` at lines
  581–600 — quirks from OF match data
- **[Phase 2]** Read HS400 quirk usage in `renesas_sdhi_core.c` (lines
  404, 555)
- **[Phase 3]** `git describe HEAD` → v6.18.44
- **[Phase 3]** `git blame` on OF match table — r8a774b1 entry absent
- **[Phase 3]** `git log -S "renesas,sdhi-r8a774b1"` on driver file →
  empty (never added)
- **[Phase 3]** DTS added in `6317736729acb` (2019) — confirmed in tree
- **[Phase 3]** Quirks refactor `71b7597c63d2dd` — confirmed in tree
- **[Phase 3]** RZ/G2H backport `535ff092b6860` — confirmed in tree with
  Cc: stable
- **[Phase 4]** `b4 dig -c 5ce500d31a162` → lore URL found
- **[Phase 4]** `b4 dig -m /tmp/rzg2n_thread.mbox` — cover letter with
  benchmark data and Cc: stable
- **[Phase 4]** Reviewed-by Wolfram Sang and Geert Uytterhoeven
  confirmed in thread
- **[Phase 5]** Grep `of_device_get_match_data` in probe path —
  confirmed flow
- **[Phase 5]** Grep `r8a774b1` in driver — no matches (bug present)
- **[Phase 6]** `r8a774b1.dtsi` SDHI nodes use `"renesas,sdhi-r8a774b1"`
  — confirmed at lines 2162+
- **[Phase 6]** `of_r8a77965_compatible` exists in 6.18.44 — confirmed
- **[Phase 6]** Commit NOT in current HEAD — `git log --grep="RZ/G2N"`
  on driver returns only unrelated entries
- **[Phase 8]** Cover letter benchmarks: RZ/G2N read 46680→104731 KB/s —
  from mbox

**YES**

 drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/renesas_sdhi_internal_dmac.c b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
index 6816d491b0bf0..8bc1c3209edb0 100644
--- a/drivers/mmc/host/renesas_sdhi_internal_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_internal_dmac.c
@@ -279,6 +279,7 @@ static const struct renesas_sdhi_of_data_with_quirks of_rza2_compatible = {
 static const struct of_device_id renesas_sdhi_internal_dmac_of_match[] = {
 	{ .compatible = "renesas,sdhi-r7s9210", .data = &of_rza2_compatible, },
 	{ .compatible = "renesas,sdhi-mmc-r8a77470", .data = &of_rcar_gen3_compatible, },
+	{ .compatible = "renesas,sdhi-r8a774b1", .data = &of_r8a77965_compatible, },
 	{ .compatible = "renesas,sdhi-r8a774e1", .data = &of_r8a7795_compatible, },
 	{ .compatible = "renesas,sdhi-r8a7795", .data = &of_r8a7795_compatible, },
 	{ .compatible = "renesas,sdhi-r8a77961", .data = &of_r8a77961_compatible, },
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.15] mmc: core: Add validation for host-provided max_segs

[Sasha Levin]

From: Shawn Lin <shawn.lin@rock-chips.com>

[ Upstream commit 3e0483e93a8be320f70a1ff68d835f7f015af311 ]

The max_segs field is of type unsigned short, and if a host driver
sets an excessively large value, it may be truncated to zero. This
can cause mmc_alloc_sg() to call kmalloc_objs() with a zero size
allocation request, which leads to undefined behavior.

Under the SLUB allocator, kmalloc(0) returns a special pointer
(ZERO_SIZE_PTR). The subsequent 'if (sg)' check will evaluate to
true, and sg_init_table() will then attempt to access invalid memory,
resulting in a crash:

dwmmc_rockchip 2a310000.mmc: Successfully tuned phase to 133
mmc1: new UHS-I speed SDR104 SDHC card at address aaaa
Unable to handle kernel paging request at virtual address 0000001ffffffff0
Mem abort info:
ESR = 0x0000000096000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x04: level 0 translation fault
Data abort info:
ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
CM = 0, WnR = 0, TnD = 0, TagAccess = 0
GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=0000000102c88000
[0000001ffffffff0] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 0000000096000004 [#1] SMP
Modules linked in:
CPU: 2 UID: 0 PID: 102 Comm: kworker/2:1 Not tainted 7.0.0-rc6-next-20260331-00013-g4d93c25963c5-dirty #80 PREEMPT
Hardware name: Rockchip RK3576 EVB V10 Board (DT)
Workqueue: events_freezable mmc_rescan
pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : sg_init_table+0x2c/0x50
lr : sg_init_table+0x24/0x50
sp : ffff8000837db710
x29: ffff8000837db710 x28: 000000000000c000 x27: 0000000000000300
x26: 0000000000000000 x25: 0000000000000040 x24: ffff0000c46a0000
x23: 0000000000000000 x22: ffff0000c0c73c00 x21: 0000000000000010
x20: 0000000000000010 x19: 0000000000000000 x18: 000000000000002c
x17: 0000000000000000 x16: 0000000000000001 x15: 0000000000000000
x14: 0000000000000400 x13: ffff8000837dc000 x12: 0000000000000000
x11: ffff0000c0c73ca0 x10: 0000000000000040 x9 : 459ec1f0abbdbb00
x8 : 0000001fffffffe0 x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000035579 x4 : 0000000000000901 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000010
Call trace:
sg_init_table+0x2c/0x50 (P)
mmc_mq_init_request+0x64/0x90
blk_mq_alloc_map_and_rqs+0x3ac/0x480
blk_mq_alloc_set_map_and_rqs+0x98/0x1e0
blk_mq_alloc_tag_set+0x1c0/0x290
mmc_init_queue+0x120/0x370
mmc_blk_alloc_req+0x150/0x420

To prevent this, add a validation check in mmc_mq_init_request() to
detect when sg_len (derived from max_segs) is zero. If sg_len is zero,
we return an error and print an error message, allowing host driver
developers to identify and fix incorrect max_segs configuration.

This is a defensive measure that ensures the MMC core fails gracefully
when host drivers provide invalid max_segs values, rather than crashing
with a page fault.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background git lookups finished and match the earlier analysis:

- **Fix commit** `064155c261550` ("mmc: core: Add validation for host-
  provided max_segs") is in the repo but **not** in the current 6.18.43
  tree (`v6.18.43-1-gc7f0dac02d232`). The vulnerable code is still
  present in `drivers/mmc/core/queue.c`.
- **History searches** for `mmc_mq_init_request` and `can_dma_map_merge`
  only hit merge commits in this shallow stable checkout; tag checks
  already showed both symbols exist back to at least v6.6/v6.12.

**Verdict for 6.18.43: YES** — small defensive fix that turns a kernel
oops (zero `max_segs` → `ZERO_SIZE_PTR` → fault in `sg_init_table`) into
a graceful `-EINVAL` during MMC block device init.

 drivers/mmc/core/queue.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/core/queue.c b/drivers/mmc/core/queue.c
index eb1053d8cae72..eb25a0825adcf 100644
--- a/drivers/mmc/core/queue.c
+++ b/drivers/mmc/core/queue.c
@@ -214,8 +214,14 @@ static int mmc_mq_init_request(struct blk_mq_tag_set *set, struct request *req,
 	struct mmc_queue *mq = set->driver_data;
 	struct mmc_card *card = mq->card;
 	struct mmc_host *host = card->host;
+	u16 sg_len = mmc_get_max_segments(host);
 
-	mq_rq->sg = mmc_alloc_sg(mmc_get_max_segments(host), GFP_KERNEL);
+	if (!sg_len) {
+		dev_err(mmc_dev(host), "Wrong max_segs assigned\n");
+		return -EINVAL;
+	}
+
+	mq_rq->sg = mmc_alloc_sg(sg_len, GFP_KERNEL);
 	if (!mq_rq->sg)
 		return -ENOMEM;
 
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] mmc: davinci: fix mmc_add_host order in probe

[Sasha Levin]

From: Osama Abdelkader <osama.abdelkader@gmail.com>

[ Upstream commit d04e0151d316edbdb4f0397a9b92a1936e4a1421 ]

mmc_add_host() makes the host visible to the MMC core. Register the
interrupt handlers and advertise MMC_CAP_SDIO_IRQ before that, so the
core cannot start using the host before IRQ handling is set up.

Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `mmc: davinci: fix mmc_add_host order in
probe`

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

**Commit under review:** `d04e0151d316e` (exists in repo on `all-next`
etc., **not** an ancestor of this tree’s HEAD)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject line
**Record:** `[mmc: davinci]` `[fix]` — correct probe initialization
order so IRQ handlers and SDIO capability are ready before
`mmc_add_host()`.

### Step 1.2: Tags
**Record:**
- **Fixes:** — none
- **Reported-by:** — none
- **Tested-by:** — none
- **Reviewed-by:** — none
- **Acked-by:** — none
- **Link:** — none in commit message
- **Cc: stable@vger.kernel.org** — none (expected for manual review)
- **Signed-off-by:** Osama Abdelkader `<osama.abdelkader@gmail.com>`
  (author)
- **Signed-off-by:** Ulf Hansson `<ulfh@kernel.org>` (MMC maintainer
  merge)

Notable: maintainer Signed-off-by; no syzbot/user bug report.

### Step 1.3: Body analysis
**Record:**
- **Bug:** `mmc_add_host()` exposes the host to the MMC core before IRQ
  handlers are registered and before `MMC_CAP_SDIO_IRQ` is advertised.
- **Symptom:** MMC core may start card detection / I/O while interrupts
  are not handled → requests can hang or SDIO IRQ support is mis-
  advertised.
- **Root cause:** Wrong probe ordering; `mmc_add_host()` should be last
  among setup steps that the core depends on.
- **Version info:** none in message.

### Step 1.4: Hidden bug fix?
**Record:** No — this is an explicit probe-order bug fix, not disguised
cleanup.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
**Record:**
- **File:** `drivers/mmc/host/davinci_mmc.c` (+5 / −7 lines)
- **Function:** `davinci_mmcsd_probe()`
- **Scope:** Single-file surgical fix

### Step 2.2: Code flow per hunk
**Record:**
1. **Remove early `mmc_add_host()`** — before: host registered with core
   immediately after cpufreq setup → after: deferred until IRQ setup
   completes.
2. **IRQ failure path** — before: `goto request_irq_fail` →
   `mmc_remove_host()` → after: `goto mmc_add_host_fail` (host was never
   added).
3. **Move `mmc_add_host()` after IRQ registration** — SDIO IRQ handler
   registered and `MMC_CAP_SDIO_IRQ` set first, then host registered.
4. **Remove `request_irq_fail` label** — no longer needed since
   `mmc_add_host()` hasn’t run yet.

### Step 2.3: Bug mechanism
**Record:** **Race condition / initialization ordering bug**
- `mmc_add_host()` → `mmc_start_host()` → `_mmc_detect_change(host, 0,
  false)` schedules card-detection work immediately.
- Before fix: detection can issue `mmc_davinci_request()` while
  `devm_request_irq()` for `mmc_davinci_irq` is not yet registered.
- Command completion depends on `mmc_davinci_irq()` (interrupt-driven;
  `mmc_davinci_start_command()` enables `DAVINCI_MMCIM` interrupt mask).
- SDIO: `MMC_CAP_SDIO_IRQ` was set after `mmc_add_host()`, so core could
  probe SDIO before capability was advertised.

### Step 2.4: Fix quality
**Record:**
- **Obviously correct:** matches established MMC driver pattern
  (`sdhci.c`, `omap_hsmmc.c`, and prior fixes like `mmc: uniphier-sd:
  register irqs before registering controller`).
- **Minimal:** pure reorder + simplified error path.
- **Regression risk:** very low; only changes probe ordering and removes
  unnecessary `mmc_remove_host()` on IRQ failure.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
**Record:** Buggy order introduced in **2009** (`b4cff4549b7a8c`, Vipin
Bhandari). `mmc_add_host()` before `devm_request_irq()` has been wrong
since initial davinci driver integration. `PROBE_PREFER_ASYNCHRONOUS`
added in `21b2cec61c04b` (2020), increasing realistic race window with
async detect work.

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

### Step 3.3: Related file history
**Record:** Same class of fix already in tree history:
- `a5d8de1cb7e1d` — `mmc: uniphier-sd: register irqs before registering
  controller`
- `74f45de394d97` — `mmc: renesas_sdhi: register irqs before registering
  controller`

Standalone one-patch fix; not part of a series.

### Step 3.4: Author context
**Record:** Osama Abdelkader is an active contributor (e.g. Panthor DRM
fixes) but not davinci maintainer. Fix merged by Ulf Hansson (MMC
subsystem maintainer).

### Step 3.5: Dependencies
**Record:** No prerequisites. Self-contained reorder in existing probe
function. Applies standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: Original discussion
**Record:**
- **URL:** https://lkml.iu.edu/hypermail/linux/kernel/2605.1/03199.html
- **Revisions:** single patch (no v2/v3 found)
- **Maintainer response:** Ulf Hansson — “Applied for next, thanks!”
  (https://lists.openwall.net/linux-kernel/2026/05/29/1414)
- **Stable nomination:** none in thread
- **NAKs/concerns:** none found

### Step 4.2: Reviewers
**Record:** CC’d to `linux-mmc@`, `linux-kernel@`, Ulf Hansson, and
other maintainers. Accepted by subsystem maintainer without objections.

### Step 4.3: Bug report
**Record:** No external bug report, syzbot, or stack trace. Bug
identified by code inspection / correct driver pattern.

### Step 4.4: Related patches
**Record:** Precedent patches in same subsystem (uniphier-sd,
renesas_sdhi) for identical IRQ-before-`mmc_add_host` ordering.

### Step 4.5: Stable list
**Record:** No stable-list discussion found (lore.kernel.org blocked by
bot protection for direct search; patch thread has no stable Cc).

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key functions
**Record:** `davinci_mmcsd_probe()`, `mmc_add_host()`,
`mmc_start_host()`, `_mmc_detect_change()`, `mmc_davinci_irq()`,
`mmc_davinci_request()`, `mmc_davinci_start_command()`

### Step 5.2: Callers
**Record:**
- `davinci_mmcsd_probe()` — platform driver probe during boot / module
  load on `ARCH_DAVINCI` boards.
- `mmc_add_host()` → `mmc_start_host()` → card detection workqueue.
- `mmc_davinci_request()` — MMC core callback during card init and I/O.

### Step 5.3: Callees
**Record:** `mmc_add_host()` calls `device_add()`, `mmc_start_host()`;
probe uses `devm_request_irq()`, `mmc_davinci_cpufreq_register()`.

### Step 5.4: Reachability
**Record:**
- Triggered on every DaVinci MMC controller probe with a card present
  (or during rescan).
- Card detection is scheduled from `mmc_start_host()` with **zero
  delay** (`_mmc_detect_change(host, 0, false)`).
- Requests issued before IRQ registration can hang waiting for
  interrupts that have no handler.
- **Userspace reachability:** indirect via boot-time device enumeration;
  can cause hung boot / unresponsive MMC block device.

### Step 5.5: Similar patterns
**Record:** `sdhci.c` (request IRQ at ~4883, `mmc_add_host` at ~4898),
`omap_hsmmc.c` (IRQ + `MMC_CAP_SDIO_IRQ` before `mmc_add_host` at
~1944). Davinci was the outlier.

---

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

### Step 6.1: Buggy code present?
**Record:** **YES.** Current `drivers/mmc/host/davinci_mmc.c` at lines
1297–1312 still has `mmc_add_host()` before `devm_request_irq()`. Fix
commit `d04e0151d316e` is **not** in HEAD (`git merge-base --is-
ancestor` → NOT ancestor).

### Step 6.2: Backport complications
**Record:** **Clean apply expected.** Probe structure matches the patch
context; no conflicting recent churn in that hunk. `request_irq_fail` /
`mmc_remove_host` path still present and removable as in the patch.

### Step 6.3: Related fixes already present?
**Record:** uniphier-sd and renesas_sdhi IRQ-ordering fixes are in tree;
davinci-specific fix is **not**.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem criticality
**Record:** **PERIPHERAL** — `CONFIG_MMC_DAVINCI` (`ARCH_DAVINCI ||
COMPILE_TEST`). TI DaVinci embedded platforms (e.g. DM644x, OMAP-L138
class). Small user base but real production embedded deployments.

### Step 7.2: Subsystem activity
**Record:** davinci driver receives periodic maintenance (PM macros,
devm helpers, bus-width reporting in 2024–2025) but is mature/legacy.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Who is affected
**Record:** Users building kernels with `CONFIG_MMC_DAVINCI=y/m` on
DaVinci hardware. Not universal; driver-specific.

### Step 8.2: Trigger conditions
**Record:**
- Boot or module load with MMC/SD/SDIO media present.
- Race between `mmc_start_host()` detect work and remaining probe steps.
- More likely since `PROBE_PREFER_ASYNCHRONOUS` (2020).
- Unprivileged users cannot directly trigger; impact is at
  boot/enumeration.

### Step 8.3: Failure mode severity
**Record:**
- **Hung MMC requests** / boot stall during card detection → **HIGH**
  for affected hardware.
- **SDIO IRQ not advertised** → SDIO Wi‑Fi/BT modules may fail →
  **HIGH** for SDIO users.
- Not a typical security issue; no data-corruption mechanism identified,
  but boot hang is a serious stability issue.

### Step 8.4: Risk-benefit
**Record:**
- **Benefit:** Prevents probe-time hangs and SDIO capability mis-
  registration on DaVinci boards; aligns with maintainer-accepted
  pattern used in sibling drivers.
- **Risk:** Very low — 12-line reorder, no API changes, simpler error
  path.
- **Ratio:** Favorable for backport despite narrow hardware scope.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence summary

**FOR backport:**
- Real initialization race with concrete mechanism (`mmc_start_host` →
  immediate detect work).
- IRQ-dependent request completion in `mmc_davinci_irq()`.
- SDIO capability must be set before host registration.
- Identical fixes already accepted in MMC subsystem (uniphier-sd,
  renesas_sdhi).
- Matches omap_hsmmc/sdhci canonical ordering.
- Tiny, obviously correct, maintainer-merged.
- Bug present in 6.18.44; fix not yet applied.

**AGAINST backport:**
- Very small user population (`ARCH_DAVINCI` only).
- No user bug report or syzbot reproduction.
- Theoretical race existed since 2009 (may have been rare on synchronous
  probe).

**Unresolved:** No field crash log confirming reproduction on specific
DaVinci board (not required for this class of fix).

### Step 9.2: Stable rules checklist
1. Obviously correct and tested? **PASS** — pattern proven in other MMC
   drivers; maintainer merged.
2. Fixes a real bug? **PASS** — probe ordering race verified in code.
3. Important issue? **PASS** — boot hang / MMC timeout on affected
   hardware (HIGH for those users).
4. Small and contained? **PASS** — 1 file, 12 lines.
5. No new features/APIs? **PASS** — reorder only.
6. Can apply to local tree? **PASS** — buggy code present; patch should
   apply cleanly.

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

### Step 9.4: Decision rationale
For **Linux 6.18.44**, this commit fixes a verified probe race in an
existing driver where the buggy code is present and the fix is absent.
While the hardware audience is narrow, boot-time hangs on embedded
systems are exactly the sort of contained, low-risk driver fixes stable
trees routinely take—especially when the MMC maintainer has already
accepted the same pattern for other host drivers. The patch is minimal,
follows established subsystem practice, and introduces negligible
regression risk.

---

## Verification

- **[Phase 1]** Parsed subject, tags, body from provided commit message.
- **[Phase 1]** Confirmed no Reported-by/Tested-by/Fixes/Link tags.
- **[Phase 2]** Diff analysis: reorder `mmc_add_host()` after IRQ setup;
  remove `request_irq_fail` path.
- **[Phase 2]** Read `mmc_add_host()` in
  `drivers/mmc/core/host.c:644-661` — calls `mmc_start_host()`.
- **[Phase 2]** Read `mmc_start_host()` / `_mmc_detect_change()` in
  `drivers/mmc/core/core.c:2338-2353,1441-1452` — schedules detect work
  with delay 0.
- **[Phase 2]** Read `davinci_mmcsd_probe()` buggy ordering at
  `davinci_mmc.c:1297-1328`.
- **[Phase 2]** Read `mmc_davinci_irq()` and `mmc_davinci_request()` —
  IRQ-driven completion path.
- **[Phase 3]** `git blame -L 1290,1330 drivers/mmc/host/davinci_mmc.c`
  — buggy order since 2009.
- **[Phase 3]** `git show 21b2cec61c04b` — `PROBE_PREFER_ASYNCHRONOUS`
  on davinci since 2020.
- **[Phase 3]** `git log --oneline` — found precedent commits
  `a5d8de1cb7e1d`, `74f45de394d97`.
- **[Phase 3]** `git show a5d8de1cb7e1d` — confirmed identical rationale
  for uniphier-sd.
- **[Phase 4]** WebFetch lkml.iu.edu patch submission — original patch
  found.
- **[Phase 4]** WebFetch lists.openwall.net — Ulf Hansson “Applied for
  next, thanks!”
- **[Phase 4]** `b4 dig -c HEAD` — failed (commit not in HEAD); `b4 dig
  -l` — unsupported syntax.
- **[Phase 5]** Compared `omap_hsmmc.c:1916-1946` and
  `sdhci.c:4883-4898` — IRQ before `mmc_add_host`.
- **[Phase 5]** Read `Kconfig` `CONFIG_MMC_DAVINCI` — `ARCH_DAVINCI ||
  COMPILE_TEST`.
- **[Phase 6]** `git describe HEAD` → `v6.18.44`.
- **[Phase 6]** `git merge-base --is-ancestor d04e0151d316e HEAD` → fix
  **NOT** in tree.
- **[Phase 6]** Grep confirmed buggy probe order still present in
  checked-out tree.
- **[Phase 6]** `git show d04e0151d316e` — verified commit exists and
  matches provided diff.
- **[Phase 7]** `git log --oneline -20 --
  drivers/mmc/host/davinci_mmc.c` — driver actively maintained.
- **[Phase 8]** Assessed impact limited to `ARCH_DAVINCI` with boot-time
  hang severity for those users.

**YES**

 drivers/mmc/host/davinci_mmc.c | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 00adc15956fd2..3d0d05ab1fe48 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -1294,14 +1294,10 @@ static int davinci_mmcsd_probe(struct platform_device *pdev)
 		goto cpu_freq_fail;
 	}
 
-	ret = mmc_add_host(mmc);
-	if (ret < 0)
-		goto mmc_add_host_fail;
-
 	ret = devm_request_irq(&pdev->dev, irq, mmc_davinci_irq, 0,
 			       mmc_hostname(mmc), host);
 	if (ret)
-		goto request_irq_fail;
+		goto mmc_add_host_fail;
 
 	if (host->sdio_irq >= 0) {
 		ret = devm_request_irq(&pdev->dev, host->sdio_irq,
@@ -1311,6 +1307,10 @@ static int davinci_mmcsd_probe(struct platform_device *pdev)
 			mmc->caps |= MMC_CAP_SDIO_IRQ;
 	}
 
+	ret = mmc_add_host(mmc);
+	if (ret < 0)
+		goto mmc_add_host_fail;
+
 	rename_region(mem, mmc_hostname(mmc));
 
 	if (mmc->caps & MMC_CAP_8_BIT_DATA)
@@ -1324,8 +1324,6 @@ static int davinci_mmcsd_probe(struct platform_device *pdev)
 
 	return 0;
 
-request_irq_fail:
-	mmc_remove_host(mmc);
 mmc_add_host_fail:
 	mmc_davinci_cpufreq_deregister(host);
 cpu_freq_fail:
-- 
2.53.0

[PATCH AUTOSEL 6.18-5.10] mmc: davinci: avoid NULL deref of host->data in IRQ handler

[Sasha Levin]

From: Stepan Ionichev <sozdayvek@gmail.com>

[ Upstream commit 4f28846aaf8db9668e338b8987973f8935edff34 ]

mmc_davinci_irq() returns early only when both host->cmd and
host->data are NULL:

  if (host->cmd == NULL && host->data == NULL) {
          ...
          return IRQ_NONE;
  }

So we may legitimately reach the rest of the handler with
host->data == NULL (and therefore data == NULL). The DATDNE branch
already guards against this with an explicit "if (data != NULL)"
check, but the subsequent TOUTRD ("read data timeout") and
CRCWR/CRCRD ("data CRC error") branches dereference data
unconditionally:

  if (qstatus & MMCST0_TOUTRD) {
          data->error = -ETIMEDOUT;        <-- NULL deref
          ...
          davinci_abort_data(host, data);
  }

  if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) {
          data->error = -EILSEQ;           <-- NULL deref
          ...
  }

If either bit is set in qstatus while host->data is NULL, the kernel
will crash inside the IRQ handler. smatch flags this:

  drivers/mmc/host/davinci_mmc.c:933 mmc_davinci_irq() error: we
    previously assumed 'data' could be null (see line 914)

Gate both branches on a non-NULL data, matching the existing pattern
used by the DATDNE branch.

No functional change for callers where data is non-NULL, which is
the only case in which these branches did meaningful work before
this change.

Signed-off-by: Stepan Ionichev <sozdayvek@gmail.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

The background git search finished. It found other DaVinci-related fixes
in this tree (gpio, i2c, etc.), but no commit matching the `if (data &&
(qstatus & ...)` guard pattern — so the MMC IRQ NULL-deref fix is still
absent from **6.18.43**.

That matches the earlier analysis: the buggy unguarded branches are
present in `drivers/mmc/host/davinci_mmc.c`, and this patch should be
backported.

**YES**

 drivers/mmc/host/davinci_mmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 2b7d6d9bcde51..00adc15956fd2 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -928,7 +928,7 @@ static irqreturn_t mmc_davinci_irq(int irq, void *dev_id)
 		}
 	}
 
-	if (qstatus & MMCST0_TOUTRD) {
+	if (data && (qstatus & MMCST0_TOUTRD)) {
 		/* Read data timeout */
 		data->error = -ETIMEDOUT;
 		end_transfer = 1;
@@ -940,7 +940,7 @@ static irqreturn_t mmc_davinci_irq(int irq, void *dev_id)
 		davinci_abort_data(host, data);
 	}
 
-	if (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD)) {
+	if (data && (qstatus & (MMCST0_CRCWR | MMCST0_CRCRD))) {
 		/* Data CRC error */
 		data->error = -EILSEQ;
 		end_transfer = 1;
-- 
2.53.0