Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI

[Arnd Bergmann <arnd@xxxxxxxx>]

On Wed, Jan 3, 2018 at 3:32 PM, Mark Brown <broonie@xxxxxxxxxx> wrote:
> On Wed, Jan 03, 2018 at 10:28:22PM +0800, Wang, Haiyue wrote:
>
>> Should send to like this ? Because I add patch for Aspeed chip:
>
>> ./scripts/get_maintainer.pl drivers/misc/aspeed-lpc-snoop.c
>> Joel Stanley <joel@xxxxxxxxx> (maintainer:ARM/ASPEED MACHINE SUPPORT)
>> Arnd Bergmann <arnd@xxxxxxxx> (supporter:CHAR and MISC DRIVERS)
>> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> (supporter:CHAR and MISC
>> DRIVERS)
>> linux-kernel@xxxxxxxxxxxxxxx (open list)
>
> So it's not actually doing anything at all with the SPI subsystem?  I
> lacked any context for the discussion having been copied in part way
> through.  If it is a SPI controller it ought to have been in
> drivers/spi.

It's not an SPI host controller, but a specialized driver for a specialuzed
SPI slave hardware block.

The SPI slave driver implements the higher-level parts of the eSPI protocol
stack in Linux, and the lower levels in hardware. The question is whether (and
how) there should be a split between the levels. If we are expecting to add
a software implementation of the same eSPI stack in software using the generic
SPI slave code in the future, it may be helpful to have that separate in place
already.

With my later suggestion of splitting out the eSPI "virtual wire" low-level
support into a gpiochip driver, neither half would be in drivers/spi/, but
one could implement a drivers/spi/spi-slave-espi-vw.c slave protocol
driver that exposes the same in-kernel interface on top of a slave-capable
SPI controller.

      Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html