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

Message-ID: <CALHNRZ8jq++KVKxKP2-GwMA6CauP=cM2_wt==MRAV4mOzK2kxw@mail.gmail.com>
Date: Mon, 30 Jun 2025 14:23:42 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Linus Walleij <linus.walleij@...aro.org>, 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 10:23 AM Thierry Reding
<thierry.reding@...il.com> wrote:
>
> 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

So what's the path forward on this? Will this series be used, or is
Nvidia going to bring back the pinmux scripts and regenerate
everything in a new series?

Aaron