[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 at 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