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

["Arnd Bergmann" <arnd@arndb.de>]

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.

From reading the old comments that Andrew linked to at

https://lore.kernel.org/linux-aspeed/HK0PR06MB377924CFCBFE9BD40E1C4A5D91D49@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?

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.

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.

One option here would be to sidestep this problem entirely by
moving all of the eSPI implementation out of the kernel but instead
have a hardware-independent userspace implementation that uses
the spidev ioctl interface. This is always going to be slower than
an in-kernel implementation, but also much easier to implement
and debug.

An in-kernel implementation of the eSPI backend (on top of
the SPI layer) is certainly a realistic option for the higher
layers, but requires finding consensus both on the the logistics
(subsystem, code ownership, interfaces to other subsystems)
and more importantly the user space interfaces that look like
they will require several revisions on top of what you have
today.

      Arnd