Re: [PATCH wireless-next v2 09/18] wifi: cfg80211: document wiphy mutex for radar/CAC events

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2026-10-05 at 11:36 -0700, Brian Norris wrote:
> > I think so. Or we can discuss it should be async in cfg80211, or an
> > async version? I guess first we should discuss how to solve it either
> > way, and look at all the drivers that still have the issue.
> 
> At first, I thought it'd be trivial to just throw in
> wiphy_lock()/unlock() in 1 or 2 places, similar to commit 0d7c2194f17c
> ("wifi: mwifiex: add missing locking for cfg80211 calls"). But I'm not
> sure that's actually sound -- it might introduce some locking inversion
> problems, where (for example) mwifiex_del_virtual_intf() expects to be
> able to flush/destroy these workers, but it's already holding the wiphy
> mutex.
> 
> (I wonder if commit 0d7c2194f17c is similarly unsound.)

Yeah, I have no idea :-)

Some worker here could maybe move to wiphy work these days? But you
probably wouldn't want arbitrary rx/tx handled with wiphy mutex ...

> Either I'm missing something (quite possible), or it'll take a little
> more thought on what the right solution should be.
> 
> Anyway, I'm fine with your approach of document first, fix later. It's
> hard to move anything if you have to reason through every crazy /
> lightly-maintained driver for every problem.

I pretty much try to for all the ones that are correct in the first
place, but ... ;-)

johannes