[PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support

[YH Chung]

Hi Arnd,

> On Tue, Mar 17, 2026, at 09:14, YH Chung wrote:
> >
> > In the meantime, my understanding is that this driver is for the Intel
> > eSPI interface used by the AST2600 BMC,
> > rather than fitting a conventional SPI controller/device model. That
> > was the reason for initially placing it under
> > drivers/soc/aspeed/, since there does not appear to be an in-tree eSPI
> > subsystem at present.
> > However, if that is not the preferred upstream direction, we are happy
> > to restructure the series accordingly.
> > It would be very helpful if you could advise on the preferred placement.
> 
> I think we need to make sure everyone understands what the options are
> here based on what the hardware can do, and what your use cases require.
> 
For reference, Intel's eSPI base specification is defined here:
https://www.intel.com/content/www/us/en/content-details/841685/enhanced-serial-peripheral-interface-espi-interface-base-specification-for-client-and-server-platforms.html

Although eSPI physically reuses some SPI pins, it is not used as a
conventional SPI controller/device interface. It also adds RESET# and ALERT#
beyond the usual SPI signals.

The spec also defines two roles in eSPI transaction model: Controller and
Target Device. ASPEED SoCs act as the Target Device side to interact with the
host. In this case, the hardware is not exposed in a form that maps naturally
onto the existing SPI subsystem model.

> If I understood this correctly, I think there is a general agreement
> upstream that the low-level device access should indeed be in a
> drivers/spi driver, with no ports of it in drivers/soc/aspeed. Using
> a portable driver subsystem is always better than a custom solution
> if it works at all.

We understand the preference for using a generic subsystem where possible.
Our hesitation is that the eSPI functionality appears to software primarily
in terms of the eSPI Peripherals, Virtual Wires, OOB (SMBus), and Flash
channel semantics and backend routing, rather than low-level bus signaling.

Since this driver is responsible for configuring those Aspeed-specific
backend interfaces so they can service host requests, we initially placed it
under drivers/soc/aspeed.

> From reading the old comments that Andrew linked to at
> 
> https://lore.kernel.org/linux-aspeed/HK0PR06MB377924CFCBFE9BD40E1C4A5D91
> D49 at HK0PR06MB3779.apcprd06.prod.outlook.com/
> 
> I understand that the SoC has a "hardware mode" in which eSPI is
> directly implemented by redirecting upper-level eSPI transactions into
> functional blocks of the chip, while the software mode behaves like
> a regular SPI endpoint controller and your driver implements the
> same interfaces in a mix of kernel and userspace components. Can you
> confirm that this is a correct understanding of what the hardware
> does, or where I misunderstand parts?

Broadly yes, except that the AST2600 does not operate in a single global
"hardware mode" or "software mode". Instead, some backends in the eSPI target
controller support per-function HW/SW mode selection.

Depending on that function-specific setting, the controller either forwards a
received transaction directly to the corresponding hardware block or traps it
for software handling instead.

This mechanism exists because some backend blocks include their own hardware
filtering, but not all request types could be validated generically in
hardware. For example, the LPC bridge can reject illegal requests. In some
cases, blindly forwarding host requests to the target block would also have
security implications.

The channel/backend mapping on AST2600 can be summarized as:

eSPI
├── Peripheral
│ ├── Memory (HW mode only)
│ └── LPC bridge (HW mode only)
├── Virtual Wire
│ └── GPIO (HW/SW mode selection)
├── Out-of-Band (SW mode only)
└── Flash
   └── Storage controller (HW/SW mode selection)