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: <CALHNRZ_1_WeUrfqUiOTsy3cEkwm2k7nj+4hA-7xZFgoA+DZKjg@mail.gmail.com>
Date: Fri, 1 Aug 2025 01:33:10 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Thierry Reding <thierry.reding@...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, Jul 23, 2025 at 6:08 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Mon, Jul 14, 2025 at 7:45 AM Aaron Kling <webgeek1234@...il.com> wrote:
>
> > 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.
>
> If this means people with 186 dev boards cannot use mainline
> Linux and they would if this driver was applied, maybe we need
> to apply it anyways?

I wouldn't call t186 unusable without it. The devkits work fine
without kernel pinmuxing as the bootloader configures everything to a
reasonable default. It's only if something non-standard (for example,
an audio codec) is plugged into one of the expansion headers that
runtime configuration could be needed. However, I do agree that it
would be worthwhile to move this forward for merging. Since it is
unlikely I will get the generation script to a usable state soon. If
Thierry or one of the other tegra maintainers agrees, I can start
addressing the review comments and send a new revision.

Aaron