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]

Date:   Fri, 12 Nov 2021 14:16:35 +0200
From:   Tony Lindgren <tony@...mide.com>
To:     Andy Shevchenko <andy.shevchenko@...il.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

* Andy Shevchenko <andy.shevchenko@...il.com> [211112 11:22]:
> > 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.

I think you are misunderstanding what I mean here. Certainly the driver
needs to know how to deal with the SoC specific hardware. And that we
can easily do that in quite easily already. The device tree data I'm
describing would be similar to the interrupts with instance offset and
generic mux flags.

See for example the driver for drivers/pinctrl/ti/pinctrl-ti-iodelay.c.
For that driver we have the instance and picosecond iodelay values in
the devicetree, and with #nr-pinctrl cells there could be some generic
pinctrl mux flags. We are missing the generic pinctrl flags part AFAIK.

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

Hmm I don't think we have any of that for what I'm describing. But
please take a look at the iodelay example above, maybe I'm not
following.

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

Agreed we need a generic labeling schema.

Regards,

Tony