RE: [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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> 
> 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)

>From the link thread, what Jeremy mentioned is the GPIO HW/SW mode for CH1,
which determines whether the host can directly control the corresponding BMC
GPIO output, or whether BMC software can inspect and decide whether to act on
that request.

Another example is the Target Attached Flash Sharing (TAFS) defined by the
eSPI specification that allows BMC to share its storage with the host.

In hardware mode, the eSPI Target Device controller routes the request
directly to a predefined storage controller on AST2600.
In software mode, it raises an interrupt and lets software handle the
transaction instead.

So I would not describe the AST2600 eSPI block as being globally in either
"hardware mode" or "software mode".
That choice is made per backend function, and some backend functions do not
implement such a switch at all.

So far, this series only covers the LPC bridge and flash channel parts.

> For the higher-level interfaces (flash, gpio, ...), I don't think
> there is any consensus yet about how this should be done, but again
> I think this won't be drivers/soc but instead something more
> generic.

For the flash-related interface, would it make sense to follow the
configuration model used by the USB gadget mass-storage function, and expose
the backing storage selection through configfs? 

For the attributes, perhaps the only backing storage object and read-only
flag would be required in our case.

For the Virtual Wire GPIO, we think GPIO subsystem may be leveraged here,
though some corner cases may not map cleanly to a typical GPIO controller
model.

For the Out-of-band channel, since the eSPI spec models it for tunneled SMBus
packets, we may want to integrate it with the kernel's MCTP stack if that is
a suitable fit.

Thanks,
Yun Hsuan