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

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: <CAHp75VeO4yr9fAx_-MHDnRGQn1paWF=59+o-9ZyP5PGSCPU8og@mail.gmail.com>
Date:   Fri, 12 Nov 2021 13:21:26 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        Rafał Miłecki <zajec5@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Rafał Miłecki <rafal@...ecki.pl>
Subject: Re: [PATCH RFC] dt-bindings: pinctrl: support specifying pins

On Fri, Nov 12, 2021 at 12:16 PM Tony Lindgren <tony@...mide.com> wrote:
> * Linus Walleij <linus.walleij@...aro.org> [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