AMD a envoyé le 29 juillet 2026 une série de patchs à la liste de diffusion du noyau Linux qui apprend au pilote amd_hsmp à dialoguer avec les processeurs Zen 6 client, c'est-à-dire les APU mobiles Medusa1 et Medusa2 et Olympic Ridge sur le bureau. Jusqu'ici ce pilote était réservé aux EPYC. Les puces client utilisent une boîte aux lettres différente, la série ajoute donc un second chemin, et le point intéressant est le jeu de messages retenu : les messages SMC de Ryzen Master, ceux-là mêmes qu'utilise le logiciel Windows d'AMD. Capteurs et métriques, TjMax, activation de l'overclocking, fréquence tous cœurs, identification de tension, FCLK dynamique. C'est une proposition, pas une fusion, et aucun outil espace utilisateur n'existe encore.
The short answer
Un ingénieur d'AMD a publié des patchs qui étendent le pilote Linux amd_hsmp, jusqu'ici réservé aux EPYC, aux processeurs Zen 6 client. Les puces client utilisent une boîte aux lettres différente de l'interface HSMP serveur, la série ajoute donc un chemin distinct et, fait notable, le jeu de messages SMC de Ryzen Master plutôt que les identifiants serveur. Les messages client couvrent les capteurs et métriques, le seuil TjMax, l'activation et la désactivation de l'overclocking, la fréquence d'overclocking tous cœurs, l'identification de tension et le FCLK dynamique. C'est de la plomberie noyau en relecture, pas une fonction livrée, et aucun logiciel espace utilisateur n'a été annoncé pour la piloter.
Quiconque a essayé d'ajuster un portable Ryzen sous Linux connaît le rituel. On trouve un projet hors arbre, on vérifie s'il gère encore sa génération, on lit un fil de forum sur les offsets qui ont bougé, et on accepte que tout casse à la prochaine puce mobile d'AMD. La réponse Windows a toujours été Ryzen Master, un outil officiel qui parle à une interface documentée. La réponse Linux a toujours été le projet du week-end de quelqu'un, qui parle à des registres dont AMD n'a jamais promis la stabilité.
Cela pourrait changer, lentement.
Ce qui a été publié
Le mercredi 29 juillet 2026, un ingénieur d'AMD a envoyé à la liste de diffusion du noyau Linux une série qui étend le pilote amd_hsmp aux processeurs Zen 6 client. Les cibles nommées sont Medusa1 et Medusa2, les APU mobiles Zen 6, et Olympic Ridge sur le bureau.
HSMP, le Host System Management Port, est la boîte aux lettres par laquelle le système d'exploitation demande de la télémétrie au contrôleur de gestion du processeur et applique des politiques de plateforme. Jusqu'ici le pilote Linux ne parlait qu'aux EPYC, parce que c'est là qu'AMD avait exposé l'interface. Les puces client ont une boîte aux lettres différente, une simple réutilisation du code existant ne pouvait donc pas fonctionner.
Le détail qui fait de cette série autre chose qu'une activation de routine, c'est le jeu de messages ajouté. Au lieu des identifiants HSMP serveur, les patchs implémentent le jeu de messages SMC de Ryzen Master, avec les mêmes accesseurs que le pilote HSMP Windows d'AMD. Les identifiants client couvrent les capteurs et métriques, le réglage du seuil TjMax, l'activation et la désactivation de l'overclocking, la fréquence d'overclocking sur tous les cœurs, l'identification de tension d'overclocking et le réglage dynamique du FCLK.
Autrement dit, le transport de ce que fait Ryzen Master.
Le jeu de messages compte plus que le pilote
Un pilote noyau ne contrôle rien à lui seul. C'est un tuyau. Ce qui déterminera si les utilisateurs Linux obtiennent un jour une manière supportée de fixer une limite de température ou une horloge Infinity Fabric, c'est l'existence des messages à l'autre bout du tuyau et la volonté du noyau de les exposer.
La première moitié est désormais sur la table. AMD propose de câbler la boîte aux lettres client dans mainline, avec le vocabulaire de messages qu'utilise son propre outillage Windows. C'est une situation très différente de la rétro-ingénierie, et c'est la part qu'aucun projet hors arbre n'aurait jamais pu fournir.
La seconde moitié n'est pas tranchée. La relecture noyau des interfaces qui laissent l'espace utilisateur pousser tensions et fréquences hors des plages validées est généralement lente et pointue, pour une bonne raison : le mode de défaillance n'est pas un code d'erreur, c'est une machine qui corrompt silencieusement des données pendant six mois. Nous nous attendons à des discussions sur les permissions, sur l'opportunité de placer les messages d'overclocking derrière une option de compilation, et sur la forme de la surface sysfs ou ioctl. Rien de tout cela n'était résolu au moment de la publication.
Ce que cela change, et ne change pas, pour vous
Cela ne change rien au matériel que vous possédez aujourd'hui. Le support HSMP client vise des puces Zen 6 qui ne sont pas sorties. Votre portable Ryzen actuel n'est pas concerné, et ryzenadj reste ce qu'il était.
Cela ne veut pas dire qu'un Ryzen Master pour Linux arrive. Aucun logiciel espace utilisateur n'a été annoncé. Un pilote avec un jeu de messages est la condition nécessaire, pas la condition suffisante, et il est tout à fait possible que l'interface fusionnée expose la télémétrie tout en plaçant les messages d'overclocking derrière quelque chose de volontairement inconfortable.
Ce que cela veut dire, en revanche, c'est qu'AMD active désormais la gestion de puissance et de température des puces client dans Linux mainline comme elle le fait depuis longtemps pour les plateformes serveur. C'est le schéma qui finit par produire des outils installables depuis sa distribution plutôt que compilés depuis une archive GitHub. Ce type d'activation arrive normalement des mois avant le matériel : si les puces Zen 6 client sortent avec un noyau qui parle déjà leur boîte aux lettres, cette série de juillet en sera la raison.
Suivez le fil. La relecture intéressante sera celle qui portera sur ce que l'espace utilisateur a le droit de régler.
Sources et pour aller plus loin
- Phoronix : AMD Zen 6 client HSMP patches point to Ryzen Master functionality on Linux
- Documentation noyau de l'interface AMD HSMP
- Wccftech : AMD expands Zen 6 family support in Linux
- Archive de la liste de diffusion du noyau Linux
Questions fréquentes
Qu'est-ce que HSMP, et pourquoi était-ce réservé aux EPYC ?
HSMP est le Host System Management Port d'AMD, une boîte aux lettres entre le système d'exploitation et le contrôleur de gestion embarqué dans le boîtier du processeur. C'est par là que le logiciel demande à la puce sa télémétrie de puissance, de température et de fabric, et qu'il applique des politiques de plateforme comme les limites de puissance ou les bornes de fréquence du fabric. Le pilote Linux s'appelle amd_hsmp et expose un périphérique caractère plus une interface sysfs. C'était une fonction EPYC parce que c'est là qu'AMD avait choisi d'exposer la boîte aux lettres : les plateformes serveur ont besoin d'une gestion depuis l'hôte, et le jeu de messages a été conçu autour de préoccupations serveur comme la puissance socket ou la largeur des liens NBIO. Les processeurs client ont toujours eu un contrôleur de gestion eux aussi, mais la boîte aux lettres côté hôte n'était ni documentée ni câblée dans Linux mainline.
Que permet réellement le jeu de messages client ?
D'après la série de patchs, les identifiants de messages client couvrent la lecture des capteurs et métriques, le réglage du seuil TjMax, l'activation et la désactivation de l'overclocking, le réglage de la fréquence d'overclocking pour tous les cœurs, le réglage de l'identification de tension d'overclocking et le réglage dynamique du FCLK. Cette liste correspond de près à ce qu'offre Ryzen Master sous Windows : une limite de température, une fréquence manuelle tous cœurs, une tension manuelle et le contrôle de l'horloge Infinity Fabric. Les patchs implémentent les mêmes accesseurs que le pilote HSMP Windows d'AMD. Ce qu'ils ne contiennent pas, c'est la moindre politique et la moindre interface utilisateur. Il s'agit de la couche de transport.
Quels processeurs sont visés ?
Deux familles Zen 6 client sont nommées dans la série. Medusa1 et Medusa2 sont les APU mobiles, et Olympic Ridge la puce de bureau. Aucune n'est sortie, ce qui est le schéma normal du travail d'activation d'AMD dans Linux : le support pilote arrive dans le noyau des mois avant le matériel, pour que la première version de distribution après le lancement fonctionne déjà. Cela signifie aussi que ces patchs indiquent raisonnablement ce que les plateformes Zen 6 client exposeront, et n'indiquent rien du tout sur leur date de sortie ou leur prix.
Est-ce que cela remplace ryzenadj et ryzen_smu ?
Pas aujourd'hui, et peut-être jamais de la façon dont on l'espère. Les projets hors arbre qui exposent les contrôles de puissance Ryzen sous Linux fonctionnent en sollicitant l'unité de gestion système par des interfaces qu'AMD n'a pas documentées pour cet usage, d'où leurs ruptures entre générations et le refus des distributions de les livrer. Une boîte aux lettres officielle dans mainline est une bien meilleure fondation, parce qu'elle est documentée, relue et maintenue par le fabricant. Mais cette série ne couvre que les puces Zen 6 client, rien de ce que vous possédez aujourd'hui n'en profite, et aucun outil espace utilisateur n'a été annoncé pour s'appuyer dessus. Voyez-y le début d'un chemin plutôt qu'une arrivée.
Les fonctions d'overclocking seront-elles acceptées en amont ?
C'est la question ouverte, et mieux vaut suivre le fil que présumer. Les relecteurs du noyau sont généralement prudents avec les interfaces qui laissent l'espace utilisateur régler des tensions et des fréquences hors des plages validées par le matériel, parce que le mode de défaillance est une corruption silencieuse ou un composant endommagé, pas un code d'erreur. Les précédents vont dans les deux sens : le noyau expose déjà quantité de réglages qui font mal si on se trompe, et il a aussi une longue tradition d'exiger des garde-fous sur exactement cette catégorie de contrôle. Les patchs ont été publiés le 29 juillet 2026 et n'étaient pas fusionnés au moment où nous écrivons, la forme finale de l'interface reste donc réellement indécise.