summaryrefslogtreecommitdiff
path: root/tools/testing/vma/include/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorBitterblue Smith <rtl8821cerfe2@gmail.com>2026-03-18 19:45:13 +0200
committerPing-Ke Shih <pkshih@realtek.com>2026-03-30 09:41:41 +0800
commit737e980e12983bb7420a2c00b981a1e607079a84 (patch)
treed23a96c0390468b91cc98f6f556aec8ec3b7f266 /tools/testing/vma/include/git@git.tavy.me:linux.git
parentb2bf9d61e14af4129362aeb9c10034229a6d8f08 (diff)
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
Diffstat (limited to 'tools/testing/vma/include/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions