RE: [PATCH v8 0/6] wifi: rtw88: preparations for RTL8723B/RTL8723BS

[Luka Gejak <luka.gejak@linux.dev>]

Hi Ping-Ke,
On August 31, 2026 4:23:48 AM GMT+02:00, Ping-Ke Shih <pkshih@realtek.com> wrote:

The probe_wait_ms test you suggested has run, nine hours in the tester's
poor signal environment. At 2000 ms he saw one "Failed to send nullfunc
... disconnecting". At 500 ms it was one every twenty to forty seconds.
Same environment, same driver.

The reports are late rather than missing:

  txrpt: nullfunc sn=f0 queued
  wlan0: Failed to send nullfunc to AP after 500ms, disconnecting
  txrpt: nullfunc sn=f0 acked after 810ms

The frame was acknowledged and the link was alive. Nullfunc reports run
400 to 1000 ms on this chip when the link is poor, against 0 to 20 ms
for management frames on the same hardware, so it is firmware retry
time.

That also rules out the timeout path as the mechanism. It fires 2500 ms
after the last enqueue, well after mac80211 has given up, and a build
that handed the frames back as not acked instead of dropping them made
no difference. The sequence number aliasing I raised does not show up
either: every instance had one frame in the queue.

So there is nothing here for the driver to fix, and probe_wait_ms is not
something a driver can set. I am not proposing anything for it.

> But I feel this case, using ieee80211_purge_tx_queue() is equivalent?

Not equivalent. ieee80211_purge_tx_queue() calls ieee80211_free_txskb(),
which calls ieee80211_report_used_skb() with dropped = true: that
settles the airtime accounting and frees the skb properly, but never
reaches ieee80211_sta_tx_notify(). Only ieee80211_tx_status_*() does. It
fixes the ownership bug and tells the connection poll nothing, which
given the above does not matter.

Still worth doing on its own. I will send it separately, no chip
condition.

Best regards,
Luka Gejak