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_Jsq+FfYE2SrzwB_A=d-LMut-JrqdivKz6x8EQhkc3Zh5NAA@mail.gmail.com>
Date:   Thu, 11 Mar 2021 07:57:55 -0700
From:   Rob Herring <robh+dt@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.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 03/15] pinctrl: bcm: add bcm63xx base code

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. 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.

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?

Rob