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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 3 Jan 2018 16:05:50 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Mark Brown <broonie@...nel.org>
Cc:     "Wang, Haiyue" <haiyue.wang@...ux.intel.com>,
        Joel Stanley <joel@....id.au>,
        gregkh <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host
 with PCH runs on eSPI

On Wed, Jan 3, 2018 at 3:32 PM, Mark Brown <broonie@...nel.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@....id.au> (maintainer:ARM/ASPEED MACHINE SUPPORT)
>> Arnd Bergmann <arnd@...db.de> (supporter:CHAR and MISC DRIVERS)
>> Greg Kroah-Hartman <gregkh@...uxfoundation.org> (supporter:CHAR and MISC
>> DRIVERS)
>> linux-kernel@...r.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.

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