[PATCH AUTOSEL 7.0-6.12] wifi: rtw89: ser: Wi-Fi 7 reset HALT C2H after reading it

[Sasha Levin <sashal@kernel.org>]

From: Zong-Zhe Yang <kevin_yang@realtek.com>

[ Upstream commit 0cae26a78b14fe1292b0f50f28ebabe6801f3885 ]

When a SER (system error recovery) interrupt happens, driver reads HALT C2H
register to get the error status via MAC. For Wi-Fi 7 chipset, driver needs
to reset HALT C2H register after reading it to make FW aware that.

Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260213061552.29997-12-pkshih@realtek.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have a comprehensive understanding. Let me compile my analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: PARSE THE SUBJECT LINE
Record: [wifi: rtw89: ser] [reset] [Wi-Fi 7 reset HALT C2H register
after reading it during SER to notify FW]

### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by**: Zong-Zhe Yang (author, Realtek engineer) and Ping-
  Ke Shih (maintainer, Realtek)
- **Link**:
  `https://patch.msgid.link/20260213061552.29997-12-pkshih@realtek.com`
  - patch 12 of a series
- No Fixes: tag (expected for candidate commits)
- No Reported-by: tag
- No Cc: stable

Record: Standard Realtek vendor team submission. No user reports or
explicit stable nomination.

### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The body states: "When a SER (system error recovery) interrupt happens,
driver reads HALT C2H register to get the error status via MAC. For Wi-
Fi 7 chipset, driver needs to reset HALT C2H register after reading it
to make FW aware that."

Record: Bug is that Wi-Fi 7 firmware requires the HALT_C2H register to
be cleared after the driver reads it during error recovery, but the
driver was not doing this. Without the clear, FW doesn't know the driver
has acknowledged the error, potentially breaking the SER recovery flow.
No version info or stack trace provided.

### Step 1.4: DETECT HIDDEN BUG FIXES
Record: Yes, this IS a bug fix. The language "driver needs to reset"
indicates a missing protocol step. The SER recovery on Wi-Fi 7 is broken
without this change because the firmware protocol requires the register
to be cleared after reading.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: INVENTORY THE CHANGES
- **File**: `drivers/net/wireless/realtek/rtw89/mac.c`
- **Function**: `rtw89_mac_get_err_status()`
- **Lines added**: ~5 (1 variable declaration, 1 goto, 1 label, 1
  conditional write, 1 empty line)
- **Lines removed**: 1 (`return err` replaced with `goto bottom`)
- **Scope**: Single-file, single-function surgical fix

Record: Very small, contained change to one function in one file.

### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Before**: When `rtw89_mac_suppress_log()` returns true, the function
immediately returns without clearing HALT_C2H. When it returns false,
the function dumps debug info and returns without clearing HALT_C2H.

**After**: Both paths converge at the `bottom:` label. For non-AX chips
(Wi-Fi 7/BE), `R_AX_HALT_C2H` is written to 0 before returning. AX chips
are unaffected.

Record: The change ensures HALT_C2H is always cleared for Wi-Fi 7 chips
regardless of which path is taken through the function.

### Step 2.3: IDENTIFY THE BUG MECHANISM
Record: This is a **hardware protocol fix** (category h). The Wi-Fi 7
firmware requires the HALT_C2H register to be reset after the driver
reads it, to acknowledge receipt of the error status. Without this, the
FW doesn't know the driver has read the error, potentially preventing
proper error recovery.

### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct**: Yes - the register is already cleared to 0
  during initialization (line 4066). This just does the same during SER.
- **Minimal**: Yes - only 5 lines of actual change
- **Regression risk**: Very low - the new write only applies to non-AX
  chips, so existing Wi-Fi 6 behavior is completely unchanged
- **Red flags**: None

Record: High quality fix. Low regression risk. Only affects Wi-Fi 7
chips.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: BLAME THE CHANGED LINES
The function `rtw89_mac_get_err_status()` was introduced in commit
`e3ec7017f6a20d` (2021-10-11, "rtw89: add Realtek 802.11ax driver"). The
function has been modified by:
- `198b6cf70146ca` (2022-03-14): Added error scenario parsing
- `f5d98831badb89` (2023-01-19): Added RXI300 error case
- `8130e94e888bf9` (2023-05-08): Added suppress_log functionality
- `6f8d36552bab7d` (2023-12-04): Switched to mac_gen_def for
  dump_err_status

Record: Function exists since driver inception. Has been incrementally
enhanced for new chips. Code is stable and well-understood.

### Step 3.2: FOLLOW THE FIXES TAG
Record: No Fixes: tag present (expected).

### Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES
Recent SER-related commits in the tree:
- `f4de946bdb379`: "wifi: rtw89: ser: enable error IMR after recovering
  from L1"
- `44ec302e029d8`: "wifi: rtw89: ser: L1 skip polling status if FW runs
  event mode"
- `6792fcf6a6912`: "wifi: rtw89: debug: tweak Wi-Fi 7 SER L0/L1
  simulation methods"

These are from a Dec 2025 series "refine MLO, MCC and SER functions".
The commit under review is from a later Feb 2026 series.

Record: Related SER improvements already in tree. This commit appears
standalone.

### Step 3.4: CHECK THE AUTHOR'S OTHER COMMITS
Zong-Zhe Yang is a regular Realtek contributor with many rtw89 commits
including SER-related work. Ping-Ke Shih is the primary rtw89
maintainer.

Record: Author is a regular subsystem contributor. Maintainer signed
off.

### Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS
The diff only uses existing types/macros: `rtw89_chip_info`, `chip_gen`,
`RTW89_CHIP_AX`, `R_AX_HALT_C2H`. All exist in the current tree.

Record: No dependencies. The patch applies standalone.

---

## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH

### Step 4.1: FIND THE ORIGINAL PATCH DISCUSSION
Using b4 dig on related commits, found the previous SER series (v3 from
Dec 2025). The commit under review is from a different, later series
(20260213061552.29997-12). Lore.kernel.org was blocked by Anubis
protection.

Record: Patch is from a series by Ping-Ke Shih. Could not access lore
directly due to bot protection. The previous SER series was titled
"refine MLO, MCC and SER functions" and went through v1-v3 before
merging.

### Step 4.2: CHECK WHO REVIEWED THE PATCH
Record: Ping-Ke Shih (rtw89 maintainer) signed off. Submitted through
standard wireless-next pipeline.

### Step 4.3-4.5: External research
Record: Could not access lore.kernel.org due to Anubis protection. No
stable-specific discussion found.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1-5.2: FUNCTION ANALYSIS
`rtw89_mac_get_err_status()` is called from:
- `rtw89_pci_interrupt_threadfn()` (pci.c line 968) - the PCI interrupt
  handler threaded function

This is the primary SER entry point when a HALT_C2H interrupt fires. The
interrupt handler calls `rtw89_mac_get_err_status()` to read the error
code, then passes it to `rtw89_ser_notify()` which triggers the SER
state machine.

Record: Called from interrupt handler. Critical path for error recovery.
Called for every SER event.

### Step 5.3-5.4: CALL CHAIN
Interrupt -> `rtw89_pci_interrupt_threadfn()` ->
`rtw89_mac_get_err_status()` -> reads register, returns error code ->
`rtw89_ser_notify()` -> `ser_send_msg()` -> SER state machine

Record: Reachable from hardware interrupt. Not userspace-triggerable
directly, but occurs during hardware error conditions which are real-
world events.

### Step 5.5: SEARCH FOR SIMILAR PATTERNS
The initialization code at line 4066 already performs
`rtw89_write32(rtwdev, R_AX_HALT_C2H, 0)` - confirming the protocol
requires this register to be cleared.

Record: Consistent with existing initialization code pattern.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?
Wi-Fi 7 (RTL8922A/BE) support was added in v6.8. The `chip_gen` check
means only Wi-Fi 7 chips are affected. The function
`rtw89_mac_get_err_status()` exists in all stable trees from v5.15+, but
the bug only matters for trees with Wi-Fi 7 support (v6.8+).

Record: Bug is relevant to stable trees v6.8+.

### Step 6.2: BACKPORT COMPLICATIONS
The patch is small and touches a simple function. The code around it
hasn't changed dramatically. Should apply cleanly to any tree that has
the `rtw89_mac_suppress_log()` call (added in 2023) and `chip_gen`
(added in 2023).

Record: Clean apply expected on v6.8+.

### Step 6.3: RELATED FIXES
No duplicate fix found in stable trees.

Record: No related fixes already in stable.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: SUBSYSTEM CRITICALITY
**Subsystem**: drivers/net/wireless/realtek/rtw89 (Wi-Fi driver)
**Criticality**: IMPORTANT - RTL8922A is a popular Wi-Fi 7 chipset used
in laptops and desktop PCIe cards.

Record: IMPORTANT - popular wireless driver with growing user base.

### Step 7.2: SUBSYSTEM ACTIVITY
Very active - many commits per month. Actively developed for Wi-Fi 7
support.

Record: Highly active subsystem.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: AFFECTED USERS
Users with RTL8922A (Wi-Fi 7) hardware. This is a PCIe wireless card
found in recent laptops and desktops.

Record: Driver-specific (Wi-Fi 7 / RTL8922A users). Growing user
population.

### Step 8.2: TRIGGER CONDITIONS
Triggered when a SER (system error recovery) interrupt fires on Wi-Fi 7
hardware. This happens during firmware errors, which can occur due to:
- Firmware assertions
- DMA errors
- Watchdog timeouts
- Various hardware error conditions

Record: Trigger is hardware-dependent error condition. Not predictable
but real-world occurrence.

### Step 8.3: FAILURE MODE SEVERITY
Without this fix, when SER triggers on Wi-Fi 7:
- Firmware doesn't know driver acknowledged the error
- SER recovery flow may stall or not complete properly
- Wi-Fi device may become non-functional requiring manual intervention
  (module reload/reboot)

Record: **HIGH** severity - device recovery failure, Wi-Fi becomes
unusable until manual intervention.

### Step 8.4: RISK-BENEFIT RATIO
- **Benefit**: Ensures Wi-Fi 7 SER recovery works, preventing device
  failure during error conditions
- **Risk**: Very low - 5-line change, only affects non-AX chips,
  consistent with initialization code pattern
- **Ratio**: Very favorable - high benefit, very low risk

Record: Benefit HIGH, Risk VERY LOW. Strongly favorable ratio.

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: EVIDENCE COMPILATION

**FOR backporting:**
- Fixes broken SER recovery on Wi-Fi 7 chips (real functional bug)
- Small, surgical fix (5 lines meaningful change)
- Self-contained, no dependencies on other patches
- Only affects Wi-Fi 7 chips (no regression risk for existing hardware)
- Consistent with existing initialization pattern (line 4066)
- From vendor driver team (Realtek) with maintainer sign-off
- Critical error recovery path

**AGAINST backporting:**
- No explicit user bug reports or crash reports
- No Fixes: tag
- Part of a "rtw-next" development series
- Only affects Wi-Fi 7 users (relatively new hardware)
- Commit message doesn't describe explicit user-visible failure

**UNRESOLVED:**
- Could not verify lore.kernel.org discussion due to bot protection
- Exact failure behavior without this fix is inferred (not explicitly
  documented)

### Step 9.2: STABLE RULES CHECKLIST
1. **Obviously correct and tested?** YES - writes 0 to same register
   cleared at init, gated by chip_gen check
2. **Fixes a real bug?** YES - incomplete Wi-Fi 7 SER protocol
   implementation
3. **Important issue?** YES - device recovery failure leads to non-
   functional Wi-Fi
4. **Small and contained?** YES - 5 lines in one function
5. **No new features or APIs?** CORRECT - no new features
6. **Can apply to stable trees?** YES - applicable to v6.8+ (when Wi-Fi
   7 support was added)

### Step 9.3: EXCEPTION CATEGORIES
This is a hardware workaround/fix category - it fixes the SER protocol
for Wi-Fi 7 chipsets.

### Step 9.4: DECISION
The fix is small, obviously correct, self-contained, and addresses a
real functional bug in Wi-Fi 7 error recovery. The risk is very low
(only affects Wi-Fi 7 chips, consistent with existing patterns). The
benefit is significant (broken SER means device can't recover from
errors).

---

## Verification

- [Phase 1] Parsed tags: Signed-off-by from Zong-Zhe Yang and Ping-Ke
  Shih; Link to patch series
- [Phase 2] Diff analysis: 5 lines added to
  `rtw89_mac_get_err_status()`, adds HALT_C2H register clear for non-AX
  chips
- [Phase 3] git blame: function introduced in e3ec7017f6a20d
  (2021-10-11), present since driver inception
- [Phase 3] git log: confirmed related SER commits (f4de946bdb379,
  44ec302e029d8) already in tree
- [Phase 3] git merge-base: RTL8922A (Wi-Fi 7) support added in v6.8
  (commit c0a04552e36e1, 2023-11-17)
- [Phase 4] b4 dig -c f4de946bdb379 -a: found series went through v1-v3
  before merging
- [Phase 4] lore.kernel.org: blocked by Anubis protection, could not
  access discussions
- [Phase 5] grep callers: `rtw89_mac_get_err_status` called from PCI
  interrupt handler threadfn (pci.c:968)
- [Phase 5] grep: `R_AX_HALT_C2H` already cleared to 0 at init time
  (mac.c:4066), confirming protocol requirement
- [Phase 6] chip_gen RTW89_CHIP_BE exists since v6.8;
  `rtw89_mac_suppress_log` since v6.5
- [Phase 6] Patch applies standalone - no dependencies on other patches
  from series
- [Phase 8] Failure mode: device recovery failure on Wi-Fi 7, severity
  HIGH
- UNVERIFIED: Exact FW behavior when HALT_C2H not cleared (inferred from
  commit message and protocol)
- UNVERIFIED: Could not access lore discussion for reviewer comments

**YES**

 drivers/net/wireless/realtek/rtw89/mac.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireless/realtek/rtw89/mac.c
index 8472f1a63951b..fa60f8e8bb3d4 100644
--- a/drivers/net/wireless/realtek/rtw89/mac.c
+++ b/drivers/net/wireless/realtek/rtw89/mac.c
@@ -814,6 +814,7 @@ static bool rtw89_mac_suppress_log(struct rtw89_dev *rtwdev, u32 err)
 u32 rtw89_mac_get_err_status(struct rtw89_dev *rtwdev)
 {
 	const struct rtw89_mac_gen_def *mac = rtwdev->chip->mac_def;
+	const struct rtw89_chip_info *chip = rtwdev->chip;
 	u32 err, err_scnr;
 	int ret;
 
@@ -836,11 +837,15 @@ u32 rtw89_mac_get_err_status(struct rtw89_dev *rtwdev)
 		err = MAC_AX_ERR_RXI300;
 
 	if (rtw89_mac_suppress_log(rtwdev, err))
-		return err;
+		goto bottom;
 
 	rtw89_fw_st_dbg_dump(rtwdev);
 	mac->dump_err_status(rtwdev, err);
 
+bottom:
+	if (chip->chip_gen != RTW89_CHIP_AX)
+		rtw89_write32(rtwdev, R_AX_HALT_C2H, 0);
+
 	return err;
 }
 EXPORT_SYMBOL(rtw89_mac_get_err_status);
-- 
2.53.0