Inżynier AMD Shyam Sundar S K zgłosił 10 października 2026 r. propozycję sterownika AOD dla Ryzenów w Linuksie. Seria trzech poprawek miała udostępniać wybrane ustawienia firmware przez interfejs jądra. Według relacji z 23 października poprawki nadal były wtedy przeglądane i nie zostały włączone do jądra Linux.

Zgłoszenie i przegląd poprawek

Relacje techniczne podawały, że seria trafiła do przeglądu 10 października. 12 października Mario Limonciello przesłał opinię „Reviewed-by” i poparł proponowaną strukturę katalogów. 15 października Armin Wolf skomentował wszystkie trzy poprawki, a 21 października Ilpo Järvinen odniósł się do pierwszej i drugiej. Informacja opublikowana 23 października mówiła, że przegląd wciąż trwał, a poprawki nie weszły do jądra.

Jakie ustawienia udostępniałby AOD

Proponowany sterownik WMI miał łączyć Linuksa z firmware platformy Ryzen i udostępniać ustawienia przez sysfs, czyli wirtualny system plików, za pomocą którego jądro pokazuje programom swoje atrybuty. Opisywany zakres obejmował limity PPT, TDC i EDC, przełącznik SMT na poziomie platformy oraz odczyt bieżącego taktowania pamięci.

  • PPT, TDC i EDC: można byłoby ustawiać limity mocy i prądu. Interfejs miał też podawać obsługiwane zakresy wartości i wielkość kroku między nimi.
  • SMT: sterownik miał pozwalać włączać i wyłączać tę funkcję na poziomie firmware platformy. To inny mechanizm niż opcja startowa Linuksa nosmt, która nakazuje jądru nie używać wątków współdzielących rdzenie.
  • Taktowanie pamięci: można byłoby odczytać jego bieżącą wartość, ale nie zmieniać jej za pomocą opisywanego interfejsu.

Opisywana seria nie obejmowała aplikacji graficznej AMD podobnej do Ryzen Master. Ustawienia miały być dostępne przez interfejs jądra, a nie przez nowy program z panelem sterowania.

Dlaczego zmiana limitów wymagałaby restartu

Nowe wartości PPT, TDC i EDC miały trafiać do firmware i zaczynać obowiązywać po ponownym uruchomieniu komputera. Nie byłyby więc zmianami limitów działającymi natychmiast. Opisane atrybuty pozwalałyby zapisywać ustawienia, ale nie odczytywać aktualnie aktywnych wartości limitów.

AOD, HSMP i dostęp debugowania

AOD i HSMP miały działać na różnych poziomach. AOD zmieniałby zapisane w firmware ustawienia, które zaczynają obowiązywać po restarcie. HSMP zmienia limity w czasie pracy przez SMU, układ zarządzający funkcjami procesora; te zmiany nie utrzymują się po ponownym uruchomieniu. Relacje techniczne opisywały HSMP jako interfejs przeznaczony dla serwerów EPYC.

Surowy dostęp do metod WMI przez debugfs nie byłby stabilną alternatywą dla atrybutów sysfs. debugfs służy do debugowania i, według opisu projektu, nie zapewnia stabilnego ABI, czyli trwałego kontraktu, na którym mogą polegać programy. To ograniczenie ma znaczenie dla twórców narzędzi użytkowych, którzy potrzebowaliby przewidywalnego interfejsu.