SysadminNews

AMD’s eSPI RFC: four channels, one shared link

On this page
  1. What the first series implements
  2. Read the diagram as layers, not four completed drivers
  3. What to ask a board vendor

A new bus abstraction is useful only if its implemented operations are clear. AMD’s eSPI proposal establishes the link layer; it does not yet expose every peripheral function.

Layer diagram of the eSPI RFC: configuration and reset establish the shared link; peripheral, virtual-wire, OOB and flash channel operations remain deferred in the initial series. Logical channels do not imply four independent physical links.
Layer diagram of the eSPI RFC: configuration and reset establish the shared link; peripheral, virtual-wire, OOB and flash channel operations remain deferred in the initial series. Logical channels do not imply four independent physical links. Chart : PeopleAreGeek. Data source.
View full-size image

What the first series implements

AMD’s August 4 RFC proposes a dedicated Linux eSPI bus. It reports validation on the AMDI0070 controller for capability discovery, configuration and reset. Device enumeration is manual; the controller uses ACPI. Channel operations and the alert/interrupt path are deferred. Four logical channels share a physical link, with serialized downstream operations in this design.

In review discussion, Andrew Jeffery connects AMD’s controller work to ASPEED’s device-side effort and discusses using existing GPIO, MCTP and MTD interfaces where appropriate. That is a direction for integration, not evidence that this RFC already supplies them.

Read the diagram as layers, not four completed drivers

The illustration separates negotiated transport from services carried over it. This distinction provides a useful way to read hardware support announcements: a successful link negotiation demonstrates that two endpoints agree on how to communicate. It does not demonstrate that an operating system can perform every transaction the protocol defines.

For example, a flash-access channel in a specification is insufficient to conclude that a board’s firmware can now be updated from Linux. That conclusion also needs an implemented operation, a supported device and an appropriate update path. Likewise, exposing negotiated link settings does not by itself provide temperature readings or a history of power-management events.

What to ask a board vendor

Request the controller identifier, the kernel patch revision and the exact operation being demonstrated. A result saying “configuration register read succeeds” answers a narrower question than “flash update succeeds and recovers from interruption.” Keep these outcomes separate in a support matrix.

For integration work, distinguish the host controller from the target device. A driver written for one side is not interchangeable with the other simply because both use eSPI. The useful next milestone is working channel support with identified devices and reproducible tests, rather than the existence of a new directory in the kernel tree.

September 8: separate implemented link setup from deferred channel and interrupt operations; include the ASPEED discussion and remove unsupported visibility promises.