Re: [PATCH RFC] dt-bindings: pinctrl: support specifying pins

[Andy Shevchenko]

On Fri, Nov 12, 2021 at 12:16 PM Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * Linus Walleij <linus.walleij@xxxxxxxxxx> [211111 15:32]:
> > 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.
>
> We have some newish tools now compared 2011 though with #pinctrl-cells.
> And we now have also GENERIC_PINCTRL_GROUPS, GENERIC_PINMUX_FUNCTIONS
> and GENERIC_PINCONF :)
>
> The problem with the pinctrl-single binding is that it uses the hardware
> specific mux values in addition to the mux register offsets. IMO the
> values should use Linux generic pinctrl defines instead. Just like we
> do for the gpio and interrupt bindings. And then the generic pinctrl
> binding would be very similar to the interrupts-extended binding for
> example.
>
> And with a generic pinctrl binding pinctrl-single could be updated to
> parse the generic binding naturally too in addition to the legacy
> binding.
>
> > That said, the topic is open in a way. Some people are also annoyed
> > that some graphics drivers just ask Torvalds to pull 100.000+ lines
> > of register defnes in some merge windows. The data has to go
> > somewhere.
>
> Yes and the amount of SoC specific LOC under drivers/pinctrl is pretty
> staggering already.
>
> With all that SoC specific data built into the kernel, it's like going
> camping with all your pants stuffed into your car instead of just the
> pants you need :)
>
> We only need the SoC specific data for the booted SoC, so devicetree
> and loadable modules makes more sense there compared to the current
> built-in setup.

I'm against putting that into DT and here is why.

DT is the thing that describes the _platform_. While it's fine to put
GPIO expander thingy (and we actually do this with labeling schema for
GPIOs, right?), the SoC level of things is a _hardware_ and with all
flexibility the DT gives us we will definitely have a deviations on
_different_ platforms with _the same_ SoC! To work around this we must
have a validation of the pin names and their functions in many places.

And last but not least the copying it in tons of DT feels like a
duplication effort.,

AFAIU the topic, the pin control lacks labeling schema that will
provide the view from the platform perspective, while driver provides
from HW perspective.

-- 
With Best Regards,
Andy Shevchenko