linux-kernel - Re: [RFC 2/5] dt-bindings: pinctrl: add pic64gx "gpio2" pinmux

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: <20251013-grouped-dictation-83e84fb989db@spud>
Date: Mon, 13 Oct 2025 12:22:54 +0100
From: Conor Dooley <conor@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Conor Dooley <conor.dooley@...rochip.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [RFC 2/5] dt-bindings: pinctrl: add pic64gx "gpio2" pinmux

On Mon, Oct 13, 2025 at 12:56:42PM +0200, Linus Walleij wrote:
> On Wed, Oct 1, 2025 at 5:47 PM Conor Dooley <conor@...nel.org> wrote:
> 
> > tbh, I found it hard to understand the "line" between using a pinmux
> > property and where stuff should be described in groups or functions in a
> > driver. What is that line?
> 
> There is no such line, basically what I like as pin control maintainer
> is what exists in the documentation with groups and functions.
> 
> Then various driver maintainers have pushed me around since
> day 1 because they think it is much more convenient to just
> have some single value to poke into a register.
> 
> I have come to accept both because the discussions just
> go on forever. I'm not a very stern person, "those are my
> principles, if you don't like them, I have others".

Right, I see. Currently I have 3 drivers, two being what are here. Both
of those I have converted to use functions and groups. The third retains
the pinmux property, mostly because of the number of functions that each
pin can be routed due to being an FPGA. I'll send the first two in the
coming day or two and see what to do about the third. It's got much more
going on and no internal pressure to get it working, unlike these the
first two that folks have expressed a need for.

> Essentially it is a question about what the device tree is for:
> is it just for (outline) description and configuration of hardware
> for a specific system, i.e. where everything that is not
> system-specific should be encoded into the driver, or is it
> for dumping all kind of various SoC-specific stuff into, without
> abstraction. There is no clear line there either, and that is
> part of the problem here.

Now that I have some understanding about how this stuff works, I can
start whinging about people using these pinmux properties if you want.
I'm probably biased by my own laziness and not wanting to write out
dozens and dozens of groups etc, but in cases where there's only two or
three functions per pin, using functions/groups seems like the way to
go..

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