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

[YH Chung]

> On Fri, 2026-03-13 at 22:36 +0100, Arnd Bergmann wrote:
> > On Fri, Mar 13, 2026, at 17:24, Conor Dooley wrote:
> > > On Fri, Mar 13, 2026 at 06:07:35PM +0800, aspeedyh wrote:
> > > > This series adds initial support for the eSPI controller found on ASPEED
> > > > AST2600 BMC SoCs.
> > > >
> > > > The series introduces a eSPI controller framework for ASPEED SoCs under
> > > > drivers/soc/aspeed/, adds AST2600-specific controller support for
> > > > peripheral and flash channels, defines the corresponding devicetree
> > > > binding, and adds the AST2600 eSPI controller node to the SoC dtsi.
> > > >
> > > > The driver is intended to support host-BMC communication over the
> BMC-side
> > > > eSPI slave controller present on AST2600 systems.
> > >
> > > This all seems to be in the wrong places entirely, shouldn't an eSPI
> > > driver and bindings go in the spi subsystem?
> >
> > From an initial reading, my impression is that patches 1, 2, 3 and 7
> > should be modified to use the normal SPI interfaces to implement
> > an spi target driver, possibly a combined host/target driver.
> > Reworking this should be fairly straightforward because the interfaces
> > to the SPI core are well documented.
> >
> > It is possible that the hardware can only be used to provide espi
> > device emulation. From what I could see in the code, there is
> > not much special in there, but I'm not that familiar with SPI
> >
> > Patches 4, 5 and 6 in consequently would need to be reworked so
> > these can implement the TAFS spec independent of the SPI controller,
> > and can be shared e.g. with other OpenBMC targets using the same
> > module and the same user interface. None of this should be aspeed
> > specific.
> >
> > There is a good chance that both the user interface and the placing
> > of the code will need a more debate, but I would suggest first trying
> > to move everything over to use the SPI subsystem but leave other
> > parts untouched for the moment.
> 
> To extend Arnd's points here, some previous attempts were made to
> support Intel's eSPI protocol on Aspeed's SoCs which aren't discussed
> in this cover letter. I think it would be helpful to cover the history
> and why we now have a third approach:
> 
> -
> https://lore.kernel.org/linux-aspeed/20240319093405.39833-1-manojkiran.eda@g
> mail.com/
> -
> https://lore.kernel.org/openbmc/20220516005412.4844-1-chiawei_wang@aspeedt
> ech.com/
> 
> Previously, Jeremy had some suggestions covering the various channels:
> 
> https://lore.kernel.org/linux-aspeed/20c13b9bb023091758cac3a07fb4037b7d7965
> 78.camel at codeconstruct.com.au/
> 
> Andrew

Hi Andrew, Ivan, Arnd,

Thanks for the additional context and the review links. It was my mistake not to reference the previous
discussions in the cover letter.

This series is intended to support the Intel eSPI interface on AST2600, specifically the parts corresponding
to LPC-style accesses and Target Flash Access Sharing (TAFS), which are defined in the peripheral and flash
channels of the eSPI specification.

Because the earlier OpenBMC work from Chia-Wei dates back to 2021, and because the code structure and
overall approach in this series differs substantially from that earlier work, I chose to post this as a new series
rather than as a revision of the earlier one.

I agree that the cover letter should explain this history more clearly, including the definition of eSPI, how this 
series differs from the previous attempts and how it relates to the earlier feedback on the channel split.
I will revise the cover letter accordingly in the next version.

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.

Thanks,
Yun Hsuan