Re: [PATCH v2 1/3] wifi: ath12k: fix MLO station firmware crash recovery

[Baochen Qiang <baochen.qiang@oss.qualcomm.com>]

On 8/5/2026 1:49 AM, Jose Ignacio Tornos Martinez wrote:

[...]

> Fix by moving clear_bit(ATH12K_FLAG_RECOVERY) from
> ath12k_core_reconfigure_on_crash() to ath12k_mac_op_reconfig_complete(),
> so the flag stays set through the entire mac80211 reconfig phase. Add
> ATH12K_FLAG_RECOVERY checks in change_vif_links, set_key, and sta_state
> to skip operations that are invalid during recovery. Add
> ATH12K_FLAG_CRASH_FLUSH checks in mac_flush, station_remove,
> clear_peer_keys, dp_rx_ampdu_stop, and peer_mlo_link_peers_delete to
> return immediately when the firmware is dead.


I don't think patches 1 and 2 are the right approach. Guarding every callback that can run
during recovery with a RECOVERY/CRASH_FLUSH check doesn't scale, whatever callback we
forget today is the next crash report. Besides, such guards don't help those in-flight ops.

The actual problem is that nothing stops mac80211 from issuing control ops while the
ath12k driver is in mid-recovery. I'd rather fix that than keep adding per-op checks.


---

Hi Johannes,

We keep running into this in ath12k and I'd like your opinion before I send anything.

Firmware crash recovery in ath12k (and probably other drivers too) is slow and async: we
detect the crash, then do driver internal state cleanup, then power-cycle + firmware
reload (total ~1.3s) before the driver is usable again, and only then call
ieee80211_restart_hw(). For that whole window mac80211 doesn't know about the crash and
keeps pushing scan, connect, add_key, sta_state etc. into the driver that's tearing its
state down, which gets us NULL derefs rather than clean failures.

The trouble is I can't see a clean driver-only fix. The driver knows the device is gone at
crash-detect, but it has no way to tell mac80211 to hold off until it calls restart_hw().
in_reconfig would do exactly what I want, but it's only raised inside restart_hw(), which
is far too late for a device like this - by the time it goes up we've already taken the ops.

So the driver and mac80211 are out of sync for that window and I don't see a good hook to
close it today. I see two ways out and I'm not sure which you'd prefer:

1. Do the whole recovery inside the restart path, i.e. move the whole thing including
state reset, power cycle and firmware reload into the driver's .start() reached from
ieee80211_reconfig(). Then it all runs with the wiphy lock held and in_reconfig already
set, so the sync is free and no new API is needed. The downside is we'd be holding rtnl
for ~1.3s, which I don't think you'll like.

2. Let the driver raise the barrier early, right after crash is detected, e.g. split
ieee80211_restart_hw() into two parts behind separate APIs: the first stops queues and
sets in_reconfig, the second just queues the restart work. That way ath12k can do the
time-consuming part outside the rtnl lock while staying in sync with mac80211. This would
also need a few op entry points that don't currently check in_reconfig (the scan entry,
for one) to be filled in, otherwise raising it early doesn't actually fence those ops.

Does either of these look right to you, or is there a direction I'm missing?