On Mon, Jan 12, 2026 at 08:31:03AM +0100, Krzysztof Kozlowski wrote:
> On 11/01/2026 17:46, Stafford Horne wrote:
> > On Sun, Jan 11, 2026 at 11:18:42AM +0100, Krzysztof Kozlowski wrote:
> >> On Fri, Jan 09, 2026 at 01:43:53PM +0000, Stafford Horne wrote:
> >>> 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 <[email protected]>
> >>> ---
> >>> Since v2:
> >>> - Fixup patch to simply add opencores,gpio and add an example.
> >>
> >> Simplify? You completely changed the meaning of binding here - now
> >> device is not compatible.
> >>
> >> I don't know which one is correct, but your changelog must explain why
> >> now devices are not compatible but they were before.
Trying to answer this better this time:
As per our discussion with Geert and Linus W. It was pointed out that the
original patch, which added openrisc,gpio to be allowed along with the broadcom
chip e.g. ( compatible = "opencores,gpio", "brcm,bcm6345-gpio"; ), was wrong.
The opencores,gpio is compatible with the gpio-mmio driver, but it is not a
hardware clone with the broadcomm chip. It has 8-bit registers vs 32-bit
registers and the register map is different. Instead of allowing opencores,gpio
to be specified along with the broadcom chip, opencores,gpio should be specified
on its own.
So we agreed to resend the patch with to parts:
1. A commit to add the opencores,gpio to the driver compatibility list. (new
1/6)
2. A commit to add opencores,gpio to the binding (replacement of the
original patch 2/6)
(now I understand this order is bad, I can resend)
This is a "simplification" as we are now just adding the opencores,gpio string
to the list rather than changing the schema with oneOf and items.
I wanted top get it out quickly so it can be fixed up before the merge window
opens.
> > Hello,
> >
> > Did you miss the 1/6 patch in this series? We add the compatible string to
> > the
>
> There is no 1/6!
It seems you are not on it, but it is on lore here, if you missed it.
https://lore.kernel.org/lkml/[email protected]/
Reading the bindings submitting patches doc's it seems I need to send the whole
series to the bindings list. Which may explain.
> > driver there before we add it here.
>
> How does it matter? How can you add something to the driver before you
> document the ABI? Did you read the submitting patches doc?
Sorry, I didn't read, or realize there was a device tree bindings specific patch
document. I see it now, and I see point 5 makes it clear that we should
document the binding before the code change. I got the order swapped.
https://docs.kernel.org/devicetree/bindings/submitting-patches.html
If necessary I can resend the 2 patches in the right order as a series to the
devicetree list. [email protected]
> >
> > Sorry, I thought the series and the over letter would be enough to
> > understand
> > what I meant by the "Fixup" description here.
>
> You still did not answer to my comments.
OK, I tried again above.
-stafford
