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: <CALHNRZ928+=85FbvfKt1c4VX7RudU7ehuOa6wwLj8JJNz+=W-A@mail.gmail.com>
Date: Mon, 14 Jul 2025 00:45:39 -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 Thu, Jul 3, 2025 at 2:08 AM Thierry Reding <thierry.reding@...il.com> wrote:
>
> 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.

I started looking at the pinmux scripts a few days ago, but updating
the pinmux driver import/export for the t194 style spiderwebbed out of
control quickly. I expected it to be hairy, but that was an
underestimation. Doesn't help that I'm not the most proficient at
python either. I'll continue the effort later, but if someone with
more familiarity wants to try, it might be quicker.

Aaron