[RFC PATCH] ath11k: add ath11k_mac_op_flush_sta to properly flush pending packets
Sebastian Gottschall
s.gottschall at dd-wrt.com
Tue Oct 7 23:09:37 PDT 2025
Am 07.10.2025 um 15:59 schrieb Florian Maurer:
> On Tue, 2025-10-07 at 14:38 +0200, Sebastian Gottschall wrote:
>> Am 07.10.2025 um 10:11 schrieb Florian Maurer:
>>
>>> When a STA is marked as no longer authorized, if the driver doesn't
>>> implement flush_sta(), mac80211 calls ieee80211_flush_queues() to
>>> flush hardware queues to avoid sending unencrypted frames.
>>>
>>> This has became a problem for ath11k because ieee80211_flush_queues()
>>> will stop all traffic and call ath11k_flush, which waits until the
>>> whole HW queue is empty. In a busy environment this will trigger a
>>> timeout warning and stalls other STAs.
>>>
>>> Fix this by implementing flush_sta method using WMI command to flush
>>> frames of a specific STA.
>>> Flushed frames will be marked as discard in tx complete indication.
>>>
>>> warning print "ath11k c000000.wifi: failed to flush transmit queue 0"
>>> was observed on various openwrt devices, and is fixed through this patch.
>>>
>>> Signed-off-by: Florian Maurer <f.maurer at outlook.de>
>>> Tested-by: Florian Maurer <f.maurer at outlook.de>
>>> Co-authored-by: Benjamin Berg <benjamin at sipsolutions.net>
>>> Tested-by: Flole <flole at flole.de>
>>> ---
>>> We tested this patch and it solved the problem of flushing the transmit
>>> queues taking too long when the AP is busy.
>>> We did not confirm if this flush is implemented to guarantee that no
>>> unencrypted frames are sent out on station removal.
>>> Could someone with more knowledge about the firmware behavior check
>>> wether this approach is feasible or if a different approach should be
>>> taken.
>>> It is not clear to me if the approach taken in "wifi: ath10k: Flush
>>> only requested txq in ath10k_flush()" might be better.
>>> https://lore.kernel.org/linux-wireless/01d859e8e574a1f5d0b916333fe0b5cda859af9b.1732293922.git.repk@triplefau.lt/
>>>
>>> Regards
>>> Florian
>>>
>>> drivers/net/wireless/ath/ath11k/mac.c | 19 +++++++++++++++++++
>>> 1 file changed, 19 insertions(+)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
>>> index 106e2530b64e..a94649edd4ed 100644
>>> --- a/drivers/net/wireless/ath/ath11k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath11k/mac.c
>>> @@ -8330,6 +8330,24 @@ static void ath11k_mac_op_flush(struct ieee80211_hw *hw, struct ieee80211_vif *v
>>> ath11k_mac_flush_tx_complete(ar);
>>> }
>>>
>>> +static void ath11k_mac_op_flush_sta(struct ieee80211_hw *hw,
>>> + struct ieee80211_vif *vif,
>>> + struct ieee80211_sta *sta)
>>> +{
>>> + struct ath11k_vif *arvif = (void *)vif->drv_priv;
>>> + struct ath11k *ar = hw->priv;
>>> + struct peer_flush_params params = {
>>> + .peer_tid_bitmap = 0xFF,
>>> + .vdev_id = arvif->vdev_id,
>>> + };
>>> + int ret = 0;
>>> +
>>> + ret = ath11k_wmi_send_peer_flush_tids_cmd(ar, sta->addr, ¶ms);
>>> + if (ret)
>>> + ath11k_warn(ar->ab, "failed to flush sta (sta %pM)\n",
>>> + sta->addr);
>>> +}
>>> +
>>> static bool
>>> ath11k_mac_has_single_legacy_rate(struct ath11k *ar,
>>> enum nl80211_band band,
>>> @@ -9920,6 +9938,7 @@ static const struct ieee80211_ops ath11k_ops = {
>>> .set_bitrate_mask = ath11k_mac_op_set_bitrate_mask,
>>> .get_survey = ath11k_mac_op_get_survey,
>>> .flush = ath11k_mac_op_flush,
>>> + .flush_sta = ath11k_mac_op_flush_sta,
>>> .sta_statistics = ath11k_mac_op_sta_statistics,
>>> CFG80211_TESTMODE_CMD(ath11k_tm_cmd)
>>>
>> why is peer_tid_bitmap 0xff instead of 0xffffffff?
> When setting it to 0xffffffff it fails with:
> Assertion !CHK_TID_FLG(ptid, WAL_TID_IN_SCHEDQ) failedparam0 :zero,
> param1 :zero, param2 :zero.
> leading to a device reboot. See:
> https://github.com/openwrt/openwrt/pull/20293#issuecomment-3367037471
> It works with 0xffff though, but I don't quite know what the firmware
> does/expects here. Maybe someone with more information can help.
due the sources. BIT 17 has a special purpose named WMI_MGMT_TID
all bits can be masked but bit 17 as it seems
>
More information about the ath11k
mailing list