Re: [RFC PATCH] wifi: ath10k: support flush_sta method

["Nicolas Escande" <nico.escande@gmail.com>]

On Wed Aug 6, 2025 at 9:00 AM CEST, Zhi-Jun You wrote:
> 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 ath10k because ieee80211_flush_queues()
> will stop all traffic and call ath10k_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.
>
> ops->flush_sta will be set to NULL if htt.disable_tx_comp is set to
> true.
>
> Tested-on: QCA9984 hw1.0 PCI 10.4-3.9.0.2-00157
>
> Signed-off-by: Zhi-Jun You <hujy652@gmail.com>
> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 24dd794e31ea..6959f20334a7 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -8135,6 +8135,20 @@ static void ath10k_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
>  	mutex_unlock(&ar->conf_mutex);
>  }
>  
> +static void ath10k_mac_op_flush_sta(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
> +			     struct ieee80211_sta *sta)
> +{
> +	struct ath10k_vif *arvif = (void *)vif->drv_priv;
> +	struct ath10k *ar = hw->priv;
> +	u32 bitmap = 0xFFFFFFFF;
> +	int ret = 0;
> +
> +	ret = ath10k_wmi_peer_flush(ar, arvif->vdev_id, sta->addr, bitmap);
> +	if (ret)
> +		ath10k_warn(ar, "failed to flush sta (sta %pM)\n",
> +			    sta->addr);

Hello,

Just to be sure, you have seen real improvements from this ?
Because I remember trying this exact WMI command two years ago and I couldn't be
sure it was actually doing something. That's one of the reasons why we ended up
doing the per peer frame accounting as posted by remi here
https://lore.kernel.org/linux-wireless/17d26d6a3e80ff03939ee7935fdc07f979b61a4f.1732293922.git.repk@triplefau.lt/

Thanks