RE: [PATCH rtw-next] wifi: rtw88: Ignore TX report sequence number from the 8051 chips

[Ping-Ke Shih <pkshih@realtek.com>]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 09/02/2026 10:19, Ping-Ke Shih wrote:
> > Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> >> 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.
> >
> > Does it mean number of reports is correct? But with incorrect sequence number?
> > Then, you just ignore checking 'sn' but assume 'st' is correct.
> >
> 
> The number of reports is correct most of the time. Only when the firmware
> is overwhelmed (?) it doesn't provide every report, but later it recovers.
> 

I was not aware that this happened while scanning, so we might apply this loose
checking under scan condition -- test_bit(RTW_FLAG_SCANNING, rtwdev->flags)"?
If TX report is because of re-key, it can still use original rule. 

[...]

> 
> >>
> >> 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. Ignore the TX report sequence
> >> number reported by these chips and match the reports with the requests
> >> in the order they come in.
> >>
> >> Tested with RTL8821AU and RTL8723DU.
> >>
> >> Signed-off-by: Bitterblue Smith <rtl8821cerfe2@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 c04ff31d0f1e..98215ecc884a 100644
> >> --- a/drivers/net/wireless/realtek/rtw88/tx.c
> >> +++ b/drivers/net/wireless/realtek/rtw88/tx.c
> >> @@ -248,7 +248,7 @@ void rtw_tx_report_handle(struct rtw_dev *rtwdev, struct sk_buff *skb, int src)
> >>         spin_lock_irqsave(&tx_report->q_lock, flags);
> >>         skb_queue_walk_safe(&tx_report->queue, cur, tmp) {
> >>                 n = (u8 *)IEEE80211_SKB_CB(cur)->status.status_driver_data;
> >> -               if (*n == sn) {
> >> +               if (*n == sn || rtw_chip_wcpu_8051(rtwdev)) {
> >
> > Can we only limit to USB devices (or non-PCI devices)?
> >
> 
> I don't think so. RTL8821AE also has this problem. I didn't mention it
> in the commit message because support for RTL8821AE in rtw88 is
> unofficial. (I modified rtw88_pci to handle the older generation, see
> the use_new_trx_flow=false code path in rtlwifi.)

How about official RTL8723DE?

> 
> >>                         __skb_unlink(cur, &tx_report->queue);
> >>                         rtw_tx_report_tx_status(rtwdev, cur, st == 0);
> >>                         break;
> >> --
> >> 2.52.0
> >