linux: carry 0067 (rtw88 8821c RFE type 7)

board/mister/de10nano/linux-patches-beta/0067-wifi-rtw88-8821c-support-rfe-type-7.patch

@@ -0,0 +1 @@
+../linux-patches/0067-wifi-rtw88-8821c-support-rfe-type-7.patch

board/mister/de10nano/linux-patches-beta/series

@@ -78,8 +78,8 @@
 #   shape and a 7.x fix would be ORIGINAL code with no fork commit behind
 #   it. Recorded as open in docs/kernel-recon/fork-sync-2026-09-21.md §5
 #   rather than invented. Retires together with 0050.
-# The beta series therefore carries 37 of the 41 shared patches plus the 4
-# beta-local ones below — 41 entries — so within the carried set the 7.x
+# The beta series therefore carries 51 of the 53 shared patches plus the 4
+# beta-local ones below — 55 entries — so within the carried set the 7.x
 # and 6.18 kernels diverge only where an upstream API forced a re-anchor.
 # (0040 and 0041 are NOT exclusions: they were RETIRED from linux-patches/
 # outright on 2026-09-12 -- upstream chose the userspace fix, Main_MiSTer
@@ -276,3 +276,4 @@
 0064-dwc2-ddma-giveback-on-dequeue-halt.patch
 0065-dwc2-ddma-halt-before-freeing-desc-list.patch
 0066-dwc2-ddma-keep-xfercompl-unmasked.patch
+0067-wifi-rtw88-8821c-support-rfe-type-7.patch

board/mister/de10nano/linux-patches/0067-wifi-rtw88-8821c-support-rfe-type-7.patch

@@ -0,0 +1,57 @@
+From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
+From: "Michael C. Ferguson" <michael.christopher.ferguson@gmail.com>
+Date: Wed, 30 Sep 2026 21:04:31 -0500
+Subject: [PATCH] wifi: rtw88: 8821c: support RFE type 7
+
+Some RTL8811CU USB adapters (0bda:c811) are programmed with RFE type 7
+and fail to probe:
+
+  rtw88_8821cu 1-1:1.0: rfe 7 isn't supported
+  rtw88_8821cu 1-1:1.0: failed to setup chip efuse info
+  rtw88_8821cu 1-1:1.0: failed to setup chip information
+
+The driver already knows RFE type 7 is a BTG board: the efuse parser
+sets rfe_btg for it and the coex code describes it as "2-Ant, DPDT,
+BTG". Only the RFE definition is missing.
+
+Realtek's vendor driver handles type 7 the same way as types 2 and 4.
+phydm_init_hw_info_by_rfe_type_8821c() puts 2, 4 and 7 on SWITCH_TO_BTG,
+all three use the default PHY_REG_PG and TXPWR_LMT tables plus the BTG
+AGC diff table (rtw8821c_agc_btg_type2 is identical to the vendor's
+agc_tab_diff_btg), and rtl8821c_set_tx_power_level() takes the 2.4 GHz
+TX power index from path B on every BTG board, with the comment
+"(RFEType == 2) || (RFEType == 4) || (RFEType == 7)".
+
+Add the RFE definition and take the 2.4 GHz power index from path B
+for type 7 too, as is already done for 2 and 4.
+
+Signed-off-by: Michael C. Ferguson <michael.christopher.ferguson@gmail.com>
+---
+ drivers/net/wireless/realtek/rtw88/rtw8821c.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
+index 2078b06..a1654ad 100644
+--- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c
++++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c
+@@ -87,7 +87,8 @@ static int rtw8821c_read_efuse(struct rtw_dev *rtwdev, u8 *log_map)
+ 	for (i = 0; i < 4; i++)
+ 		efuse->txpwr_idx_table[i] = map->txpwr_idx_table[i];
+
+-	if (rtwdev->efuse.rfe_option == 2 || rtwdev->efuse.rfe_option == 4)
++	if (rtwdev->efuse.rfe_option == 2 || rtwdev->efuse.rfe_option == 4 ||
++	    rtwdev->efuse.rfe_option == 7)
+ 		efuse->txpwr_idx_table[0].pwr_idx_2g = map->txpwr_idx_table[1].pwr_idx_2g;
+
+ 	switch (rtw_hci_type(rtwdev)) {
+@@ -1943,6 +1944,7 @@ static const struct rtw_rfe_def rtw8821c_rfe_defs[] = {
+ 	[2] = RTW_DEF_RFE_EXT(8821c, 0, 0, 0, 2),
+ 	[4] = RTW_DEF_RFE_EXT(8821c, 0, 0, 0, 2),
+ 	[6] = RTW_DEF_RFE(8821c, 0, 0, 0),
++	[7] = RTW_DEF_RFE_EXT(8821c, 0, 0, 0, 2),
+ };
+
+ static const struct rtw_reg_domain coex_info_hw_regs_8821c[] = {
+-- 
+2.53.0
+

board/mister/de25nano/linux-patches/0067-wifi-rtw88-8821c-support-rfe-type-7.patch

@@ -0,0 +1 @@
+../../de10nano/linux-patches/0067-wifi-rtw88-8821c-support-rfe-type-7.patch

board/mister/de25nano/linux-patches/README.md

@@ -99,6 +99,7 @@ Source of the verdicts: [`docs/de25-patch-portability.md`](../../../../docs/de25
 | — | `0064-dwc2-ddma-giveback-on-dequeue-halt` | *post-audit (added 2026-09-26, #205)* | **excluded** — descriptor DMA is off on this board: dwc2 only enables it through `0059`, which is held for hardware qualification, so this code never runs | Same as `0054`. |
 | — | `0065-dwc2-ddma-halt-before-freeing-desc-list` | *post-audit (added 2026-09-26, #205)* | **excluded** — descriptor DMA is off on this board: dwc2 only enables it through `0059`, which is held for hardware qualification, so this code never runs | Same as `0054`. |
 | — | `0066-dwc2-ddma-keep-xfercompl-unmasked` | *post-audit (added 2026-09-26, #205)* | **excluded** — descriptor DMA is off on this board: dwc2 only enables it through `0059`, which is held for hardware qualification, so this code never runs | Same as `0054`. |
+| — | `0067-wifi-rtw88-8821c-support-rfe-type-7` | *post-audit (added 2026-09-30)* | **included** | Adds the missing RFE type 7 definition to rtw88's RTL8821C driver; USB-generic, no architecture exposure. |
 
 ### DE25-local patches (not in the audit — new work)
 
@@ -116,8 +117,9 @@ Source of the verdicts: [`docs/de25-patch-portability.md`](../../../../docs/de25
 | Excluded from the audit | **8** — 7 `de10-only` (`0001` `0003` `0004` `0043` `0044` `0045` `0046`) + `0002` (`portable-with-rework`, deferred) |
 | Post-audit patches considered | 6 (`0047` excluded — already upstream at 7.2, and retired 2026-09-21 when 6.18.53 took it too; `0048`, `0049` included — 2026-09-11; `0050` excluded — 7.2.3 already carries mainline's own plugged read-ahead, 2026-09-11; `0051` excluded — a revert of a 6.18.y-only backport defect 7.x never had, 2026-09-14; `0052` excluded — DesignWare MMC hook, this board is Cadence SDHCI, 2026-09-21; `0053` excluded — 7.x has no `exfat_dir_readahead()` to bound, 2026-09-21) |
 | dwc2 series `0054`–`0066` (#205) | 13 considered, **3** included (`0056`, `0060`, `0061`); 10 held: the descriptor-DMA set and `0058`/`0059`/`0062` wait for hardware qualification (`docs/dwc2-usb-irq.md`) |
+| rtw88 `0067` (2026-09-30) | 1 considered, **1** included |
 | DE25-local patches | **2** (`0101`, `0102`) |
-| **Total applied here** | **37** |
+| **Total applied here** | **38** |
 
 ## Note for the DE25 DTS
 

docs/kernel-recon/reduce.py

@@ -58,6 +58,9 @@ def carried_patches_str(r):
            "0065-dwc2-ddma-halt-before-freeing-desc-list",
            "0066-dwc2-ddma-keep-xfercompl-unmasked",
        )},
+    "0067-wifi-rtw88-8821c-support-rfe-type-7.patch":
+        "Original rtw88 fix for a forum user's 0bda:c811 dongle, not a fork commit. Reason and "
+        "provenance live in docs/patch-provenance.md. Added 2026-09-30.",
 }
 
 # "carried-upstream-only" is distinct from "carried": the commit is NOT applied to the

docs/patch-provenance.md

@@ -1839,6 +1839,16 @@ question and the options ledger are in [`dwc2-usb-irq.md`](dwc2-usb-irq.md). Non
 sent upstream yet (owner decision, after rig soak). Parked patches and lab-only
 instrumentation from the same work live in [`dwc2-usb-irq/`](dwc2-usb-irq/README.md) and are not applied.
 
+### `0067` — rtw88 RTL8821C RFE type 7, added 2026-09-30
+
+Original fix by the repo owner, not from the fork. A forum user's RTL8811CU dongle (`0bda:c811`)
+reports RFE type 7, which `rtw8821c_rfe_defs[]` has no entry for, so probe fails with
+"rfe 7 isn't supported" on stock's kernel and ours alike. The patch adds the entry and extends the
+2.4 GHz path-B power-index copy from types 2/4 to 7, following Realtek's vendor driver
+(`morrownr/8821cu-20210916`, which groups 2/4/7 as BTG); the patch header has the details. Type 7
+was still missing from wireless, wireless-next and rtw-next on 2026-09-30. Carried in all three
+series (beta and de25nano by symlink). Not yet tested on the hardware, not sent upstream (owner decision).
+
 ### Provenance note
 
 B1 and B4 were **found by automated static review on PR #2**, not by the porting

docs/rt-beta-kernel.md

@@ -14,13 +14,13 @@ see `linux.hash`), and the kernel release string (`7.2.0-rc7` → **`7.2.0`**,
 which is the module directory name too). From here the pin tracks **7.2.y**
 point releases rather than mainline; it does not follow 7.3-rc1. See §10.
 
-The variant builds end-to-end (`make rt`, **37 of the 40 shared + 4 beta-local**
-carried patches — **41 entries; the three omissions are `0050`, `0051` and
-`0053`, and 7.2.x needs none of them — the first it already has in-tree in a
-different shape, the second repairs a 6.18.y-only backport defect that never
-reached 7.x, and the third bounds a function 7.x does not have, see §2 and the
-series header** (`0047`, a fourth omission from 2026-08-24, retired on
-2026-09-21 when 6.18.53 took the same mainline commit); three of the
+The variant builds end-to-end (`make rt`, **51 of the 53 shared + 4 beta-local**
+carried patches — **55 entries; the two omissions are `0050` and `0053`, and
+7.2.x needs neither — the first it already has in-tree in a different shape,
+the second bounds a function 7.x does not have, see §2 and the series header**
+(two earlier omissions are retired: `0047` on 2026-09-21 when 6.18.53 took the
+same mainline commit, `0051` on 2026-09-26 when 6.18.54 reverted the commit it
+repaired); three of the
 beta-local four are the UIO set (§8) and the fourth is the ramoops crash-record
 reservation (§9)) and **boots and runs MiSTer on a
 real DE10-Nano — confirmed 2026-07-20 on 7.2-rc4, and again 2026-08-14 on
@@ -245,7 +245,7 @@ card, and nothing on the card referenced it), and deliberately NOT inside
 | 7.2 has ARM32 `ARCH_SUPPORTS_RT` in-tree | ✅ verified (`arch/arm/Kconfig`) |
 | Config layering (fragment → 7.2 config) resolves | ✅ verified (`merge_config.sh` + `olddefconfig`, clean) |
 | `linux.config` reconciles to 7.2 (criticals survive) | ✅ **after a real fix (2026-07-18)**: the earlier full-config test masked a minimal-config trap — 7.x turned the HID drivers' LED `select`s into `depends on`, so `olddefconfig` silently dropped `NEW_LEDS`/`LEDS_CLASS` **and with them the whole HID controller stack** (`HID_PLAYSTATION`/`HID_NINTENDO` vanished from the config, no error). Fixed by making the LED foundation explicit in `linux.config` (`NEW_LEDS`/`LEDS_CLASS`/`LEDS_TRIGGERS`, no-ops on 6.18); all 19 critical symbols re-audited present |
-| **All series entries** (42 at the time: 38 of the 40 shared + the 4 beta-local; 40 since the 2026-09-12 retirement of `0040`/`0041`, whose absence was re-checked at `-F0` on v7.2.5 — the current pin — for the surviving hid-nintendo stack, and `hid-nintendo.o` cross-compiled `W=1` clean there) apply to the pinned **7.2.3** at Buildroot's `patch -F0` (`linux-patches/`; the separate `linux-patches-upstream/` series is never applied to this variant — see §2) | ✅ **re-verified 2026-09-11 on the full 42-entry series** (fork-sync increment 2026-09 Wave 3, adding `0048`/`0049`), replayed with `patch -p1 -F0` in series order against a v7.2.3 tree: **42/42 applied, exit 0, zero hunks taking fuzz**. `0048` lands at zero offset; `0049` lands at offsets only (hunk 1 +20, hunks 2-3 +21) on top of this series' own `0015`/`0032`/`0034`/`0035`/`0038`–`0041` hid-nintendo stack. A separate dry-run confirmed `0050` (the newly-added 6.18-only patch, correctly NOT in this series) still fails both hunks against the same v7.2.3 tree. This re-verification is apply-only; `make rt` has not been re-run on the 42-entry series. ✅ Previously **re-verified 2026-08-17 on the full 40-entry series**, through Buildroot's own `apply-patches.sh` against a freshly extracted pristine `linux-7.2.tar.xz` whose sha256 matched kernel.org's signed manifest (`f9fef3d1…`): **40/40 applied, exit 0, zero hunks taking fuzz** (80 hunks land at an offset, which `-F0` permits). No re-anchor was needed anywhere: the four re-anchored copies (0001, 0015, 0030, 0037) carry over unchanged and, with all four beta-local patches, land at **zero offset**. The offsets are concentrated where they always were (`0017` 18, `0031` 12, `0033` 5, `0042` 5). **This row now measures the whole series** — the standing "⚠ not evidence about `0038`–`0042`" caveat is retired, because those five are in the series as of the same day (§2). Three measurements were taken that day and each is a strict superset of the last: **34/34** on the rc7 → 7.2 bump (70 offsets), **35/35** once `0046` landed (70 offsets — identical distribution, so `0046` costs the rest of the series nothing), **40/40** with `0038`–`0042` symlinked in (80 offsets, the ten new ones all inside the five added patches). Earlier figures (31/31 on rc5; before that 29/29, and a bogus "28/31" measured at `patch`'s default fuzz 2, which Buildroot forbids) predate the 2026-07-20 `0037`/`0030` re-anchors and the beta-local set. ⚠ Applying is not building — see the next row |
+| **All series entries** (42 at the time: 38 of the 40 shared + the 4 beta-local; 40 since the 2026-09-12 retirement of `0040`/`0041`, whose absence was re-checked at `-F0` on v7.2.5 for the surviving hid-nintendo stack, and `hid-nintendo.o` cross-compiled `W=1` clean there; **55 today**, after `0054`–`0067`: a `make all` on 2026-09-30 applied all 55 to 7.2.8 through Buildroot at `-F0` and built the RT kernel) apply to the pinned **7.2.3** at Buildroot's `patch -F0` (`linux-patches/`; the separate `linux-patches-upstream/` series is never applied to this variant — see §2) | ✅ **re-verified 2026-09-11 on the full 42-entry series** (fork-sync increment 2026-09 Wave 3, adding `0048`/`0049`), replayed with `patch -p1 -F0` in series order against a v7.2.3 tree: **42/42 applied, exit 0, zero hunks taking fuzz**. `0048` lands at zero offset; `0049` lands at offsets only (hunk 1 +20, hunks 2-3 +21) on top of this series' own `0015`/`0032`/`0034`/`0035`/`0038`–`0041` hid-nintendo stack. A separate dry-run confirmed `0050` (the newly-added 6.18-only patch, correctly NOT in this series) still fails both hunks against the same v7.2.3 tree. This re-verification is apply-only; `make rt` has not been re-run on the 42-entry series. ✅ Previously **re-verified 2026-08-17 on the full 40-entry series**, through Buildroot's own `apply-patches.sh` against a freshly extracted pristine `linux-7.2.tar.xz` whose sha256 matched kernel.org's signed manifest (`f9fef3d1…`): **40/40 applied, exit 0, zero hunks taking fuzz** (80 hunks land at an offset, which `-F0` permits). No re-anchor was needed anywhere: the four re-anchored copies (0001, 0015, 0030, 0037) carry over unchanged and, with all four beta-local patches, land at **zero offset**. The offsets are concentrated where they always were (`0017` 18, `0031` 12, `0033` 5, `0042` 5). **This row now measures the whole series** — the standing "⚠ not evidence about `0038`–`0042`" caveat is retired, because those five are in the series as of the same day (§2). Three measurements were taken that day and each is a strict superset of the last: **34/34** on the rc7 → 7.2 bump (70 offsets), **35/35** once `0046` landed (70 offsets — identical distribution, so `0046` costs the rest of the series nothing), **40/40** with `0038`–`0042` symlinked in (80 offsets, the ten new ones all inside the five added patches). Earlier figures (31/31 on rc5; before that 29/29, and a bogus "28/31" measured at `patch`'s default fuzz 2, which Buildroot forbids) predate the 2026-07-20 `0037`/`0030` re-anchors and the beta-local set. ⚠ Applying is not building — see the next row |
 | **`0038`–`0042` and `0046` compile on 7.2** (the six the series gained on 2026-08-17) | ✅ **verified twice, 2026-08-17.** First cheaply: a targeted ARM cross-compile of `drivers/hid/`, `drivers/leds/` and `fs/pstore/` on the 40-patch tree with the real config — exit 0, **zero warnings, zero errors**, `hid-nintendo.o` and `hid-playstation.o` (the two files all five HID patches touch) and `fs/pstore/ram.o` (`0046`'s consumer) all built. Then for real, inside the full `make rt` below, with Buildroot's own toolchain rather than the host's — which is the run that counts |
 | `xone` compiles on 7.2 | ✅ verified (not shipped by the kernel-only variant — §4) |
 | **The RT kernel compiles and links** | ✅ **re-verified locally on rc5 (2026-07-28), and again on rc7** (the `output-rt` tree for the pinned 7.2-rc7 holds a linked `zImage`, `CONFIG_PREEMPT_RT=y`, kernel release `7.2.0-rc7`) — see the `make rt` row below, which is the same cross-build end to end. Two 7.x API ports were needed back on rc3 and still live in beta-local patch copies — the shared 6.18 patches stay byte-identical to stock: `fbcon_update_vcs()`'s header moved into fbdev core (beta 0001, one-line include delta), and `exfat_remove_entries()` grew a `free_benign` arg (that one was folded back into the shared patch on 2026-07-25, so beta 0031 is a symlink again). Unlike the rc3 → rc4 bump, which re-verified patch application only and left this row resting on CI, the rc4 → rc5 bump was built locally before the pin was pushed. ✅ **Re-verified on 7.2 final, 2026-08-17**, from a clean `make rt-clean` (both toolchains from scratch, no ccache): exit 0, kernel release string **`7.2.0`**, `CONFIG_PREEMPT_RT=y` in the built tree's `.config`, and `.applied_patches_list` records all **34** series entries as they stood that day — the first time the beta-local `0044`/`0045` have been through a real build rather than an apply-check. No 7.x API port was needed beyond the ones already carried. ✅ **Re-verified on the full 40-entry series later the same day**, again from a clean tree: exit 0, release `7.2.0`, `CONFIG_PREEMPT_RT=y`, `.applied_patches_list` 40 entries ending `0044` → `0045` → `0046`. That run is the first to have compiled `0038`–`0042` and `0046` as part of a kernel rather than as an apply-check or a subsystem build. |