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 for Android: free password hash cracker in your pocket

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

Message-ID: <CACRpkdZha_ucjWvP_NQ+z2vbD65Y3u7Q0U57NYbJ=vqQ6uPGGA@mail.gmail.com>
Date: Wed, 11 Jun 2025 08:58:49 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Thierry Reding <thierry.reding@...il.com>
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 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.

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.

Yours,
Linus Walleij