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

[YH Chung]

Hi Shulzhenko, Arnd, Andrew

Please allow me to summarize the potential approaches we have discussed so
far for upstreaming the eSPI driver:

(1) Reuse the existing SPI subsystem and treat eSPI packets as pure signals.
(2) Maintain the driver under the SoC subsystem, since there is currently no
    eSPI subsystem.
(3) Create a new eSPI subsystem and rewrite the eSPI driver accordingly.

For option 1, we do not think this would be a good fit, because eSPI has
clearly defined semantics for each channel, and our hardware exposes
different sets of registers for each of them.

For option 2, we think this would be a practical short-term solution, and we
can expose the per-channel functionality through the existing GPIO, MCTP, and
MTD subsystems for the VW, OOB, and flash channels, respectively.
However, this may need to be revisited once an eSPI subsystem becomes
available in-tree.

For option 3, our concern is that there is currently no other eSPI hardware
or driver in-tree that could serve as a reference for defining a more generic
interface. Creating a new subsystem at this stage may therefore be somewhat
over-engineered, since it would only have one user.

We understand that Nuvoton may be the next likely vendor to support eSPI in
their BMC SoCs. Since drivers/soc patches for Nuvoton BMCs also go through
the BMC tree, we expect there would be an opportunity to reconsider whether
an independent eSPI subsystem is needed once another user appears.

Based on the above, we would like to prepare and submit the next revision
with the driver located under drivers/soc.

Could you please let us know if there are any concerns or suggestions that we
have not covered, or whether we could send the next revision for review?