From: Conor Dooley <conor@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Conor Dooley <conor.dooley@microchip.com>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [RFC 2/5] dt-bindings: pinctrl: add pic64gx "gpio2" pinmux
Date: Mon, 13 Oct 2025 12:22:54 +0100 [thread overview]
Message-ID: <20251013-grouped-dictation-83e84fb989db@spud> (raw)
In-Reply-To: <CACRpkdYi_n0VcN78eTCty+rVvTnSPFa-pRGOw1LFziBd_2vwBw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
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@kernel.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..
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2025-10-13 11:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 14:33 [RFC 0/5] microchip mpfs/pic64gx pinctrl questions Conor Dooley
2025-09-26 14:33 ` [RFC 1/5] dt-bindings: pinctrl: add polarfire soc iomux0 pinmux Conor Dooley
2025-09-26 14:33 ` [RFC 2/5] dt-bindings: pinctrl: add pic64gx "gpio2" pinmux Conor Dooley
2025-10-01 11:32 ` Linus Walleij
2025-10-01 15:47 ` Conor Dooley
2025-10-01 15:48 ` Conor Dooley
2025-10-13 10:56 ` Linus Walleij
2025-10-13 11:22 ` Conor Dooley [this message]
2025-09-26 14:33 ` [RFC 3/5] pinctrl: add polarfire soc iomux0 pinmux driver Conor Dooley
2025-10-01 11:34 ` Linus Walleij
2025-10-01 11:36 ` Linus Walleij
2025-10-01 15:45 ` Conor Dooley
2025-10-13 11:02 ` Linus Walleij
2025-10-13 11:42 ` Conor Dooley
2025-10-14 10:27 ` Linus Walleij
2025-09-26 14:33 ` [RFC 4/5] pinctrl: add pic64gx "gpio2" " Conor Dooley
2025-09-26 14:33 ` [RFC 5/5] riscv: dts: microchip: add pinctrl nodes for iomux0 Conor Dooley
2025-10-01 11:29 ` [RFC 0/5] microchip mpfs/pic64gx pinctrl questions Linus Walleij
2025-10-01 16:00 ` Conor Dooley
2025-10-01 16:15 ` Conor Dooley
2025-10-09 15:55 ` Conor Dooley
2025-10-13 13:27 ` Linus Walleij
2025-10-13 13:55 ` Conor Dooley
2025-10-14 10:33 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251013-grouped-dictation-83e84fb989db@spud \
--to=conor@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).