From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3A6F0C433F5 for ; Mon, 6 Sep 2021 03:16:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 217CC603E7 for ; Mon, 6 Sep 2021 03:16:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239270AbhIFDSB (ORCPT ); Sun, 5 Sep 2021 23:18:01 -0400 Received: from pi.codeconstruct.com.au ([203.29.241.158]:54516 "EHLO codeconstruct.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230062AbhIFDSA (ORCPT ); Sun, 5 Sep 2021 23:18:00 -0400 Received: from [172.16.66.38] (unknown [49.255.141.98]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id B0C892012C; Mon, 6 Sep 2021 11:16:49 +0800 (AWST) Message-ID: <6593206c0bc90186f255c6ea86339576576f70dc.camel@codeconstruct.com.au> Subject: Re: [PATCH v4 3/4] soc: aspeed: Add eSPI driver From: Jeremy Kerr To: ChiaWei Wang , "robh+dt@kernel.org" , "joel@jms.id.au" , "andrew@aj.id.au" , "linux-aspeed@lists.ozlabs.org" , "openbmc@lists.ozlabs.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Cc: Morris Mao , Ryan Chen Date: Mon, 06 Sep 2021 11:16:44 +0800 In-Reply-To: References: <20210901033015.910-1-chiawei_wang@aspeedtech.com> <20210901033015.910-4-chiawei_wang@aspeedtech.com> <20c13b9bb023091758cac3a07fb4037b7d796578.camel@codeconstruct.com.au> <513cb05f8d83d08a5c1e491dc0a9b6784195e7dd.camel@codeconstruct.com.au> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chiawei, > > If that model doesn't fit though, that's OK, but I think we need > > some rationale > > there. > > After an internal discussion, we found that our eSPI VW device may > not fit into existing GPIO model. > > The reason is that GPIO direction changes through VW channel has no > interrupts triggered. > And the direction is controlled by the Host as aforementioned. This piqued my curiosity, so I had a look through the 2500 datasheet. It appears that the host has full control of both the direction *and* hardware GPIO assignment though the platform-specific eSPI configuration register set. So, with VW GPIOs in hardware mode (ESPICTRL[9] = 0, the default), the host has arbitrary control of all hardware GPIO lines (except for the GPIOAC bank, I guess?). There's a huge security implication there - for example, GPIOs that assert physical presence can now be set by the host, possibly remotely - so I'd *strongly* recommend that we always get ESPICTRL[9] to 1, to set software-only mode. With than in mind, if we're disabling hardware mode - what does the direction control setting effect when we're in software mode (ESPICTRL[9] == 1)? Does it even matter? For example, what happens when the host goes a GET_VW cycle for a GPIO that is marked as 'master-to-slave' mode? Is the state of the GPIO in ESPI09C still reported? If that's the case, then we can just ignore the direction settings from ESPICFG800 completely, and have the BMC assign directions to standard gpiodevs as appropriate. Separate from this: I'm also proposing that we represent the system event VWs as gpiodevs as well. > A raw packet, primitive interface should have better flexibility to > manage MCTP packets over the OOB channel. OK, let me phrase this differently: can the OOB channel be used for anything other than SMBus messaging? Is it useful to provide an interface that isn't a standard SMBus/i2c device? If you need custom uapi definitions for this driver, that might be okay, but it's going to be more work for you (to define an interface that can be supported long-term), rather than using standard infrastructure that already exists. Cheers, Jeremy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2D973C433EF for ; Mon, 6 Sep 2021 03:17:32 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9592B603E7 for ; Mon, 6 Sep 2021 03:17:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 9592B603E7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeconstruct.com.au Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4H2tqt0cPwz2yS9 for ; Mon, 6 Sep 2021 13:17:30 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=codeconstruct.com.au (client-ip=203.29.241.158; helo=codeconstruct.com.au; envelope-from=jk@codeconstruct.com.au; receiver=) Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4H2tqG6MxHz2xr4; Mon, 6 Sep 2021 13:16:58 +1000 (AEST) Received: from [172.16.66.38] (unknown [49.255.141.98]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id B0C892012C; Mon, 6 Sep 2021 11:16:49 +0800 (AWST) Message-ID: <6593206c0bc90186f255c6ea86339576576f70dc.camel@codeconstruct.com.au> Subject: Re: [PATCH v4 3/4] soc: aspeed: Add eSPI driver From: Jeremy Kerr To: ChiaWei Wang , "robh+dt@kernel.org" , "joel@jms.id.au" , "andrew@aj.id.au" , "linux-aspeed@lists.ozlabs.org" , "openbmc@lists.ozlabs.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Date: Mon, 06 Sep 2021 11:16:44 +0800 In-Reply-To: References: <20210901033015.910-1-chiawei_wang@aspeedtech.com> <20210901033015.910-4-chiawei_wang@aspeedtech.com> <20c13b9bb023091758cac3a07fb4037b7d796578.camel@codeconstruct.com.au> <513cb05f8d83d08a5c1e491dc0a9b6784195e7dd.camel@codeconstruct.com.au> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Morris Mao , Ryan Chen Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" Hi Chiawei, > > If that model doesn't fit though, that's OK, but I think we need > > some rationale > > there. > > After an internal discussion, we found that our eSPI VW device may > not fit into existing GPIO model. > > The reason is that GPIO direction changes through VW channel has no > interrupts triggered. > And the direction is controlled by the Host as aforementioned. This piqued my curiosity, so I had a look through the 2500 datasheet. It appears that the host has full control of both the direction *and* hardware GPIO assignment though the platform-specific eSPI configuration register set. So, with VW GPIOs in hardware mode (ESPICTRL[9] = 0, the default), the host has arbitrary control of all hardware GPIO lines (except for the GPIOAC bank, I guess?). There's a huge security implication there - for example, GPIOs that assert physical presence can now be set by the host, possibly remotely - so I'd *strongly* recommend that we always get ESPICTRL[9] to 1, to set software-only mode. With than in mind, if we're disabling hardware mode - what does the direction control setting effect when we're in software mode (ESPICTRL[9] == 1)? Does it even matter? For example, what happens when the host goes a GET_VW cycle for a GPIO that is marked as 'master-to-slave' mode? Is the state of the GPIO in ESPI09C still reported? If that's the case, then we can just ignore the direction settings from ESPICFG800 completely, and have the BMC assign directions to standard gpiodevs as appropriate. Separate from this: I'm also proposing that we represent the system event VWs as gpiodevs as well. > A raw packet, primitive interface should have better flexibility to > manage MCTP packets over the OOB channel. OK, let me phrase this differently: can the OOB channel be used for anything other than SMBus messaging? Is it useful to provide an interface that isn't a standard SMBus/i2c device? If you need custom uapi definitions for this driver, that might be okay, but it's going to be more work for you (to define an interface that can be supported long-term), rather than using standard infrastructure that already exists. Cheers, Jeremy From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 31DCEC433EF for ; Mon, 6 Sep 2021 03:18:54 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E0F75603E7 for ; Mon, 6 Sep 2021 03:18:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E0F75603E7 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=codeconstruct.com.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:Cc:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ODyzvE2THn5oSWokQ6Oq9r+8WOGSHsjLqFkBxUxNlDw=; b=bxoK0+te69Qfdw X17of9I0ApwU1quW2DBWiMYj61aKTOc52U0+fWPm3U8z4xqwYi8YDChSbaAY+GdfPUkxwqAH02+rb J7g/uYXnYTFwjklZxybAt9sqdhQC/m9ftiHfF/uwf8f/A1x4zH5NBMXcBqyRMv3htdVLsppSU18ch TmjkBdENrAP/b3iMFc/6M9mgc+RHffb35iM2EKOQZwEeCF2L2wusLUF5jkK5uIblgAt6O3q2sO3iM ygl6QmifQGLcb/8VlnMTSuipe0Alypx+WSr9OiC99heTA+wsOi4R4wGO7m8eZsDEdUXN5cytyH05P VohUaIsF/xXOLo8JJlEA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mN588-00HB8N-P3; Mon, 06 Sep 2021 03:17:08 +0000 Received: from pi.codeconstruct.com.au ([203.29.241.158] helo=codeconstruct.com.au) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mN583-00HB7E-Hk for linux-arm-kernel@lists.infradead.org; Mon, 06 Sep 2021 03:17:06 +0000 Received: from [172.16.66.38] (unknown [49.255.141.98]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id B0C892012C; Mon, 6 Sep 2021 11:16:49 +0800 (AWST) Message-ID: <6593206c0bc90186f255c6ea86339576576f70dc.camel@codeconstruct.com.au> Subject: Re: [PATCH v4 3/4] soc: aspeed: Add eSPI driver From: Jeremy Kerr To: ChiaWei Wang , "robh+dt@kernel.org" , "joel@jms.id.au" , "andrew@aj.id.au" , "linux-aspeed@lists.ozlabs.org" , "openbmc@lists.ozlabs.org" , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Cc: Morris Mao , Ryan Chen Date: Mon, 06 Sep 2021 11:16:44 +0800 In-Reply-To: References: <20210901033015.910-1-chiawei_wang@aspeedtech.com> <20210901033015.910-4-chiawei_wang@aspeedtech.com> <20c13b9bb023091758cac3a07fb4037b7d796578.camel@codeconstruct.com.au> <513cb05f8d83d08a5c1e491dc0a9b6784195e7dd.camel@codeconstruct.com.au> User-Agent: Evolution 3.38.3-1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210905_201703_843921_A48FF0F6 X-CRM114-Status: GOOD ( 18.63 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Chiawei, > > If that model doesn't fit though, that's OK, but I think we need > > some rationale > > there. > > After an internal discussion, we found that our eSPI VW device may > not fit into existing GPIO model. > > The reason is that GPIO direction changes through VW channel has no > interrupts triggered. > And the direction is controlled by the Host as aforementioned. This piqued my curiosity, so I had a look through the 2500 datasheet. It appears that the host has full control of both the direction *and* hardware GPIO assignment though the platform-specific eSPI configuration register set. So, with VW GPIOs in hardware mode (ESPICTRL[9] = 0, the default), the host has arbitrary control of all hardware GPIO lines (except for the GPIOAC bank, I guess?). There's a huge security implication there - for example, GPIOs that assert physical presence can now be set by the host, possibly remotely - so I'd *strongly* recommend that we always get ESPICTRL[9] to 1, to set software-only mode. With than in mind, if we're disabling hardware mode - what does the direction control setting effect when we're in software mode (ESPICTRL[9] == 1)? Does it even matter? For example, what happens when the host goes a GET_VW cycle for a GPIO that is marked as 'master-to-slave' mode? Is the state of the GPIO in ESPI09C still reported? If that's the case, then we can just ignore the direction settings from ESPICFG800 completely, and have the BMC assign directions to standard gpiodevs as appropriate. Separate from this: I'm also proposing that we represent the system event VWs as gpiodevs as well. > A raw packet, primitive interface should have better flexibility to > manage MCTP packets over the OOB channel. OK, let me phrase this differently: can the OOB channel be used for anything other than SMBus messaging? Is it useful to provide an interface that isn't a standard SMBus/i2c device? If you need custom uapi definitions for this driver, that might be okay, but it's going to be more work for you (to define an interface that can be supported long-term), rather than using standard infrastructure that already exists. Cheers, Jeremy _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel