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: <xc72g7j7png443pjxu2wpsuqofgrpxvn43emkt3rv5qrjzf7vt@qzvsiy3eakub>
Date: Thu, 3 Jul 2025 09:08:18 +0200
From: Thierry Reding <thierry.reding@...il.com>
To: Aaron Kling <webgeek1234@...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 Mon, Jun 30, 2025 at 02:23:42PM -0500, Aaron Kling wrote:
> 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?

Let's bring back the pinmux scripts. I don't have much time to look into
this right now. If you have some spare cycles to take a stab, that'd be
great.

For most of these newer chips it should be far less work to get this
going because we really only need the SoC bits, for which all of the
information is available. For earlier chips where all of the default
configuration had to be done by Linux there was a lot more generation
needed, but newer chips do all of the default settings in early
firmware, so we don't need a whole lot of pinmuxing in DT, only where
it deviates from the defaults.

Thierry

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