AMD a publié le 4 août une série de patches proposant un sous-système eSPI pour le noyau Linux, et la décision intéressante n'est pas le pilote mais la forme. L'Enhanced SPI est le bus par lequel votre machine atteint son contrôleur embarqué, son TPM et son firmware, et Linux n'a jamais eu d'endroit où le ranger. Krishnamoorthi M, chez AMD, avait demandé à la liste noyau si ce travail relevait du sous-système SPI existant ou méritait son propre type de bus. Les patches répondent : l'eSPI obtient son bus, avec un pilote AMD comme premier utilisateur, validé sur une plateforme AMDI0070.
The short answer
Krishnamoorthi M, chez AMD, a publié le 4 août une série de patches proposant un sous-système eSPI dédié pour le noyau Linux. Plutôt que d'étendre le code SPI existant, l'eSPI devient son propre type de bus, avec un nouveau pilote eSPI AMD comme premier utilisateur. La série a été validée sur une plateforme AMDI0070. Les limites connues sont annoncées d'emblée : énumération ACPI uniquement, enregistrement manuel des périphériques esclaves, et opérations supplémentaires renvoyées à des patches ultérieurs.
Il existe une couche de votre ordinateur sur laquelle Linux n'a jamais vraiment eu d'avis. Elle se situe sous le système d'exploitation, relie le chipset au contrôleur embarqué et à la flash du firmware, et jusqu'ici la réponse du noyau à la question de ce qui vit là était en substance : l'affaire du firmware, pas la nôtre.
Le 4 août, Krishnamoorthi M chez AMD a publié une série de patches qui propose de changer cela. La série introduit un sous-système eSPI pour le noyau Linux, et ce qui mérite lecture est le choix d'architecture derrière, plus que le pilote livré avec.
Ce qu'est réellement l'eSPI
L'Enhanced Serial Peripheral Interface a été conçu par Intel pour succéder au LPC, le bus Low Pin Count, qui remplaçait lui-même l'ISA pour les parties lentes mais essentielles d'un PC. C'est par là que le chipset atteint le contrôleur embarqué, le Super I/O, le TPM et la flash du firmware.
Le mot « enhanced » travaille vraiment. Le SPI ordinaire déplace des octets entre un contrôleur et un périphérique. L'eSPI multiplexe plusieurs canaux logiquement distincts sur les mêmes fils physiques : trafic périphérique, signalisation par fils virtuels qui remplace des broches physiques pour des événements comme les transitions de veille et les interruptions, messagerie hors bande, accès à la flash. C'est un protocole, pas un mécanisme de transfert.
La question qu'AMD a posée avant d'écrire le code
Krishnamoorthi M avait posé la question directement sur la liste noyau : le travail eSPI d'AMD doit-il étendre le sous-système SPI existant, ou l'eSPI doit-il être introduit comme un type de bus à part entière ?
Cette question n'est pas administrative. Sous Linux, un type de bus détermine comment les périphériques sont découverts, comment les pilotes leur sont associés, à quoi ressemblent les chemins probe et remove, et comment l'ensemble apparaît dans sysfs. Réutiliser SPI aurait signifié décrire un protocole multicanal via une abstraction pensée pour quelque chose de plus simple. C'est le genre de décision qui paraît anodine dans le premier patch et coûteuse trois ans plus tard, quand chaque nouvelle capacité demande une exception.
Cette série répond dans l'autre sens. L'eSPI devient son propre bus, et le pilote eSPI AMD en devient le premier utilisateur plutôt que son unique raison d'exister.
Ce qu'il y a dedans, et ce qu'il n'y a pas
Le code a été testé et validé sur une plateforme AMDI0070, l'identifiant ACPI du contrôleur eSPI visé par AMD.
Les limites sont énoncées ouvertement dans la publication, et cela mérite d'être relevé : une première soumission de sous-système qui masque ses trous reçoit en général un accueil plus rude qu'une qui les liste. L'énumération est ACPI uniquement, donc pas encore de binding Device Tree. Les périphériques esclaves sont enregistrés manuellement plutôt que découverts. Des opérations supplémentaires sont explicitement reportées.
Rien d'inhabituel pour une proposition initiale. Cela signifie tout de même qu'il s'agit d'une demande d'accord architectural plus que d'une fonctionnalité finie, et que le cycle de relecture d'un nouveau type de bus se compte en mois.
Pourquoi un sysadmin devrait s'intéresser à un bus qu'il ne voit pas
La réponse courte et honnête : rien ne change aujourd'hui sur votre machine. La réponse longue porte sur la visibilité.
Les composants à l'autre bout de ce bus sont ceux qui décident si un serveur démarre, comment son comportement thermique est géré, ce que rapporte le TPM et comment le firmware est écrit. Sur la plupart du matériel, tout cela est opaque depuis le système d'exploitation. Quand quelque chose se passe mal à ce niveau, le chemin de diagnostic se résume aujourd'hui à l'outillage du constructeur, un BMC si vous en avez un, et de l'intuition.
Un sous-système noyau ne rend pas automatiquement tout cela lisible. Ce qu'il crée, c'est un endroit où cela pourrait le devenir : une structure définie pour les pilotes, une disposition sysfs prévisible, et un moyen pour les travaux futurs d'exposer l'état de ces périphériques sans que chaque constructeur invente son propre chemin. C'est un bénéfice lent, et il a la même forme que celui que le noyau a fini par tirer de vrais sous-systèmes pour hwmon, pour la gestion thermique et pour les mises à jour de firmware.
Nous n'allons pas prétendre que c'est une nouvelle palpitante pour un mardi. C'est une décision structurelle prise avec soin, par un ingénieur qui a demandé où son code devait vivre avant d'en écrire davantage, dans une zone de la machine à laquelle la plupart d'entre nous ne pensent que lorsqu'elle tombe en panne. Ce sont en général les patches qui méritent qu'on les remarque.
Sources et pour aller plus loin
- AMD posts proposal and Linux patches for eSPI subsystem, Phoronix, 4 août 2026
- La série de patches sur la liste de diffusion du noyau Linux
- Patch eSPI AMD antérieur ajoutant un ioctl de sélection de canal
- Documentation du modèle de périphériques et des types de bus Linux
Questions fréquentes
Qu'est-ce que l'eSPI et où se trouve-t-il dans ma machine ?
L'Enhanced Serial Peripheral Interface est le bus qui relie un chipset x86 moderne aux composants bas niveau qui font qu'un PC est un PC : le contrôleur embarqué, le Super I/O, le TPM, la flash du firmware. Intel l'a conçu pour remplacer le LPC, le bus Low Pin Count, qui remplaçait lui-même l'ISA. Vous ne le verrez pas dans lsblk ni dans ip link, parce qu'il se situe en dessous du niveau que Linux expose habituellement. Il transporte plusieurs canaux logiques sur les mêmes fils physiques : trafic périphérique, signalisation par fils virtuels qui remplace des broches dédiées pour les transitions d'état de veille, messagerie hors bande, accès à la flash. Si vous vous êtes déjà demandé comment le système apprend que le capot d'un portable s'est fermé, cette catégorie de plomberie est la réponse.
Pourquoi en faire un type de bus séparé change-t-il quelque chose ?
Parce qu'un type de bus Linux n'est pas une formalité. Il définit comment les périphériques de ce bus sont découverts, comment les pilotes leur sont associés, à quoi ressemblent les fonctions probe et remove d'un pilote, et ce que montre l'arborescence sysfs. Greffer l'eSPI sur le sous-système SPI aurait signifié exprimer un protocole multicanal, avec fils virtuels et messagerie hors bande, à travers une abstraction conçue pour de simples transferts série. En général cela tient un moment, puis chaque nouvelle fonction demande un cas particulier. Krishnamoorthi M a posé la question explicitement sur la liste avant d'écrire ce code, et c'est le bon ordre.
Est-ce que cela concerne la machine posée sur mon bureau aujourd'hui ?
Non. Il s'agit d'une série publiée pour relecture, pas de quelque chose présent dans un noyau publié, et le premier utilisateur est un contrôleur AMD identifié AMDI0070. Rien ne change dans votre chemin de mise à jour firmware, votre TPM ou votre contrôleur embarqué à cause de cela. Ce qui pourrait changer sur les prochains cycles noyau, c'est la lisibilité de cette couche depuis Linux. Aujourd'hui, sur la plupart des machines, le trafic eSPI relève entièrement du firmware et le système d'exploitation n'a aucune vue dessus.
Quelles sont les lacunes connues de la proposition ?
AMD les a listées, ce qui est bon signe sur le sérieux de la soumission. L'énumération se fait uniquement via ACPI, donc il n'y a pas encore de support Device Tree, ce qui compte pour qui espérait utiliser cela hors du monde du firmware x86. Les périphériques esclaves doivent être enregistrés manuellement plutôt que découverts. Plusieurs opérations sont reportées à des patches ultérieurs. Et la validation rapportée porte sur une seule plateforme. Rien d'inhabituel pour une première publication de sous-système, mais cela vous dit à quelle distance on se trouve de quelque chose sur quoi bâtir.
Est-ce la première tentative d'AMD pour intégrer l'eSPI en amont ?
Non, et cet historique explique en partie pourquoi la question du type de bus s'est posée. Des travaux antérieurs de pilote eSPI AMD étaient arrivés sur la liste sous le sous-système SPI, dont des patches ajoutant un ioctl de sélection de canal eSPI, et ce placement avait suscité des questions. La série actuelle est le résultat d'un pas de côté : demander où ce code doit vivre avant d'en ajouter davantage. C'est une voie plus lente que continuer d'étendre l'existant, et en termes noyau c'est en général celle qui survit à la relecture.