From nobody Sat Sep 26 17:08:46 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0D6024A0927; Mon, 31 Aug 2026 13:41:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788183699; cv=none; b=BA/PUtgTzsKV4Rhfgo7ohOwjxto9i9qHI/MEEiBv/0/PT/YSVFZHIKSobcGm2vqqbifniFJT8WaIPPjblzZWrVoUqWgg+QSh3pUSwgEIS1UXJnmqibYeWhvb/RW8ZxHkNB4Cs/sdPHe5em63p7k/GV/HJFzKxb4XNzYJK5XENZM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788183699; c=relaxed/simple; bh=ltuDfQ7QZqiRAgvpyktmmDEDKuVQA87KA5z0eue77zA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=J0O+0kCw0OBGyBa1DJhvijFNMlOlSuPNbxSuW6qAeJwiFlkderyr4m+TU2JxgyQ2tCnNU1grdO81eBSJNEbJ4KmS2svVpatbqOj9Xgsy17XvNAhTTeazm9WG92T68FSaB2NRWn5m3ZCJV9L4/R2f2FMSdabGCVWoYvxC2o2MNjE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M5f7yPAV; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M5f7yPAV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 462B31F00A3E; Mon, 31 Aug 2026 13:41:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788183696; bh=4aA/mw8wPBGPJo8tBTr0TR4w7ObCSJFfJDmxuWAwlWQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=M5f7yPAVoLwc5zPj89XaGgsvvjU9bNzaIAy2ImrEJ9XshNBBf2+jaNCjfQU6KClmv 6aQ78KKMOThjX2O5fcqm2Bh2PMy1mANqh2+5hc3TU32MwdAOMWnDJevqGNiBOaZrZS hYGfjL9WxwWoUnGjLpLWRE50zqmAinjHDyUFRC6h2DCaXZzWRQcLGXXj+dMzJEZLNj WgPuvzYpG45OX1UVViR7hHeUV90u3WwjsVdDKjh5OFZQwBG0kPIfBSbxyUZyuaA2cV cpI3OZUBsHaE9Z/l0D39yxfvU1FtrYL7zLXG7ENYsddaCMMa4kr772jr9NeWv5Hkt/ oQD9DFaQOFDWw== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: =?UTF-8?q?Marek=20Beh=C3=BAn?= , Jakub Kicinski , Sasha Levin , andrew@lunn.ch, olteanv@gmail.com, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-5.10] net: dsa: mv88e6xxx: enable .rmu_disable() for 6320 family Date: Mon, 31 Aug 2026 09:24:38 -0400 Message-ID: <20260831133314.4125787-250-sashal@kernel.org> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260831133314.4125787-1-sashal@kernel.org> References: <20260831133314.4125787-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.48 Content-Transfer-Encoding: quoted-printable From: Marek Beh=C3=BAn [ 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=C3=BAn Link: https://patch.msgid.link/20260504153227.1390546-5-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin --- 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 =3D 6`, `PATCHLEVEL =3D 18`, `SUBLEVEL =3D 43`) --- ## PHASE 1: COMMIT MESSAGE FORENSICS ### Step 1.1: PARSE THE SUBJECT LINE **Record:** `[net: dsa: mv88e6xxx]` `[enable]` =E2=80=94 add the missing `.rmu_disable()` callback to the MV88E6320/MV88E6321 ops tables. ### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS **Record:** - **Fixes:** =E2=80=94 absent (expected for manual review) - **Reported-by:** =E2=80=94 absent - **Tested-by:** =E2=80=94 absent - **Reviewed-by:** =E2=80=94 absent - **Acked-by:** =E2=80=94 absent - **Link:** `https://patch.msgid.link/20260504153227.1390546-5-kabel@kernel.org` (patch 5/N of a series by Marek Beh=C3=BAn) - **Cc: stable:** =E2=80=94 absent (not a negative signal) - **Signed-off-by:** Marek Beh=C3=BAn ``, Jakub Kicinski `` (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 =E2=80=94 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 =3D 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 =3D mv88e6352_g1_reset`, setup proceeds to VTU ops with no RMU handling. After: `.rmu_disable =3D 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 =E2=80=94 identical to `mv88e6352_ops`, `mv88e6172_ops`, `mv88e6240_ops`, etc. - **Regression risk:** Very low =E2=80=94 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` =E2=86=92 `true`), limiting deeper history. The ops tables with= out `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=C3=BAn series (message-= id suffix `-5`). Standalone =E2=80=94 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=C3=BAn 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 =E2=80=94 `b4 dig -w` not usable without matching co= mmit 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 =E2=80=94 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()` =E2=86=92 `mv88e6xxx_g1_ctl2_mask(= chip, MV88E6352_G1_CTL2_RMU_MODE_MASK, MV88E6352_G1_CTL2_RMU_MODE_DISABLED)` =E2= =80=94 clears RMU mode bits in Global Control 2. ### Step 5.4: FOLLOW THE CALL CHAIN **Record:** Device probe =E2=86=92 `mv88e6xxx_setup()` =E2=86=92 `mv88e6xxx= _rmu_setup()` =E2=86=92 (currently no-op for 6320/6321) =E2=86=92 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 =E2=80=94 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 =3D 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** =E2=80=94 2 identical lines inserted a= fter `.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=3D"rmu_disable"` and `--grep=3D"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` =E2=80=94 DSA Ethernet switch drive= r. **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=C3=BAn 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** =E2=80=94 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** =E2=80=94 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 =E2=80=94 2 lines, existing tested function, same patte= rn 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** =E2=80=94 mirrors `mv88e6352_ops`; maintainer signed off; no Tested-by. 2. Fixes a real bug that affects users? **PASS** =E2=80=94 ops-table omissi= on leaves RMU enabled on MV88E6320/6321. 3. Important issue? **PASS (borderline)** =E2=80=94 networking misconfigura= tion on affected hardware at every boot; not a crash but real functional impact. 4. Small and contained? **PASS** =E2=80=94 2 lines, 1 file. 5. No new features or APIs? **PASS** =E2=80=94 wires existing callback only. 6. Can apply to the local tree? **PASS** =E2=80=94 prerequisite code presen= t; clean apply. ### Step 9.3: CHECK FOR EXCEPTION CATEGORIES **Record:** Hardware workaround / quirk =E2=80=94 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=C3=BAn and Kicinski - [Phase 1] Commit body references `9e5baf9b3636` as RMU infrastructure origin - [Phase 2] Diff: +2 lines in `chip.c`, both `.rmu_disable =3D mv88e6352_g1_rmu_disable` - [Phase 2] Confirmed `mv88e6xxx_rmu_setup()` no-ops when callback is NULL (lines 1675=E2=80=931680) - [Phase 2] Confirmed `mv88e6352_g1_rmu_disable()` exists in `global1.c` (lines 539=E2=80=93543) - [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 =E2=80=94 **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=E2=80=935182 and 5233=E2=80=935234 - [Phase 6] Confirmed `[MV88E6320]`/`[MV88E6321]` chip entries at lines 6247=E2=80=936300 - [Phase 6] No DT bindings referencing 88E6320/6321 in this tree (no `.dts` matches) - [Phase 8] Failure mode: RMU not disabled =E2=86=92 MEDIUM severity hardwa= re misconfiguration **YES**The background history search didn=E2=80=99t finish cleanly =E2=80= =94 the repo is shallow, so `git log -S "MV88E6320]"` mostly surfaced merge commits and wasn=E2=80=99t 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=E2=80=99t 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/c= hip.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 =3D { .hardware_reset_pre =3D mv88e6xxx_g2_eeprom_wait, .hardware_reset_post =3D mv88e6xxx_g2_eeprom_wait, .reset =3D mv88e6352_g1_reset, + .rmu_disable =3D mv88e6352_g1_rmu_disable, .vtu_getnext =3D mv88e6352_g1_vtu_getnext, .vtu_loadpurge =3D mv88e6352_g1_vtu_loadpurge, .stu_getnext =3D mv88e6352_g1_stu_getnext, @@ -5232,6 +5233,7 @@ static const struct mv88e6xxx_ops mv88e6321_ops =3D { .hardware_reset_pre =3D mv88e6xxx_g2_eeprom_wait, .hardware_reset_post =3D mv88e6xxx_g2_eeprom_wait, .reset =3D mv88e6352_g1_reset, + .rmu_disable =3D mv88e6352_g1_rmu_disable, .vtu_getnext =3D mv88e6352_g1_vtu_getnext, .vtu_loadpurge =3D mv88e6352_g1_vtu_loadpurge, .stu_getnext =3D mv88e6352_g1_stu_getnext, --=20 2.53.0