linux-kernel - Re: [PATCH v6 04/15] dt-bindings: add BCM6328 pincontroller binding documentation

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] [day] [month] [year] [list]

Date:   Mon, 15 Mar 2021 16:57:33 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Álvaro Fernández Rojas <noltari@...il.com>,
        Michael Walle <michael@...le.cc>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" 
        <bcm-kernel-feedback-list@...adcom.com>,
        Jonas Gorski <jonas.gorski@...il.com>,
        Necip Fazil Yildiran <fazilyildiran@...il.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v6 04/15] dt-bindings: add BCM6328 pincontroller binding documentation

On Thu, Mar 11, 2021 at 7:14 PM Rob Herring <robh+dt@...nel.org> wrote:

> > Or this way (2):
> > syscon {
> >         compatible = "brcm,bcm6328-gpio-regs", "syscon", "simple-mfd";
> >         reg = <0x10000080 0x80>;
> >         ranges = <0 0x10000080 0x80>;
> >
> >         pinctrl: pinctrl@18 {
> >                 compatible = "brcm,bcm6328-pinctrl";
> >                 reg = <0x0 0x28>;
> >
> >                 gpio: gpio@0 {
>
> This doesn't make sense IMO because GPIO is not a sub-function of the
> pinctrl h/w. They are peers.

This becomes an ontological discussion, as in "what does the world
consist of and what are the proper definitions of the
things in it".

A couple of years back I had this presentation:
https://dflund.se/~triad/papers/pincontrol.pdf
where I try to investigate how hardware engineers build
these blocks.

TL;DR: it depends on what the hardware engineer
did.

A HW block can be pin controller, GPIO controller
and interrupt chip at the same time, that case is
straight-forward. One compatible, lots of
properties.
.
A second case is when the pin controller and the
GPIO+irqchip are two completely different HW
entities, and then they also get two different
device nodes on the same level in the device tree.
(We usually see this when the different blocks
live in totally different memory locations.)

However in the third case HW can also be bolted
with a front-end pin controller (facing the pins) with
several GPIO+interrupt controller back-ends.
Then it gets the structure in this patch,
subnodes for each GPIO controller.

Our current bindings have all three examples
and it simply reflects the different ways HW
engineers have chosen to integrate their stuff.

Yours,
Linus Walleij