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

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

On Wed Aug 6, 2025 at 5:51 PM CEST, Zhi-Jun You wrote:
> On Wed, Aug 6, 2025 at 10:23 PM Jeff Johnson
> <jeff.johnson@oss.qualcomm.com> wrote:
>>
>> On 8/6/2025 12:00 AM, 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>
>> > ---
>>
>> There is already a patch from Remi pending for this, see:
>> https://msgid.link/cover.1732293922.git.repk@triplefau.lt
>>
>> Please see if that series addresses your needs.
>>
>> First Kalle, and then I, held this back due to lack of internal validation
>> across supported platforms, but it is actually still on my TODO list:
>> https://patchwork.kernel.org/project/linux-wireless/list/?series=911851
>>
>> Let me make one more validation request internally since I know there is at
>> least one ath10k-based project with active development.
>>
>> /jeff
>
> Hi Jeff,
>
> I am aware of the series and glad to know it's still on the list.
> I did test with it but the warning can still be triggered easily with
> the instructions in Remi's series.
> And according to other people's reports it can still block sometimes. [0]

Well that's to be expected with this implementation and the use case described
by remi. You have a station that is out of range or powered down without telling
the ap, and you wait for the firmware to tell you that it did managed to
transmit to the sta or that it has given up transmitting. So clearly you will
have the warning.

The goal was to not block trafic pending for other STA when that happens.

What I recall, and sorry if this is vague it was quite a few years ago, is
that when issuing the WMI command to the firmware to drop all frames for the STA
it just did not, and it was still trying to transmit them (checked with ota
capture at that time). But I do not recall if the firmware tried to send frames
encrypted or not (as we would remove the key right after the wmi command and
before the firmware had given up on transmitting the frames) which was one of
the reason .flush_sta() was added in the first place I believe.

>
> drv_flush_sta() is called before clearing the keys and Remi's approach
> still waits for the frames to be sent which imo isn't enough in this
> situation.
>
> [0]: https://github.com/openwrt/openwrt/pull/19427#issuecomment-3102794793
>
> Best regards,
> Zhi-Jun You