L’ingénieur d’AMD Shyam Sundar S K aurait soumis le 10 octobre 2026 une série de trois correctifs pour un pilote AMD Overclocking Driver (AOD) destiné au noyau Linux. L’interface proposée donnerait accès à quelques réglages du firmware Ryzen, mais les limites de puissance et de courant ne prendraient effet qu’après un redémarrage. Le 23 octobre, Geektopia indiquait que les correctifs étaient encore en revue et n’avaient pas été intégrés au noyau.
Une série de correctifs suivie en octobre
La chronologie de revue rapportée s’étend sur plusieurs étapes : Mario Limonciello aurait donné un avis « Reviewed-by » le 12 octobre, Armin Wolf aurait commenté les trois correctifs le 15, puis Ilpo Järvinen, responsable du sous-système concerné, aurait commenté les correctifs 1 et 2 le 21 octobre. Ces interventions ne fixaient pas de date d’intégration.
Les réglages prévus pour Ryzen
AOD serait un pilote WMI qui relierait Linux au firmware de la plateforme Ryzen. Il exposerait ses commandes dans sysfs, le système de fichiers virtuel par lequel le noyau rend accessibles certains réglages et informations.
Les commandes décrites permettraient de modifier trois limites : PPT (Package Power Tracking), TDC (Thermal Design Current) et EDC (Electrical Design Current). Pour chacune, l’interface indiquerait les valeurs autorisées et le pas entre deux réglages. Elle permettrait aussi d’activer ou de désactiver le SMT au niveau du firmware, tandis que la fréquence mémoire resterait consultable en lecture seule.
Les commandes par cœur, les réglages de tension et les contrôles individuels du turbo ne figurent pas dans la liste décrite. La série ne comprendrait pas non plus d’application graphique AMD comparable à Ryzen Master.
Pourquoi les limites changeraient après redémarrage
Les nouvelles valeurs PPT, TDC et EDC seraient enregistrées dans le firmware et appliquées au démarrage suivant, plutôt que de modifier immédiatement les limites en cours d’utilisation. Les attributs décrits permettraient d’écrire ces réglages sans renvoyer leur valeur active. Pour tester une nouvelle configuration, il faudrait donc redémarrer, sans pouvoir lire ces attributs pour vérifier directement la limite appliquée.
AOD, HSMP et l’accès de débogage
AOD et HSMP agiraient à des niveaux différents. AOD modifierait des réglages conservés par le firmware et appliqués au redémarrage. HSMP modifierait des limites d’exécution dans le SMU, immédiatement, mais ces changements seraient perdus au redémarrage; cette interface cible les serveurs EPYC.
L’accès aux méthodes WMI brutes via debugfs relèverait du débogage. Comme cette interface n’aurait pas d’ABI stable, elle ne constituerait pas une base fiable pour des outils utilisateur pérennes, contrairement aux commandes prévues dans sysfs.
