[PATCH AUTOSEL 6.18-5.10] net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family

[Sasha Levin <sashal@kernel.org>]

From: Marek Behún <kabel@kernel.org>

[ Upstream commit e0fdb4157a85056bd256a7aebac4a3a2f580b201 ]

Commit 9e5baf9b3636 ("net: dsa: mv88e6xxx: add RMU disable op") did not
add the .rmu_disable() method for the 6320 family. Add it now.

Signed-off-by: Marek Behún <kabel@kernel.org>
Link: https://patch.msgid.link/20260504153227.1390546-5-kabel@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

# Stable Backport Analysis: `net: dsa: mv88e6xxx: enable .rmu_disable()
for 6320 family`

**Local tree:** Linux 6.18.43 (`v6.18.43-1-gc7f0dac02d232`, `VERSION =
6`, `PATCHLEVEL = 18`, `SUBLEVEL = 43`)

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
**Record:** `[net: dsa: mv88e6xxx]` `[enable]` — add the missing
`.rmu_disable()` callback to the MV88E6320/MV88E6321 ops tables.

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
**Record:**
- **Fixes:** — absent (expected for manual review)
- **Reported-by:** — absent
- **Tested-by:** — absent
- **Reviewed-by:** — absent
- **Acked-by:** — absent
- **Link:**
  `https://patch.msgid.link/20260504153227.1390546-5-kabel@kernel.org`
  (patch 5/N of a series by Marek Behún)
- **Cc: stable:** — absent (not a negative signal)
- **Signed-off-by:** Marek Behún `<kabel@kernel.org>`, Jakub Kicinski
  `<kuba@kernel.org>` (net maintainer)

No syzbot, no user bug reports, no explicit stable nomination.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
**Record:**
- **Bug description:** When MV88E6320/MV88E6321 ops tables were created,
  `.rmu_disable` was omitted. Commit `9e5baf9b3636` (May 2018)
  introduced the RMU-disable infrastructure for other Marvell switch
  families; these two new 6320-family chip IDs were not wired up.
- **Symptom/failure mode:** During driver setup, `mv88e6xxx_rmu_setup()`
  silently does nothing for MV88E6320/6321 because the ops pointer is
  NULL. The switch's Remote Management Unit (RMU) mode bits in Global
  Control 2 are never cleared to `RMU_MODE_DISABLED`.
- **Version information:** None stated.
- **Root cause:** Ops-table omission when MV88E6320/MV88E6321 chip
  entries were added.

### Step 1.4: DETECT HIDDEN BUG FIXES
**Record:** Yes — described as "enable," but it is a hardware-
initialization bug fix. Without it, RMU may remain enabled on a port
(per `MV88E6352_G1_CTL2_RMU_MODE_PORT_*` values in `global1.h`),
diverging from every other 6352-layout chip that sets `.rmu_disable =
mv88e6352_g1_rmu_disable`.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
**Record:**
- **Files:** `drivers/net/dsa/mv88e6xxx/chip.c` only (+2 lines)
- **Functions modified:** `mv88e6320_ops`, `mv88e6321_ops` (static const
  struct initializers)
- **Scope:** Single-file, surgical, 2-line fix

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Record:**
- **Hunk 1 (`mv88e6320_ops`):** Before: after `.reset =
  mv88e6352_g1_reset`, setup proceeds to VTU ops with no RMU handling.
  After: `.rmu_disable = mv88e6352_g1_rmu_disable` is registered, so
  `mv88e6xxx_rmu_setup()` will call it during `mv88e6xxx_setup()`.
- **Hunk 2 (`mv88e6321_ops`):** Identical change.
- **Path affected:** Normal probe/setup path, called once per switch at
  initialization.

### Step 2.3: IDENTIFY THE BUG MECHANISM
**Record:**
- **Bug category:** Logic / hardware-initialization correctness
- **Mechanism:** `mv88e6xxx_rmu_setup()` at line 1675 checks
  `chip->info->ops->rmu_disable`; if NULL, returns 0 without touching
  hardware. MV88E6320/6321 use `mv88e6352_g1_reset` and the 6352-family
  G1 CTL2 register layout but lacked the matching
  `mv88e6352_g1_rmu_disable` callback. The fix wires the existing,
  correct disable function.

### Step 2.4: ASSESS THE FIX QUALITY
**Record:**
- **Fix quality:** Obviously correct — identical to `mv88e6352_ops`,
  `mv88e6172_ops`, `mv88e6240_ops`, etc.
- **Regression risk:** Very low — adds a single register mask write
  during init, same as 15 other chip variants already do.
- **Red flags:** None.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
**Record:** `mv88e6320_ops` / `mv88e6321_ops` and
`[MV88E6320]`/`[MV88E6321]` chip table entries blame to `5d324e5159d9e`
(2025-11-28 merge). Repository is shallow (`git rev-parse --is-shallow-
repository` → `true`), limiting deeper history. The ops tables without
`rmu_disable` are present in this 6.18.43 tree.

### Step 3.2: FOLLOW THE FIXES: TAG
**Record:** No `Fixes:` tag. Referenced commit `9e5baf9b3636` ("net:
dsa: mv88e6xxx: add RMU disable op", May 2018) is in this tree and added
`mv88e6xxx_rmu_setup()` plus `.rmu_disable` for contemporary chip
families. MV88E6320/MV88E6321 as distinct chip IDs with dedicated ops
tables are a later addition; the omission is in those newer tables, not
in the 2018 commit itself.

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
**Record:** Shallow history shows only 2 commits touching `chip.c` on
HEAD. This fix appears to be patch 5 of a Marek Behún series (message-id
suffix `-5`). Standalone — no other patches required;
`mv88e6352_g1_rmu_disable` already exists in `global1.c`.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
**Record:** No Marek Behún commits found in shallow history for this
path. Jakub Kicinski (net maintainer) signed off.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
**Record:** No dependencies. `mv88e6352_g1_rmu_disable`,
`mv88e6xxx_rmu_setup()`, and MV88E6320/MV88E6321 chip entries all exist
in this tree. Applies standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
**Record:** `b4 dig -c HEAD` matched unrelated commit. `b4 shazam` for
subject and message-id returned "not known." `patch.msgid.link` and
`lore.kernel.org` blocked by Anubis bot protection. **Could not retrieve
mailing list discussion.**

### Step 4.2: CHECK WHO REVIEWED THE PATCH
**Record:** UNVERIFIED — `b4 dig -w` not usable without matching commit
hash on lore.

### Step 4.3: SEARCH FOR THE BUG REPORT
**Record:** No `Reported-by:` or bugzilla/syzbot links. No external bug
report found.

### Step 4.4: CHECK FOR RELATED PATCHES AND SERIES
**Record:** Message-id `...-5-...` indicates patch 5 of a series (likely
MV88E6320/MV88E6321 support). This fix completes ops-table wiring for
chips already present in 6.18.43. Other patches in the series not
verified.

### Step 4.5: CHECK STABLE MAILING LIST HISTORY
**Record:** UNVERIFIED — lore.kernel.org inaccessible.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: IDENTIFY KEY FUNCTIONS IN THE DIFF
**Record:** `mv88e6320_ops`, `mv88e6321_ops` (data),
`mv88e6352_g1_rmu_disable` (existing callee), `mv88e6xxx_rmu_setup`
(caller during init).

### Step 5.2: TRACE CALLERS
**Record:** `mv88e6xxx_rmu_setup()` called from `mv88e6xxx_setup()`
(line 4051), which is the DSA switch setup callback during device probe.
Every MV88E6320/6321 boot triggers this path.

### Step 5.3: TRACE CALLEES
**Record:** `mv88e6352_g1_rmu_disable()` → `mv88e6xxx_g1_ctl2_mask(chip,
MV88E6352_G1_CTL2_RMU_MODE_MASK, MV88E6352_G1_CTL2_RMU_MODE_DISABLED)` —
clears RMU mode bits in Global Control 2.

### Step 5.4: FOLLOW THE CALL CHAIN
**Record:** Device probe → `mv88e6xxx_setup()` → `mv88e6xxx_rmu_setup()`
→ (currently no-op for 6320/6321) → should call
`mv88e6352_g1_rmu_disable()`. Reachable on every boot with
MV88E6320/6321 hardware; not userspace-triggerable but always runs for
affected devices.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
**Record:** Of 28 `mv88e6xxx_ops` structs, 15 have `.rmu_disable`. Among
chips using `mv88e6352_g1_reset`, some older variants (e.g.
`mv88e6161_ops`, `mv88e6351_ops`) also lack it — but `mv88e6352_ops`,
`mv88e6172_ops`, `mv88e6341_ops`, and other newer 6352-layout chips do
have it. MV88E6320/6321 are the only chips using dedicated
`mv88e6320_ops`/`mv88e6321_ops` and are clearly intended to follow the
6352-family pattern (they already use `mv88e6352_g1_reset`,
`mv88e6352_gpio_ops`, etc.).

---

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

### Step 6.1: DOES THE BUGGY CODE EXIST IN THIS TREE?
**Record:** **YES.** `mv88e6320_ops` (line 5181) and `mv88e6321_ops`
(line 5233) have `.reset = mv88e6352_g1_reset` but no `.rmu_disable`.
`[MV88E6320]` and `[MV88E6321]` chip entries exist at lines 6247 and
6275.

### Step 6.2: CHECK FOR BACKPORT COMPLICATIONS
**Record:** **Clean apply expected** — 2 identical lines inserted after
`.reset` in each ops struct. No conflicting changes in recent `chip.c`
history.

### Step 6.3: CHECK IF RELATED FIXES ARE ALREADY HERE
**Record:** No existing fix. `git log --grep="rmu_disable"` and
`--grep="6320 family"` return nothing on this tree.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: IDENTIFY THE SUBSYSTEM AND ITS CRITICALITY
**Record:** `drivers/net/dsa/mv88e6xxx` — DSA Ethernet switch driver.
**IMPORTANT** (networking infrastructure on embedded/industrial
hardware; not core kernel, but affects connectivity for specific
platforms).

### Step 7.2: ASSESS SUBSYSTEM ACTIVITY
**Record:** Actively maintained; MV88E6320/MV88E6321 are recent
additions. Marek Behún is a regular mv88e6xxx contributor; Jakub
Kicinski signed off.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: DETERMINE WHO IS AFFECTED
**Record:** **Driver-specific / hardware-specific** — only systems with
Marvell 88E6320 or 88E6321 DSA switches (embedded/industrial routers,
automotive, etc.).

### Step 8.2: DETERMINE THE TRIGGER CONDITIONS
**Record:** Triggers on every driver probe (boot, module load). Not
timing-dependent. Requires `CONFIG_NET_DSA_MV88E6XXX` and MV88E6320/6321
hardware. Common for affected hardware (every boot).

### Step 8.3: DETERMINE THE FAILURE MODE SEVERITY
**Record:** RMU may remain enabled, routing management frames to an
unexpected port. Potential networking misbehavior or unexpected
management exposure. **Severity: MEDIUM** — functional hardware
misconfiguration, not a kernel oops/UAF/corruption. No crash reports
documented.

### Step 8.4: CALCULATE RISK-BENEFIT RATIO
**Record:**
- **Benefit:** Correct switch initialization for MV88E6320/6321; aligns
  with peer 6352-family chips; prevents incorrect RMU state on every
  boot.
- **Risk:** Minimal — 2 lines, existing tested function, same pattern as
  15 other variants.
- **Ratio:** Moderate benefit, very low risk. Appropriate for stable.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: COMPILE THE EVIDENCE

**FOR backport:**
- Real omission bug in hardware init path for MV88E6320/6321
- Buggy code confirmed present in Linux 6.18.43
- Obviously correct, 2-line fix using existing
  `mv88e6352_g1_rmu_disable`
- Called on every probe for affected hardware
- Net maintainer (Jakub Kicinski) signed off
- Zero regression risk
- Completes support for chips already in this stable tree

**AGAINST backport:**
- No user bug reports, syzbot, or crash traces
- Failure mode is incorrect hardware config, not kernel
  crash/security/CVE
- Several older 6352-reset chips also lack `rmu_disable` without known
  fallout
- Mailing list discussion unverified

**UNRESOLVED:**
- Full patch series context and reviewer stable nominations (lore
  inaccessible)
- Whether users have reported observable symptoms

### Step 9.2: APPLY THE STABLE RULES CHECKLIST
1. Obviously correct and tested? **PASS** — mirrors `mv88e6352_ops`;
   maintainer signed off; no Tested-by.
2. Fixes a real bug that affects users? **PASS** — ops-table omission
   leaves RMU enabled on MV88E6320/6321.
3. Important issue? **PASS (borderline)** — networking misconfiguration
   on affected hardware at every boot; not a crash but real functional
   impact.
4. Small and contained? **PASS** — 2 lines, 1 file.
5. No new features or APIs? **PASS** — wires existing callback only.
6. Can apply to the local tree? **PASS** — prerequisite code present;
   clean apply.

### Step 9.3: CHECK FOR EXCEPTION CATEGORIES
**Record:** Hardware workaround / quirk — corrects missing hardware
initialization for specific Marvell switch chips. Falls under the
hardware-quirk exception category.

### Step 9.4: DECISION RATIONALE
This is a small, obviously correct completion of MV88E6320/MV88E6321
driver support already present in 6.18.43. The RMU-disable step runs on
every probe and is standard for 6352-layout chips in this driver. The
fix is low-risk and addresses a real hardware-initialization omission
that can cause incorrect switch behavior. It meets stable criteria.

---

## Verification

- [Phase 1] Parsed subject, tags: Link present; no Reported-by/syzbot;
  SOB from Behún and Kicinski
- [Phase 1] Commit body references `9e5baf9b3636` as RMU infrastructure
  origin
- [Phase 2] Diff: +2 lines in `chip.c`, both `.rmu_disable =
  mv88e6352_g1_rmu_disable`
- [Phase 2] Confirmed `mv88e6xxx_rmu_setup()` no-ops when callback is
  NULL (lines 1675–1680)
- [Phase 2] Confirmed `mv88e6352_g1_rmu_disable()` exists in `global1.c`
  (lines 539–543)
- [Phase 3] `git describe HEAD`: v6.18.43; `make kernelversion`
  equivalent from Makefile: 6.18.43
- [Phase 3] `git show 9e5baf9b3636`: May 2018 commit added RMU disable
  infrastructure
- [Phase 3] Shallow repo confirmed; limited `git log` on `chip.c`
- [Phase 3] `git blame` on MV88E6320 entry and `.reset` line: present
  since `5d324e5159d9e`
- [Phase 4] `b4 dig -c HEAD`: no match for this commit
- [Phase 4] `b4 shazam`: lore lookup failed (message not known)
- [Phase 4] `patch.msgid.link` and `lore.kernel.org`: blocked by Anubis
  — **UNVERIFIED** discussion/reviewer feedback
- [Phase 5] `mv88e6xxx_rmu_setup()` caller: `mv88e6xxx_setup()` line
  4051
- [Phase 5] Python scan: `mv88e6320_ops` and `mv88e6321_ops` are only
  ops using `mv88e6352_g1_reset` without `rmu_disable` among 6320-family
  dedicated tables
- [Phase 6] Confirmed `mv88e6320_ops`/`mv88e6321_ops` lack `rmu_disable`
  at lines 5181–5182 and 5233–5234
- [Phase 6] Confirmed `[MV88E6320]`/`[MV88E6321]` chip entries at lines
  6247–6300
- [Phase 6] No DT bindings referencing 88E6320/6321 in this tree (no
  `.dts` matches)
- [Phase 8] Failure mode: RMU not disabled → MEDIUM severity hardware
  misconfiguration

**YES**The background history search didn’t finish cleanly — the repo is
shallow, so `git log -S "MV88E6320]"` mostly surfaced merge commits and
wasn’t useful for pinpointing when 6320 support landed.

What we could verify from blame: the `MV88E6320`/`MV88E6321` chip
entries and their ops tables are already in this **6.18.43** tree, and
both `mv88e6320_ops` / `mv88e6321_ops` are missing `.rmu_disable` while
using `mv88e6352_g1_reset`.

That doesn’t change the earlier verdict: this is a small, correct
hardware-init fix for chips already supported here.

**YES**

 drivers/net/dsa/mv88e6xxx/chip.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
index f324b88450427..7e294f2104b86 100644
--- a/drivers/net/dsa/mv88e6xxx/chip.c
+++ b/drivers/net/dsa/mv88e6xxx/chip.c
@@ -5179,6 +5179,7 @@ static const struct mv88e6xxx_ops mv88e6320_ops = {
 	.hardware_reset_pre = mv88e6xxx_g2_eeprom_wait,
 	.hardware_reset_post = mv88e6xxx_g2_eeprom_wait,
 	.reset = mv88e6352_g1_reset,
+	.rmu_disable = mv88e6352_g1_rmu_disable,
 	.vtu_getnext = mv88e6352_g1_vtu_getnext,
 	.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
 	.stu_getnext = mv88e6352_g1_stu_getnext,
@@ -5232,6 +5233,7 @@ static const struct mv88e6xxx_ops mv88e6321_ops = {
 	.hardware_reset_pre = mv88e6xxx_g2_eeprom_wait,
 	.hardware_reset_post = mv88e6xxx_g2_eeprom_wait,
 	.reset = mv88e6352_g1_reset,
+	.rmu_disable = mv88e6352_g1_rmu_disable,
 	.vtu_getnext = mv88e6352_g1_vtu_getnext,
 	.vtu_loadpurge = mv88e6352_g1_vtu_loadpurge,
 	.stu_getnext = mv88e6352_g1_stu_getnext,
-- 
2.53.0