mac80211: realtek: backport fix for lost TX reports on USB

Backport the upstream fix for USB devices where the firmware falls
behind on TX status requests and starts numbering the reports wrongly,
so the driver gives up on them:

    rtw_8822bu 3-1:1.0: failed to get tx report from firmware

QOS Null data frames were described to the firmware as ordinary data
while plain Null data frames were described as management frames, which
the firmware does not cope with.

Losing those reports is not cosmetic in AP mode. hostapd polls an idle
station with a Null frame and waits for the TX status. When rtw88 purges
the frame instead, hostapd never learns that the station answered and
disconnects it:

    hostapd: phy7-ap0: STA 9c:53:22:29:d3:6e IEEE 802.11: deauthenticated
    due to inactivity (timer DEAUTH/REMOVE)

mac80211 also keeps the skb in its ack_status_frames IDR, which shows up
as "Have pending ack frames!" when the device is unbound.

Upstream commit 737e980e1298 ("wifi: rtw88: TX QOS Null data the same
way as Null data"), in Linux since v7.1. It carries no Cc: stable tag,
so it will not arrive through a 6.12.y point release of the backports
tarball used by this branch. The author tested it on RTL8812BU, which is
the chip in the adapter used here.

Signed-off-by: Josef Schlehofer <pepe.schlehofer@gmail.com>
Link: https://github.com/openwrt/openwrt/pull/25299
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>

package/kernel/mac80211/Makefile

@@ -11,7 +11,7 @@ include $(INCLUDE_DIR)/kernel.mk
 PKG_NAME:=mac80211
 
 PKG_VERSION:=6.12.96
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 PKG_LICENSE:=GPL-2.0-only
 PKG_LICENSE_FILES:=COPYING
 

package/kernel/mac80211/patches/rtl/053-v7.1-wifi-rtw88-TX-QOS-Null-data-the-same-way-as-Null-data.patch

@@ -0,0 +1,50 @@
+From 737e980e12983bb7420a2c00b981a1e607079a84 Mon Sep 17 00:00:00 2001
+From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+Date: Wed, 18 Mar 2026 19:45:13 +0200
+Subject: [PATCH] wifi: rtw88: TX QOS Null data the same way as Null data
+
+When filling out the TX descriptor, Null data frames are treated like
+management frames, but QOS Null data frames are treated like normal
+data frames. Somehow this causes a problem for the firmware.
+
+When connected to a network in the 2.4 GHz band, wpa_supplicant (or
+NetworkManager?) triggers a scan every five minutes. During these scans
+mac80211 transmits many QOS Null frames in quick succession. Because
+these frames are marked with IEEE80211_TX_CTL_REQ_TX_STATUS, rtw88
+asks the firmware to report the TX ACK status for each of these frames.
+Sometimes the firmware can't process the TX status requests quickly
+enough, they add up, it only processes some of them, and then marks
+every subsequent TX status report with the wrong number.
+
+The symptom is that after a while the warning "failed to get tx report
+from firmware" appears every five minutes.
+
+This problem apparently happens only with the older RTL8723D, RTL8821A,
+RTL8812A, and probably RTL8703B chips.
+
+Treat QOS Null data frames the same way as Null data frames. This seems
+to avoid the problem.
+
+Tested with RTL8821AU, RTL8723DU, RTL8811CU, and RTL8812BU.
+
+Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
+Acked-by: Ping-Ke Shih <pkshih@realtek.com>
+Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
+Link: https://patch.msgid.link/2b53fb0d-b1ed-47b6-8caa-2bb9ae2acb80@gmail.com
+---
+ drivers/net/wireless/realtek/rtw88/tx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/wireless/realtek/rtw88/tx.c b/drivers/net/wireless/realtek/rtw88/tx.c
+index 2ab440cb2d67bb..3106edb84fb477 100644
+--- a/drivers/net/wireless/realtek/rtw88/tx.c
++++ b/drivers/net/wireless/realtek/rtw88/tx.c
+@@ -421,7 +421,7 @@ void rtw_tx_pkt_info_update(struct rtw_dev *rtwdev,
+ 		pkt_info->mac_id = rtwvif->mac_id;
+ 	}
+ 
+-	if (ieee80211_is_mgmt(fc) || ieee80211_is_nullfunc(fc))
++	if (ieee80211_is_mgmt(fc) || ieee80211_is_any_nullfunc(fc))
+ 		rtw_tx_mgmt_pkt_info_update(rtwdev, pkt_info, sta, skb);
+ 	else if (ieee80211_is_data(fc))
+ 		rtw_tx_data_pkt_info_update(rtwdev, pkt_info, sta, skb);