MT7927 WiFi + Bluetooth on Linux

The MediaTek MT7927 is the WiFi 7 card shipping on a lot of current AMD boards, and as of mid-2026 Linux support is in that awkward in-between state: the drivers are upstream, but one firmware file isn’t. Here’s what works, what’s missing, and the one manual step.

The short version

WiFi works out of the box if your kernel has the MT7927 series: mainline 7.2+, or a distro kernel that backports it (CachyOS’s 7.1.3 does, which is what I tested). The mt7925e driver handles the MT7927. Nothing to install.
Bluetooth hardware and driver are fine, but the firmware is missing. btusb logs Failed to load firmware file (-2) and Bluetooth stays dead. BT_RAM_CODE_MT6639_2_1_hdr.bin hasn’t merged into linux-firmware yet (it’s sitting in a draft merge request pending MediaTek’s redistribution sign-off). Fetch it from the MR’s source branch, verify the hash, drop it in /usr/lib/firmware/mediatek/mt7927/, reboot.

The hardware

The MT7927 is the 320MHz-channel WiFi 7 variant of MediaTek’s MT7925 family; internally the chip is an MT6639, which explains the firmware file names. It’s a single M.2 module exposing two functions: WiFi as a PCIe device (14c3:7927) and Bluetooth as a USB device (0489:e13a).

Tested configuration: Foxconn-built module (subsystem 105b:e124) onboard an X870E board, CachyOS, kernel 7.1.3, linux-firmware 20260622.

WiFi: nothing to do (with the right kernel)

MT7927 support in mt7925e landed in wireless-next on June 9, 2026 and ships in mainline kernel 7.2, at rc stage as I write this. If you’re on 7.1 or earlier, you need a distro kernel that backports the series; CachyOS’s 7.1.3 kernel does, and that’s the tested configuration here.

With the driver in place, the PCIe function just probes. A successful bring-up looks like this in journalctl -b -k:

mt7925e 0000:0a:00.0: enabling device (0000 -> 0002)
mt7925e 0000:0a:00.0: disabling ASPM  L1
mt7925e 0000:0a:00.0: ASIC revision: 0000
mt7925e 0000:0a:00.0: MT7927 raw CHIPID=0x0000, forcing chip=0x7927
mt7925e 0000:0a:00.0: HW/SW Version: 0x8a108a10, Build Time: 20250606200911a
mt7925e 0000:0a:00.0: WM Firmware Version: ____000000, Build Time: 20250606201037

Two details worth knowing. The forcing chip=0x7927 line is the driver recognizing the chip despite it reporting a zero CHIPID: expected, not a fault. And disabling ASPM L1 is deliberate: the MT7927 support series has the driver opt out of PCIe power saving at probe time, so you don’t need any pcie_aspm boot parameters or quirks yourself.

On a kernel without the series the failure mode is quiet: the device enumerates in lspci, but mt7925e never binds and you get no wlan interface. If lspci -nnk -s <slot> shows the device with no Kernel driver in use line, your kernel predates MT7927 support. The WiFi firmware (WIFI_MT6639_*) is already in linux-firmware; the kernel is the only variable.

Bluetooth: one missing file

The kernel side is ahead of the WiFi here: btusb/btmtk support for the MT7927’s BT function is in mainline since kernel 7.1 (June 2026). What’s missing is the firmware blob. As of linux-firmware 20260622, /usr/lib/firmware/mediatek/mt7927/ ships the WiFi files but not BT_RAM_CODE_MT6639_2_1_hdr.bin, so the load fails at every Bluetooth power-on. My journal had over a hundred of these per boot:

Bluetooth: hci0: Failed to load firmware file (-2)

The blob exists. It’s in linux-firmware merge request !946, stuck in draft while MediaTek’s redistribution sign-off is pending. I’m not rehosting the file here. The commands below fetch it from the MR’s own source branch, pinned to the exact commit I tested, verified by hash.

First, check whether your linux-firmware already ships it (if this post has aged well, it does, and you’re done):

ls /usr/lib/firmware/mediatek/mt7927/ | grep BT

If not, fetch from the MR source branch and verify:

curl -LO https://gitlab.com/jetm/linux-firmware/-/raw/77ad2a92acf2ac3e5ea47432b43d925ff99db909/mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin
sha256sum BT_RAM_CODE_MT6639_2_1_hdr.bin

Expected hash:

669c5c99a0c59c85c1285d3d1b8b31915c2d31341a2244f4eddcbfd60ffbbc76

If it doesn’t match, stop. Don’t install it. The URL is pinned to a commit, so the content should never drift; a mismatch means something is genuinely wrong on the wire or the host. If it matches, install and reboot:

sudo install -Dm644 BT_RAM_CODE_MT6639_2_1_hdr.bin \
  /usr/lib/firmware/mediatek/mt7927/BT_RAM_CODE_MT6639_2_1_hdr.bin

After reboot, bluetoothctl show should report the controller up:

Controller XX:XX:XX:XX:XX:XX (public)
	Powered: yes
	PowerState: on

One packaging note: the file is unowned by your package manager, so linux-firmware updates won’t touch it.

Troubleshooting: the 60-second boot hang

There’s a failure mode I hit with this module that’s worth knowing about, because I lost a weekend to it.

If the BT function’s onboard firmware state gets wedged (mine got there after repeated failed firmware loads), the USB function stops enumerating entirely. The symptom is a kernel-phase boot stall of about 60 seconds while the XHCI controller retries the dead port, with error -110 (timeout) USB messages in the journal. Bluetooth vanishes from rfkill and lsusb completely, which makes it easy to misdiagnose as a dead module.

The fix is a full cold power drain: shut down, flip the PSU switch off (or pull the plug), wait 60 seconds, power back up. A warm reboot did not clear it; the best explanation I have is that the module keeps standby power across reboots, so the wedged state survives anything short of a real power cut. After the drain, the BT function enumerated instantly and boot time returned to normal (a 66-second kernel phase dropped to under 6). One machine’s evidence, but the symptom is distinctive enough that if you’re seeing it, the drain costs you two minutes to try.

Shelf life

This post is accurate as of July 2026. The moment MR !946 merges and your distro ships that linux-firmware release, the entire Bluetooth section reduces to “update your packages.” The WiFi section and the boot-hang fix should stay useful for the life of the hardware.