Re: [REGRESSION] mt7925: MLO connectivity silently stalls with 6GHz link active

On 15/08/2026 07:51, Thorsten Leemhuis wrote:
> CCing Devin, who wrote two of the following messages

Those are the mt7921 regd deadlock. mt7925 does not have it, there is no
equivalent of the mt7921_mac_sta_add() call site that creates it.

Worth ruling in or out before you bisect. mt7925 sets
IEEE80211_MLD_CAP_OP_MAX_SIMUL_LINKS to 0 in mt7925/main.c. It is an N-1
field, mt7996 sets MT7996_MAX_RADIOS - 1, so 0 means one simultaneous link,
and mt7925/mcu.c then requests MT7925_ROC_REQ_MLSR_AG or _AA. MLSR is
multi-link single radio: your two links share one radio, and ROC is what
moves it between them.

If 5 GHz is your deflink, your pair is named on that path in
mt7925_mac_set_links():

	if (band == NL80211_BAND_2GHZ ||
	    (band == NL80211_BAND_5GHZ && secondary_band == NL80211_BAND_6GHZ)) {
		mt7925_abort_roc(...);
		mt7925_set_mlo_roc(...);
	}

That one only runs at association. The path that can run mid-session is
mt7925_change_vif_links(), which calls mt7925_set_mlo_roc() for each added
link. Both reach mt7925_mcu_set_mlo_roc(), and all of this is the same in
7.1 and 7.2-rc7.

Under your existing watchdog:

	cd /sys/kernel/debug/tracing
	echo 'r:mloroc mt7925_mcu_set_mlo_roc ret=$retval:s32' > kprobe_events
	echo 'r:rocabort mt7925_mcu_abort_roc ret=$retval:s32' >> kprobe_events
	echo 'p:rocwork mt7925_roc_work' >> kprobe_events
	echo 1 > events/kprobes/enable

Association will fire mloroc once, so anything later is a mid-session
switch. If the WFDMA0 tail freezes while one of those is in flight, it is a
link switch that did not finish. If they are silent across a stall, the
whole path is ruled out and that is worth as much.

On the bisect itself: your 6.18 good point is second-hand, from different
hardware and a different AP. Worth confirming on your own box before
spending steps against it.

Devin