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

[Johannes Berg]

On Thu, 2026-10-15 at 13:51 +0800, Baochen Qiang wrote:
> 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.

So I can relate to that, but ...

> 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.

mac80211 has the same problem? How would *it* hold off rather than
annotating every callback from userspace, debugfs, ethtool, sysfs, and
the rest of the kernel with checks? *Maybe* at the boundary _to_ the
driver, but that's bigger than the boundary every individual driver
has...

> 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.

This is what iwlwifi does, but it doesn't take *nearly* as long. :)

There might be a chance to disentangle the RTNL from this given the work
I did recently on disentangling it from cfg80211, but then on recovery
*failure* we have a problem with cfg80211_shutdown_all_interfaces().

> 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?

See above - I don't see how we'd really implement the latter reliably in
mac80211? Sure, we have a bunch of in_reconfig checks, but ... I
wouldn't really trust them and I'm not sure we can guarantee them given
the surface area.

johannes