AMD posted a patch series to the Linux kernel mailing list on July 29, 2026 that teaches the amd_hsmp driver to talk to Zen 6 client processors, meaning the Medusa1 and Medusa2 mobile APUs and Olympic Ridge on the desktop. Until now that driver has been an EPYC only affair. Client parts use a different mailbox, so the patches add a second path, and the interesting part is which message set they add: the Ryzen Master SMC messages, the same accessors AMD's Windows software uses. Sensors and metrics, TjMax, overclocking enable, all core frequency, voltage identification, dynamic FCLK. This is a proposal, not a merge, and there is no user space tool yet.
The short answer
An AMD engineer posted patches extending the Linux amd_hsmp driver, previously EPYC only, to Zen 6 client processors. Client parts use a different mailbox from the server HSMP interface, so the series adds a separate path and, notably, the Ryzen Master SMC message set rather than the server message IDs. The client messages cover sensors and metrics, the TjMax threshold, enabling and disabling overclocking, all core overclocking frequency, overclocking voltage identification and dynamic FCLK. This is kernel driver plumbing under review, not a shipped feature, and no user space software has been announced to drive it.
Anyone who has tried to tune a Ryzen laptop on Linux knows the routine. You find an out of tree project, you check whether it still supports your generation, you read a forum thread about which offsets moved, and you accept that the whole arrangement will break the next time AMD ships a new mobile part. The Windows answer has always been Ryzen Master, a first party tool talking to a documented interface. The Linux answer has always been someone's weekend project talking to registers AMD never promised would stay put.
That may be about to change, slowly.
What was posted
On Wednesday July 29, 2026, an AMD engineer sent a series to the Linux kernel mailing list extending the amd_hsmp driver to Zen 6 client processors. The named targets are Medusa1 and Medusa2, the Zen 6 mobile APUs, and Olympic Ridge on the desktop.
HSMP, the Host System Management Port, is the mailbox the operating system uses to ask the processor's management controller for telemetry and to set platform policy. Until now the Linux driver has spoken only to EPYC, because that is where AMD exposed the interface. The client parts have a different mailbox, so a straight reuse of the existing code was never going to work.
The detail that makes this more than routine enablement is which message set the patches add. Rather than the server HSMP message IDs, they implement the Ryzen Master SMC message set, using the same accessors as AMD's Windows HSMP driver. The client message IDs cover sensors and metrics, setting the TjMax threshold, enabling and disabling overclocking, setting the overclocking frequency across all cores, setting the overclocking voltage identification, and setting FCLK dynamically.
In other words, the transport for the things Ryzen Master does.
Why the message set matters more than the driver
A kernel driver on its own controls nothing. It is a pipe. What determines whether Linux users eventually get a supported way to set a temperature limit or an Infinity Fabric clock is whether the messages exist on the other end of that pipe and whether the kernel is willing to expose them.
The first half is now on the table. AMD is proposing to wire up the client mailbox in mainline, with the same message vocabulary its own Windows tooling uses. That is a materially different situation from reverse engineering, and it is the part that no out of tree project could ever provide.
The second half is undecided. Kernel review of interfaces that let user space push voltages and clocks outside validated ranges tends to be slow and pointed, for the good reason that the failure mode is not an error code but a machine that corrupts data quietly for six months. We would expect discussion about permissions, about whether the overclocking messages belong behind a build option, and about what the sysfs or ioctl surface should look like. None of that had resolved when the series was posted.
What this does and does not mean for you
It does not mean anything for hardware you own today. HSMP client support targets Zen 6 parts that have not launched. Your current Ryzen laptop is unaffected, and ryzenadj remains what it was.
It does not mean a Linux Ryzen Master is coming. No user space software has been announced. A driver with a message set is the necessary condition, not the sufficient one, and there is a real possibility that the merged interface ends up exposing telemetry while the overclocking messages sit behind something deliberately awkward.
What it does mean is that AMD is now enabling client power and thermal management in mainline Linux the way it has long enabled server platforms. That is the pattern that eventually produces tooling you can install from your distribution rather than build from a GitHub tarball. Enablement of this kind normally lands months before the hardware, so if Zen 6 client parts arrive with a kernel that already speaks their mailbox, this July patch series is why.
Watch the thread. The interesting review is the one about what user space is allowed to set.
Sources and further reading
- Phoronix: AMD Zen 6 client HSMP patches point to Ryzen Master functionality on Linux
- The AMD HSMP interface, kernel documentation
- Wccftech: AMD expands Zen 6 family support in Linux
- The Linux kernel mailing list archive
Frequently asked questions
What is HSMP, and why has it been EPYC only until now?
HSMP is AMD's Host System Management Port, a mailbox interface between the operating system and the system management controller on the processor package. It is how software asks the chip for power, thermal and fabric telemetry, and how it sets platform level policies such as power limits and fabric frequency bounds. The Linux driver is amd_hsmp and it exposes a character device plus a sysfs interface. It has been an EPYC feature because that is where AMD chose to expose the mailbox: server platforms need out of band style management from the host, and the message set was designed around server concerns like socket power and NBIO link width. Client processors have always had a management controller too, but the host facing mailbox was not something AMD documented or wired up in mainline Linux.
What can the client message set actually do?
According to the patch series, the client message IDs cover reading sensors and metrics, setting the TjMax threshold, enabling and disabling overclocking, setting the overclocking frequency for all cores, setting the overclocking voltage identification, and setting FCLK dynamically. That list maps closely to what Ryzen Master offers on Windows: a temperature limit, a manual all core clock, a manual voltage, and control of the Infinity Fabric clock. The patches implement the same accessors AMD's Windows HSMP driver uses. What they do not include is any policy or any user interface. This is the transport layer.
Which processors are targeted?
Two Zen 6 client families are named in the series. Medusa1 and Medusa2 are the mobile APUs, and Olympic Ridge is the desktop part. None of these have launched, which is the normal pattern for AMD enablement work in Linux: driver support lands in the kernel months ahead of hardware so that the first distribution release after launch already works. It also means the patches are a reasonable signal about what Zen 6 client platforms will expose, and no signal at all about when they will ship or what they will cost.
Does this replace ryzenadj and ryzen_smu?
Not today, and possibly never in the way people want. The out of tree projects that expose Ryzen power controls on Linux work by poking the system management unit through interfaces that AMD did not document for that purpose, which is why they break between generations and why distributions will not ship them. A first party mailbox in mainline is a much better foundation, because it is documented, reviewed and maintained by the vendor. But this series covers Zen 6 client parts only, so nothing you own right now benefits, and there is no user space tool announced to sit on top of it. Treat it as the start of a path rather than an arrival.
Will the overclocking hooks be accepted upstream?
That is the open question, and it is worth watching the thread rather than assuming. Kernel reviewers are generally cautious about interfaces that let user space set voltages and frequencies outside the ranges the hardware validates, because the failure modes are silent corruption and hardware damage rather than an error return. Existing precedent cuts both ways: the kernel already exposes plenty of tunables that will hurt you if you get them wrong, and it also has a long history of asking for guard rails on exactly this class of control. The patches were posted on July 29, 2026 and had not been merged at the time of writing, so the shape of the final interface is genuinely undecided.