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