Re: [RFC PATCH] ath11k: add ath11k_mac_op_flush_sta to properly flush pending packets

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 <[email protected]>
>>> Tested-by: Florian Maurer  <[email protected]>
>>> Co-authored-by: Benjamin Berg <[email protected]>
>>> Tested-by: Flole <[email protected]>
>>> ---
>>> 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, &params);
>>> +	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.
got it. i was working on exactly the same patch some days ago and got a 
report from testers with exakt that firmware crash.
i may be able to explain the cause since i have the firmware 
sourcecodes, but they are very complex and it will take a while to find 
that out
>