[PATCH] wifi: mt76: mt7921: refactor regd update to fix recursive mutex deadlock

[Mikhail Gavrilov]

I hit this deadlock on an MT7922 (mt7921e) and arrived at the same split
independently before finding this commit in linux-next.

Without it, associating with a 6 GHz AP self-deadlocks: mt76_sta_state()
holds &dev->mt76.mutex and mt7921_regd_set_6ghz_power_type() takes it
again via mt7921_mcu_regd_update(), on both the sta_add and the
sta_remove path. wpa_supplicant then blocks while holding wiphy.mtx,
NetworkManager blocks on wiphy.mtx while holding rtnl, and the machine
is left with no working network stack and needs sysrq to reboot. Because
NetworkManager retries the saved profile on every boot, an affected
kernel stops reaching a usable state at all once a 6 GHz profile exists.

With this commit applied to mainline at 3eb40771c00a (post-v7.2-rc7), on
a lockdep and UBSAN build: association with a 6 GHz AP completes
(channel 37, 6135 MHz, 160 MHz), switching back and forth between a
5 GHz and a 6 GHz BSS exercises both call sites, "iw reg set NL" reaches
the regulatory notifier and visibly takes effect - the link moves off
6 GHz - and "iw reg set RU" restores it, and an 88 s deep suspend/resume
cycle reconnects to the 6 GHz BSS. dmesg is clean throughout.

One request while this is fresh: the regression this fixes was
introduced in v7.2-rc1 by e88098133ed4, so it ought to be fixed within
7.2 rather than carried into 7.3. This commit is only in wireless-next
and has no Cc: stable. Could it go in through the fixes tree before the
7.2 release, or failing that into 7.2.y as soon as it opens?

Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov at gmail.com>