mt76 patch: RX bitrate reporting for MT7921/MT7922/MT7925, looking for testers

[Lucid-Duck]

Hey Nick and crew,

I've got a small mt76 patch I'd like community eyes on before I send it to linux-wireless.

Quick background: if you run iw dev wlan0 station dump on any MediaTek MT7921, MT7922, or MT7925 adapter, you get a tx bitrate: line but no rx bitrate: line. Never populated. The mt7921 driver landed in the kernel in early 2021 and mt7925 in late 2023, and this field has been missing on both of them the whole time. There's a function prototype sitting in each driver's header file (mt7921_mcu_get_rx_rate / mt7925_mcu_get_rx_rate) that never had a body written for it. The mt7915 sibling does populate the field, but it uses an MCU query that turns out to return an error on mt792x firmware, so the mt7915 approach can't just be ported over.

The patch takes a different angle: the rate info from each RX frame is already being decoded by the driver for radiotap / monitor mode, so it just caches the last-seen rate per station and returns it from sta_statistics. No new MCU calls, no firmware changes, minimal overhead on the RX path. Nothing about throughput, nothing about power, nothing flashy, just a field that should have been there all along.

Patch, README, and step-by-step test instructions are here:
https://github.com/Lucid-Duck/mt76-rxrate

I've tested it on my Alfa AWUS036AXML (MT7921AU USB) across all three bands, 2.4 GHz channel 1, 5 GHz channel 100 DFS, and 6 GHz channel 5, against a tri-band Wi-Fi 6 AP. Peak rx bitrate tracks correctly: 286.7 Mbit/s HE-MCS 11 NSS 2 on 2.4 GHz (20 MHz), 1200.9 Mbit/s on the 5 and 6 GHz 80 MHz channels. Legacy basic rates (1.0 Mbit/s CCK at 2.4, 6.0 Mbit/s OFDM at 5/6) show up correctly at idle when only beacons are arriving. Ran a 60-second iperf3 downlink at ~715 Mbit/s with 300 rapid station-dump samples to confirm the cache keeps up with frame-by-frame rate adaptation; it caught five distinct rate values in that window including real-time HE-MCS 9/10/11 transitions.

What I'd love is testing on hardware I don't have:

• MT7921 PCIe cards (Framework, ThinkPad, HP ProBook, whatever laptop has them embedded)
• MT7922 on any bus
• MT7925 on any bus (the Wi-Fi 7 sibling)
• Weirder SKUs at non-standard VID:PIDs
• Any setup where rate control is actually backing off. I can't hit the HT or VHT paths with this AP because it always negotiates HE.

Test instructions are in TESTING.md on the repo. About 15 minutes of work, no reboot, fully reversible with rmmod + modprobe. Fedora, Debian/Ubuntu, and Arch steps are all in there.

Once there are a couple of independent confirmations I'll send the patch to linux-wireless with Tested-by: tags for whoever reports in. Thanks in advance if anyone has the time and the hardware.

Lucid-Duck

[satmandu]

Building this now as part of my mt76 patchset for mt7925u on top of 7.0-rc7...

[satmandu]

On mt7925u:

    |__ Port 002: Dev 002, If 0, Class=Vendor Specific Class, Driver=mt7925u, 5000M
        ID 0846:9072 NetGear, Inc. 

for i in wlx289401c26b65
do 
  iw dev $i info
  iw dev $i link
  iw dev $i station dump
done > iw.station.dump.output-after.txt

Interface wlx289401c26b65
	ifindex 2
	wdev 0x1
	addr 28:94:01:c2:6b:65
	ssid SI_IoT
	type managed
	wiphy 0
	channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
	txpower 23.00 dBm
	multicast TXQ:
		qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
		0	0	0	0	0	0	0	0		0
Connected to a2:05:d6:42:fd:93 (on wlx289401c26b65)
	SSID: SI_IoT
	freq: 5180.0
	RX: 1864639 bytes (4147 packets)
	TX: 677267 bytes (2796 packets)
	signal: -35 dBm
	rx bitrate: 1296.7 MBit/s 80MHz EHT-MCS 12 EHT-NSS 2 EHT-GI 0
	tx bitrate: 1200.9 MBit/s 80MHz EHT-MCS 11 EHT-NSS 2 EHT-GI 0
	bss flags: short-slot-time
	dtim period: 3
	beacon int: 100
Station a2:05:d6:42:fd:93 (on wlx289401c26b65)
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	inactive time:	607 ms
	rx bytes:	1864639
	rx packets:	4147
	tx bytes:	677267
	tx packets:	2796
	tx retries:	0
	tx failed:	0
	beacon loss:	0
	rx drop misc:	1
	signal:  	-35 [-37, -38] dBm
	signal avg:	-36 [-38, -39] dBm
	tx bitrate:	1200.9 MBit/s 80MHz EHT-MCS 11 EHT-NSS 2 EHT-GI 0
	tx duration:	555788 us
	rx bitrate:	1296.7 MBit/s 80MHz EHT-MCS 12 EHT-NSS 2 EHT-GI 0
	rx duration:	706578 us
	last ack signal:-37 dBm
	avg ack signal:	-37 dBm
	airtime weight: 256
	DTIM period:	3
	beacon interval:100
	short slot time:yes
	connected time:	205 seconds
	associated at [boottime]:	23.404s
	associated at:	1775438058492 ms
	current time:	1775438263863 ms

[Lucid-Duck]

@satmandu Thanks for testing!

EHT-MCS 12 NSS 2 at 1296.7 Mbit/s is a great data point since I can only hit HE on my MT7921AU.

I've updated the patch to add the RX_ENC_EHT case in mt792x_mac_update_rx_rate() (was missing from the original -- your test exposed it). The repo is updated with your results and the corrected patch file.

Still looking for MT7921 PCIe and MT7922 confirmations if anyone has the hardware and 15 minutes.

[satmandu]

@Lucid-Duck That new patch gives me an error when applying:

~/src/linux-7.0-rc7$ patch --dry-run -Np1 -i ~/mt7925/0001-wifi-mt76-mt792x-report-last-RX-rate-in-station-stat.patch 
checking file drivers/net/wireless/mediatek/mt76/mt7921/mac.c
checking file drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h
checking file drivers/net/wireless/mediatek/mt76/mt7925/mac.c
checking file drivers/net/wireless/mediatek/mt76/mt7925/mt7925.h
checking file drivers/net/wireless/mediatek/mt76/mt792x.h
checking file drivers/net/wireless/mediatek/mt76/mt792x_core.c
Hunk #1 succeeded at 639 (offset 41 lines).
checking file drivers/net/wireless/mediatek/mt76/mt792x_mac.c
patch: **** malformed patch at line 243:        struct mt792x_dev *dev;

[Lucid-Duck]

@satmandu Sorry about that -- off-by-one in the patch hunk header when I added the EHT case. Fixed now, should apply cleanly. Let me know if you hit anything else.

[satmandu]

There are so many mt76 patches queued up for 7.1: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/log/?qt=grep&q=mt76

[morrownr]

@satmandu

There are so many mt76 patches queued up for 7.1

I've been keeping an eye on this as well. There is also the issue of the amount of patches going in for the wifi stack and the new firmware files that have gone in recently. I think it might be a good idea to shift into a lower gear for now and see where we are in about 3 weeks when 7.1 rc1 is available. That is, continue work and testing but with an eye toward testing with 7.1 rc1 before sending anything else upstream in at this point.

@Lucid-Duck

I have a M.2 mt7921 based card and a PCIe mt7922 based card but they are in systems that are currently used for other things. I'll need to ponder this and come up with a plan. My testing is usually 100% USB adapters and that is what I am currently set up for but that can be fixed.

There is another thing to consider: There is a new driver going into 7.1 for the mt7902 chip. You can see the 11 patches in the queue. I have not looked at the driver code but I suspect it is being added to the core mt7921 code. There is also another new driver that is in work but not queued yet, mt7927, which I think is being added to the mt7925 core code. For what it is worth, my newest system, which is a Mini PC actually has a M.2 card with the mt7902 chip so I guess I need to get smart on the details so that we know something about it.

To let both of you know, I need to reduce my time here for about 3 weeks as I have other things that I need to take care of but I hope to be 100% before May and I'm looking forward to crushing many bugs and adding a lot of capability over the rest of this year.

[satmandu]

@Lucid-Duck FYI here's what shows up with your latest patch:

for i in wlx289401c26b65
do 
  iw dev $i info
  iw dev $i link
  iw dev $i station dump
done > iw.station.dump.output-after.txt

Interface wlx289401c26b65
	ifindex 2
	wdev 0x1
	addr 28:94:01:c2:6b:65
	ssid SI_IoT
	type managed
	wiphy 0
	channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
	txpower 23.00 dBm
	multicast TXQ:
		qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
		0	0	0	0	0	0	0	0		0
Connected to a2:05:d6:42:fd:93 (on wlx289401c26b65)
	SSID: SI_IoT
	freq: 5180.0
	RX: 3902721 bytes (5173 packets)
	TX: 743177 bytes (3705 packets)
	signal: -36 dBm
	rx bitrate: 1296.7 MBit/s 80MHz EHT-MCS 12 EHT-NSS 2 EHT-GI 0
	tx bitrate: 1200.9 MBit/s 80MHz EHT-MCS 11 EHT-NSS 2 EHT-GI 0
	bss flags: short-slot-time
	dtim period: 3
	beacon int: 100
Station a2:05:d6:42:fd:93 (on wlx289401c26b65)
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	inactive time:	4 ms
	rx bytes:	3902721
	rx packets:	5173
	tx bytes:	743177
	tx packets:	3705
	tx retries:	0
	tx failed:	0
	beacon loss:	0
	rx drop misc:	0
	signal:  	-36 [-38, -39] dBm
	signal avg:	-33 [-35, -39] dBm
	tx bitrate:	1200.9 MBit/s 80MHz EHT-MCS 11 EHT-NSS 2 EHT-GI 0
	tx duration:	436994 us
	rx bitrate:	1296.7 MBit/s 80MHz EHT-MCS 12 EHT-NSS 2 EHT-GI 0
	rx duration:	610293 us
	last ack signal:-31 dBm
	avg ack signal:	-31 dBm
	airtime weight: 256
	DTIM period:	3
	beacon interval:100
	short slot time:yes
	connected time:	127 seconds
	associated at [boottime]:	22.888s
	associated at:	1775575644962 ms
	current time:	1775575771482 ms

[Lucid-Duck]

Hey @satmandu, quick heads up that morrownr and I have been building out a community mt76 repo so we have a cleaner place for testers to try patches against. Both the build infrastructure and the firmware tree landed yesterday:

https://github.com/morrownr/mt76

The idea is one-command install, one-command diagnostic, one-command uninstall:

git clone https://github.com/morrownr/mt76.git
cd mt76
sudo sh install-driver.sh

That will blacklist the in-kernel modules, build the out-of-tree _git variants, and copy the bundled firmware blobs into /lib/firmware/mediatek/ so you are always testing against the revision staged in the repo rather than whatever your distro's linux-firmware happens to ship. A full firmware refresh for mt7921, mt7922, mt7902, mt7925, and the mt76x2 family was pushed last night.

Since you have been the most reliable MT7925U tester by a mile, would you be willing to take it for a spin? What would help most:

1. Clone, sudo sh install-driver.sh, reboot.
2. Confirm the adapter comes back up and associates.
3. Run ./check-driver.sh 2>&1 | tee mt76-diag.txt and drop the output here so we can see loaded _git modules vs in-kernel leakage, firmware presence, and dmesg state in one go.
4. If you want to stress it, the usual iperf3 run over 5 GHz is plenty.

No rush on any of this. If you hit anything weird, open it as a separate issue on morrownr/mt76 and I will chase it down.

Thanks as always for the MT7925U testing last weekend. Your EHT-MCS 12 output is what flagged the missing RX_ENC_EHT path in the first cut of the patch, and the follow-up fix is in now.

[satmandu]

Looks like sudo sh install-driver.sh is throwing an error, aside from the ANSI codes not working properly:

sudo sh install-driver.sh
\033[1m\033[1;33mPlease copy and post all displayed lines when reporting an issue!\033[0m
Press Enter to continue...

\033[1m  ================================================================
     mt76 WiFi Driver Installer
  ================================================================\033[0m
  install-driver.sh v20260408
  Source:  \033[0;36m376b680e\033[0m
  Distro:  Ubuntu Resolute Raccoon (development branch)
  Kernel:  7.0.0-rc7-mt7925utest (x86_64)
  Params:   ro, mitigations=off, i915.mitigations=off, acpi_mask_gpe=0x17, rcuupdate.rcu_cpu_stall_suppress=1, zswap.enabled=1, zswap.zpool=zsmalloc, log_buf_len=1M, nouveau.config=NvPmEnableGating=3, zfs.zil.replay_disable=1, zfs.zfs_recover=1, cfi=off, nouveau.atomic=1, i915.force_probe=!0d26
  CPUs:    8/8 (in-use/total)
  Memory:  16279904 kB
  gcc:     gcc (Ubuntu 15.2.0-16ubuntu1) 15.2.0
  dkms:    dkms-3.2.2
  SecBoot: not supported
  Reg:     country US: DFS-FCC

  \033[1mDetected mt76 hardware:\033[0m
    \033[2m(none detected -- modules will still be installed)\033[0m
  \033[1m----------------------------------------------------------------\033[0m

\033[1m\033[0;36m[1/7]\033[0m \033[1mChecking prerequisites\033[0m
\033[0;32m  All prerequisites found.\033[0m
\033[0;32m  Kernel headers present.\033[0m

\033[1m\033[0;36m[2/7]\033[0m \033[1mRemoving previous installation (if any)\033[0m
\033[0;32m  Clean.\033[0m

\033[1m\033[0;36m[3/7]\033[0m \033[1mConfiguring\033[0m
  Installing mt76_git.conf to /etc/modprobe.d
\033[0;32m  Done.\033[0m

\033[1m\033[0;36m[4/7]\033[0m \033[1mInstalling firmware\033[0m
\033[0;32m  Installed 16 firmware file(s) to /lib/firmware/mediatek\033[0m

\033[1m\033[0;36m[5/7]\033[0m \033[1mBuilding modules\033[0m
  \033[2m(dkms build)\033[0m
  Copying source to /usr/src/mt76-1.0
Creating symlink /var/lib/dkms/mt76/1.0/source -> /usr/src/mt76-1.0
\033[0;32m  Added to dkms.\033[0m
Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv
Public certificate (MOK): /var/lib/shim-signed/mok/MOK.der

Building module(s)..................(bad exit status: 2)
Failed command:
KVER=7.0.0-rc7-mt7925utest 'make' modules
ERROR (dkms apport): binary package for mt76: 1.0 not found

Error! Bad return status for module build on kernel: 7.0.0-rc7-mt7925utest (x86_64)
Consult /var/lib/dkms/mt76/1.0/build/make.log for more information.
Command exited with non-zero status 10
  Compile time: 306.97 seconds
\033[0;31mAn error occurred: 10\033[0m
Please report this error.
Please copy and post the following items into the problem report.
    -all screen output from install-driver.sh
You should run the following before reattempting installation.
$ sudo ./uninstall-driver.sh

[satmandu]

Also:

tail -n 25  /var/lib/dkms/mt76/1.0/build/make.log
  CC [M]  mt76x2/usb_mac.o
  LD [M]  mt7921/mt7921s_git.o
  CC [M]  mt76x2/usb_mcu.o
  LD [M]  mt7921/mt7921u_git.o
  CC [M]  mt76x2/usb_phy.o
  LD [M]  mt7925/mt7925u_git.o
  CC [M]  mt76x2/pci.o
  CC [M]  mt76x2/pci_main.o
  LD [M]  mt7996/mt7996e_git.o
  CC [M]  mt76x2/pci_init.o
  CC [M]  mt76x2/pci_mcu.o
  CC [M]  mt76x2/pci_phy.o
  LD [M]  mt76x2/mt76x2_common_git.o
  LD [M]  mt76x2/mt76x2u_git.o
  LD [M]  mt76x2/mt76x2e_git.o
make[3]: *** [/usr/src/linux-headers-7.0.0-rc7-mt7925utest/Makefile:2105: .] Error 2
make[2]: *** [/usr/src/linux-headers-7.0.0-rc7-mt7925utest/Makefile:248: __sub-make] Error 2
make[2]: Leaving directory '/var/lib/dkms/mt76/1.0/build'
make[1]: *** [Makefile:248: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-7.0.0-rc7-mt7925utest'
make: *** [Makefile:112: modules] Error 2

# exit code: 2
# elapsed time: 00:00:47
----------------------------------------------------------------

[satmandu]

This works for colors for me:

https://github.com/lavabit/magma/blob/develop/dev/scripts/test/t.colors.sh

[Lucid-Duck]

@satmandu thanks for the report -- both fixed and pushed.

The build error was a transitive-include thing -- mt7615/debugfs.c calls mac_pton() and used to pick up the declaration through <linux/kernel.h>, but upstream 24c776355f40 dropped that path in December and updated mainline mt7615.h to include <linux/hex.h> directly. This fork missed the sync. Added the same one-line include in 96f18123. Clean rebuild against vanilla 7.0-rc7, all 25 modules.

The ANSI thing: color vars were defined as GREEN='\033[0;32m' but printed via printf '%s', and printf only interprets backslash escapes in the format string or %b args, never %s. So the literal sequence was hitting the terminal. Swapped the definitions to GREEN=$(printf '\033[0;32m') so they hold real ESC bytes and every existing %s keeps working. 67d3172d, all four scripts.

Pull and retry:

cd mt76 && git pull
sudo sh uninstall-driver.sh
sudo sh install-driver.sh