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

["Wang, Haiyue" <haiyue.wang@linux.intel.com>]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

On 2018-01-03 23:05, Arnd Bergmann wrote:
> On Wed, Jan 3, 2018 at 3:32 PM, Mark Brown <broonie@kernel.org> 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@jms.id.au> (maintainer:ARM/ASPEED MACHINE SUPPORT)
>>> Arnd Bergmann <arnd@arndb.de> (supporter:CHAR and MISC DRIVERS)
>>> Greg Kroah-Hartman <gregkh@linuxfoundation.org> (supporter:CHAR and MISC
>>> DRIVERS)
>>> linux-kernel@vger.kernel.org (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.

 From ASpeed's reference code and datasheet, this eSPI driver should 
just a **user** of eSPI
protocol. Its feature doesn't belong to - Enhanced Serial Peripheral 
Interface (eSPI)
Interface Base Specification (for Client and Server Platforms) r1.0

https://www.intel.com/content/dam/support/us/en/documents/software/chipset-software/327432-004_espi_base_specification_rev1.0.pdf




> 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


[-- Attachment #2: Type: text/html, Size: 3921 bytes --]