Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751140AbdL3XKy (ORCPT ); Sat, 30 Dec 2017 18:10:54 -0500 Received: from mail-ot0-f180.google.com ([74.125.82.180]:43547 "EHLO mail-ot0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750982AbdL3XKw (ORCPT ); Sat, 30 Dec 2017 18:10:52 -0500 X-Google-Smtp-Source: ACJfBovQgtdhvWRQ07ZUz6CX86pC7i1BFChu6Vuv6BLxTrEtqrN2CyElIwWRBvPbaxU/14Wxa/L/nL8d12Nj2/nY8ng= MIME-Version: 1.0 In-Reply-To: <1514512387-27113-1-git-send-email-haiyue.wang@linux.intel.com> References: <1514512387-27113-1-git-send-email-haiyue.wang@linux.intel.com> From: Arnd Bergmann Date: Sun, 31 Dec 2017 00:10:51 +0100 X-Google-Sender-Auth: 2WVWBYJb8aeRlwcAa8DAH9gdXlg Message-ID: Subject: Re: [PATCH v1] eSPI: add Aspeed AST2500 eSPI driver to boot a host with PCH runs on eSPI To: Haiyue Wang Cc: Joel Stanley , gregkh , Linux Kernel Mailing List , Mark Brown , 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 Content-Length: 1392 Lines: 31 On Fri, Dec 29, 2017 at 2:53 AM, Haiyue Wang wrote: > When PCH works under eSPI mode, the PMC (Power Management Controller) in > PCH is waiting for SUS_ACK from BMC after it alerts SUS_WARN. It is in > dead loop if no SUS_ACK assert. This is the basic requirement for the BMC > works as eSPI slave. > > Also for the host power on / off actions, from BMC side, the following VW > (Virtual Wire) messages are done in firmware: > 1. SLAVE_BOOT_LOAD_DONE / SLAVE_BOOT_LOAD_STATUS > 2. SUS_ACK > 3. OOB_RESET_ACK > 4. HOST_RESET_ACK I have not looked at the driver contents yet, but I'm adding the SPI maintainer and mailing list to Cc here for further discussion. Can you clarify how the eSPI slave mode relates to SPI slaves that we already support? I was under the impression that the difference between SPI and eSPI is mainly on the master side, but that any SPI slave can also act as an eSPI slave. Would this driver fit into the SPI slave framework, possibly with some extensions to the generic abstraction? It also seems rather inflexible to have a single driver that is responsible both for the transport (eSPI register level interface for ASPEED) and the high-level protocol (talking to an Intel PCH), since either half of the work could be done elsewhere, using either a different eSPI slave implementation, or a different host architecture) Arnd