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@91000000 {
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@gmail.com>
---
Since v1:
- Fix schema to actually match the example.
.../devicetree/bindings/gpio/gpio-mmio.yaml | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
index b4d55bf6a285..6fcf5fd2cb66 100644
--- 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
big-endian: true
--
2.51.0Hi Stafford,
On Wed, 17 Dec 2025 at 09:15, Stafford Horne <shorne@gmail.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@91000000 {
> 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@gmail.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...
>
> big-endian: true
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
On Wed, Jan 07, 2026 at 03:35:45PM +0100, Geert Uytterhoeven wrote:
> Hi Stafford,
>
> On Wed, 17 Dec 2025 at 09:15, Stafford Horne <shorne@gmail.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@91000000 {
> > 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@gmail.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...
Hello,
I was following what we did for uart, where we have
"opencores,uart16550-rtlsvn105", "ns16550a".
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@91000000 {
compatible = "opencores,gpio", "brcm,bcm6345-gpio";
reg = <0x91000000 0x1>, <0x91000001 0x1>;
reg-names = "dat", "dirout";
gpio-controller;
#gpio-cells = <2>;
};
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?
If so I will can revise this patch and add patch to gpio-mmio.c.
-Stafford
Hi Stafford,
(reviving linusw)
On Thu, 8 Jan 2026 at 09:20, Stafford Horne <shorne@gmail.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@gmail.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@91000000 {
> > > 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@gmail.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@91000000 {
> 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@linux-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
On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > 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...
Yeah this needs to be fixed/reverted pronto :/
> > 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@91000000 {
> > 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
...as proved here.
Stafford can you send a fixup or revert patch?
(Only need to revert if you can't make a fix quick enough, which I
think you can.)
> > 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.
Yes this is better.
I should have seen this, I guess I was sloppy :(
> > 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[]?
I think "gpio-mmio" combined with compulsory property of
bus-width = <nn> (as used by multiple bindings) would be
generic enough. So a schema that accepts "gpio-mmio" if and
only if bus-width = 8|16|32|64 would be acceptable.
Yours,
Linus Walleij
On Fri, Jan 09, 2026 at 11:07:17AM +0100, Linus Walleij wrote:
> On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > > > 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...
>
> Yeah this needs to be fixed/reverted pronto :/
>
> > > 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@91000000 {
> > > 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
>
> ...as proved here.
>
> Stafford can you send a fixup or revert patch?
> (Only need to revert if you can't make a fix quick enough, which I
> think you can.)
Sure, I'll send a fixup to the devicetree binding and a update to the driver to
just support opencores,gpio.
Hopefully, that can be picked up in time by Bartosz who has this one staged in
gpio/for-next.
I'll send the 2 patches as part of my series for OpenRISC multicore fixups as
the devicetree's I have added have a soft dependency the patches. After/if the
patches are pulled to the gpio branch I can drop them from my queue and I'll
just have to make sure Linux merged the GPIO changes binding updates before the
OpenRISC updates during the merge window. Let me know if there are any issues.
> > > 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.
>
> Yes this is better.
>
> I should have seen this, I guess I was sloppy :(
I should have also thought more, but I don't do this often enough to remember
all of the rules. Sorry for the head ache.
-Stafford
On Fri, Jan 9, 2026 at 1:51 PM Stafford Horne <shorne@gmail.com> wrote:
>
> On Fri, Jan 09, 2026 at 11:07:17AM +0100, Linus Walleij wrote:
> > On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > > > > 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...
> >
> > Yeah this needs to be fixed/reverted pronto :/
> >
> > > > 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@91000000 {
> > > > 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
> >
> > ...as proved here.
> >
> > Stafford can you send a fixup or revert patch?
> > (Only need to revert if you can't make a fix quick enough, which I
> > think you can.)
>
> Sure, I'll send a fixup to the devicetree binding and a update to the driver to
> just support opencores,gpio.
>
I assume, the v3 you sent is *not* it and you will send a v4 with
issues pointed out by Krzysztof fixes?
> Hopefully, that can be picked up in time by Bartosz who has this one staged in
> gpio/for-next.
>
I'm ready to pick it up as soon as Krzysztof Acks it.
> I'll send the 2 patches as part of my series for OpenRISC multicore fixups as
> the devicetree's I have added have a soft dependency the patches. After/if the
> patches are pulled to the gpio branch I can drop them from my queue and I'll
> just have to make sure Linux merged the GPIO changes binding updates before the
> OpenRISC updates during the merge window. Let me know if there are any issues.
>
Sounds good.
Bartosz
> > > > 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.
> >
> > Yes this is better.
> >
> > I should have seen this, I guess I was sloppy :(
>
> I should have also thought more, but I don't do this often enough to remember
> all of the rules. Sorry for the head ache.
>
> -Stafford
On Mon, Jan 12, 2026 at 10:25:03AM +0100, Bartosz Golaszewski wrote:
> On Fri, Jan 9, 2026 at 1:51 PM Stafford Horne <shorne@gmail.com> wrote:
> >
> > On Fri, Jan 09, 2026 at 11:07:17AM +0100, Linus Walleij wrote:
> > > On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >
> > > > > > 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...
> > >
> > > Yeah this needs to be fixed/reverted pronto :/
> > >
> > > > > 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@91000000 {
> > > > > 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
> > >
> > > ...as proved here.
> > >
> > > Stafford can you send a fixup or revert patch?
> > > (Only need to revert if you can't make a fix quick enough, which I
> > > think you can.)
> >
> > Sure, I'll send a fixup to the devicetree binding and a update to the driver to
> > just support opencores,gpio.
> >
>
> I assume, the v3 you sent is *not* it and you will send a v4 with
> issues pointed out by Krzysztof fixes?
Yes, I have just sent out the v4.
> > Hopefully, that can be picked up in time by Bartosz who has this one staged in
> > gpio/for-next.
> >
>
> I'm ready to pick it up as soon as Krzysztof Acks it.
OK.
> > I'll send the 2 patches as part of my series for OpenRISC multicore fixups as
> > the devicetree's I have added have a soft dependency the patches. After/if the
> > patches are pulled to the gpio branch I can drop them from my queue and I'll
> > just have to make sure Linux merged the GPIO changes binding updates before the
> > OpenRISC updates during the merge window. Let me know if there are any issues.
> >
>
> Sounds good.
Thank you.
-Stafford
> > > > > 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.
> > >
> > > Yes this is better.
> > >
> > > I should have seen this, I guess I was sloppy :(
> >
> > I should have also thought more, but I don't do this often enough to remember
> > all of the rules. Sorry for the head ache.
> >
> > -Stafford
Hi Linus,
On Fri, 9 Jan 2026 at 11:07, Linus Walleij <linusw@kernel.org> wrote:
> On Thu, Jan 8, 2026 at 9:41 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > 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...
>
> Yeah this needs to be fixed/reverted pronto :/
>
> > > 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@91000000 {
> > > 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
>
> ...as proved here.
>
> Stafford can you send a fixup or revert patch?
> (Only need to revert if you can't make a fix quick enough, which I
> think you can.)
>
> > > 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.
>
> Yes this is better.
>
> I should have seen this, I guess I was sloppy :(
>
> > > 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[]?
>
> I think "gpio-mmio" combined with compulsory property of
> bus-width = <nn> (as used by multiple bindings) would be
> generic enough. So a schema that accepts "gpio-mmio" if and
> only if bus-width = 8|16|32|64 would be acceptable.
Each register is described individually, and the width is derived
from the register's size, so no bus-width is needed"
reg:
minItems: 1
description:
A list of registers in the controller. The width of each register is
determined by its size. All registers must have the same width. The number
of GPIOs is set by the width, with bit 0 corresponding to GPIO 0, unless
the ngpios property further restricts the number of used lines.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-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
On Wed, Dec 17, 2025 at 9:09 AM Stafford Horne <shorne@gmail.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@91000000 {
> 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@gmail.com>
Looks reasonable,
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
Acked-by: Conor Dooley <conor.dooley@microchip.com> pw-bot: not-applicable
© 2016 - 2026 Red Hat, Inc.