AMD posted a patch series on August 4 proposing a new eSPI subsystem for the Linux kernel, and the interesting decision is not the driver but the shape. Enhanced SPI is the bus your machine uses to reach its embedded controller, its TPM and its firmware, and Linux has never had a place to put it. AMD's Krishnamoorthi M asked the mailing list whether the work belonged inside the existing SPI subsystem or deserved a bus type of its own. The patches answer that question: eSPI gets its own bus, with an AMD driver as the first user, validated on an AMDI0070 platform.
The short answer
Krishnamoorthi M of AMD posted a patch series on August 4 proposing a dedicated eSPI subsystem for the Linux kernel. Rather than extending the existing SPI code, eSPI becomes its own bus type, with a new AMD eSPI driver as the first user. The series was validated on an AMDI0070 platform. Known limitations are listed up front: ACPI only enumeration, manual registration of slave devices, and further operations left to follow up patches.
There is a layer of your computer that Linux has never really had an opinion about. It sits under the operating system, connects the chipset to the embedded controller and the firmware flash, and until now the kernel's answer to what lives there has essentially been: the firmware's business, not ours.
On August 4, AMD's Krishnamoorthi M posted a patch series that proposes changing that. The series introduces an eSPI subsystem for the Linux kernel, and the reason it is worth reading is the architectural choice behind it rather than the driver that ships with it.
What eSPI actually is
Enhanced Serial Peripheral Interface was designed by Intel as a successor to LPC, the Low Pin Count bus, which itself replaced ISA for the slow but essential parts of a PC. It is how the chipset reaches the embedded controller, the Super I/O, the TPM and the firmware flash.
The word "enhanced" is doing real work. Ordinary SPI moves bytes between a controller and a peripheral. eSPI multiplexes several logically distinct channels over the same physical wires: peripheral traffic, virtual wire signalling that replaces individual physical pins for events like sleep state transitions and interrupts, out of band messaging, and flash access. That is a protocol, not a transfer mechanism.
The question AMD asked before writing the code
Krishnamoorthi M had earlier raised the question directly on the kernel mailing list: should AMD's eSPI work extend the existing SPI subsystem, or should eSPI be introduced as a bus type of its own?
That question is not bureaucratic. In Linux, a bus type determines how devices are discovered, how drivers are matched, what the probe and remove paths look like and how the whole thing appears in sysfs. Choosing to reuse SPI would have meant describing a multi channel protocol through an abstraction designed for something simpler. It is the kind of decision that looks harmless in the first patch and expensive three years later, when every new capability needs a carve out.
This series answers the question the other way. eSPI becomes its own bus, and the AMD eSPI driver becomes its first user rather than its only reason for existing.
What is in it, and what is not
The code has been tested and validated on an AMDI0070 platform, which is the ACPI identifier for the eSPI controller AMD is targeting.
The limitations are stated openly in the posting, which is worth noting because a first subsystem submission that hides its gaps tends to get a rougher reception than one that lists them. Enumeration is ACPI only, so there is no Device Tree binding yet. Slave devices are registered manually rather than discovered. Additional operations are explicitly deferred to follow up patches.
None of that is unusual for an initial proposal. It does mean this is a request for architectural agreement more than a finished feature, and the review cycle for a new bus type is measured in months.
Why a sysadmin should care about a bus they cannot see
The honest short answer is that nothing on your machine changes today. The longer answer is about visibility.
The components on the other end of this bus are the ones that decide whether a server powers on, how its thermal behaviour is managed, what the TPM reports and how firmware gets written. On most hardware, all of that is opaque from the operating system. When something goes wrong at that level, the diagnostic path today is vendor tooling, a BMC if you have one, and guesswork.
A kernel subsystem does not automatically make any of that legible. What it does is create a place where it could become legible: a defined structure for drivers, a predictable sysfs layout, and a way for future work to expose the state of these devices without every vendor inventing its own path. That is a slow benefit, and it is the same shape as the benefit the kernel eventually got from having proper subsystems for hwmon, for thermal management, and for firmware updates.
We are not going to pretend this is exciting news for a Tuesday. It is a structural decision made carefully, by an engineer who asked where the code belonged before writing more of it, in an area of the machine that most of us only think about when it fails. Those are usually the patches worth noticing.
Sources and further reading
- AMD posts proposal and Linux patches for eSPI subsystem, Phoronix, August 4, 2026
- The patch series on the Linux kernel mailing list
- Earlier AMD eSPI driver patch adding a set channel ioctl
- Linux device model and bus types documentation
Frequently asked questions
What is eSPI and where is it in my machine?
Enhanced Serial Peripheral Interface is the bus that connects a modern x86 chipset to the low level components that make a PC a PC: the embedded controller, the Super I/O, the TPM, the firmware flash. Intel designed it as a replacement for LPC, the Low Pin Count bus, which itself replaced ISA. You will not see it in lsblk or ip link because it is below the level Linux usually exposes. It carries several logical channels over the same physical wires, including peripheral traffic, virtual wire signalling that replaces dedicated pins for things like sleep state transitions, out of band messaging, and flash access. If you have ever wondered how the OS learns that a laptop lid closed, this class of plumbing is the answer.
Why does making it a separate bus type matter?
Because a Linux bus type is not a formality. It defines how devices on that bus are discovered, how drivers get matched to them, what a driver's probe and remove functions look like, and what the sysfs tree shows. Bolting eSPI onto the SPI subsystem would have meant expressing a multi channel protocol with virtual wires and out of band messaging through an abstraction built for plain serial peripheral transfers. It usually works for a while, then every new feature needs a special case. Krishnamoorthi M asked the question explicitly on the mailing list before writing this, which is the right order to do it in.
Does this affect the machine on my desk today?
No. This is a patch series posted for review, not something in a released kernel, and the first user is an AMD controller identified as AMDI0070. Nothing about your current firmware update path, your TPM or your embedded controller changes because of it. What it may change over the next few kernel cycles is how much of that layer is legible from Linux at all. Right now, on most machines, eSPI traffic is entirely the firmware's business and the operating system has no view into it.
What are the known gaps in the proposal?
AMD listed them, which is a good sign about the seriousness of the submission. Enumeration is ACPI only, so there is no Device Tree support yet, which matters for anyone hoping to use this outside the x86 firmware world. Slave devices have to be registered manually rather than discovered. Several operations are deferred to follow up patches. And the validation reported is on a single platform. None of that is unusual for a first posting of a new subsystem, but it does tell you how far this is from being something you can build on.
Is this the first time AMD has tried to upstream eSPI support?
No, and the history is part of why the bus type question came up. Earlier AMD eSPI driver work went to the mailing list under the SPI subsystem, including patches adding an eSPI set channel ioctl, and that placement drew questions. The current series is the result of stepping back and asking where this code belongs before adding more of it. That is a slower path than continuing to extend what already exists, and in kernel terms it is usually the one that survives review.