linux-kernel - Re: [PATCH v2 2/3] pinctrl: tegra: Add Tegra186 pinmux driver

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] [day] [month] [year] [list]

Message-ID: <yslfabklduaybg255d3ulaxmzpghyj54zdfeqkx3oxgisxf6fo@2wecuqpvvefc>
Date: Wed, 11 Jun 2025 17:23:00 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: webgeek1234@...il.com, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Jonathan Hunter <jonathanh@...dia.com>, Bartosz Golaszewski <brgl@...ev.pl>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/3] pinctrl: tegra: Add Tegra186 pinmux driver

On Wed, Jun 11, 2025 at 08:58:49AM +0200, Linus Walleij wrote:
> On Tue, Jun 10, 2025 at 11:40 AM Thierry Reding
> <thierry.reding@...il.com> wrote:
> 
> > One thing that's not clear from this patch set is whether we actually
> > need the Tegra186 pinmux driver, or you're only adding it because it
> > happens to be present in a 5.10 downstream driver. Do you actually have
> > a requirement for setting pins dynamically at runtime? Do you need to be
> > able to set a static configuration at boot that can't be set using some
> > earlier bootloader/firmware mechanism?
> 
> Actually, speaking as the maintainer of pin control I hear the following
> a lot:
> 
> - We don't need pin control, the BIOS/firmware deals with it
> - We don't need runtime pin control, the BIOS/firmware deals
>   with it
> - We don't need runtime pin control, static set-up should be
>   enough
> 
> These are all enthusiastic estimates, but in practice, for any
> successful SoC we always need pin control. Either the BIOS
> firmware authors got things wrong or made errors (bugs) and
> there is no path to upgrade the firmware safely, or runtime
> usecases appear that no-one ever thought about.
> 
> Aarons case looks like that latter.

This was a long time ago now, but I have a vague recollection about
hardware engineers telling software engineers that muxing pins
dynamically at runtime wasn't safe for all pins and hence we had to
do static configuration during early boot.

But then along came devkits with expansion headers and then people
started using scripts to mux pins to the right functions and such.

> I think it'd be wise to send the message to any SoC system
> architects (or Linux base port overseer or whatever title
> this person may have) that a pin control driver is usually
> needed.
> 
> The SCMI people heard the message and have added pin
> control into the specification for that firmware interface.

I'd agree with you that there's plenty of evidence that we need these
drivers, so maybe I need to go back and look at what exactly the risks
are that come with this and maybe there's something we need to do to
avoid that (I'm thinking along the lines of certain pins being generally
safe to mux at runtime, but not all).

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)