linux-kernel - Re: [PATCH v2 1/5] dt-bindings: Add compatible string opencores,gpio to gpio-mmio

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: <CAMuHMdXYCNR0ANn152ghFExpWY_yZ5+kyFGGRwA+X-EFUvxZXw@mail.gmail.com>
Date: Thu, 8 Jan 2026 09:41:37 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
To: Stafford Horne <shorne@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>, 
	Linux OpenRISC <linux-openrisc@...r.kernel.org>, Bartosz Golaszewski <brgl@...nel.org>, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	linux-gpio@...r.kernel.org, devicetree@...r.kernel.org, 
	Linus Walleij <linusw@...nel.org>
Subject: Re: [PATCH v2 1/5] dt-bindings: Add compatible string opencores,gpio
 to gpio-mmio

Hi Stafford,

(reviving linusw)

On Thu, 8 Jan 2026 at 09:20, Stafford Horne <shorne@...il.com> wrote:
> On Wed, Jan 07, 2026 at 03:35:45PM +0100, Geert Uytterhoeven wrote:
> > On Wed, 17 Dec 2025 at 09:15, Stafford Horne <shorne@...il.com> wrote:
> > > In FPGA Development boards with GPIOs we use the opencores gpio verilog
> > > rtl.  This is compatible with the gpio-mmio.  Add the compatible string
> > > to allow as below.
> > >
> > > Example:
> > >
> > >         gpio0: gpio@...00000 {
> > >                 compatible = "opencores,gpio", "brcm,bcm6345-gpio";
> > >                 reg = <0x91000000 0x1>, <0x91000001 0x1>;
> > >                 reg-names = "dat", "dirout";
> > >                 gpio-controller;
> > >                 #gpio-cells = <2>;
> > >                 status = "okay";
> > >         };
> > >
> > > Link: https://opencores.org/projects/gpio
> > > Signed-off-by: Stafford Horne <shorne@...il.com>
> >
> > Thanks for your patch, which is now commit f48b5e8bc2e1344f
> > ("dt-bindings: gpio-mmio: Add compatible string for opencores,gpio")
> > in gpio/gpio/for-next.
> >
> > > --- a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> > > +++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
> > > @@ -18,11 +18,16 @@ description:
> > >
> > >  properties:
> > >    compatible:
> > > -    enum:
> > > -      - brcm,bcm6345-gpio
> > > -      - ni,169445-nand-gpio
> > > -      - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
> > > -      - intel,ixp4xx-expansion-bus-mmio-gpio
> > > +    oneOf:
> > > +      - enum:
> > > +          - brcm,bcm6345-gpio
> > > +          - ni,169445-nand-gpio
> > > +          - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
> > > +          - intel,ixp4xx-expansion-bus-mmio-gpio
> > > +      - items:
> > > +          - enum:
> > > +              - opencores,gpio
> > > +          - const: brcm,bcm6345-gpio
> >
> > What is the rationale behind using brcm,bcm6345-gpio?
> > Given brcm,bcm6345-gpio has 32-bit registers, while opencores,gpio
> > has 8-bit registers, I doubt the latter is compatible with the former...

> I was following what we did for uart, where we have
> "opencores,uart16550-rtlsvn105", "ns16550a".

I assume the former is a 100% compatible plug-in for the latter.

> I am using brcm,bcm6345-gpio to match the drivers/gpio/gpio-mmio.c driver.
> The opencores,gpio is compatible with the same driver as brcm,bcm6345-gpio but
> not 100% the same as the brcm,bcm6345-gpio.  Since the device tree allows
> configuring the gpio-mmio driver to make it compatible with opencore,gpio I
> thought this would be OK.
>
> I switch the size from 32-bit to 8-bit using the reg = <* 0x1>, <* 0x1> setting.
> Also the reg addresses of "dat" and "dirout" are different for the real
> brcm,bcm6345-gpio.
>
> brcm,bcm6345-gpio. Example:
>
>        /* GPIOs 192 .. 223 */
>        gpio6: gpio@518 {
>                compatible = "brcm,bcm6345-gpio";
>                reg = <0x518 0x04>, <0x538 0x04>;
>                reg-names = "dirout", "dat";
>                gpio-controller;
>                #gpio-cells = <2>;
>        };
>
> vs opencores,gpio Example:
>
>        gpio0: gpio@...00000 {
>                compatible = "opencores,gpio", "brcm,bcm6345-gpio";
>                reg = <0x91000000 0x1>, <0x91000001 0x1>;
>                reg-names = "dat", "dirout";
>                gpio-controller;
>                #gpio-cells = <2>;
>        };

Exactly, the register space and register widths are different

> The opencores,gpio setup does work.
>
> Now that I think about it, would it have been better to just add opencores,gpio
> to gpio-mmio.c compatible list?

I think that would be better.

> If so I will can revise this patch and add patch to gpio-mmio.c.

DT maintainers: Given gpio-mmio is that generic/simple, is there a
specific reason there is no generic "gpio-mmio" compatible value that
can be used as a fallback, avoiding the need to keep on adding new
entries to gpio_mmio_of_match[]?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds