We have profiled Broadcom — the hostile vendor. We have profiled Realtek — the indifferent vendor. Today we profile a vendor that does not fit either category.

MediaTek.

MediaTek is a Taiwanese semiconductor company that was spun off from United Microelectronics Corporation in 1997, originally designing chipsets for optical drives. They make WiFi chips, smartphone processors, router silicon, smart TV SoCs, and anything else that needs a cheap, integrated solution. They power more than 2 billion devices a year. One in every three mobile phones on Earth has a MediaTek chip.

MediaTek is neither hostile nor indifferent. MediaTek is chaotic. They employ kernel developers. They contribute drivers upstream. They support mac80211. They do things correctly — and the drivers still break after kernel updates. They are the vendor that tries and still leaves you without WiFi on a Tuesday morning.

I respect the effort. I question the execution.

The Shanzhai Revolution:

Before we discuss drivers, you must understand how MediaTek became the fifth largest fabless semiconductor company in the world. The answer is not innovation. The answer is democratization of manufacturing.

In 2004, MediaTek entered the mobile phone market. In 2005, they developed something unprecedented: a turnkey solution — a single chip that integrated the baseband processor, the application processor, the Bluetooth radio, and the software stack. Everything a phone manufacturer needed, on one chip, with reference designs included.

You did not need to be Samsung or Nokia to build a phone. You needed a MediaTek chip, a screen, a battery, a plastic case, and a factory in Shenzhen. The chip cost $15 to $30. The phone could be assembled in days.

This enabled the shanzhai (山寨) revolution — “bandit phones,” “white-box phones,” unlicensed clones and original designs pouring out of thousands of tiny factories in southern China. By 2006, shanzhai manufacturers held 30% of China’s domestic phone market. Ninety percent of all shanzhai phones used MediaTek chips.

Year	Event
1997	MediaTek spun off from UMC
2004	Enters mobile phone chipset market
2005	Launches turnkey phone-on-a-chip solution
2006	Shanzhai phones hit 30% of China domestic market
2011	First MediaTek smartphone chip ships (Lenovo)
2012	45% market share in China smartphones
2020	Overtakes Qualcomm as world’s largest smartphone chipset vendor

MediaTek shipped 351.8 million smartphone chipsets in 2020, surpassing Qualcomm for the first time. The company that armed the bandit phone factories of Shenzhen became the largest mobile chipset vendor on Earth.

This is relevant to our driver discussion because MediaTek’s culture is built on volume. They do not make the best chip. They make the chip that goes into the most devices. And when your chip is in a billion routers, a billion phones, and a hundred million laptops, you eventually have to deal with Linux.

The Driver Approach: Actually Trying

Here is where MediaTek diverges from Broadcom and Realtek.

MediaTek employs kernel developers. Real ones. Lorenzo Bianconi and Sean Wang from MediaTek contribute directly to the Linux kernel wireless tree. They write mac80211-compliant drivers. They submit patches through the proper channels. They respond to review feedback.

The mt76 driver — covering the MT76x0, MT76x2, MT7603, MT7615, MT7628, MT7688, MT7915, MT7921, MT7922, MT7925, MT7996, and more — lives in the mainline Linux kernel at drivers/net/wireless/mediatek/mt76/. It is not an out-of-tree dump. It is not a Windows driver with a shim. It is a proper Linux wireless driver maintained by MediaTek employees.

The mt76 driver also lives on GitHub under the OpenWrt organization, maintained by Felix Fietkau — a key figure in the OpenWrt router firmware project. MediaTek chips power a significant portion of the world’s WiFi routers, and OpenWrt support is critical for that market.

Compare this to the other vendors:

Vendor	Kernel Developers	Upstream Contribution	Uses mac80211
Intel	Yes	Yes (dual-licensed)	Yes
MediaTek	Yes	Yes (GPL)	Yes
Qualcomm/Atheros	Yes	Yes (ath9k, ath11k)	Yes
Broadcom	No	Partial, reluctant	Partial
Realtek	No	SDK dumps, abandoned	No (out-of-tree)

MediaTek is in the “doing it right” column. They have paid engineers submitting proper patches to the Linux kernel wireless subsystem. This is more than Broadcom has ever done. This is infinitely more than Realtek has ever done.

And yet.

The Reality: It Still Breaks

The MT7921 is MediaTek’s WiFi 6 chip, found in millions of laptops since 2021. It has an in-kernel driver. It uses mac80211. MediaTek employees maintain it. The firmware is available in standard distribution repositories.

The bug reports tell a different story:

• “driver own failed” — a common probe failure that bricks WiFi on boot
• Firmware loading failures after kernel updates — the chip stops working, no error message, just silence
• WiFi disappearing after random updates, forcing users onto Ethernet or USB adapters
• CPU-intensive processes and kernel panics during shutdown related to the mt7921e driver
• Kernel 6.14 regression — Linux kernel 6.19 had to revert code to fix MT792x WiFi issues

The driver exists. The driver is maintained. The driver is in the kernel. The driver still breaks.

This is the difference between having a driver and having a stable driver. MediaTek submits code. The code gets merged. Then a kernel update changes something, and millions of laptops lose WiFi until someone submits a fix and it propagates through distribution updates.

On Fedora 42 with kernel 6.14, users reported MT7921 and MT7922 firmware failing to load entirely. The chip was present. The driver was present. The firmware was not loaded. No WiFi. The fix required manual intervention that most users cannot perform.

The Router Side:

MediaTek’s WiFi reputation is better in the router world than the laptop world. The MT7615, MT7915, and MT7996 chipsets power many consumer and enterprise routers running OpenWrt.

But even here, the MT7615 was described as “hit and miss” for speed and stability. The MT7628 was called “useless” by a forum user who could not get the mt76 driver working. The MT7615 lacks STA mode support (connecting to another AP as a client), unlike the MT7915.

The pattern is consistent: the hardware ships, the driver follows, and then years of bug fixes are required before it works reliably.

The FreeBSD Situation:

There is no working MediaTek WiFi driver for FreeBSD.

The mt76 driver exists in the FreeBSD source tree on the 14.x branch, brought over via the linuxkpi compatibility layer. It is present in the code. It does not compile. LinuxKPI VM changes are identified as a blocker. As of early 2026, it does not work.

And even when it does compile, the FullMAC state machine has a gift for you.

MediaTek’s chipset has a detach sequence: you tell the device to detach, it should reset itself so the next boot starts clean. But if the chipset is busy when you issue the detach command, it acknowledges the request — “Ok” — and does not reset. The firmware lies. The state machine says it is ready. It is not ready. It is still holding state from the previous session.

Cold boot? No problem. The chip powers on fresh. Warm reboot? No WiFi. The chip is in a ghost state — it believes it is still attached to the previous session, the driver believes it started clean, and neither is correct. The state machine lies to the driver, the driver lies to the kernel, and the kernel lies to you.

This bug will never appear in testing if you only cold boot. It will appear every single time in production, where warm reboots are the default.

The kernel’s solution? It tells you to unplug and replug the USB WiFi stick. If your USB stick is plugged into the machine in front of you, this is annoying. If your USB stick is plugged into a server behind a wall in another room, you have two options: walk there, or blow a fuse to power-cycle the building. I have seen engineers choose the fuse.

A FullMAC chip that lies about its own state is not a driver bug. It is an architecture defect. And it is the kind of defect that no amount of upstream kernel contribution will fix, because the bug is in the firmware, and the firmware is a black box.

MediaTek, despite being one of the more cooperative Linux vendors, provides nothing for BSD. Their cooperation extends exactly as far as the Linux kernel and no further. The border wall holds.

The Shanzhai Parallel:

There is a poetic symmetry to MediaTek’s driver situation.

MediaTek’s business model has always been: provide a turnkey solution that is good enough. Not the best. Good enough. The shanzhai phones were not iPhones. They were phones that worked, mostly, for $30. The MediaTek WiFi drivers are not Intel drivers. They are drivers that work, mostly, until a kernel update.

The turnkey approach that conquered the phone market is the same approach applied to drivers: ship fast, fix later, move on to the next chip. The MT7921 driver shipped with kernel 5.12. By kernel 6.14, it was still having firmware loading failures. The chip has been on the market for five years and the driver is not fully stable.

MediaTek ships 2 billion devices a year. They cannot spend years polishing each driver. They ship, they patch, they move to the next chip generation. The driver for the MT7996 (WiFi 7) entered the kernel in 6.2. The MT7925 in 6.7. The MT7992 in 6.8. The pace is relentless. The stability follows… eventually.

The Verdict:

MediaTek is not hostile. MediaTek is not indifferent. MediaTek is overwhelmed by their own output.

They do the right thing: hire kernel developers, contribute upstream, use mac80211, maintain the drivers in-tree. Then they release a new chip every six months and the kernel developers cannot keep up with the bug reports from the last chip before the next one arrives.

Vendor	Sin
Broadcom	Hostility
Realtek	Indifference
MediaTek	Velocity

Broadcom refuses to cooperate. Realtek refuses to participate. MediaTek cooperates at a speed that outpaces their own quality control.

The Lesson:

MediaTek armed a million factories in Shenzhen with turnkey chips and changed the phone industry. They contribute upstream to the Linux kernel with real engineers doing real work. They are, by every reasonable measure, trying to do the right thing.

And the driver still breaks after a kernel update.

The lesson is that good intentions are necessary but not sufficient. A driver in the kernel is better than a driver on GitHub. A driver maintained by the vendor is better than a driver maintained by one volunteer. But a driver that loses WiFi on kernel 6.14 is still a driver that loses WiFi on kernel 6.14, regardless of who maintains it.

The shanzhai revolution succeeded because “good enough” was enough. In the driver world, “good enough” means you lose WiFi on a Tuesday and spend an hour on a forum learning that you need to downgrade your kernel.

In the Republic of Derails, we do not upgrade kernels on Tuesdays. We do not upgrade kernels at all. The kernel we shipped in 2019 still works. The WiFi still connects. The MediaTek chip in our router has been running the same firmware for six years. This is not because we are wise. It is because we are afraid of what would happen if we updated.

— Kim Jong Rails, Supreme Leader of the Republic of Derails