Re: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: Shulzhenko, Oleksandr
Date: Tue May 12 2026 - 04:45:55 EST
On 5/12/2026 9:08 AM, YH Chung wrote:
Hi Shulzhenko,Hi YH,
Thanks for the follow-up.
Integrating this driver into the SPI subsystem may allow reusing some existingAgreed. eSPI introduces two additional pins, RESET# and ALERT#, beyond the
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.
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 fromI believe only a limited portion of the SPI subsystem can be reused. Some
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?
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 reuseOur main concern is an abstraction mismatch. SPI is designed as a generic
the SPI core here?
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.
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).