Re: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
Ivan Mikhaylov <[email protected]>
| 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 | <[email protected]> |
On Fri, 2026-03-13 at 22:36 +0100, Arnd Bergmann wrote: > On Fri, Mar 13, 2026, at 17:24, Conor Dooley wrote: > > On Fri, Mar 13, 2026 at 06:07:35PM +0800, aspeedyh wrote: > > > This series adds initial support for the eSPI controller found on > > > ASPEED > > > AST2600 BMC SoCs. > > > > > > The series introduces a eSPI controller framework for ASPEED SoCs > > > under > > > drivers/soc/aspeed/, adds AST2600-specific controller support for > > > peripheral and flash channels, defines the corresponding > > > devicetree > > > binding, and adds the AST2600 eSPI controller node to the SoC > > > dtsi. > > > > > > The driver is intended to support host-BMC communication over the > > > BMC-side > > > eSPI slave controller present on AST2600 systems. > > > > This all seems to be in the wrong places entirely, shouldn't an > > eSPI > > driver and bindings go in the spi subsystem? > > From an initial reading, my impression is that patches 1, 2, 3 and 7 > should be modified to use the normal SPI interfaces to implement > an spi target driver, possibly a combined host/target driver. > Reworking this should be fairly straightforward because the > interfaces > to the SPI core are well documented. Arnd, that's would be nice if it would be standard SPI device. But what if eSPI would be a bus? So, I assume all other which lying underneath eSPI would be much easier to implement as standard driver data set SPI/GPIO/I2C with something like devm_regmap_init_espi(like for i2c/spi or anything else) for example as common part for these drivers. Thanks.