Outdated and buggy USB Wifi adapter firmware

[leezu]

Hi,

please update the firmware files for USB Wifi adapters, such as mt7921u. Upstream provides updated and fixed versions at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/mediatek The files included in the RPi distro are more than 1 year old and can cause hangs with newer USB Wifi cards.

For example, for the mt7921u (mt7921au chipset) enabled in raspberrypi/linux#5117 , please include the updated BT_RAM_CODE_MT7961_1_2_hdr.bin cyfmac43455-sdio-minimal.bin WIFI_MT7961_patch_mcu_1_2_hdr.bin WIFI_RAM_CODE_MT7961_1.bin from above linux-firmware.git (Via https://github.com/morrownr/USB-WiFi/blob/main/home/How_to_Install_Firmware_for_Mediatek_based_USB_WiFi_adapters.md)

Thank you

[pelwell]

For situations like this where the requestor knows exactly what they want, Pull Requests are the preferred workflow.

[leezu]

Thank you for your prompt response. I'll prepare a pull request shortly.

[XECDesign]

I'm not sure I'm entirely on board with bumping files for third party hardware like this, even with a PR. The package is for taking whatever Debian ships and improving support for our hardware.

linux-firmware has fairly frequent releases and a huge amount of files and I don't think I'm ready to commit to supporting all of that.

[pelwell]

Fair point. The required kernel config change to enable the driver is only for 5.18 and 5.19, and we'll be shipping 5.15 until the next LTS (5.20 or 5.21) is out and thoroughly tested - probably Q1 or Q2 2023. By then the Debian firmware should have been updated.

[leezu]

If so, should there be a separate rpi firmware-nonfree version in testing? Debian upstream has newer firmware versions in the testing repo, but rpi only provides patched version for stable (currently "1:20210315-3+rpt7" compared to 20210818-1 upstream in testing).

[XECDesign]

Fair point. The required kernel config change to enable the driver is only for 5.18 and 5.19, and we'll be shipping 5.15 until the next LTS (5.20 or 5.21) is out and thoroughly tested - probably Q1 or Q2 2023. By then the Debian firmware should have been updated.

Yeah, bookworm should be frozen and around the corner by then.

f so, should there be a separate rpi firmware-nonfree version in testing? Debian upstream has newer firmware versions in the testing repo, but rpi only provides patched version for stable (currently "1:20210315-3+rpt7" compared to 20210818-1 upstream in testing).

We currently only support stable and oldstable. Sometimes we pull things from stable-backports, but I didn't see firmware-nofree there yet.

I am not entirely against the idea of us adopting support of upstream firmware-nonfree. Good firmware support can make a huge different to the user experience and we're past the days of having to build our own drivers and downloading firmware from random sources. But, I think an internal discussion would need to be had first.

[leezu]

Sure, it's a valid discussion and the reason why I first opened this issue instead of a pull request. I suggest to select a few firmware vendors that you expect RPi users to use (such as USB Wifi cards) and update them in RPi-Distro firmware-nonfree on a set schedule (perhaps until Upstream Debian improves). Please let me know the outcome of your internal discussion.

[XECDesign]

So, the plan is to get an image release out and then take a look at updating firmware-nonfree to latest upstream and see how it goes. If it causes regressions, we'll fix them and then leave the package as is. If it all goes smoothly, we'll consider updating it on a more regular schedule.

[XECDesign]

Okay, just had a look at what this would actually involve and it's not happening. There have been over a thousand files added or removed and these changes need to be reflected in the 'defines' files for Debian's packaging to work. I am not seeing a script which helps do this automatically.

Had a look at how Ubuntu handles it and it seems like their approach is entirely different from Debian's

So I think the best I can do for now is backport 20210818-1, but I'm not sure this solves OP's problem.