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

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@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)

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

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

[Arnd Bergmann]

On Wed, Mar 25, 2026, at 09:41, YH Chung wrote:
>> On Tue, Mar 17, 2026, at 09:14, YH Chung wrote:
>> From reading the old comments that Andrew linked to at
>> 
>> https://lore.kernel.org/linux-aspeed/HK0PR06MB377924CFCBFE9BD40E1C4A5D91
>> D49@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)
>
> 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.

I see, thanks for the detailed explanation! Two follow-up questions:

- For the HW-mode-only peripherals (memory, LPC), is there any
  driver interaction at all for setting it up, or is this completely
  transparent to Linux running on the BMC?

- For the other devices running in SW mode, is the interface that the
  driver sees abstract in the sense that the same low-level code
  is shared for all of them, or are these still separate functional
  blocks that each need their own register-level interface?

>> 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.

These all seem to be viable options, but I still think we should
focus on agreeing on a design for the low-level hardware interface
and whether this can or should be abstracted between SoC vendor
specific drivers before trying to solve the user interface side.

      Arnd

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

[YH Chung]

Hi Arnd,

> - For the HW-mode-only peripherals (memory, LPC), is there any
>   driver interaction at all for setting it up, or is this completely
>   transparent to Linux running on the BMC?

For LPC-style IO accesses like Post Code Capture (PCC), the accesses are
completely transparent to Linux.

For memory accesses, they are also transparent to Linux on the BMC. It just
requires configuring the translation from the bus address to a reserved
memory region on the BMC during driver probe.


> - For the other devices running in SW mode, is the interface that the
>   driver sees abstract in the sense that the same low-level code
>   is shared for all of them, or are these still separate functional
>   blocks that each need their own register-level interface?

The channels are distinct functional blocks within the eSPI controller, each
using its own channel-specific registers regardless of whether they operate
in HW or SW mode. There is no common message flow or registers for the
software modes. The eSPI controller dispatches eSPI messages to the relevant
channel's hardware function block, which then takes action according to its
mode configuration.

Some low-level framework code may be shareable, for example a unified ISR
entry that checks interrupt status register and routes to channel-specific
handlers, but the corresponding handling will be channel-specific.

Thanks,
Yun Hsuan

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

[YH Chung]

Hi Arnd,

Thanks for the comments and questions.

> These all seem to be viable options, but I still think we should focus on
> agreeing on a design for the low-level hardware interface and whether this
> can or should be abstracted between SoC vendor specific drivers before
> trying to solve the user interface side.
 
Could you share your thoughts on whether it would make sense to accept our
eSPI driver as is, and whether it should live under the SoC vendor-specific
directories? Any comment would be greatly appreciated.

Thanks,
YunHsuan

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

[Shulzhenko, Oleksandr]

On 4/7/2026 11:36 AM, YH Chung wrote:
> Hi Arnd,
>
> Thanks for the comments and questions.
>
>> These all seem to be viable options, but I still think we should focus on
>> agreeing on a design for the low-level hardware interface and whether this
>> can or should be abstracted between SoC vendor specific drivers before
>> trying to solve the user interface side.
>   
> Could you share your thoughts on whether it would make sense to accept our
> eSPI driver as is, and whether it should live under the SoC vendor-specific
> directories? Any comment would be greatly appreciated.
>
> Thanks,
> YunHsuan

Hi YunHsuan,

Let me add my 5 cents on this matter.

Integrating this driver into the SPI subsystem may allow reusing some 
existing definitions, e.g.|spi_controller|,|spi_message|, and perhaps 
parts related to single/dual/quad I/O handling. At the same time, parts 
such as the Flash channel (included in the current series), and OOB / 
Virtual Wire support (I would expect to come later), appear to be 
specific to the Intel eSPI protocol. Modeling all of that as just 
another SPI IP driver may introduce some awkward layering and overhead.

Also, the current series already seems to separate common eSPI logic 
from AST2600-specific pieces, assuming that 2700 driver is also coming 
at some point.

This makes me wonder whether a dedicated eSPI layer/subsystem could be a 
better fit — either under the SPI or as something separate (but not SoC 
driver).

Given my limited experience with SPI/eSPI, could you help clarify a few 
points for me (and probably others as well)?

  * How much of the SPI subsystem can be reused for this implementation,
    both for the current patchset and for likely future extensions?
  * Are there any pitfalls or abstraction mismatches in trying to reuse
    the SPI core here?

I think this would help make the subsystem placement discussion much 
clearer.

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

[YH Chung]

Hi Shulzhenko, 

Thanks for the follow-up. 

> Integrating this driver into the SPI subsystem may allow reusing some existing 
> definitions, e.g.|spi_controller|,|spi_message|, and perhaps parts related to 
> single/dual/quad I/O handling. At the same time, parts such as the Flash channel 
> (included in the current series), and OOB / Virtual Wire support (I would expect 
> to come later), appear to be specific to the Intel eSPI protocol. Modeling all of 
> that as just another SPI IP driver may introduce some awkward layering and 
> overhead. 

Agreed. eSPI introduces two additional pins, RESET# and ALERT#, beyond the
standard SPI signals. More importantly, eSPI functionality is described
primarily in terms of four logical channels, rather than generic low-level
bus signaling or pure data transfers.

> Also, the current series already seems to separate common eSPI logic from 
> AST2600-specific pieces, assuming that 2700 driver is also coming at some point. 
>
> This makes me wonder whether a dedicated eSPI layer/subsystem could be a 
> better fit — either under the SPI or as something separate (but not SoC driver). 
>
> Given my limited experience with SPI/eSPI, could you help clarify a few points for 
> me (and probably others as well)? 
> 
> * How much of the SPI subsystem can be reused for this implementation, 
> both for the current patchset and for likely future extensions? 

I believe only a limited portion of the SPI subsystem can be reused. Some
generic framework elements, such as controller registration and basic
scaffolding, may be useful initially. But this reuse appears to be mostly
mechanical rather than semantic. Once eSPI-specific features like Flash
channels, OOB messaging, and Virtual Wire semantics are involved, the SPI
transaction model does not seem to map very naturally. 

> * Are there any pitfalls or abstraction mismatches in trying to reuse 
> the SPI core here? 

Our main concern is an abstraction mismatch. SPI is designed as a generic
peripheral bus, while eSPI is more of a system-management interface with
explicit host-BMC-specific semantics. Reusing the SPI core would likely
require treating eSPI packets as generic bus-level transfers in the kernel.

However, some eSPI transactions and protocol handling, such as LPC bridge
accesses, are performed autonomously by the hardware rather than being fully
driven as low-level bus operations by the driver. This makes the eSPI driver
somewhat different from a conventional serial bus controller driver
maintained under the SPI core.

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

[Shulzhenko, Oleksandr]

On 5/12/2026 9:08 AM, YH Chung wrote:
> Hi Shulzhenko,
>
> Thanks for the follow-up.
>
>> Integrating this driver into the SPI subsystem may allow reusing some existing
>> definitions, e.g.|spi_controller|,|spi_message|, and perhaps parts related to
>> single/dual/quad I/O handling. At the same time, parts such as the Flash channel
>> (included in the current series), and OOB / Virtual Wire support (I would expect
>> to come later), appear to be specific to the Intel eSPI protocol. Modeling all of
>> that as just another SPI IP driver may introduce some awkward layering and
>> overhead.
> Agreed. eSPI introduces two additional pins, RESET# and ALERT#, beyond the
> standard SPI signals. More importantly, eSPI functionality is described
> primarily in terms of four logical channels, rather than generic low-level
> bus signaling or pure data transfers.
>
>> Also, the current series already seems to separate common eSPI logic from
>> AST2600-specific pieces, assuming that 2700 driver is also coming at some point.
>>
>> This makes me wonder whether a dedicated eSPI layer/subsystem could be a
>> better fit — either under the SPI or as something separate (but not SoC driver).
>>
>> Given my limited experience with SPI/eSPI, could you help clarify a few points for
>> me (and probably others as well)?
>>
>> * How much of the SPI subsystem can be reused for this implementation,
>> both for the current patchset and for likely future extensions?
> I believe only a limited portion of the SPI subsystem can be reused. Some
> generic framework elements, such as controller registration and basic
> scaffolding, may be useful initially. But this reuse appears to be mostly
> mechanical rather than semantic. Once eSPI-specific features like Flash
> channels, OOB messaging, and Virtual Wire semantics are involved, the SPI
> transaction model does not seem to map very naturally.
>
>> * Are there any pitfalls or abstraction mismatches in trying to reuse
>> the SPI core here?
> Our main concern is an abstraction mismatch. SPI is designed as a generic
> peripheral bus, while eSPI is more of a system-management interface with
> explicit host-BMC-specific semantics. Reusing the SPI core would likely
> require treating eSPI packets as generic bus-level transfers in the kernel.
>
> However, some eSPI transactions and protocol handling, such as LPC bridge
> accesses, are performed autonomously by the hardware rather than being fully
> driven as low-level bus operations by the driver. This makes the eSPI driver
> somewhat different from a conventional serial bus controller driver
> maintained under the SPI core.
>
Hi YH,

My main concern is trying to understand whether it is completely 
impossible (or introduces too much effort that we'd better not to take) 
integrating this to SPI subsystem.

 From your reply I understand there are two potential blockers:

a) Treating eSPI transfers as bus-level transfers (meaning that it will 
be necessary probably making separate driver for OOB/VW/Flash channels 
as they essentially use eSPI as a transport);

b) Some logic being done by the hardware (i.e. LPC bridge).

Please confirm my understanding:

(a) is feasible, but requires many effort to re-define architecture

(b) If something is done by the hardware - what is the driver impact? I 
recall eDAF use case when the driver wasn't involved at all - and flash 
access was fully done by the hardware (unless the controller is 
configured to handle it in SW mode).


P.S. I guess we can talk about host-BMC communication only when talking 
about hardware-dependent stuff (i.e. ast2600-espi files). eSPI core 
should be (it seems to be already is) at least BMC agnostic and this is 
the reason not having it under SOC/aspeed (ast2600-espi.* may stay here 
though).

Re: [PATCH 3/7] soc: aspeed: Add AST2600 peripheral channel port I/O support

[Shulzhenko, Oleksandr]

On 3/13/2026 11:07 AM, aspeedyh wrote:
> Add initial support for the AST2600 eSPI peripheral channel handling of
> port I/O transactions used for LPC-style accesses.
>
> This patch does not yet implement peripheral memory read or write
> cycles. Support for those transactions will be added in a follow-up
> patch once the remaining transport and buffer handling pieces are in
> place.
>
> Signed-off-by: aspeedyh <yh_chung@aspeedtech.com>
> ---
>   drivers/soc/aspeed/espi/Makefile       |   2 +-
>   drivers/soc/aspeed/espi/aspeed-espi.c  |  24 +++
>   drivers/soc/aspeed/espi/ast2600-espi.c | 139 ++++++++++++++++
>   drivers/soc/aspeed/espi/ast2600-espi.h | 291 +++++++++++++++++++++++++++++++++
>   4 files changed, 455 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/soc/aspeed/espi/Makefile b/drivers/soc/aspeed/espi/Makefile
> index d96dc030e23b..30f9dbf92a0f 100644
> --- a/drivers/soc/aspeed/espi/Makefile
> +++ b/drivers/soc/aspeed/espi/Makefile
> @@ -1 +1 @@
> -obj-y += aspeed-espi.o
> +obj-y += aspeed-espi.o ast2600-espi.o
> diff --git a/drivers/soc/aspeed/espi/aspeed-espi.c b/drivers/soc/aspeed/espi/aspeed-espi.c
> index 15d58b38bbe4..e369738119bc 100644
> --- a/drivers/soc/aspeed/espi/aspeed-espi.c
> +++ b/drivers/soc/aspeed/espi/aspeed-espi.c
> @@ -13,15 +13,28 @@
>   #include <linux/reset.h>
>   
>   #include "aspeed-espi.h"
> +#include "ast2600-espi.h"
>   
>   struct aspeed_espi_ops {
>   	void (*espi_pre_init)(struct aspeed_espi *espi);
>   	void (*espi_post_init)(struct aspeed_espi *espi);
>   	void (*espi_deinit)(struct aspeed_espi *espi);
> +	int (*espi_perif_probe)(struct aspeed_espi *espi);
> +	int (*espi_perif_remove)(struct aspeed_espi *espi);
Should it be int? I don't see any error condition returned
>   	irqreturn_t (*espi_isr)(int irq, void *espi);
>   };
>   
> +static const struct aspeed_espi_ops aspeed_espi_ast2600_ops = {
> +	.espi_pre_init = ast2600_espi_pre_init,
> +	.espi_post_init = ast2600_espi_post_init,
> +	.espi_deinit = ast2600_espi_deinit,
> +	.espi_perif_probe = ast2600_espi_perif_probe,
> +	.espi_perif_remove = ast2600_espi_perif_remove,
> +	.espi_isr = ast2600_espi_isr,
> +};
> +
>   static const struct of_device_id aspeed_espi_of_matches[] = {
> +	{ .compatible = "aspeed,ast2600-espi", .data = &aspeed_espi_ast2600_ops },
>   	{ }
>   };
>   MODULE_DEVICE_TABLE(of, aspeed_espi_of_matches);
> @@ -88,6 +101,14 @@ static int aspeed_espi_probe(struct platform_device *pdev)
>   	if (espi->ops->espi_pre_init)
>   		espi->ops->espi_pre_init(espi);
>   
> +	if (espi->ops->espi_perif_probe) {
> +		rc = espi->ops->espi_perif_probe(espi);
> +		if (rc) {
> +			dev_err(dev, "cannot init peripheral channel, rc=%d\n", rc);
> +			goto err_deinit;
> +		}
> +	}
> +
>   	rc = devm_request_irq(dev, espi->irq, espi->ops->espi_isr, 0,
>   			      dev_name(dev), espi);
>   	if (rc) {
> @@ -121,6 +142,9 @@ static void aspeed_espi_remove(struct platform_device *pdev)
>   	if (!espi)
>   		return;
>   
> +	if (espi->ops->espi_perif_remove)
> +		espi->ops->espi_perif_remove(espi);
> +
>   	if (espi->ops->espi_deinit)
>   		espi->ops->espi_deinit(espi);
>   
> diff --git a/drivers/soc/aspeed/espi/ast2600-espi.c b/drivers/soc/aspeed/espi/ast2600-espi.c
> new file mode 100644
> index 000000000000..8effd0404d1f
> --- /dev/null
> +++ b/drivers/soc/aspeed/espi/ast2600-espi.c
> @@ -0,0 +1,139 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright Aspeed Technology Inc.
> + */
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/reset.h>
> +
> +#include "aspeed-espi.h"
> +#include "ast2600-espi.h"
> +
> +static void ast2600_espi_perif_isr(struct aspeed_espi *espi)
> +{
> +	u32 sts;
> +
> +	sts = readl(espi->regs + ESPI_INT_STS);
> +
> +	if (sts & ESPI_INT_STS_PERIF_PC_RX_CMPLT)
> +		writel(ESPI_INT_STS_PERIF_PC_RX_CMPLT, espi->regs + ESPI_INT_STS);
> +}
> +
> +static void ast2600_espi_perif_sw_reset(struct aspeed_espi *espi)
> +{
> +	u32 reg;
> +
> +	reg = readl(espi->regs + ESPI_CTRL);
> +	reg &= ~(ESPI_CTRL_PERIF_NP_TX_SW_RST
> +		 | ESPI_CTRL_PERIF_NP_RX_SW_RST
> +		 | ESPI_CTRL_PERIF_PC_TX_SW_RST
> +		 | ESPI_CTRL_PERIF_PC_RX_SW_RST
> +		 | ESPI_CTRL_PERIF_NP_TX_DMA_EN
> +		 | ESPI_CTRL_PERIF_PC_TX_DMA_EN
> +		 | ESPI_CTRL_PERIF_PC_RX_DMA_EN
> +		 | ESPI_CTRL_PERIF_SW_RDY);
> +	writel(reg, espi->regs + ESPI_CTRL);
> +
> +	udelay(1);
> +
> +	reg |= (ESPI_CTRL_PERIF_NP_TX_SW_RST
> +		| ESPI_CTRL_PERIF_NP_RX_SW_RST
> +		| ESPI_CTRL_PERIF_PC_TX_SW_RST
> +		| ESPI_CTRL_PERIF_PC_RX_SW_RST);
> +	writel(reg, espi->regs + ESPI_CTRL);
> +}
> +
> +static void ast2600_espi_perif_reset(struct aspeed_espi *espi)
> +{
> +	u32 reg;
> +
> +	writel(ESPI_INT_EN_PERIF, espi->regs + ESPI_INT_EN_CLR);
> +	writel(ESPI_INT_STS_PERIF, espi->regs + ESPI_INT_STS);
> +
> +	writel(0x0, espi->regs + ESPI_MMBI_INT_EN);
> +	writel(0xffffffff, espi->regs + ESPI_MMBI_INT_STS);
> +
> +	reg = readl(espi->regs + ESPI_CTRL2);
> +	reg &= ~(ESPI_CTRL2_MCYC_RD_DIS_WDT | ESPI_CTRL2_MCYC_WR_DIS_WDT);
> +	writel(reg, espi->regs + ESPI_CTRL2);
> +
> +	reg = readl(espi->regs + ESPI_CTRL);
> +	reg &= ~(ESPI_CTRL_PERIF_NP_TX_DMA_EN
> +		 | ESPI_CTRL_PERIF_PC_TX_DMA_EN
> +		 | ESPI_CTRL_PERIF_PC_RX_DMA_EN
> +		 | ESPI_CTRL_PERIF_SW_RDY);
> +	writel(reg, espi->regs + ESPI_CTRL);
> +
> +	reg = readl(espi->regs + ESPI_CTRL) | ESPI_CTRL_PERIF_SW_RDY;
> +	writel(reg, espi->regs + ESPI_CTRL);
> +}
> +
> +int ast2600_espi_perif_probe(struct aspeed_espi *espi)
> +{
> +	ast2600_espi_perif_reset(espi);
> +	return 0;
> +}
> +
> +int ast2600_espi_perif_remove(struct aspeed_espi *espi)
> +{
> +	u32 reg;
> +
> +	writel(ESPI_INT_EN_PERIF, espi->regs + ESPI_INT_EN_CLR);
> +
> +	reg = readl(espi->regs + ESPI_CTRL2);
> +	reg |= (ESPI_CTRL2_MCYC_RD_DIS | ESPI_CTRL2_MCYC_WR_DIS);
> +	writel(reg, espi->regs + ESPI_CTRL2);
> +
> +	reg = readl(espi->regs + ESPI_CTRL);
> +	reg &= ~(ESPI_CTRL_PERIF_NP_TX_DMA_EN
> +		 | ESPI_CTRL_PERIF_PC_TX_DMA_EN
> +		 | ESPI_CTRL_PERIF_PC_RX_DMA_EN
> +		 | ESPI_CTRL_PERIF_SW_RDY);
> +	writel(reg, espi->regs + ESPI_CTRL);
> +	return 0;
> +}
> +
> +/* global control */
> +irqreturn_t ast2600_espi_isr(int irq, void *arg)
> +{
> +	struct aspeed_espi *espi;
> +	u32 sts;
> +
> +	espi = (struct aspeed_espi *)arg;
> +	sts = readl(espi->regs + ESPI_INT_STS);
> +
> +	if (!sts)
> +		return IRQ_NONE;
> +
> +	if (sts & ESPI_INT_STS_PERIF)
> +		ast2600_espi_perif_isr(espi);
> +
> +	if (sts & ESPI_INT_STS_RST_DEASSERT) {
> +		/* this will clear all interrupt enable and status */
> +		reset_control_assert(espi->rst);
> +		reset_control_deassert(espi->rst);
> +
> +		ast2600_espi_perif_sw_reset(espi);
> +		ast2600_espi_perif_reset(espi);
> +
> +		/* re-enable eSPI_RESET# interrupt */
> +		writel(ESPI_INT_EN_RST_DEASSERT, espi->regs + ESPI_INT_EN);
> +	}
> +
> +	return IRQ_HANDLED;
> +}
> +
> +void ast2600_espi_pre_init(struct aspeed_espi *espi)
> +{
> +	writel(ESPI_INT_EN_RST_DEASSERT, espi->regs + ESPI_INT_EN_CLR);
> +}
> +
> +void ast2600_espi_post_init(struct aspeed_espi *espi)
> +{
> +	writel(ESPI_INT_EN_RST_DEASSERT, espi->regs + ESPI_INT_EN);
> +}
> +
> +void ast2600_espi_deinit(struct aspeed_espi *espi)
> +{
> +	writel(ESPI_INT_EN_RST_DEASSERT, espi->regs + ESPI_INT_EN_CLR);
> +}
> diff --git a/drivers/soc/aspeed/espi/ast2600-espi.h b/drivers/soc/aspeed/espi/ast2600-espi.h
> new file mode 100644
> index 000000000000..309479ee1187
> --- /dev/null
> +++ b/drivers/soc/aspeed/espi/ast2600-espi.h
> @@ -0,0 +1,291 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Register definitions for Aspeed AST2600 eSPI controller
> + * Copyright 2026 Aspeed Technology Inc.
> + */
> +#ifndef AST2600_ESPI_H
> +#define AST2600_ESPI_H
> +
> +#include <linux/bits.h>
> +#include <linux/irqreturn.h>
> +#include "aspeed-espi.h"
> +
> +/* registers */
> +#define ESPI_CTRL				0x000
> +#define   ESPI_CTRL_FLASH_TX_SW_RST		BIT(31)
> +#define   ESPI_CTRL_FLASH_RX_SW_RST		BIT(30)
> +#define   ESPI_CTRL_OOB_TX_SW_RST		BIT(29)
> +#define   ESPI_CTRL_OOB_RX_SW_RST		BIT(28)
> +#define   ESPI_CTRL_PERIF_NP_TX_SW_RST		BIT(27)
> +#define   ESPI_CTRL_PERIF_NP_RX_SW_RST		BIT(26)
> +#define   ESPI_CTRL_PERIF_PC_TX_SW_RST		BIT(25)
> +#define   ESPI_CTRL_PERIF_PC_RX_SW_RST		BIT(24)
> +#define   ESPI_CTRL_FLASH_TX_DMA_EN		BIT(23)
> +#define   ESPI_CTRL_FLASH_RX_DMA_EN		BIT(22)
> +#define   ESPI_CTRL_OOB_TX_DMA_EN		BIT(21)
> +#define   ESPI_CTRL_OOB_RX_DMA_EN		BIT(20)
> +#define   ESPI_CTRL_PERIF_NP_TX_DMA_EN		BIT(19)
> +#define   ESPI_CTRL_PERIF_PC_TX_DMA_EN		BIT(17)
> +#define   ESPI_CTRL_PERIF_PC_RX_DMA_EN		BIT(16)
> +#define   ESPI_CTRL_FLASH_EDAF_MODE		GENMASK(11, 10)
> +#define   ESPI_CTRL_VW_GPIO_SW			BIT(9)
> +#define   ESPI_CTRL_FLASH_SW_RDY		BIT(7)
> +#define   ESPI_CTRL_OOB_SW_RDY			BIT(4)
> +#define   ESPI_CTRL_VW_SW_RDY			BIT(3)
> +#define   ESPI_CTRL_PERIF_SW_RDY		BIT(1)
> +#define ESPI_STS				0x004
> +#define ESPI_INT_STS				0x008
> +#define   ESPI_INT_STS_RST_DEASSERT		BIT(31)
> +#define   ESPI_INT_STS_OOB_RX_TMOUT		BIT(23)
> +#define   ESPI_INT_STS_VW_SYSEVT1		BIT(22)
> +#define   ESPI_INT_STS_FLASH_TX_ERR		BIT(21)
> +#define   ESPI_INT_STS_OOB_TX_ERR		BIT(20)
> +#define   ESPI_INT_STS_FLASH_TX_ABT		BIT(19)
> +#define   ESPI_INT_STS_OOB_TX_ABT		BIT(18)
> +#define   ESPI_INT_STS_PERIF_NP_TX_ABT		BIT(17)
> +#define   ESPI_INT_STS_PERIF_PC_TX_ABT		BIT(16)
> +#define   ESPI_INT_STS_FLASH_RX_ABT		BIT(15)
> +#define   ESPI_INT_STS_OOB_RX_ABT		BIT(14)
> +#define   ESPI_INT_STS_PERIF_NP_RX_ABT		BIT(13)
> +#define   ESPI_INT_STS_PERIF_PC_RX_ABT		BIT(12)
> +#define   ESPI_INT_STS_PERIF_NP_TX_ERR		BIT(11)
> +#define   ESPI_INT_STS_PERIF_PC_TX_ERR		BIT(10)
> +#define   ESPI_INT_STS_VW_GPIO			BIT(9)
> +#define   ESPI_INT_STS_VW_SYSEVT		BIT(8)
> +#define   ESPI_INT_STS_FLASH_TX_CMPLT		BIT(7)
> +#define   ESPI_INT_STS_FLASH_RX_CMPLT		BIT(6)
> +#define   ESPI_INT_STS_OOB_TX_CMPLT		BIT(5)
> +#define   ESPI_INT_STS_OOB_RX_CMPLT		BIT(4)
> +#define   ESPI_INT_STS_PERIF_NP_TX_CMPLT	BIT(3)
> +#define   ESPI_INT_STS_PERIF_PC_TX_CMPLT	BIT(1)
> +#define   ESPI_INT_STS_PERIF_PC_RX_CMPLT	BIT(0)
> +#define ESPI_INT_EN				0x00c
> +#define   ESPI_INT_EN_RST_DEASSERT		BIT(31)
> +#define   ESPI_INT_EN_OOB_RX_TMOUT		BIT(23)
> +#define   ESPI_INT_EN_VW_SYSEVT1		BIT(22)
> +#define   ESPI_INT_EN_FLASH_TX_ERR		BIT(21)
> +#define   ESPI_INT_EN_OOB_TX_ERR		BIT(20)
> +#define   ESPI_INT_EN_FLASH_TX_ABT		BIT(19)
> +#define   ESPI_INT_EN_OOB_TX_ABT		BIT(18)
> +#define   ESPI_INT_EN_PERIF_NP_TX_ABT		BIT(17)
> +#define   ESPI_INT_EN_PERIF_PC_TX_ABT		BIT(16)
> +#define   ESPI_INT_EN_FLASH_RX_ABT		BIT(15)
> +#define   ESPI_INT_EN_OOB_RX_ABT		BIT(14)
> +#define   ESPI_INT_EN_PERIF_NP_RX_ABT		BIT(13)
> +#define   ESPI_INT_EN_PERIF_PC_RX_ABT		BIT(12)
> +#define   ESPI_INT_EN_PERIF_NP_TX_ERR		BIT(11)
> +#define   ESPI_INT_EN_PERIF_PC_TX_ERR		BIT(10)
> +#define   ESPI_INT_EN_VW_GPIO			BIT(9)
> +#define   ESPI_INT_EN_VW_SYSEVT			BIT(8)
> +#define   ESPI_INT_EN_FLASH_TX_CMPLT		BIT(7)
> +#define   ESPI_INT_EN_FLASH_RX_CMPLT		BIT(6)
> +#define   ESPI_INT_EN_OOB_TX_CMPLT		BIT(5)
> +#define   ESPI_INT_EN_OOB_RX_CMPLT		BIT(4)
> +#define   ESPI_INT_EN_PERIF_NP_TX_CMPLT		BIT(3)
> +#define   ESPI_INT_EN_PERIF_PC_TX_CMPLT		BIT(1)
> +#define   ESPI_INT_EN_PERIF_PC_RX_CMPLT		BIT(0)
> +#define ESPI_PERIF_PC_RX_DMA			0x010
> +#define ESPI_PERIF_PC_RX_CTRL			0x014
> +#define   ESPI_PERIF_PC_RX_CTRL_SERV_PEND	BIT(31)
> +#define   ESPI_PERIF_PC_RX_CTRL_LEN		GENMASK(23, 12)
> +#define   ESPI_PERIF_PC_RX_CTRL_TAG		GENMASK(11, 8)
> +#define   ESPI_PERIF_PC_RX_CTRL_CYC		GENMASK(7, 0)
> +#define ESPI_PERIF_PC_RX_DATA			0x018
> +#define ESPI_PERIF_PC_TX_DMA			0x020
> +#define ESPI_PERIF_PC_TX_CTRL			0x024
> +#define	  ESPI_PERIF_PC_TX_CTRL_TRIG_PEND	BIT(31)
> +#define	  ESPI_PERIF_PC_TX_CTRL_LEN		GENMASK(23, 12)
> +#define	  ESPI_PERIF_PC_TX_CTRL_TAG		GENMASK(11, 8)
> +#define	  ESPI_PERIF_PC_TX_CTRL_CYC		GENMASK(7, 0)
> +#define ESPI_PERIF_PC_TX_DATA			0x028
> +#define ESPI_PERIF_NP_TX_DMA			0x030
> +#define ESPI_PERIF_NP_TX_CTRL			0x034
> +#define   ESPI_PERIF_NP_TX_CTRL_TRIG_PEND	BIT(31)
> +#define	  ESPI_PERIF_NP_TX_CTRL_LEN		GENMASK(23, 12)
> +#define	  ESPI_PERIF_NP_TX_CTRL_TAG		GENMASK(11, 8)
> +#define	  ESPI_PERIF_NP_TX_CTRL_CYC		GENMASK(7, 0)
> +#define ESPI_PERIF_NP_TX_DATA			0x038
> +#define ESPI_OOB_RX_DMA				0x040
> +#define ESPI_OOB_RX_CTRL			0x044
> +#define	  ESPI_OOB_RX_CTRL_SERV_PEND		BIT(31)
> +#define	  ESPI_OOB_RX_CTRL_LEN			GENMASK(23, 12)
> +#define	  ESPI_OOB_RX_CTRL_TAG			GENMASK(11, 8)
> +#define	  ESPI_OOB_RX_CTRL_CYC			GENMASK(7, 0)
> +#define ESPI_OOB_RX_DATA			0x048
> +#define ESPI_OOB_TX_DMA				0x050
> +#define ESPI_OOB_TX_CTRL			0x054
> +#define	  ESPI_OOB_TX_CTRL_TRIG_PEND		BIT(31)
> +#define	  ESPI_OOB_TX_CTRL_LEN			GENMASK(23, 12)
> +#define	  ESPI_OOB_TX_CTRL_TAG			GENMASK(11, 8)
> +#define	  ESPI_OOB_TX_CTRL_CYC			GENMASK(7, 0)
> +#define ESPI_OOB_TX_DATA			0x058
> +#define ESPI_FLASH_RX_DMA			0x060
> +#define ESPI_FLASH_RX_CTRL			0x064
> +#define	  ESPI_FLASH_RX_CTRL_SERV_PEND		BIT(31)
> +#define	  ESPI_FLASH_RX_CTRL_LEN		GENMASK(23, 12)
> +#define	  ESPI_FLASH_RX_CTRL_TAG		GENMASK(11, 8)
> +#define	  ESPI_FLASH_RX_CTRL_CYC		GENMASK(7, 0)
> +#define ESPI_FLASH_RX_DATA			0x068
> +#define ESPI_FLASH_TX_DMA			0x070
> +#define ESPI_FLASH_TX_CTRL			0x074
> +#define	  ESPI_FLASH_TX_CTRL_TRIG_PEND		BIT(31)
> +#define	  ESPI_FLASH_TX_CTRL_LEN		GENMASK(23, 12)
> +#define	  ESPI_FLASH_TX_CTRL_TAG		GENMASK(11, 8)
> +#define	  ESPI_FLASH_TX_CTRL_CYC		GENMASK(7, 0)
> +#define ESPI_FLASH_TX_DATA			0x078
> +#define ESPI_CTRL2				0x080
> +#define   ESPI_CTRL2_VW_TX_SORT			BIT(30)
> +#define   ESPI_CTRL2_MCYC_RD_DIS_WDT		BIT(11)
> +#define   ESPI_CTRL2_MCYC_WR_DIS_WDT		BIT(10)
> +#define   ESPI_CTRL2_MCYC_RD_DIS		BIT(6)
> +#define   ESPI_CTRL2_MMBI_RD_DIS		ESPI_CTRL2_MCYC_RD_DIS
> +#define   ESPI_CTRL2_MCYC_WR_DIS		BIT(4)
> +#define   ESPI_CTRL2_MMBI_WR_DIS		ESPI_CTRL2_MCYC_WR_DIS
> +#define ESPI_PERIF_MCYC_SADDR			0x084
> +#define ESPI_PERIF_MMBI_SADDR			ESPI_PERIF_MCYC_SADDR
> +#define ESPI_PERIF_MCYC_TADDR			0x088
> +#define ESPI_PERIF_MMBI_TADDR			ESPI_PERIF_MCYC_TADDR
> +#define ESPI_PERIF_MCYC_MASK			0x08c
> +#define ESPI_PERIF_MMBI_MASK			ESPI_PERIF_MCYC_MASK
> +#define ESPI_FLASH_EDAF_TADDR			0x090
> +#define   ESPI_FLASH_EDAF_TADDR_BASE		GENMASK(31, 24)
> +#define   ESPI_FLASH_EDAF_TADDR_MASK		GENMASK(15, 8)
> +#define ESPI_VW_SYSEVT_INT_EN			0x094
> +#define ESPI_VW_SYSEVT				0x098
> +#define   ESPI_VW_SYSEVT_HOST_RST_ACK		BIT(27)
> +#define   ESPI_VW_SYSEVT_RST_CPU_INIT		BIT(26)
> +#define   ESPI_VW_SYSEVT_SLV_BOOT_STS		BIT(23)
> +#define   ESPI_VW_SYSEVT_NON_FATAL_ERR		BIT(22)
> +#define   ESPI_VW_SYSEVT_FATAL_ERR		BIT(21)
> +#define   ESPI_VW_SYSEVT_SLV_BOOT_DONE		BIT(20)
> +#define   ESPI_VW_SYSEVT_OOB_RST_ACK		BIT(16)
> +#define   ESPI_VW_SYSEVT_NMI_OUT		BIT(10)
> +#define   ESPI_VW_SYSEVT_SMI_OUT		BIT(9)
> +#define   ESPI_VW_SYSEVT_HOST_RST_WARN		BIT(8)
> +#define   ESPI_VW_SYSEVT_OOB_RST_WARN		BIT(6)
> +#define   ESPI_VW_SYSEVT_PLTRSTN		BIT(5)
> +#define   ESPI_VW_SYSEVT_SUSPEND		BIT(4)
> +#define   ESPI_VW_SYSEVT_S5_SLEEP		BIT(2)
> +#define   ESPI_VW_SYSEVT_S4_SLEEP		BIT(1)
> +#define   ESPI_VW_SYSEVT_S3_SLEEP		BIT(0)
> +#define ESPI_VW_GPIO_VAL			0x09c
> +#define ESPI_GEN_CAP_N_CONF			0x0a0
> +#define ESPI_CH0_CAP_N_CONF			0x0a4
> +#define ESPI_CH1_CAP_N_CONF			0x0a8
> +#define ESPI_CH2_CAP_N_CONF			0x0ac
> +#define ESPI_CH3_CAP_N_CONF			0x0b0
> +#define ESPI_CH3_CAP_N_CONF2			0x0b4
> +#define ESPI_VW_GPIO_DIR			0x0c0
> +#define ESPI_VW_GPIO_GRP			0x0c4
> +#define ESPI_INT_EN_CLR				0x0fc
> +#define ESPI_VW_SYSEVT1_INT_EN			0x100
> +#define ESPI_VW_SYSEVT1				0x104
> +#define   ESPI_VW_SYSEVT1_SUSPEND_ACK		BIT(20)
> +#define   ESPI_VW_SYSEVT1_SUSPEND_WARN		BIT(0)
> +#define ESPI_VW_SYSEVT_INT_T0			0x110
> +#define ESPI_VW_SYSEVT_INT_T1			0x114
> +#define ESPI_VW_SYSEVT_INT_T2			0x118
> +#define ESPI_VW_SYSEVT_INT_STS			0x11c
> +#define ESPI_VW_SYSEVT1_INT_T0			0x120
> +#define ESPI_VW_SYSEVT1_INT_T1			0x124
> +#define ESPI_VW_SYSEVT1_INT_T2			0x128
> +#define ESPI_VW_SYSEVT1_INT_STS			0x12c
> +#define ESPI_OOB_RX_DESC_NUM			0x130
> +#define ESPI_OOB_RX_DESC_RPTR			0x134
> +#define	  ESPI_OOB_RX_DESC_RPTR_UPDATE		BIT(31)
> +#define   ESPI_OOB_RX_DESC_RPTR_RP		GENMASK(11, 0)
> +#define ESPI_OOB_RX_DESC_WPTR			0x138
> +#define   ESPI_OOB_RX_DESC_WPTR_RECV_EN		BIT(31)
> +#define   ESPI_OOB_RX_DESC_WPTR_SP		GENMASK(27, 16)
> +#define   ESPI_OOB_RX_DESC_WPTR_WP		GENMASK(11, 0)
> +#define ESPI_OOB_TX_DESC_NUM			0x140
> +#define ESPI_OOB_TX_DESC_RPTR			0x144
> +#define	  ESPI_OOB_TX_DESC_RPTR_UPDATE		BIT(31)
> +#define ESPI_OOB_TX_DESC_WPTR			0x148
> +#define	  ESPI_OOB_TX_DESC_WPTR_SEND_EN		BIT(31)
> +#define ESPI_MMBI_CTRL				0x800
> +#define   ESPI_MMBI_CTRL_INST_SZ		GENMASK(10, 8)
> +#define   ESPI_MMBI_CTRL_TOTAL_SZ		GENMASK(6, 4)
> +#define   ESPI_MMBI_CTRL_EN			BIT(0)
> +#define ESPI_MMBI_INT_STS			0x808
> +#define ESPI_MMBI_INT_EN			0x80c
> +#define ESPI_MMBI_HOST_RWP(x)			(0x810 + ((x) << 3))
> +
> +/* collect ESPI_INT_EN bits for convenience */
> +#define ESPI_INT_EN_PERIF			\
> +	(ESPI_INT_EN_PERIF_NP_TX_ABT |		\
> +	 ESPI_INT_EN_PERIF_PC_TX_ABT |		\
> +	 ESPI_INT_EN_PERIF_NP_RX_ABT |		\
> +	 ESPI_INT_EN_PERIF_PC_RX_ABT |		\
> +	 ESPI_INT_EN_PERIF_NP_TX_ERR |		\
> +	 ESPI_INT_EN_PERIF_PC_TX_ERR |		\
> +	 ESPI_INT_EN_PERIF_NP_TX_CMPLT |	\
> +	 ESPI_INT_EN_PERIF_PC_TX_CMPLT |	\
> +	 ESPI_INT_EN_PERIF_PC_RX_CMPLT)
> +
> +#define ESPI_INT_EN_VW			\
> +	(ESPI_INT_EN_VW_SYSEVT1 |	\
> +	 ESPI_INT_EN_VW_GPIO    |	\
> +	 ESPI_INT_EN_VW_SYSEVT)
> +
> +#define ESPI_INT_EN_OOB		\
> +	(ESPI_INT_EN_OOB_RX_TMOUT |	\
> +	 ESPI_INT_EN_OOB_TX_ERR |	\
> +	 ESPI_INT_EN_OOB_TX_ABT |	\
> +	 ESPI_INT_EN_OOB_RX_ABT |	\
> +	 ESPI_INT_EN_OOB_TX_CMPLT |	\
> +	 ESPI_INT_EN_OOB_RX_CMPLT)
> +
> +#define ESPI_INT_EN_FLASH		\
> +	(ESPI_INT_EN_FLASH_TX_ERR |	\
> +	 ESPI_INT_EN_FLASH_TX_ABT |	\
> +	 ESPI_INT_EN_FLASH_RX_ABT |	\
> +	 ESPI_INT_EN_FLASH_TX_CMPLT |	\
> +	 ESPI_INT_EN_FLASH_RX_CMPLT)
> +
> +/* collect ESPI_INT_STS bits for convenience */
> +#define ESPI_INT_STS_PERIF			\
> +	(ESPI_INT_STS_PERIF_NP_TX_ABT |		\
> +	 ESPI_INT_STS_PERIF_PC_TX_ABT |		\
> +	 ESPI_INT_STS_PERIF_NP_RX_ABT |		\
> +	 ESPI_INT_STS_PERIF_PC_RX_ABT |		\
> +	 ESPI_INT_STS_PERIF_NP_TX_ERR |		\
> +	 ESPI_INT_STS_PERIF_PC_TX_ERR |		\
> +	 ESPI_INT_STS_PERIF_NP_TX_CMPLT |	\
> +	 ESPI_INT_STS_PERIF_PC_TX_CMPLT |	\
> +	 ESPI_INT_STS_PERIF_PC_RX_CMPLT)
> +
> +#define ESPI_INT_STS_VW			\
> +	(ESPI_INT_STS_VW_SYSEVT1 |	\
> +	 ESPI_INT_STS_VW_GPIO    |	\
> +	 ESPI_INT_STS_VW_SYSEVT)
> +
> +#define ESPI_INT_STS_OOB		\
> +	(ESPI_INT_STS_OOB_RX_TMOUT |	\
> +	 ESPI_INT_STS_OOB_TX_ERR |	\
> +	 ESPI_INT_STS_OOB_TX_ABT |	\
> +	 ESPI_INT_STS_OOB_RX_ABT |	\
> +	 ESPI_INT_STS_OOB_TX_CMPLT |	\
> +	 ESPI_INT_STS_OOB_RX_CMPLT)
> +
> +#define ESPI_INT_STS_FLASH		\
> +	(ESPI_INT_STS_FLASH_TX_ERR |	\
> +	 ESPI_INT_STS_FLASH_TX_ABT |	\
> +	 ESPI_INT_STS_FLASH_RX_ABT |	\
> +	 ESPI_INT_STS_FLASH_TX_CMPLT |	\
> +	 ESPI_INT_STS_FLASH_RX_CMPLT)
> +
> +/* function operators */
> +void ast2600_espi_pre_init(struct aspeed_espi *espi);
> +void ast2600_espi_post_init(struct aspeed_espi *espi);
> +void ast2600_espi_deinit(struct aspeed_espi *espi);
> +int ast2600_espi_perif_probe(struct aspeed_espi *espi);
> +int ast2600_espi_perif_remove(struct aspeed_espi *espi);
> +int ast2600_espi_vw_probe(struct aspeed_espi *espi);
> +int ast2600_espi_vw_remove(struct aspeed_espi *espi);
> +int ast2600_espi_oob_probe(struct aspeed_espi *espi);
> +int ast2600_espi_oob_remove(struct aspeed_espi *espi);
> +int ast2600_espi_flash_probe(struct aspeed_espi *espi);
> +int ast2600_espi_flash_remove(struct aspeed_espi *espi);
> +irqreturn_t ast2600_espi_isr(int irq, void *arg);
> +#endif
>