Another one off the list: the 2.4 / 5 / 6 GHz front LEDs now each light and blink on their own band's traffic.
Previously only the 2.4 GHz LED worked — the 5/6 GHz LEDs stayed dark (a known long-standing thing on BE14 cards). Under the single-wiphy MLO model the secondary bands never got their LED classdev registered, and a WARN_ON() fired at probe.
Fixed with two small generic mt76 driver patches (not board-specific — any MT7996/BE14 benefits):
wifi: mt76: share the throughput LED trigger across bands
wifi: mt76: mt7996: register a LED classdev for every band
Verified on BPI-R4 with single-band and active MLO clients. Already shipping as part of my BPI-R4 deploy system — both the standard and Pro 8X (X8) builds: https://github.com/woziwrt/bpi-r4-deploy/releases
Yes — genuinely per-band, not one LED mirroring all. All three band LEDs register as separate classdevs (mt76-phy0 / mt76-phy0_1 / mt76-phy0_2), and each blinks on its own band's traffic.
Single-wiphy MLO was exactly the catch: all bands share one ieee80211_hw, so two things broke it —
the throughput LED trigger is one-per-ieee80211_hw, so ieee80211_create_tpt_led_trigger() warned and handed the secondary bands a NULL trigger;
mt7996 assigned the LED brightness_set/blink_set callbacks only to the primary (2.4 GHz) PHY, so mt76_led_init() bailed for 5/6 GHz and never registered their classdevs.
The two patches fix both: every band registers its own classdev and they share the one trigger.
The HW path was already per-band — mt7996_led_set_config() indexes MT_LED_EN()/MT_LED_CTRL() by mphy->band_idx, with MT_LED_CTRL_BLINK_BAND_SEL for band1 — so per-band hardware blink works the moment the classdev exists.
Tested on BE14 with single-band clients (traffic on one band lights only that band's LED) and an MLO client (the bands it's actually using blink).