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

[Baochen Qiang]

On 10/17/2026 5:33 PM, Johannes Berg wrote:
> 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().

Hmm, I wonder whether the restart work could take rtnl only around
cfg80211_shutdown_all_interfaces(). From a quick look,
ieee80211_reconfig() itself mostly only needs the wiphy mutex, except
ieee80211_add_virtual_monitor(), which asserts RTNL. Though any rtnl holder that then
needs this wiphy would still end up stalling everyone while the recovery runs.

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

Fair enough, I agree. Looking at it again, option 2 would just move the
per-callback checks from the driver into mac80211, with an even bigger
surface to cover, so it doesn't really solve anything. Let's drop it.

> 
> johannes