linux-kernel - Re: [RFC 3/5] pinctrl: add polarfire soc iomux0 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: <20251013-spoiling-halogen-4e56c4bc83dd@spud>
Date: Mon, 13 Oct 2025 12:42:39 +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 3/5] pinctrl: add polarfire soc iomux0 pinmux driver

On Mon, Oct 13, 2025 at 01:02:35PM +0200, Linus Walleij wrote:
> On Wed, Oct 1, 2025 at 5:45 PM Conor Dooley <conor@...nel.org> wrote:
> 
> > They're not actually package pins at all that are being configured here,
> > it's internal routing inside the FPGA. It does operate on a function
> > level, but I don't think there's a neat mapping to the pinctrl subsystem
> > which (AFAIU) considers functions to contain groups, which in turn
> > contain pins. I suppose it could be thought of that, for example, spi0
> > is actually a function containing 4 (or 5, don't ask - or do if you want
> > to read a rant about pointlessly confusing design) "pins" in 1 group.
> >
> > If I could just work in terms of functions only, and avoid groups or
> > pins at all, feels (to me ofc) like it'd maybe match the purpose of this
> > aspect of the hardware better.
> 
> What I would ask myself is whether the abstraction fits the bill,
> like if there is a natural set of functions in the silicon, then the code
> should reflect that.
> 
> When it comes to those:
> 
> +static const struct pinctrl_pin_desc mpfs_iomux0_pinctrl_pins[] = {
> +       PINCTRL_PIN(0, "spi0"),
> +       PINCTRL_PIN(1, "spi1"),
> 
> At least be careful with the nouns used: are they really "pins"?
> Should they be described as "pins"?

I think that my choices if talking to someone outside of the context of
the structure of the pinctrl subsystem would be functions (for what's in
the driver as pins) and routings (instead of groups). pinctrl's function
doesn't really do very much in this context, although the devicetree
function and groups I think actually work fairly well: "function ABC is
assigned to pin 1".
Regarding nouns, I think it depends on how far you go with that...

> Maybe it is best to come up with some custom struct if not?

...because taking that to an extreme means forsaking a lot (all) of the
common pinctrl infrastructure, no? If it's just choosing more apt names
for variables/functions in the driver or redefining PINCTRL_PIN to be
something more suitably named, then sure. But if I have to avoid using
pinctrl_pin_desc et al, am I going to lose out on a bunch of useful
common code?

I'll send my v2 on tomorrow probably, and we can talk about what exact
changes should be made there?

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