Apple's M3 Pro, M3 Max and M3 Ultra are getting their first mainline Linux support in the 7.3 merge window, through a pull request from Sven Peter that adds device tree files for every Mac carrying those chips. It brings the bigger M3 variants up to the same baseline the plain M3 reached in Linux 7.2, which means the machines boot a stock kernel and not much more. There is no GPU acceleration. The same pull also adds HWMON sensor support for M1 and M2 hardware, which is the more immediately useful half if you already run Linux on an older Apple Silicon Mac.
The short answer
Sven Peter has sent a pull request adding device tree files for Apple's M3 Pro, M3 Max and M3 Ultra to the Linux 7.3 merge window, covering every Mac that ships those chips. It puts the larger M3 variants at the same baseline the plain M3 reached in Linux 7.2: the machines boot a mainline kernel, and that is close to the whole story. GPU acceleration is not there. The same pull also adds HWMON sensor support for M1 and M2 series hardware, which is the part that changes something today. For actually using these Macs, downstream Asahi Linux remains the route.
The gap between a machine booting Linux and a machine running Linux is where most of the work lives, and Apple Silicon has spent five years demonstrating it. This week's news sits firmly on the booting side of that gap, which is worth knowing before anyone reformats a Mac Studio.
What is in the pull request
Sven Peter has queued device tree support for the M3 Pro, M3 Max and M3 Ultra for the Linux 7.3 merge window. Device trees are the structured description a kernel reads on ARM platforms to discover what hardware is present, which addresses its registers occupy, and which interrupts belong to what. Without them a mainline kernel on these machines has nothing to enumerate. With them it can boot.
The pull covers every Apple device carrying those chips, and brings the larger M3 variants to roughly the level the base M3 reached in Linux 7.2. Phoronix is direct about the limits: the support is not yet useful for end users because various features remain unsupported, GPU acceleration included. That is the sentence that determines whether this is news you act on.
The second half of the pull request is quieter and more immediately useful. It adds HWMON support for M1 and M2 series sensors, which exposes readings through the kernel's standard hwmon interface. Anything that already reads /sys/class/hwmon picks them up, including sensors from lm-sensors and whatever monitoring agent you run.
Why this takes years
Apple publishes nothing. No register maps, no hardware documentation, no driver source. Every block in these SoCs is understood by watching what macOS does with it and inferring the rest, and the resulting knowledge has to be turned into a device tree binding that a subsystem maintainer will accept. The M3 Pro and M3 Max shipped in late 2023, and the M3 Ultra arrived in March 2025 alongside the Mac Studio, so the earlier parts have taken about two and a half years to reach the point of booting a stock kernel.
That timeline is not uniform across the machine, and the shape of it explains why boot support keeps arriving well before usable support. The boot path is comparatively small: a handful of blocks, clearly bounded behaviour, a spec you can validate by whether the thing comes up. The graphics stack is the opposite. It is enormous, entirely proprietary, and unlike anything in the ARM SoCs the kernel already knows how to drive, so there is no existing driver to adapt. Storage, networking and audio sit somewhere between, which is why they land in the middle of the sequence every time.
What we would do if we own one of these Macs
Keep using Asahi Linux, and read this as a progress marker rather than an invitation. On M3 series hardware the downstream project already has PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, audio, CPU frequency scaling and big.LITTLE aware scheduling working, which covers the machine well enough to be someone's daily driver with caveats. Mainline covers none of that yet for the Pro, Max and Ultra.
If you already run Linux on an M1 or M2 Mac, the HWMON change is the line in the 7.3 changelog worth acting on. A machine with no thermal instrumentation is a machine you cannot reason about under sustained load, and this turns that into a normal sensors output and a normal set of Prometheus metrics. It is the least exciting item here and probably the one that changes the most working days.
The broader point is about direction rather than dates. Every piece that moves from Asahi's tree into mainline is a piece that stops needing to be rebased against each new kernel, and stops being a reason to stay on a specific distribution. Nobody has committed to when the M3 series becomes genuinely usable upstream, and given the volunteer scale of the effort, nobody sensibly could. What we would track is which subsystem maintainers start accepting M3 patches, because that is the signal that arrives before the release notes do.
Sources and further reading
- Initial Apple M3 Pro / Max / Ultra support being upstreamed for Linux 7.3, Phoronix, August 7, 2026
- M3 series feature support, Asahi Linux documentation
- Progress report: Linux 7.0, Asahi Linux, April 2026
- Asahi Linux gets closer to full M3 support on Apple Silicon Macs, Linuxiac
Frequently asked questions
Does this mean I can install a normal Linux distribution on an M3 Max MacBook Pro?
Not in any way you would enjoy. What lands in Linux 7.3 is device tree data, which is the description the kernel reads to learn what hardware exists and where its registers live. Having it means a mainline kernel can boot on these machines instead of failing to recognise them. It does not mean the peripherals you need are driven. Phoronix is explicit that the support is not yet useful for end users because various features are unsupported, GPU acceleration among them, and a laptop without graphics acceleration is a laptop with a slow software rendered desktop. The realistic path today remains the downstream Asahi Linux work, where M3 series machines already have PCIe, WiFi, Bluetooth, NVMe, keyboard, trackpad, audio, CPU frequency scaling and big.LITTLE aware scheduling working. Mainline is where that eventually consolidates, and this pull request is the first step of the consolidation rather than the end of it.
What is the difference between mainline support and Asahi support?
Asahi Linux is the downstream project doing the reverse engineering and driver development, and it ships a distribution with patches that have not yet been merged upstream. Mainline is Linus Torvalds' kernel tree, where code arrives after review and stays maintained by the wider community. Work flows from the first to the second, usually in pieces and usually years apart, because upstreaming means each driver has to be acceptable to the maintainer of whichever subsystem it touches rather than merely working. The practical consequence is that Asahi is always ahead on features and mainline is always ahead on longevity: once support is mainline, your distribution of choice gets it for free with its next kernel and nobody has to keep rebasing patches. For M3 hardware specifically, the interesting parts, GPU in particular, are Asahi patches today and mainline patches at some unannounced future point.
Why does device tree support arrive so long after the hardware ships?
Because none of this is documented. Apple does not publish register maps or hardware specifications for its SoCs, so every block has to be worked out by observing what macOS does with it, and the resulting knowledge has to be written up as a device tree binding and defended in review. The M3 Pro and M3 Max shipped in late 2023 and the M3 Ultra arrived in March 2025 with the Mac Studio, which puts this at roughly two and a half years for the earlier parts. That is not unusual for a platform with no vendor cooperation, and the gap is not evenly distributed either: booting is comparatively quick to reach because the boot path is small and well understood, while the display and GPU stack takes far longer because it is large, proprietary and has no analogue in other ARM SoCs. The work is done by a small volunteer team, which is worth keeping in mind when reading any timeline.
What does the HWMON part of the pull request give me on an M1 or M2 machine?
Sensor readings, exposed through the standard kernel hwmon interface. That means temperatures, and depending on what the platform exposes, power and voltage rails become visible to ordinary tooling: `sensors` from lm-sensors, anything that reads `/sys/class/hwmon`, and by extension your monitoring agent, whether that is Prometheus node_exporter, Netdata or a shell script. Before this, running Linux on an M1 or M2 Mac meant flying without thermal instrumentation, which is a genuine operational gap if the machine is doing anything sustained rather than sitting on a desk. It is the least glamorous item in the pull request and probably the one that changes the most days, because it turns a machine you cannot observe into a machine you can graph. If you already run Linux on Apple Silicon, this is the line in the 7.3 changelog that concerns you.
When will the M3 series be genuinely usable on mainline Linux?
Nobody has committed to a date, and we would treat any specific claim with suspicion. The pattern from the M1 and M2 generations is instructive: boot support arrives, then storage and networking, then audio and power management, and the display and GPU stack arrives last by a wide margin because it is the hardest and least documented piece. The M3 series is at the very start of that sequence in mainline, with the plain M3 having reached the baseline in Linux 7.2 and the Pro, Max and Ultra joining it in 7.3. What we would watch is not release announcements but which subsystem maintainers start taking M3 patches, because that is the leading indicator. In the meantime the practical answer for anyone who wants to use these machines is unchanged: use Asahi, accept that some features are work in progress, and expect the mainline story to catch up over kernel cycles rather than months.