From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Jeffery Date: Thu, 05 Oct 2023 11:47:50 +1030 Subject: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults In-Reply-To: <20231004071605.21323-2-zev@bewilderbeest.net> References: <20231004071605.21323-2-zev@bewilderbeest.net> Message-ID: List-Id: To: linux-aspeed@lists.ozlabs.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Wed, 2023-10-04 at 00:16 -0700, Zev Weiss wrote: > Previously we've generally assumed that the defaults in the hardware > strapping register are in fact appropriate for the system and thus > have avoided making any changes to its contents (with the exception of > the bits controlling the GPIO passthrough feature). > > Unfortunately, on some platforms corrections from software are > required as the hardware strapping is simply incorrect for the system > (such as the SPI1 interface being configured for passthrough mode when > master mode is in fact the only useful configuration for it). We thus > remove the checks preventing changes to the strap register so that the > pinctrl subsystem can be used for such corrections. So the strapping for the SPI1 configuration seems to be prone to (copy/paste?) mistakes. Is there evidence that motivates dropping all the protection instead of poking a hole for SPI1 like we did for the passthrough GPIOs? I'm still a little attached to the policy that software should be beholden to the strapping, and to try to mitigate software mistakes given the smattering of bits required to drive the Aspeed pinmux. Andrew 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81249E936F0 for ; Thu, 5 Oct 2023 01:17:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244289AbjJEBR6 (ORCPT ); Wed, 4 Oct 2023 21:17:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244241AbjJEBR5 (ORCPT ); Wed, 4 Oct 2023 21:17:57 -0400 Received: from codeconstruct.com.au (pi.codeconstruct.com.au [203.29.241.158]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA469C6; Wed, 4 Oct 2023 18:17:54 -0700 (PDT) Received: from [192.168.68.112] (ppp118-210-84-62.adl-adc-lon-bras32.tpg.internode.on.net [118.210.84.62]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 8B8D1200DB; Thu, 5 Oct 2023 09:17:51 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1696468672; bh=WN/ilaCxe3QgMddZZjU7PId19PdgcBpr/ZP9C7Gmuag=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=m9x/vKg/TE3TAGrcLxTojNzClrEkgYnOEY5+tf8xe76QiqAhHIeMjif1oQec6sjbL CcLutjUOP4/x2v5wDlX6JEfJ8iO3sFLOS+VVSRT6IbtsC7d0lI8rBShKgChEaGp4k8 N3/L7kqwcY4VqvrStpYmNLwcR67dHYh8kYnUUdneo9S0IU8nVRq5DqlDqR5qX+Q08M Vi/4W18RcVM5VsxUv/BTFv4ASfhE6ZP5krKuY8Zcoon8WFB7dosKCDDrN3CsB30B8c YI4QZmkNccNHGsOr4AueM848o8vtRNwvshBjzznt2Ei/8qA/6n8pIaB4gyUDLjlixk j/cExR+TeHnNg== Message-ID: Subject: Re: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults From: Andrew Jeffery To: Zev Weiss , Linus Walleij , Joel Stanley , linux-aspeed@lists.ozlabs.org Cc: openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Thu, 05 Oct 2023 11:47:50 +1030 In-Reply-To: <20231004071605.21323-2-zev@bewilderbeest.net> References: <20231004071605.21323-2-zev@bewilderbeest.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Wed, 2023-10-04 at 00:16 -0700, Zev Weiss wrote: > Previously we've generally assumed that the defaults in the hardware > strapping register are in fact appropriate for the system and thus > have avoided making any changes to its contents (with the exception of > the bits controlling the GPIO passthrough feature). >=20 > Unfortunately, on some platforms corrections from software are > required as the hardware strapping is simply incorrect for the system > (such as the SPI1 interface being configured for passthrough mode when > master mode is in fact the only useful configuration for it). We thus > remove the checks preventing changes to the strap register so that the > pinctrl subsystem can be used for such corrections. So the strapping for the SPI1 configuration seems to be prone to (copy/paste?) mistakes. Is there evidence that motivates dropping all the protection instead of poking a hole for SPI1 like we did for the passthrough GPIOs? I'm still a little attached to the policy that software should be beholden to the strapping, and to try to mitigate software mistakes given the smattering of bits required to drive the Aspeed pinmux. Andrew 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 9BFCDE936F0 for ; Thu, 5 Oct 2023 01:18:55 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.a=rsa-sha256 header.s=2022a header.b=m9x/vKg/; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4S1DGk0V1Kz3cQr for ; Thu, 5 Oct 2023 12:18:54 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=codeconstruct.com.au header.i=@codeconstruct.com.au header.a=rsa-sha256 header.s=2022a header.b=m9x/vKg/; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=codeconstruct.com.au (client-ip=203.29.241.158; helo=codeconstruct.com.au; envelope-from=andrew@codeconstruct.com.au; receiver=lists.ozlabs.org) 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)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4S1DFX5Sgsz3bd6; Thu, 5 Oct 2023 12:17:52 +1100 (AEDT) Received: from [192.168.68.112] (ppp118-210-84-62.adl-adc-lon-bras32.tpg.internode.on.net [118.210.84.62]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 8B8D1200DB; Thu, 5 Oct 2023 09:17:51 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1696468672; bh=WN/ilaCxe3QgMddZZjU7PId19PdgcBpr/ZP9C7Gmuag=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=m9x/vKg/TE3TAGrcLxTojNzClrEkgYnOEY5+tf8xe76QiqAhHIeMjif1oQec6sjbL CcLutjUOP4/x2v5wDlX6JEfJ8iO3sFLOS+VVSRT6IbtsC7d0lI8rBShKgChEaGp4k8 N3/L7kqwcY4VqvrStpYmNLwcR67dHYh8kYnUUdneo9S0IU8nVRq5DqlDqR5qX+Q08M Vi/4W18RcVM5VsxUv/BTFv4ASfhE6ZP5krKuY8Zcoon8WFB7dosKCDDrN3CsB30B8c YI4QZmkNccNHGsOr4AueM848o8vtRNwvshBjzznt2Ei/8qA/6n8pIaB4gyUDLjlixk j/cExR+TeHnNg== Message-ID: Subject: Re: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults From: Andrew Jeffery To: Zev Weiss , Linus Walleij , Joel Stanley , linux-aspeed@lists.ozlabs.org Date: Thu, 05 Oct 2023 11:47:50 +1030 In-Reply-To: <20231004071605.21323-2-zev@bewilderbeest.net> References: <20231004071605.21323-2-zev@bewilderbeest.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 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: linux-gpio@vger.kernel.org, openbmc@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On Wed, 2023-10-04 at 00:16 -0700, Zev Weiss wrote: > Previously we've generally assumed that the defaults in the hardware > strapping register are in fact appropriate for the system and thus > have avoided making any changes to its contents (with the exception of > the bits controlling the GPIO passthrough feature). >=20 > Unfortunately, on some platforms corrections from software are > required as the hardware strapping is simply incorrect for the system > (such as the SPI1 interface being configured for passthrough mode when > master mode is in fact the only useful configuration for it). We thus > remove the checks preventing changes to the strap register so that the > pinctrl subsystem can be used for such corrections. So the strapping for the SPI1 configuration seems to be prone to (copy/paste?) mistakes. Is there evidence that motivates dropping all the protection instead of poking a hole for SPI1 like we did for the passthrough GPIOs? I'm still a little attached to the policy that software should be beholden to the strapping, and to try to mitigate software mistakes given the smattering of bits required to drive the Aspeed pinmux. Andrew 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3AB21E936F0 for ; Thu, 5 Oct 2023 01:18:22 +0000 (UTC) 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=qdEKb8Ky0Lt5Cy2AERxpzx8DsUHUaB3jS4e/c3VAdPk=; b=YjQLx8W+iFcB8F fBLr3jJPx6CUIehe7+93GNoTWH4b9dWT01Jje4LOcuJ5viEZQkgqf2BeorKQwZq4RUTrpK1syzuX1 ++L9340UHVx+Kr/nDJcwg60ucqAz1WBd3X6yjTGrXcq0WE0FJo8Ia/A8YcMd4EH2o97ng5Wpyh330 1Id8gHd+KYhERTkPa/hj/OSPvXXDJjHeXYO+ywT47VbO++D9XI1/sN2PwLNcg+QaHMT1hf/FUz0vf leQHaESfHJ9u5oAMk9Sb8Qn/CA0JSOiPRn6+tpqYpbqI85xjmmUfkIjERSIO9f1QOFDl+G1ROGOJm v4sPAyQZG327DPyMQlmQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qoD01-001C3J-2G; Thu, 05 Oct 2023 01:17:57 +0000 Received: from pi.codeconstruct.com.au ([203.29.241.158] helo=codeconstruct.com.au) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qoCzx-001C2A-2r for linux-arm-kernel@lists.infradead.org; Thu, 05 Oct 2023 01:17:55 +0000 Received: from [192.168.68.112] (ppp118-210-84-62.adl-adc-lon-bras32.tpg.internode.on.net [118.210.84.62]) by mail.codeconstruct.com.au (Postfix) with ESMTPSA id 8B8D1200DB; Thu, 5 Oct 2023 09:17:51 +0800 (AWST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeconstruct.com.au; s=2022a; t=1696468672; bh=WN/ilaCxe3QgMddZZjU7PId19PdgcBpr/ZP9C7Gmuag=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=m9x/vKg/TE3TAGrcLxTojNzClrEkgYnOEY5+tf8xe76QiqAhHIeMjif1oQec6sjbL CcLutjUOP4/x2v5wDlX6JEfJ8iO3sFLOS+VVSRT6IbtsC7d0lI8rBShKgChEaGp4k8 N3/L7kqwcY4VqvrStpYmNLwcR67dHYh8kYnUUdneo9S0IU8nVRq5DqlDqR5qX+Q08M Vi/4W18RcVM5VsxUv/BTFv4ASfhE6ZP5krKuY8Zcoon8WFB7dosKCDDrN3CsB30B8c YI4QZmkNccNHGsOr4AueM848o8vtRNwvshBjzznt2Ei/8qA/6n8pIaB4gyUDLjlixk j/cExR+TeHnNg== Message-ID: Subject: Re: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults From: Andrew Jeffery To: Zev Weiss , Linus Walleij , Joel Stanley , linux-aspeed@lists.ozlabs.org Cc: openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Date: Thu, 05 Oct 2023 11:47:50 +1030 In-Reply-To: <20231004071605.21323-2-zev@bewilderbeest.net> References: <20231004071605.21323-2-zev@bewilderbeest.net> User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231004_181754_110415_BAF43CAB X-CRM114-Status: GOOD ( 15.11 ) 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 On Wed, 2023-10-04 at 00:16 -0700, Zev Weiss wrote: > Previously we've generally assumed that the defaults in the hardware > strapping register are in fact appropriate for the system and thus > have avoided making any changes to its contents (with the exception of > the bits controlling the GPIO passthrough feature). > > Unfortunately, on some platforms corrections from software are > required as the hardware strapping is simply incorrect for the system > (such as the SPI1 interface being configured for passthrough mode when > master mode is in fact the only useful configuration for it). We thus > remove the checks preventing changes to the strap register so that the > pinctrl subsystem can be used for such corrections. So the strapping for the SPI1 configuration seems to be prone to (copy/paste?) mistakes. Is there evidence that motivates dropping all the protection instead of poking a hole for SPI1 like we did for the passthrough GPIOs? I'm still a little attached to the policy that software should be beholden to the strapping, and to try to mitigate software mistakes given the smattering of bits required to drive the Aspeed pinmux. Andrew _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel