Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6;
Message-ID: <e5f0a67e05cf477bdb4ec6efd9c554f4aaa2cf8b.camel@codeconstruct.com.au>
Subject: Re: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults
From:   Andrew Jeffery <andrew@codeconstruct.com.au>
To:     Zev Weiss <zev@bewilderbeest.net>,
        Linus Walleij <linus.walleij@linaro.org>,
        Joel Stanley <joel@jms.id.au>, 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

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