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.

Patch summary:
1. dt-bindings: soc: aspeed: Add AST2600 eSPI controller
2. soc: aspeed: Introduce core eSPI controller support
3. soc: aspeed: Add AST2600 peripheral channel port I/O support
4. soc: aspeed: Add eSPI TAFS backend support
5. soc: aspeed: Add espi flash channel support
6. soc: aspeed: Add sysfs controls for flash LUN selection
7. arm: dts: aspeed: Add eSPI node for AST2600

This series has been tested on AST2600 platform with Intel's host eSPI
controller.

Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
---
aspeedyh (7):
      dt-bindings: soc: aspeed: Add AST2600 eSPI controller
      soc: aspeed: Introduce core eSPI controller support
      soc: aspeed: Add AST2600 peripheral channel port I/O support
      soc: aspeed: Add eSPI TAFS backend support
      soc: aspeed: Add eSPI flash channel support
      soc: aspeed: Add sysfs controls for flash backend selection
      arm: dts: aspeed: Add eSPI node for AST2600

 .../bindings/soc/aspeed/aspeed,ast2600-espi.yaml   |  74 +++
 arch/arm/boot/dts/aspeed/aspeed-g6.dtsi            |  11 +
 drivers/soc/aspeed/Kconfig                         |   7 +
 drivers/soc/aspeed/Makefile                        |   1 +
 drivers/soc/aspeed/espi/Makefile                   |   1 +
 drivers/soc/aspeed/espi/aspeed-espi-comm.h         |  62 +++
 drivers/soc/aspeed/espi/aspeed-espi.c              | 618 +++++++++++++++++++++
 drivers/soc/aspeed/espi/aspeed-espi.h              |  63 +++
 drivers/soc/aspeed/espi/ast2600-espi.c             | 304 ++++++++++
 drivers/soc/aspeed/espi/ast2600-espi.h             | 302 ++++++++++
 drivers/soc/aspeed/espi/espi_storage.c             | 322 +++++++++++
 drivers/soc/aspeed/espi/espi_storage.h             |  32 ++
 12 files changed, 1797 insertions(+)
---
base-commit: 0257f64bdac7fdca30fa3cae0df8b9ecbec7733a
change-id: 20260313-upstream_espi-d9fea66d1772

Best regards,
-- 
aspeedyh <yh_chung@aspeedtech.com>

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? FSL's appears to be there.
Mark?

> 
> Patch summary:
> 1. dt-bindings: soc: aspeed: Add AST2600 eSPI controller
> 2. soc: aspeed: Introduce core eSPI controller support
> 3. soc: aspeed: Add AST2600 peripheral channel port I/O support
> 4. soc: aspeed: Add eSPI TAFS backend support
> 5. soc: aspeed: Add espi flash channel support
> 6. soc: aspeed: Add sysfs controls for flash LUN selection
> 7. arm: dts: aspeed: Add eSPI node for AST2600
> 
> This series has been tested on AST2600 platform with Intel's host eSPI
> controller.
> 
> Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>

Unless you're an fanatical employee of Aspeed, I doubt that this signoff
reflects your actual name!

> ---
> aspeedyh (7):
>       dt-bindings: soc: aspeed: Add AST2600 eSPI controller
>       soc: aspeed: Introduce core eSPI controller support
>       soc: aspeed: Add AST2600 peripheral channel port I/O support
>       soc: aspeed: Add eSPI TAFS backend support
>       soc: aspeed: Add eSPI flash channel support
>       soc: aspeed: Add sysfs controls for flash backend selection
>       arm: dts: aspeed: Add eSPI node for AST2600
> 
>  .../bindings/soc/aspeed/aspeed,ast2600-espi.yaml   |  74 +++
>  arch/arm/boot/dts/aspeed/aspeed-g6.dtsi            |  11 +
>  drivers/soc/aspeed/Kconfig                         |   7 +
>  drivers/soc/aspeed/Makefile                        |   1 +
>  drivers/soc/aspeed/espi/Makefile                   |   1 +
>  drivers/soc/aspeed/espi/aspeed-espi-comm.h         |  62 +++
>  drivers/soc/aspeed/espi/aspeed-espi.c              | 618 +++++++++++++++++++++
>  drivers/soc/aspeed/espi/aspeed-espi.h              |  63 +++
>  drivers/soc/aspeed/espi/ast2600-espi.c             | 304 ++++++++++
>  drivers/soc/aspeed/espi/ast2600-espi.h             | 302 ++++++++++
>  drivers/soc/aspeed/espi/espi_storage.c             | 322 +++++++++++
>  drivers/soc/aspeed/espi/espi_storage.h             |  32 ++
>  12 files changed, 1797 insertions(+)
> ---
> base-commit: 0257f64bdac7fdca30fa3cae0df8b9ecbec7733a
> change-id: 20260313-upstream_espi-d9fea66d1772
> 
> Best regards,
> -- 
> aspeedyh <yh_chung@aspeedtech.com>
> 

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.

> FSL's appears to be there.

I think this is just a similarly named device: Freescale/NXP's eSPI
device driver is unrelated to the Intel eSPI spec but rather implements
a normal SPI driver the same way that eDMA and eSDHC are Freescale's
implementation of dmaengine and SDHCI drivers.

    Arnd

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@gmail.com/
- https://lore.kernel.org/openbmc/20220516005412.4844-1-chiawei_wang@aspeedtech.com/

Previously, Jeremy had some suggestions covering the various channels:

https://lore.kernel.org/linux-aspeed/20c13b9bb023091758cac3a07fb4037b7d796578.camel@codeconstruct.com.au/

Andrew

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.

Arnd, that's would be nice if it would be standard SPI device. But what
if eSPI would be a bus? So, I assume all other which lying underneath 
eSPI would be much easier to implement as standard driver data set
SPI/GPIO/I2C with something like devm_regmap_init_espi(like for i2c/spi
or anything else) for example as common part for these drivers.

Thanks.

On Fri, Mar 13, 2026 at 10:36:02PM +0100, Arnd Bergmann wrote:
> On Fri, Mar 13, 2026, at 17:24, Conor Dooley wrote:

> > FSL's appears to be there.

> I think this is just a similarly named device: Freescale/NXP's eSPI
> device driver is unrelated to the Intel eSPI spec but rather implements
> a normal SPI driver the same way that eDMA and eSDHC are Freescale's
> implementation of dmaengine and SDHCI drivers.

Yeah, SPI with a random letter or string in front of it is usually just
someone made a new controller for some reason (often a new feature, like
all the QuadSPI devices) and wants to differentiate it from their old
ones or connect it to other branding.

On Fri, Mar 13, 2026 at 04:24:22PM +0000, 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? FSL's appears to be there.
> Mark?

As documented in submitting-patches.rst please send patches to the 
maintainers for the code you would like to change.  The normal kernel
workflow is that people apply patches from their inboxes, if they aren't
copied they are likely to not see the patch at all and it is much more
difficult to apply patches.

Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.

On Fri, Mar 13, 2026 at 04:32:31PM +0000, Mark Brown wrote:
> On Fri, Mar 13, 2026 at 04:24:22PM +0000, 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? FSL's appears to be there.
> > Mark?
> 
> As documented in submitting-patches.rst please send patches to the 
> maintainers for the code you would like to change.  The normal kernel
> workflow is that people apply patches from their inboxes, if they aren't
> copied they are likely to not see the patch at all and it is much more
> difficult to apply patches.
> 
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.

If this is a driver for SPI hardware it should be under drivers/spi and
use the framework there.