On 2018-01-03 23:05, Arnd Bergmann wrote: > On Wed, Jan 3, 2018 at 3:32 PM, Mark Brown 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 (maintainer:ARM/ASPEED MACHINE SUPPORT) >>> Arnd Bergmann (supporter:CHAR and MISC DRIVERS) >>> Greg Kroah-Hartman (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