linux-kernel - Re: [PATCH v6 03/15] pinctrl: bcm: add bcm63xx base code

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: <CAL_JsqKSqQLUJB9OArwjtSgo5g4nPYLJFt+x54MwS+EHq0+Jww@mail.gmail.com>
Date:   Thu, 11 Mar 2021 11:24:28 -0700
From:   Rob Herring <robh+dt@...nel.org>
To:     Álvaro Fernández Rojas <noltari@...il.com>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        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 03/15] pinctrl: bcm: add bcm63xx base code

On Thu, Mar 11, 2021 at 10:00 AM Álvaro Fernández Rojas
<noltari@...il.com> wrote:
>
> Hi Rob and Linus,
>
> El 11/03/2021 a las 17:13, Linus Walleij escribió:
> > On Thu, Mar 11, 2021 at 3:58 PM Rob Herring <robh+dt@...nel.org> wrote:
> >> On Wed, Mar 10, 2021 at 6:09 PM Linus Walleij <linus.walleij@...aro.org> wrote:
> >>> On Wed, Mar 10, 2021 at 6:51 PM Rob Herring <robh+dt@...nel.org> wrote:
> >>>
> >>>>> +static const struct of_device_id bcm63xx_gpio_of_match[] = {
> >>>>> +       { .compatible = "brcm,bcm6318-gpio", },
> >>>>> +       { .compatible = "brcm,bcm6328-gpio", },
> >>>>> +       { .compatible = "brcm,bcm6358-gpio", },
> >>>>> +       { .compatible = "brcm,bcm6362-gpio", },
> >>>>> +       { .compatible = "brcm,bcm6368-gpio", },
> >>>>> +       { .compatible = "brcm,bcm63268-gpio", },
> >>>>
> >>>> All these would be moved to gpio-mmio.c (or maybe that can have a
> >>>> fallback compatible?).
> >>>
> >>> This is gpio-regmap.c and it can only be used as a library
> >>> by a certain driver. gpio-mmio.c can be used stand-alone
> >>> for certain really simple hardware (though most use that
> >>> as a library as well).
> >>
> >> I don't really care which one is used, but the problem is that this
> >> choice is leaking into the binding design.
> >
> > Aha I guess I misunderstood your comment.
> >
> >> The primary problem here is
> >> once someone uses regmap, then they think they must have a syscon and
> >> can abandon using 'reg' and normal address properties as Linux happens
> >> to not use them (currently). I think we really need some better regmap
> >> vs. mmio handling to eliminate this duplication of foo-mmio and
> >> foo-regmap drivers and difference in binding design. Not sure exactly
> >> what that looks like, but basically some sort of 'reg' property to
> >> regmap creation.
> >
> > I see the problem. Yeah we should try to be more strict around
> > these things. To me there are syscons and "other regmaps",
> > where syscon is a real hurdle of registers while "other regmaps"
> > are just regmaps by convenience.
> >
> > Documentation/devicetree/bindings/mfd/syscon.yaml
> > describes what a syscon really is so if everyone could
> > just read the documentation that would be great ...
> >
> >> Given we already have a Broadcom GPIO binding for what looks to be
> >> similar to this one, I'm left wondering what's the real difference
> >> here?
> >
> > Which one is similar? I can take a look.
>
> @Linus I think @Rob is referring to brcm,bcm6345-gpio:
> https://github.com/torvalds/linux/blob/a74e6a014c9d4d4161061f770c9b4f98372ac778/drivers/gpio/gpio-mmio.c#L686

Well, since it's the bindings we're talking about:
Documentation/devicetree/bindings/gpio/brcm,bcm6345-gpio.txt

Which says this:
"These bindings can be used on any BCM63xx SoC. However, BCM6338 and
BCM6345 are the only ones which don't need a pinctrl driver."

Not that the 1 in tree user of this is perfect. Seems like it too
should be a child of a system controller if there's other registers.

>
> However, the real difference between BCM6345 (and BCM6338) is that these
> SoCs have no pin controller at all, only a GPIO controller:
>
> BCM6345:
> typedef struct GpioControl {
>    uint16        unused0;
>    byte          unused1;
>    byte          TBusSel;
>    uint16        unused2;
>    uint16        GPIODir;
>    byte          unused3;
>    byte          Leds;
>    uint16        GPIOio;
>    uint32        UartCtl;
> } GpioControl;
>
> BCM6338:
> typedef struct GpioControl {
>    uint32        unused0;
>    uint32        GPIODir;      /* bits 7:0 */
>    uint32        unused1;
>    uint32        GPIOio;       /* bits 7:0 */
>    uint32        LEDCtrl;
>    uint32        SpiSlaveCfg;
>    uint32        vRegConfig;
> } GpioControl;
>
> BCM6348 and newer also have pinctrl.
> That's the main difference between that driver @Rob's referring to and
> the ones in this patch series.