RE: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
YH Chung <[email protected]> Wed, 24 Jun 2026 03:59:27 +0000
| Newsgroups | org.ozlabs.lists.openbmc,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel,org.ozlabs.lists.linux-aspeed |
|---|---|
| Message-ID | <KL1PR0601MB4276FA2C6347192CC45826E490ED2@KL1PR0601MB4276.apcprd06.prod.outlook.com> |
Hi Mark, > (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. Regarding option 1, could you kindly share your feedback on whether this patch set should be modified to fit under the SPI subsystem, or whether a new eSPI subsystem would be more appropriate? For option 2, Arnd has indicated that he does not want to take this through the SoC subsystem. Therefore, if the SPI subsystem is also not a good fit, we think a new eSPI subsystem may be needed to provide a common home for channel handling, even though the individual channels are relatively independent. For example, the VW and OOB channel handling could potentially be integrated with existing subsystems such as GPIO or net/mctp. However, the Flash channel would still need an eSPI-specific interface to configure the backing store. Placing that code under MTD feels awkward, since the driver is not really an MTD device or a flash controller. If this direction sounds reasonable, we would like to explore introducing a new drivers/espi subsystem and moving the eSPI driver there. Please let us know if you think we should take a different approach. Thanks, Yun Hsuan.