A 222-point Hacker News discussion formed around an awkward split in Asahi Linux's latest progress report: M3 Macs are nearly ready for an official release, while M4 and early M5 machines can finally use their NVMe storage but still cannot be installed through Asahi's normal route. That distinction matters more than a generic claim of "support." The project has crossed several hard hardware milestones, yet its own Linux 7.2 report says little else works on M4 and M5 and keeps them out of the Asahi Installer.
This is how support for undocumented hardware advances. A webcam starts working after one changed initialization message. USB 3.0 returns after developers trace a controller that moved to a different bus. A storage controller comes alive, but the rest of the machine is still too incomplete for users. Asahi's report, published after Linux 7.2, is useful because it separates those engineering wins from a finished distribution release.
M3 is approaching the usable line
Asahi says it is "almost ready" to make an official release for M3-series Macs. The remaining work described in the report is less about proving that Linux can boot and more about filling in the devices people expect to work every day. A skipped initialization message on the M3 Max was the last change needed for webcam support across M3 models with built-in cameras, according to the project's account.
Microphone support required a larger initialization message and a new set of coefficients for a high-frequency decimator introduced with M3. USB-C connectivity presented a different problem. Apple moved the M3 Pro and Max from its CD3217 controller on I2C to an ACE3 controller on SPMI. Reverse engineering found that ACE3 retained much of the earlier controller's register layout behind the new interface. Asahi now reports USB 3.0 and Thunderbolt working across the M3 series.
Display and graphics firmware remain tied to particular macOS releases because Apple can change the private interfaces between its firmware and operating system. Asahi plans to target the interfaces shipped with macOS 14.8.3 for M3 hardware. The project's Display Co-Processor work is now close to the feature coverage it has for the macOS 13.5 interface used on M1 and M2. That does not produce a release date, and Asahi only says it expects to discuss the release in the coming weeks.
The important editorial line is therefore "nearly ready," not "supported." Asahi has announced no M3 installer release in this report. Developers and curious owners should wait for the project's release notice rather than treating individual driver milestones as an invitation to install on a primary machine.
M4 and M5 can see storage, but cannot enter the installer
The M4 and early M5 results sit at an earlier stage. Apple changed the firmware interface for its NVMe controller in the macOS 15.x firmware bundle. Asahi developers updated both the m1n1 boot and reverse-engineering tool and the Linux side, and the project now reports working NVMe on M4 and M5. PCIe has reached the point where Linux can enumerate devices on the bus. A separate fix stops Linux from crashing shortly after boot when more than one CPU core is enabled.
Those results solve prerequisites rather than the whole machine. Storage access means the kernel can talk to the internal drive; PCIe enumeration means it can discover devices. Neither says the display, keyboard, networking, power management and other daily-use components are ready together. Asahi explicitly says that not much else works on M4 and M5 and that it is not ready to enable either generation in the installer.
M4 also exposed an unusual CPU idle failure. On earlier M1 through M3 chips, software could configure per-core settings that control whether a core retains its state during a Wait For Interrupt instruction. Starting with M4, Apple's boot firmware sets and locks those controls. In the resulting configuration, an M4 core can lose state when Linux uses WFI during early boot, crashing the code that was running.
A new kernel command-line option lets Asahi choose a safe idle-loop behavior before its downstream CPU idle driver loads. The report says those patches are already in linux-next. Once the driver takes control, it saves the state that would otherwise be lost before issuing WFI. It is a narrow fix, but it shows why a machine that "boots" can still be far from a reliable installer target.
Power management needs a new path through firmware
The longer-term CPU idle solution runs into an upstream Linux rule. Arm systems are expected to expose CPU power functions through the Power State Coordination Interface, rather than placing each vendor's private sleep mechanism in the kernel. Linux normally reaches PSCI firmware with an SMC or HVC instruction that transfers control to a higher exception level. Apple Silicon does not provide the EL3 firmware environment that this conventional route expects, while Linux already runs at EL2.
Asahi currently carries an Apple-specific CPU idle driver downstream, but that driver cannot be accepted upstream under the arm64 maintainers' PSCI requirement. Moving Linux down to EL1 and hosting PSCI at EL2 could make the calls work, although Asahi says this would break architectural features including virtualization. The proposed route instead treats m1n1 as firmware that Linux can call through UEFI Runtime Services.
Developer Sven Peter has modified m1n1 so it reserves memory for a PSCI implementation after boot, according to the Asahi progress report. A companion Linux proposal adds a UEFI Runtime Service conduit for PSCI and has reached the mailing list as a request for comments. It is still a proposal. If maintainers accept the design, Asahi could replace a private kernel path with an interface that fits upstream Linux's power-management rules.
M4 tracing works again by emulating Apple's guarded mode
Apple's newer memory protection created a second obstacle for M4 development. XNU expects Apple's Secure Page Table Monitor to run inside Guarded Execution Framework levels and control page-table operations. Without SPTM, XNU panics early. Loading m1n1 as though it were XNU causes a different failure because m1n1 needs memory controls that SPTM would restrict.
The project worked around that conflict inside the m1n1 hypervisor. Earlier reverse engineering documented GXF as lateral guarded levels beside EL1 and EL2, with a separate permission system called SPRR; Asahi's technical notes on SPRR and GXF describe the system registers behind those modes. The new hypervisor work emulates them, loads Apple's SPTM in the environment it expects, then loads a modified XNU alongside it.
That restores the ability to observe memory-mapped I/O accesses on M4 and later chips, a central technique for learning how undocumented devices behave. Asahi warns that tracing is slower on these machines, but calls it usable. This is an enabling tool rather than an end-user feature: it gives developers a way to investigate the hardware needed for future drivers.
Video decoding works before desktop integration does
Hardware video decode has advanced on machines Asahi already supports. Its Apple Video Decoder work now handles H.264, H.265 and VP9 with what the project describes as mostly reliable operation across supported Macs. M3 and later hardware also has AV1 decode capability. The decoder itself is stateless, so software must supply the information needed for each frame rather than relying on the hardware to track the stream. The Linux kernel's stateless decoder documentation assigns that parsing and state management to the client through the V4L2 Request API.
That kernel interface has weak coverage in mainstream desktop applications. GStreamer has basic support, while FFmpeg needs patches outside its main tree, according to Asahi. The project revived an abandoned translation layer that presents the V4L2 stateless decoder through VA-API, which desktop software understands more widely. Applications can then reach Apple's decoder after an environment variable is set for the login session.
There are firm limits. Fedora Asahi Remix does not ship the translation layer by default, and Firefox's video-decoding sandbox prevents this route from working. The stack has moved from driver development into integration work, where a functioning kernel component still needs packaging, browser compatibility and a stable userspace path.
Asahi is also wiring Apple's Interchange framebuffer format across its GPU, display controller and video decoder work. Sharing a compatible buffer can avoid copies between those blocks and may let the display controller scan out a frame without waking the GPU for composition. Direct scanout is currently blocked because KWin views the separate GPU and display controller as a multi-GPU setup and disables this DMA-BUF path. Asahi says changes under discussion could make the setup work as early as Plasma 6.8, but it does not claim that outcome is settled.
The next concrete markers are easy to name. Watch for the promised M3 release notice, an installer change that admits newer machines, and movement of the UEFI-based PSCI proposal beyond RFC status. On the desktop side, Fedora packaging and Firefox compatibility will say more about useful video acceleration than another decoder demo. Until those pieces land, M4 and M5 storage access remains a developer milestone, not a usable Asahi Linux release.