Re: [PATCH ath-current v2] wifi: ath11k: reset ar->num_station on hardware start

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

On Fri Jul 31, 2026 at 7:41 AM CEST, Baochen Qiang wrote:
> s/ar->num_station/ar->num_stations/ in subject
>
>
> On 7/30/2026 10:03 PM, Nicolas Escande wrote:
>> When (multiple) hw restart occurs, we end up in a situation where we
>
> by hw restart do you mean firmware crash and then recovers ?

Yes firmware crash indeed.
 
>
>> cannot accept new stations / mesh peers. This seems to be the
>> 'num_stations' in 'struct ath11k' that did not get reset properly in
>> this case. In ath11k_mac_op_start(), it was indeed the only accounting var
>> that did not get reset so let's clear it too.
>
> the root cause description looks confused to me: if it is firmware crash and recover, we
> should run the path ath11k_core_reset() -> ath11k_core_post_reconfigure_recovery() ->
> ath11k_core_halt() -> ath11k_mac_peer_cleanup_all() and in that function ar->num_stations
> is cleared.

So about how I came up to this fix:

When I first saw it I though I would be able to reproduce it using the
debugfs simulate firmware crash feature, but I was not. Then from the logs
I had at the time I noticed that there were multiple crashes back to back,
sometimes while still recovering from the first one. I think thats why I was
not able to properly simulate it and find the race condition leading to this.

In the meantime I wondered why we hit the num_station checks and not the
others like num_peers for example, and found that it was missing in
ath11k_mac_op_start(). So I made this change as I do not see how it hurts,
and I've never hit the issue again.

>> 
>> This avaoids problems like those:
>
> s/avaoids/avoids/
>
[...]
>> 
>> Tested-on: QCN9074 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1
>> 
>> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
>> Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
[...]
I'll spin a new revision with all the feedback taken into account at some point