From: Rob Herring <robh@kernel.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
"ext Tony Lindgren" <tony@atomide.com>,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, "Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH RFC] dt-bindings: pinctrl: support specifying pins
Date: Thu, 11 Nov 2021 13:53:20 -0600 [thread overview]
Message-ID: <YY10sIZ7BdAebR59@robh.at.kernel.org> (raw)
In-Reply-To: <CACRpkdbAS0JiqTQUU0R0yRhVCwagubwsNYLxj1DLE1Ldc+H_JQ@mail.gmail.com>
On Thu, Nov 11, 2021 at 04:31:28PM +0100, Linus Walleij wrote:
> On Thu, Nov 11, 2021 at 12:14 AM Rafał Miłecki <zajec5@gmail.com> wrote:
>
> > While working with pinctrl in Linux I started wondering if we could
> > start specifying pins in DT instead of Linux drivers. When working with
> > DT we usually avoid hardcoding hardware description in drivers so it
> > isn't clear to me why it doesn't apply to pins.
I thought we were...
> Historically this is what pinctrl-single.c does.
> Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
>
> At the time we created pin control there was a bit back-and-forth and
> the conclusion was that there is not one-size-fits all for pin defines.
>
> The reason TI (Tony) wanted to push the information into DT
> was that what he gets is a number of unprocessed ASIC datasets,
> that are then turned into tables with a script. Header files or DTS
> source alike, but some kind of tables.
>
> At the time (2011?) it was unclear what kind of data should go into
> e.g. header and data files in the kernel (modules) and what should
> go into the DT. So the approach to put pin information into the DT
> was allowed for pinctrl-single.
>
> The way I have understood it, DT maintainers have since gotten
> a bit wary about (ab)using the DT as a container for "anything data"
> and prefer that drivers contain details and derive these from
> compatible strings.
>
> As of today, IIUC the DT maintainers are against this scheme.
The question is more can the data be static (complete) and correct? That
doesn't work for quirk properties nor entire clock trees with a node per
clock.
Pins? Maybe. That's a flat thing and you should know all the pins up
front.
Rob
next prev parent reply other threads:[~2021-11-11 19:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-10 23:14 [PATCH RFC] dt-bindings: pinctrl: support specifying pins Rafał Miłecki
2021-11-11 15:31 ` Linus Walleij
2021-11-11 19:53 ` Rob Herring [this message]
2021-11-12 10:16 ` Tony Lindgren
2021-11-12 11:21 ` Andy Shevchenko
2021-11-12 12:16 ` Tony Lindgren
2021-11-12 12:20 ` Andy Shevchenko
2021-11-11 20:06 ` Rob Herring
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=YY10sIZ7BdAebR59@robh.at.kernel.org \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafal@milecki.pl \
--cc=tony@atomide.com \
--cc=zajec5@gmail.com \
/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).