linux-kernel - Re: [PATCH v2 1/3] dt-bindings: pinctrl: starfive,jh7110: add PAD_INTERNAL

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: <CACRpkdbPhKwjb0dkOom6HyzTrhPWvMPhX5M=nyxw1HBHNJa0fQ@mail.gmail.com>
Date: Mon, 28 Apr 2025 16:18:10 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: Icenowy Zheng <uwu@...nowy.me>
Cc: Emil Renner Berthing <kernel@...il.dk>, Jianlong Huang <jianlong.huang@...rfivetech.com>, 
	Hal Feng <hal.feng@...rfivetech.com>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-gpio@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 1/3] dt-bindings: pinctrl: starfive,jh7110: add
 PAD_INTERNAL_* virtual pins

On Thu, Apr 24, 2025 at 2:26 PM Icenowy Zheng <uwu@...nowy.me> wrote:
[Me]
> > I guess what rubs me the wrong way is why the external users
> > (devices, device drivers or even pin hogs) cannot trigger the chain
> > of
> > events leading to this configuration, instead of different "magic"
> > configurations that are just set up in the pin controller itself.
>
> Well I am just extending what's already in use...
>
> Currently it's already supported to route GPIOs to GPI signals, I added
> the support to route fixed level sources to them, in a similar way.
>
> If any external users ever have the need of banging the internal
> signals instead of tying it fixedly, maybe switching between different
> pinctrl configuration sets is enough? (Because this kind of operation
> could never be as high speed enough as real hardware pins)

What I am thinking is that one of the following must be true:

1. The internal pads are always set up the same way for this SoC
  in which case they should be just hardcoded instead, or at
  least just implied from the compatible string of the pin controller.

2. The internal pads are routed differently depending on different
  use cases, in which case they need to be set up or implied
  from configuration in other DT nodes describing this use.

I guess this binding if for (2)?

Yours,
Linus Walleij