From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBouN1bs4+qJ3m7rDI4xzdEHE+MKDkHiL3+UBt26q0U5gP37Y+CTv0ZWz+7lFd92qcXETuSxn ARC-Seal: i=1; a=rsa-sha256; t=1514998089; cv=none; d=google.com; s=arc-20160816; b=zwsCibqno27E6yyM2Jpn7sAvSY3TzTcS8zfJNT8kyyv8Ihnr7sIaL7qsKSkdvXd6DF QcI29mrKFHQsCCxUmAOsSBnNzE8nuR889Ryd4M4mmYlyghxxdkgE9HgWnPS51XXShiQd KPmZAY+eQ5KmszNgmLupexnXGJPzwMMDsplYRzZlSf0ZP6U0o7mkMwu5b3ANnr/fzcv0 bk/n3V0uodBwKRc5fz60RggsQZ3fcSxZ98c5AeDB6mtPD4B4AgVjLSFVg5/y1sR3q4Pv AXJ0XrbQUE3Xti4S/+HbkdOTPAd8TdL2Unjl3ZzZ7Ufjh+dOAf38IZ0VKUtlgUVFlzdG zGrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=FyIcpU+OsrUyuXvsiWSiwe7PJP7wXMWCNpwTWHITLKM=; b=rOatImz5t41b0ZTJ3udLJc56K7/dhbFxpUAO3a8k3wmjEtB0JwogMMsOP7u9/zrQxM qGhtUd2erXubnNCqQMRbccXgAY26/6jHbpqDctvtZmIOerI3tyfzaksN9ZjZzeQ333U2 oRd0Sfqpy4Vc9mnog3D4zbQT3NsT+LXexPk9L2KqZy2UfrMxI7TcGIlec4mkEgtD1FNL 7bbFyT9ASijSR0iG/551j6JMOvvnrZVX7horY70bpfKuwifgRm8j+cuc72g01foUZXPh XLQ8Fu+Vx2WZFu48mdYKYXY90ZahnfwRNFR7V6XcvH8bBh7SR/g9mnVyGIbVkhtmWbyr 99YA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of haiyue.wang@linux.intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=haiyue.wang@linux.intel.com Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of haiyue.wang@linux.intel.com designates 192.55.52.93 as permitted sender) smtp.mailfrom=haiyue.wang@linux.intel.com X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,501,1508828400"; d="scan'208,217";a="6967356" Subject: Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI To: Arnd Bergmann , Mark Brown Cc: Joel Stanley , gregkh , Linux Kernel Mailing List , linux-spi , "Shevchenko, Andriy" References: <1514512387-27113-1-git-send-email-haiyue.wang@linux.intel.com> <20180103113805.GD5603@sirena.org.uk> <004d3017-5477-ec42-c78a-aba0ca0621bc@linux.intel.com> <20180103143226.GI5603@sirena.org.uk> From: "Wang, Haiyue" Message-ID: Date: Thu, 4 Jan 2018 00:48:06 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1C2BEDB63ED04A6E13465296" Content-Language: en-US X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1588081316766464367?= X-GMAIL-MSGID: =?utf-8?q?1588590636350179236?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: This is a multi-part message in MIME format. --------------1C2BEDB63ED04A6E13465296 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------1C2BEDB63ED04A6E13465296 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
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


    

    

  


--------------1C2BEDB63ED04A6E13465296--