On Wed, Jan 14, 2026 at 09:36:55AM +0100, Bartosz Golaszewski wrote:

On Wed, Jan 14, 2026 at 9:31 AM Krzysztof Kozlowski [off-list ref] wrote:

quoted

On Tue, Jan 13, 2026 at 04:31:33PM +0000, Stafford Horne wrote:

quoted

On Tue, Jan 13, 2026 at 05:20:28PM +0100, Bartosz Golaszewski wrote:

quoted

On Tue, Jan 13, 2026 at 5:15 PM Stafford Horne [off-list ref] wrote:

quoted

Add a device tree binding for the opencores GPIO controller.

On FPGA Development boards with GPIOs the OpenRISC architecture uses the
opencores gpio verilog rtl which is compatible with the MMIO GPIO driver.

Link: https://opencores.org/projects/gpio
Signed-off-by: Stafford Horne <shorne@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Since v3:
 - Removed example.
 - Re-order this patch to be before adding compatible string to driver as per
   device tree binding patch rules.
 - Add Reviewed-by's.
Since v2:
 - Fixup (replace) patch to simply add opencores,gpio and add an example.
   (It was incorrect to specifying opencores,gpio with brcm,bcm6345-gpio
    as opencores,gpio is not the same hardware, its 8-bit vs 32-bit)
Since v1:
 - Fix schema to actually match the example.

 Documentation/devicetree/bindings/gpio/gpio-mmio.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
index ee5d5d25ae82..a8823ca65e78 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml
+++ b/Documentation/devicetree/bindings/gpio/gpio-mmio.yaml

@@ -23,6 +23,7 @@ properties:
       - ni,169445-nand-gpio
       - wd,mbl-gpio # Western Digital MyBook Live memory-mapped GPIO controller
       - intel,ixp4xx-expansion-bus-mmio-gpio
+      - opencores,gpio

   big-endian: true

--

2.51.0

This is not a follow-up patch. Please rebase your fix on top of
linux-next. I already have the previous patch in my tree and will not
be rebasing the entire for-next branch.

OK, understood, I wasn't aware you would not rebase. I will rework this rebasing
on linux-next reberting my previous dt-binding: patch first.

No, you need to rebase, not revert.

Just to be extra-clear: take current linux-next (next-20260114) and -
on top of it - create a patch that fixes the issues in an incremental
way. No reverts. Also: add the Fixes: tag to your commit before your
SoB.

Got it, I was doing this but preparing the series with a revert.  Good thing I
waited a bit before sending.

-Stafford