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

Stafford Horne <[email protected]>
Newsgroups org.kernel.vger.linux-openrisc,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-gpio,org.kernel.vger.linux-kernel
Message-ID <aWZwJ569WMBOKUVc@antec>
On Mon, Jan 12, 2026 at 10:25:03AM +0100, Bartosz Golaszewski wrote:
> On Fri, Jan 9, 2026 at 1:51 PM Stafford Horne <[email protected]> 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 <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.