kernel/git/stable/linux.git/drivers/net/wireless/realtek, branch master

Merge tag 'rtw-next-2026-08-02' of https://github.com/pkshih/rtw

2026-08-02T16:50:03+00:00

Ping-Ke Shih says: ================== rtw-next patches for v7.3 Some random cleanups and fixes on rtlwifi, rtw88 and rtw89. The major features added to rtw89 are listed: rtw89: - add LED support - update BT-coexistence mechanism to support dual Bluetooth for RTL8922D - support WiFi 7 chip RTL8922DE ================== Signed-off-by: Johannes Berg

wifi: rtw89: 8922d: enable Makefile and Kconfig for RTL8922DE

2026-08-02T01:55:20+00:00

RTL8922DE is a WiFi 7 chipset, supporting 2x2 2GHz/5GHz/6GHz 4096/1024-QAM 160MHz channels. As STA, AP and P2P modes work well, enable this chipset. Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260730060220.55844-8-pkshih@realtek.com

wifi: rtw89: coex: Update Wi-Fi/Bluetooth coexistence version to 9.24.1

2026-08-02T01:55:04+00:00

The 9.24.1 coexistence version included firmware 0.35.111.X support for RTL8922A/D, 0.24.97.X support for RTL8852C, 0.29.133.X support for RTL8852B chip family. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260730060220.55844-7-pkshih@realtek.com

wifi: rtw89: coex: Port _update_bt_ctrl_lps() for BT profile-based LPS control

2026-08-02T01:53:22+00:00

The old lps_ctrl_scbd logic in _update_bt_scbd() blocked WiFi LPS only when mode == BTC_WLINK_V0_2G_STA, which created a dead-lock while WiFi already in LPS suppressed TDD binding so mode was never set to BTC_WLINK_V0_2G_STA, lps_ctrl_scbd stayed 0, and WiFi remained stuck in LPS. Port _update_bt_ctrl_lps() from the reference implementation to check BT profile existence (A2DP, HFP, PAN) for both radios directly, with out_of_band and freerun guards so LPS is only blocked when WiFi and Bluetooth actually share a band. Call it from both _update_bt_scbd() and _update_bt_info() so profile changes reported via either SCBD or BT info C2H correctly update lps_ctrl_scbd. Also remove the dead lps_ctrl_scbd_last field. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260730060220.55844-6-pkshih@realtek.com

wifi: rtw89: coex: Change Wi-Fi link_mode_v0 translating timing

2026-08-02T01:53:06+00:00

Logic should only get explicit link_mode only, to cover the old branch link_mode_v0 using (old branch firmware needed) should do translating after link_mode is settled. And the coexistence logic has already updated to new branch style, so the logic should use new link_mode, don't need to consider link_mode_v0. To prevent unexpected logic bug, refine the related logic. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260730060220.55844-5-pkshih@realtek.com

wifi: rtw89: coex: Clear BT link weight when BT is disabled

2026-08-02T01:52:50+00:00

When a BT device is disabled, _update_bt_link_cnt() is no longer called for that device, so its link_weight[] retains stale values from the last active period. _set_bind_info() then computes a non-zero band score for the disabled device, which can lead to an incorrect tdd_bind.rf_band selection and ultimately wrong coexistence policy. Clear link_weight[] for any disabled BT device at the start of the _set_bind_info() loop so that stale scores are not carried forward. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260730060220.55844-4-pkshih@realtek.com

wifi: rtw89: coex: Fix BT-info parsing for 5/6 GHz band & dual Bluetooth

2026-08-02T01:51:10+00:00

The _update_bt_info() function always parsed BT-info for bt0 and used a single raw_info buffer regardless of which BT device sent the packet or which RF band it belongs to. This caused two bugs: 1. BT-info packets from bt1 were incorrectly parsed into bt0's state. 2. BT-info packets from 5/6 GHz BT (L1 bit7=1) overwrote the 2.4 GHz link_info and raw_info, breaking duplicate detection across bands. Fix by adding the bid parameter to select bt0/bt1, detecting the 5/6 GHz band flag (L1 bit7) to route packets into link_info_56g with a dedicated raw_info_56g buffer, and updating the early-return mask to ignore bit7 when checking the length field. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260730060220.55844-3-pkshih@realtek.com

wifi: rtw89: coex: Fix Bluetooth link weight not updated on profile change

2026-08-02T01:50:54+00:00

_update_bt_link_cnt() was missing the bt->link_weight[]. Without it, link_weight stays at the initial value of 5 (set on BT re-enable) regardless of the active BT profile. _set_bind_info() uses link_weight to compute b2g_score/b5g_score, which determines tdd_bind.rf_band. With a stale weight of 5 (below the active profile threshold), tdd_bind.rf_band may not reflect the actual RF band, causing mode_v0 in _run_coex() to remain 0 (BTC_WLINK_NOLINK), which incorrectly triggers _action_wl_nc() instead of the BT-profile action. Add the link_weight calculation to _update_bt_link_cnt() using the same weighting table as Formal (BIS/A2DP-sink: 70, A2DP: 40-60, PAN/active: 30, no-profile: 5, else: 9) and call _update_bt_link_cnt() from _update_bt_info() after parsing the profile exist flags, replacing the open-coded link_cnt increment that omitted le-audio profiles. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260730060220.55844-2-pkshih@realtek.com

wifi: rtw89: change scan offload format to V3 for WiFi 7 IC

2026-08-02T01:31:24+00:00

Adapt H2C format to fit firmware version after 0.35.113.2, which only supports active scanning with a provided SSID list. The wildcard_6ghz field is no longer required for WiFi 7 chips' new format, but not removed since WiFi 6 still requires it. Keep original H2C style also to support older firmwares. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260729124354.3231368-4-pkshih@realtek.com

wifi: rtw89: fix scan offload version check logic

2026-08-02T01:31:07+00:00

The version check with less than should check for smallest upper-bound first, or some branch will be unreachable. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20260729124354.3231368-3-pkshih@realtek.com