linux-kernel - Re: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e5f0a67e05cf477bdb4ec6efd9c554f4aaa2cf8b.camel@codeconstruct.com.au>
Date:   Thu, 05 Oct 2023 11:47:50 +1030
From:   Andrew Jeffery <andrew@...econstruct.com.au>
To:     Zev Weiss <zev@...ilderbeest.net>,
        Linus Walleij <linus.walleij@...aro.org>,
        Joel Stanley <joel@....id.au>, linux-aspeed@...ts.ozlabs.org
Cc:     openbmc@...ts.ozlabs.org, linux-gpio@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: aspeed: Allow changing hardware strap defaults

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