Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753195AbeACPFx (ORCPT + 1 other); Wed, 3 Jan 2018 10:05:53 -0500 Received: from mail-qk0-f196.google.com ([209.85.220.196]:34403 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751263AbeACPFw (ORCPT ); Wed, 3 Jan 2018 10:05:52 -0500 X-Google-Smtp-Source: ACJfBoscq6z+5PieFyEMwwgTmyjPjLC+vRHprd9IBVk0Zqu+wCtpbqTeHs6i009bptEFQ7Oc22BWuZ6c6kWrR9cXcg4= MIME-Version: 1.0 In-Reply-To: <20180103143226.GI5603@sirena.org.uk> 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: Arnd Bergmann Date: Wed, 3 Jan 2018 16:05:50 +0100 X-Google-Sender-Auth: GVcJQgV0hpicvR8TBbhfqVlZxrI Message-ID: Subject: Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI To: Mark Brown Cc: "Wang, Haiyue" , Joel Stanley , gregkh , Linux Kernel Mailing List , linux-spi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: 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. 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