[PATCH AUTOSEL 6.18-6.12] rtase: Fix flow control configuration
From: Sasha Levin
Date: Mon Aug 31 2026 - 11:37:35 EST
From: Justin Lai <justinlai0215@xxxxxxxxxxx>
[ Upstream commit fea3521e043fa1388ec909205687db7d4b0c57ec ]
The hardware has two sets of registers controlling TX/RX flow control.
The effective flow control state is determined by the logical OR of
these two sets of bits.
RTASE_FORCE_TXFLOW_EN and RTASE_FORCE_RXFLOW_EN in RTASE_CPLUS_CMD are
the bits used by the driver to control TX/RX flow control according to
the ethtool pause configuration.
RTASE_TXFLOW_EN and RTASE_RXFLOW_EN in RTASE_GPHY_STD_00 are another
set of TX/RX flow control enable bits. Clear them by default so they do
not keep flow control enabled independently of the driver setting.
With the RTASE_GPHY_STD_00 bits cleared, the effective flow control
state is controlled through RTASE_CPLUS_CMD, so the ethtool setting can
take effect correctly.
Signed-off-by: Justin Lai <justinlai0215@xxxxxxxxxxx>
Reviewed-by: Andrew Lunn <andrew@xxxxxxx>
Link: https://patch.msgid.link/20260505064121.31286-1-justinlai0215@xxxxxxxxxxx
Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>
---
LLM Generated explanations, may be completely bogus:
# Stable Backport Analysis: `rtase: Fix flow control configuration`
**Local tree:** `v6.18.43-1-gc7f0dac02d232` (kernel 6.18.43)
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject Line
**Record:** `[rtase] [fix] flow control configuration` — Realtek
automotive Ethernet driver; fixes incorrect hardware flow-control setup.
### Step 1.2: Commit Message Tags
**Record:**
| Tag | Value |
|-----|-------|
| Signed-off-by | Justin Lai `<justinlai0215@xxxxxxxxxxx>` |
| Reviewed-by | Andrew Lunn `<andrew@xxxxxxx>` |
| Link | https://patch.msgid.link/20260505064121.31286-1-
justinlai0215@xxxxxxxxxxx |
| Signed-off-by | Jakub Kicinski `<kuba@xxxxxxxxxx>` (committer) |
**Notable patterns:** Reviewed-by from netdev reviewer Andrew Lunn. No
Reported-by, Fixes:, Cc: stable, syzbot, or Tested-by. Absence of stable
tags is expected per pipeline rules.
### Step 1.3: Commit Body Analysis
**Record:**
- **Bug:** Hardware has two independent TX/RX flow-control enable bit
sets (`RTASE_CPLUS_CMD` and `RTASE_GPHY_STD_00`); effective state is
logical OR of both.
- **Symptom:** Driver only manages `RTASE_CPLUS_CMD` via ethtool pause,
but `RTASE_GPHY_STD_00` bits left set by hardware default keep flow
control enabled even when ethtool disables it.
- **Root cause:** Missing initialization to clear `RTASE_GPHY_STD_00`
flow-control bits at driver init.
- **Fix:** Clear `RTASE_TXFLOW_EN | RTASE_RXFLOW_EN` in
`RTASE_GPHY_STD_00` during `rtase_hw_config()` so ethtool pause
settings take effect.
- **Version info:** None in message.
### Step 1.4: Hidden Bug Fix Detection
**Record:** Not disguised — explicit hardware-configuration bug fix.
`rtase_get_pauseparam()` / `rtase_set_pauseparam()` read/write only
`RTASE_CPLUS_CMD`, so userspace sees disabled pause while hardware still
pauses when GPHY bits remain set.
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Change Inventory
**Record:**
| File | Changes | Functions |
|------|---------|-----------|
| `rtase.h` | +4 lines (register + bit defs) | enum/constants only |
| `rtase_main.c` | +3 lines | `rtase_hw_config()` |
**Scope:** Single-file surgical fix in one function (+ header
constants). ~7 lines total.
### Step 2.2: Code Flow Change
**Record:**
- **Hunk 1 (`rtase.h`):** Adds `RTASE_GPHY_STD_00 = 0x6024` and
`RTASE_RXFLOW_EN`/`RTASE_TXFLOW_EN` bit definitions.
- **Hunk 2 (`rtase_main.c`, init path):** Before enabling flow control
via `RTASE_CPLUS_CMD`, reads `RTASE_GPHY_STD_00`, clears TX/RX flow
bits, writes back. Then existing CPLUS_CMD enable proceeds unchanged.
**Before:** Only `RTASE_CPLUS_CMD` bits managed; GPHY bits could
independently enable flow control.
**After:** GPHY bits cleared at init; CPLUS_CMD is sole effective
control path for driver/ethtool.
### Step 2.3: Bug Mechanism
**Record:** **Category:** Hardware quirk / logic correctness fix.
**Mechanism:** Hardware OR-combines two register sets; driver assumed
single control path. Clearing the GPHY set at init removes the shadow
enable path.
### Step 2.4: Fix Quality
**Record:** Obviously correct per commit message and hardware behavior
described. Minimal, no API changes. Low regression risk — only clears
two bits once during `rtase_hw_config()`. `rtase_hw_config()` is called
from open, reset, and resume paths (lines 1116, 1746, 2577).
---
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: Blame
**Record:** Flow-control lines at 979–982 introduced in `5d324e5159d9e`
(2025-11-28, 6.18-rc8 merge). Bug present since driver introduction in
this tree. No `RTASE_GPHY_STD_00` references anywhere in current HEAD.
### Step 3.2: Fixes: Tag
**Record:** N/A — no Fixes: tag.
### Step 3.3: File History
**Record:** Recent rtase commits in this tree:
- `4a4f3aa6af205` — TX hang workaround
- `1bf84f4013fac` — TX subqueue reset
- `54f9cdcd73118` — get_stats64() sleep fix
Standalone fix; not part of a multi-patch series. Patch submission was
v2 (v1→v2: rebase + expanded message only).
### Step 3.4: Author Context
**Record:** Justin Lai is listed maintainer in MAINTAINERS for
`drivers/net/ethernet/realtek/rtase/`. Three prior rtase fixes already
in this tree.
### Step 3.5: Dependencies
**Record:** No prerequisites. Uses existing `rtase_r16()`/`rtase_w16()`
helpers. Applies cleanly to current HEAD.
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1: Original Discussion
**Record:** Thread at https://lore.kernel.org/netdev/20260505064121.3128
6-1-justinlai0215@xxxxxxxxxxx/ — submitted as `[PATCH net-next v2]`.
Andrew Lunn reviewed: *"Odd design."* + Reviewed-by. No NAKs, no stable
nomination, no user bug reports.
### Step 4.2: Reviewers
**Record:** CC'd: kuba@xxxxxxxxxx, davem@xxxxxxxxxxxxx,
edumazet@xxxxxxxxxx, pabeni@xxxxxxxxxx, andrew+netdev@xxxxxxx,
netdev@xxxxxxxxxxxxxxx, Realtek maintainers.
### Step 4.3: Bug Reports
**Record:** No external bug reports, syzbot, or crash traces. Vendor-
discovered hardware behavior issue.
### Step 4.4: Related Patches
**Record:** v1→v2 only changed rebase and commit message. Standalone.
### Step 4.5: Stable List
**Record:** No discussion found on lore stable list for "rtase flow
control".
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: Key Functions
**Record:** `rtase_hw_config()` (modified), `rtase_get_pauseparam()`,
`rtase_set_pauseparam()` (unchanged but affected).
### Step 5.2: Callers of `rtase_hw_config()`
**Record:**
- `rtase_open()` — netdev open (userspace `ip link set up`)
- Reset path (~line 1746) — after ring reinit
- Resume path (~line 2577) — PM resume
Common device bring-up and recovery paths.
### Step 5.3: Callees
**Record:** `rtase_r16()`, `rtase_w16()` — standard MMIO register
access.
### Step 5.4: Reachability
**Record:** Triggered on every interface open/reset/resume for
`CONFIG_RTASE` hardware (Realtek RTL9054/9068/9072/9075/9071 PCIe).
Userspace can change pause via `ethtool -A`; broken without fix.
### Step 5.5: Similar Patterns
**Record:** No other GPHY flow-control handling in rtase driver.
`rtase_set_pauseparam()` still only touches `RTASE_CPLUS_CMD` — correct
once GPHY bits are cleared at init.
---
## PHASE 6: CROSS-REFERENCING AGAINST LOCAL TREE (6.18.43)
### Step 6.1: Buggy Code Exists?
**Record:** **YES.** Current HEAD at lines 979–982 enables flow control
via `RTASE_CPLUS_CMD` only; no `RTASE_GPHY_STD_00` handling. Bug present
since `5d324e5159d9e` (Nov 2025).
### Step 6.2: Backport Complications
**Record:** **Clean apply expected.** Fix commit object `73d7d1b6e1d8c`
exists locally but is NOT an ancestor of HEAD (`git merge-base --is-
ancestor` exit 1). Patch not yet merged into this checkout.
### Step 6.3: Related Fixes Already Present?
**Record:** **NO.** `grep RTASE_GPHY_STD_00` returns no matches in tree.
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: Subsystem Criticality
**Record:** `drivers/net/ethernet/realtek/rtase/` — network driver,
**PERIPHERAL** (automotive PCIe Ethernet switch chips). Affects users
with `CONFIG_RTASE` hardware only.
### Step 7.2: Subsystem Activity
**Record:** New driver in 6.18 with active post-merge fixes (TX hang,
stats, subqueue). Actively maintained.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: Who Is Affected
**Record:** Users of Realtek automotive Ethernet PCIe devices with
`CONFIG_RTASE` built-in or as module.
### Step 8.2: Trigger Conditions
**Record:** Any time hardware leaves `RTASE_GPHY_STD_00` flow-control
bits set (default after reset) and user attempts to disable pause via
ethtool, or reads pause state via ethtool after disabling. Common on
every device probe/open. Unprivileged users can trigger via ethtool on
the netdev.
### Step 8.3: Failure Mode Severity
**Record:** Flow control remains enabled when userspace believes it is
disabled; `ethtool -a` reports incorrect state. Can cause unexpected
pause-frame behavior, network tuning failures, or interoperability
issues. **Severity: MEDIUM** (functional/incorrect reporting, not
crash/corruption/security).
### Step 8.4: Risk-Benefit
**Record:**
- **Benefit:** MEDIUM — restores correct ethtool pause behavior on
supported hardware; fixes kernel/userspace state mismatch.
- **Risk:** VERY LOW — 7 lines, register clear at init only, reviewed by
netdev reviewer.
- **Ratio:** Favorable for a hardware-quirk-style init fix on a driver
that already exposes ethtool pause API.
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence Summary
**FOR backport:**
- Real, reproducible hardware behavior bug (dual OR'd register sets)
- Breaks user-visible ethtool pause API
(`get_pauseparam`/`set_pauseparam`)
- Small, surgical, reviewed fix
- Buggy code present in 6.18.43 since driver introduction
- Fits hardware quirk/workaround exception category
- Driver maintainer-authored fix
**AGAINST backport:**
- No crashes, data corruption, security, or deadlock
- No user/fuzzer reports — vendor-found during development
- Niche hardware (automotive Realtek switches)
- Driver brand-new in 6.18
**Unresolved:** Whether GPHY bits can be re-set at runtime by firmware
(fix assumes init-time clear is sufficient; commit message supports
this).
### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **PASS** — clear register semantics,
Reviewed-by Andrew Lunn; no runtime test reports.
2. Fixes real bug affecting users? **PASS** — ethtool pause control
ineffective/misreported.
3. Important issue? **PASS (borderline)** — incorrect netdev
configuration and userspace/kernel state mismatch on real hardware;
hardware quirk category.
4. Small and contained? **PASS** — 7 lines, 2 files, one function.
5. No new features/APIs? **PASS** — register init only.
6. Can apply to local tree? **PASS** — driver and buggy code exist;
clean apply.
### Step 9.3: Exception Category
**Record:** **Hardware quirk/workaround** — clearing default hardware
register bits so driver-controlled flow control via ethtool works
correctly.
### Step 9.4: Problem and Decision Rationale
The rtase driver exposes ethtool pause parameters but only programs
`RTASE_CPLUS_CMD`. The Realtek hardware also has independent flow-
control enable bits in `RTASE_GPHY_STD_00` that are OR'd with the CPLUS
bits. Without clearing the GPHY bits at initialization, users cannot
reliably disable flow control, and `ethtool -a` can report a state that
does not match hardware.
For the 6.18.43 tree checked out here, the rtase driver exists with this
bug since its introduction. The fix is minimal, self-contained, and
matches the established stable pattern for hardware register workarounds
that make existing driver interfaces work correctly on real devices.
---
## Verification
- **[Phase 1]** `make kernelversion` → 6.18.43; `git describe HEAD` →
v6.18.43-1-gc7f0dac02d232
- **[Phase 1]** Parsed commit message tags from user-provided diff and
lore mbox
- **[Phase 2]** Read `rtase_main.c` lines 979–982 (buggy code) and
2025–2054 (ethtool pause handlers)
- **[Phase 2]** Confirmed diff: +4 lines in `rtase.h`, +3 lines in
`rtase_hw_config()`
- **[Phase 3]** `git blame -L 979,982` → introduced in `5d324e5159d9e`
(2025-11-28)
- **[Phase 3]** `git log --oneline --
drivers/net/ethernet/realtek/rtase/` → 4 commits total
- **[Phase 3]** `git show
5d324e5159d9e:drivers/net/ethernet/realtek/rtase/rtase_main.c` → same
buggy flow-control code at introduction
- **[Phase 4]** Fetched lore mbox via curl from lore.kernel.org — v2
patch, Andrew Lunn Reviewed-by, no stable nomination
- **[Phase 4]** No stable-list hits for "rtase flow control"
- **[Phase 5]** `grep rtase_hw_config` → called at lines 1116, 1746,
2577
- **[Phase 5]** `grep RTASE_GPHY_STD_00` in rtase/ → no matches (fix not
in HEAD)
- **[Phase 6]** `git merge-base --is-ancestor 73d7d1b6e1d8c HEAD` → exit
1 (fix not merged)
- **[Phase 6]** `git show 73d7d1b6e1d8c --stat` → commit object exists
locally
- **[Phase 6]** `git log HEAD..73d7d1b6e1d8c` → fix commit is ahead of
HEAD
- **[Phase 7]** MAINTAINERS entry confirms Justin Lai as rtase
maintainer
- **[Phase 7]** Kconfig confirms RTASE targets
RTL9054/9068/9072/9075/9071 PCIe devices
- **[Phase 8]** Failure mode: incorrect ethtool pause state, severity
MEDIUM
**YES**The background check for whether the flow-control fix is already
in your tree timed out on `git branch -a --contains` (likely due to a
large ref set). I killed that and re-ran a simpler check.
**Result:** commit `73d7d1b6e1d8c` (`rtase: Fix flow control
configuration`) is **not** in your current HEAD (`6.18.43`). The buggy
code is still present — `rtase_hw_config()` only sets `RTASE_CPLUS_CMD`
and never clears `RTASE_GPHY_STD_00`.
**Backport verdict (unchanged):** **YES** — small hardware quirk fix so
ethtool pause settings work on rtase hardware in this tree.
drivers/net/ethernet/realtek/rtase/rtase.h | 4 ++++
drivers/net/ethernet/realtek/rtase/rtase_main.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/realtek/rtase/rtase.h b/drivers/net/ethernet/realtek/rtase/rtase.h
index 43087b17a0ff2..03b12d83f6e9d 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase.h
+++ b/drivers/net/ethernet/realtek/rtase/rtase.h
@@ -153,6 +153,10 @@ enum rtase_registers {
#define RTASE_FORCE_TXFLOW_EN BIT(10)
#define RTASE_RX_CHKSUM BIT(5)
+ RTASE_GPHY_STD_00 = 0x6024,
+#define RTASE_RXFLOW_EN BIT(7)
+#define RTASE_TXFLOW_EN BIT(6)
+
RTASE_Q0_RX_DESC_ADDR0 = 0x00E4,
RTASE_Q0_RX_DESC_ADDR4 = 0x00E8,
RTASE_Q1_RX_DESC_ADDR0 = 0x4000,
diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c b/drivers/net/ethernet/realtek/rtase/rtase_main.c
index bc9b14614f7a7..e3cd4f7c13804 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
+++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c
@@ -977,6 +977,9 @@ static void rtase_hw_config(struct net_device *dev)
rtase_hw_set_features(dev, dev->features);
/* enable flow control */
+ reg_data16 = rtase_r16(tp, RTASE_GPHY_STD_00);
+ reg_data16 &= ~(RTASE_TXFLOW_EN | RTASE_RXFLOW_EN);
+ rtase_w16(tp, RTASE_GPHY_STD_00, reg_data16);
reg_data16 = rtase_r16(tp, RTASE_CPLUS_CMD);
reg_data16 |= (RTASE_FORCE_TXFLOW_EN | RTASE_FORCE_RXFLOW_EN);
rtase_w16(tp, RTASE_CPLUS_CMD, reg_data16);
--
2.53.0