Developers working on Apple Silicon support just dropped a new set of patches. They target NVMe storage access on the M4 chip. The work comes from Yureka Lilian. It builds directly on months of quiet progress inside the Asahi Linux project and related kernel efforts.
Storage sits at the heart of any usable system. Without reliable NVMe, even a booting kernel offers little value. These changes make that piece functional on Apple’s latest silicon. But don’t expect production laptops anytime soon. The path from patch to polished desktop remains long.
Targeted Changes Unlock M4 Storage Compatibility
Yureka Lilian sent the series to the Linux kernel mailing list this week. The patches add device tree bindings and driver support for the ANS2 NVMe controller on the Apple t8132, known as the M4 SoC. “This patch series adds dt-bindings and driver support for ANS2 NVMe on the Apple t8132 (M4) SoC,” Lilian wrote in the cover letter. (Phoronix)
This variant uses a separate MMIO base for its NVMMU. It also requires the IO queues to be registered using an additional MMIO write. Otherwise it is largely the same as the ANS2 NVMe variants present on Apple M1-M3 SoCs. The modifications touched fewer than 100 lines of code in the existing Apple NVMe driver. Small. Precise. Yet they clear a critical barrier.
But the story didn’t start here. Earlier this month Sven Peter posted fixes for the same driver. New firmware shipped with macOS 15 proved stricter than before. It triggered a kernel panic during failed controller initialization. It exposed a missing chicken bit. It demanded behavior that matched Apple’s XNU kernel more closely. And it required page-aligned admin queue buffers. That last quirk matters especially for M4 and later chips. (Phoronix)
Those firmware-related fixes became prerequisites. Without them M4 enablement would have stalled. The timing lines up. macOS updates often preview hardware requirements that open-source developers later reverse-engineer. Here the pattern holds.
Only weeks earlier Lilian posted initial device tree patches for the M4. “This series adds initial device trees and dt-bindings for the Apple Silicon devices using the M4 (t8132) SoC. For the most part it mirrors Janne’s M3 (t8122) bringup series as it was merged in the 7.2 cycle,” the developer explained. Those DT patches enable basic booting to a console. Nothing more. Peripherals stay silent. GPU acceleration remains distant. SMP boot still shows instability even with related idle=nop patches. (Phoronix)
The NVMe work rides on that foundation. It also depends on bootloader changes inside m1n1. Apple now locks certain CPU configuration bits inside iBoot. The bootloader no longer sets them. Such shifts force kernel and firmware teams to adapt in tandem. Progress feels incremental. Each piece clicks into place only after the prior one stabilizes.
Consider the broader picture. Apple M3 hardware still lacks end-user readiness in mainline Linux. M4 sits even further back. Yet the pace of patches has accelerated. Contributions arrive from a small but dedicated group. They reverse-engineer undocumented hardware. They upstream where possible. They maintain out-of-tree code in the meantime.
And the storage patches matter beyond raw functionality. Fast NVMe unlocks practical testing. Developers can boot, install distributions, and iterate on other subsystems without wrestling with USB drives or network root filesystems. That speeds everything else up. GPU drivers. Display support. Power management. All benefit from a stable backing store.
Of course challenges remain. The M4 brings architectural tweaks. Its NVMMU setup diverges just enough to need explicit handling. Queue registration requires that extra MMIO write. These details sound minor. They can cause hours of debugging when missed. Lilian’s series addresses them cleanly.
Reviewers will examine the code. They will test on available hardware. They will debate whether the quirks belong in the core driver or behind more specific compatibles. Such discussion happens every time new Apple silicon appears. The process works. It just takes time.
Meanwhile industry watchers note the contrast. Apple ships polished, locked-down hardware. The open-source community patiently maps its internals. The result? The same silicon runs both macOS and Linux. Not with equal performance or features yet. But the gap narrows.
Recent days brought fresh discussion on X. Phoronix shared the news. Linux enthusiasts replied with cautious optimism. One post highlighted that M3 support still lags. Another pointed to the firmware fixes as the real unsung heroes. No one claims victory. They recognize another step forward. (Phoronix on X)
So what happens next? More device tree entries. Additional driver tweaks for other M4 blocks. GPU work will demand far more effort. Display controllers, interrupt controllers, and power domains all need attention. The NVMe patches simply remove one blocker from that list.
Yet their arrival signals momentum. The community has absorbed the M1 and M2 generations. It tackled M3 with increasing confidence. M4 follows the pattern. Each generation reuses more code. Differences grow smaller. The engineering debt shrinks.
Enterprise users may not rush to install Linux on Mac minis powered by M4 chips. Not yet. Developers, researchers, and tinkerers will. They value the combination of Apple’s efficient silicon and Linux’s flexibility. They accept the incomplete state. They contribute fixes. The cycle continues.
Patch series like this one rarely make headlines outside specialized outlets. They lack drama. They contain no bold claims. Just careful code. Accurate descriptions. Links to lore.kernel.org. But they accumulate. Month after month they turn experimental kernels into something closer to daily drivers.
The M4 NVMe support won’t ship in Linux 6.12 or even 7.0. Review takes time. Dependencies must merge first. Testing must validate stability across revisions. Still, the patches exist. They compile. They boot. They detect storage. That counts as success at this stage.
Look back two years. M1 support felt miraculous. Today it feels routine. The same shift will happen for M4. These storage patches mark one early milepost on that road. Others will follow. The work never stops. But it clearly advances.
And for those watching the intersection of proprietary hardware and open source, the message stays consistent. Persistence pays. Detailed reverse engineering wins. Small teams can still influence massive platforms. The latest NVMe patches prove it once again.