Since v5:
 - Adjust dt-binding patch based on suggestions from Geert and Krzysztof.
 - Add reviewed-by's on the dt-binding patch.
Since v4:
 - Rebased the series on linux-next to allow patches to be incremental.
 - Rewrote the dt-bindings patch as an incremental patch, Due to this I
   dropped reviewed-by's.
 - Added acked-by to the IPI fix patch.
Since v3:
 - Switch order of gpio-mmio driver and bindings patches to patch binding
   first before driver.  Suggested by Krzysztof.
 - Removed example form binding suggested by Krzysztof.
 - Added Reviewed-by's from Geert and Linus W.
Since v2:
 - Fixup (replace) gpio-mmio patch to update driver compatible list and just add
   opencores,gpio to mmio-gpio bindings.  Discussed with Geert and Linus W
   because the 8-bit opencores,gpio is not the same as the 32-bit broadcom
   chip. [1].
 - Update new device trees to use proper ordering, remove debug options, remove
   unneeded "status" properties.  Suggested by Geert.
Since v1:
 - Use proper schema in gpio-mmio suggsted by Conor Dooley
 - Remove 0 clock-frequency definitions in dtsi file

The patches add support for OpenRISC systems running on the De0 Nano FPGA
development board.  We have two SoCs which are available here:

 - https://github.com/olofk/de0_nano - Single core
 - https://github.com/stffrdhrn/de0_nano-multicore - Multicore

As I work on tutorials [2] to help other get started with OpenRISC I would like to
have these defconfig and devicetree definitions in the upstream kernel to avoid
losing them.

When I was working on resurrecting these old setup's I found a major bug in
OpenRISC SMP which is fixed in this series as well.

[1] https://lore.kernel.org/lkml/20251217080843.70621-1-shorne@gmail.com/
[2] https://openrisc.io/tutorials/

Stafford Horne (6):
  dt-bindings: gpio-mmio: Correct opencores GPIO
  gpio: mmio: Add compatible for opencores GPIO
  openrisc: dts: Add de0 nano config and devicetree
  openrisc: Fix IPIs on simple multicore systems
  openrisc: dts: Split simple smp dts to dts and dtsi
  openrisc: dts: Add de0 nano multicore config and devicetree

 .../devicetree/bindings/gpio/gpio-mmio.yaml   | 16 ++--
 arch/openrisc/boot/dts/de0-nano-common.dtsi   | 42 +++++++++
 arch/openrisc/boot/dts/de0-nano-multicore.dts | 25 +++++
 arch/openrisc/boot/dts/de0-nano.dts           | 54 +++++++++++
 arch/openrisc/boot/dts/simple-smp.dts         | 25 +++++
 .../dts/{simple_smp.dts => simple-smp.dtsi}   | 11 +--
 arch/openrisc/configs/de0_nano_defconfig      | 79 ++++++++++++++++
 .../configs/de0_nano_multicore_defconfig      | 92 +++++++++++++++++++
 arch/openrisc/configs/simple_smp_defconfig    |  2 +-
 arch/openrisc/include/asm/smp.h               |  3 +-
 arch/openrisc/kernel/smp.c                    | 22 ++++-
 drivers/gpio/gpio-mmio.c                      |  1 +
 drivers/irqchip/irq-ompic.c                   | 15 ++-
 drivers/irqchip/irq-or1k-pic.c                | 27 +++++-
 14 files changed, 390 insertions(+), 24 deletions(-)
 create mode 100644 arch/openrisc/boot/dts/de0-nano-common.dtsi
 create mode 100644 arch/openrisc/boot/dts/de0-nano-multicore.dts
 create mode 100644 arch/openrisc/boot/dts/de0-nano.dts
 create mode 100644 arch/openrisc/boot/dts/simple-smp.dts
 rename arch/openrisc/boot/dts/{simple_smp.dts => simple-smp.dtsi} (90%)
 create mode 100644 arch/openrisc/configs/de0_nano_defconfig
 create mode 100644 arch/openrisc/configs/de0_nano_multicore_defconfig

-- 
2.51.0

On Thu, 15 Jan 2026 15:09:56 +0000, Stafford Horne wrote:
> Since v5:
>  - Adjust dt-binding patch based on suggestions from Geert and Krzysztof.
>  - Add reviewed-by's on the dt-binding patch.
> Since v4:
>  - Rebased the series on linux-next to allow patches to be incremental.
>  - Rewrote the dt-bindings patch as an incremental patch, Due to this I
>    dropped reviewed-by's.
>  - Added acked-by to the IPI fix patch.
> Since v3:
>  - Switch order of gpio-mmio driver and bindings patches to patch binding
>    first before driver.  Suggested by Krzysztof.
>  - Removed example form binding suggested by Krzysztof.
>  - Added Reviewed-by's from Geert and Linus W.
> Since v2:
>  - Fixup (replace) gpio-mmio patch to update driver compatible list and just add
>    opencores,gpio to mmio-gpio bindings.  Discussed with Geert and Linus W
>    because the 8-bit opencores,gpio is not the same as the 32-bit broadcom
>    chip. [1].
>  - Update new device trees to use proper ordering, remove debug options, remove
>    unneeded "status" properties.  Suggested by Geert.
> Since v1:
>  - Use proper schema in gpio-mmio suggsted by Conor Dooley
>  - Remove 0 clock-frequency definitions in dtsi file
> 
> [...]

Applied, thanks!

[1/6] dt-bindings: gpio-mmio: Correct opencores GPIO
      commit: b2b8d247ad8ee1abe860598cae70e2dbe8a09128
[2/6] gpio: mmio: Add compatible for opencores GPIO
      commit: 3a6a36a3fc4e18e202eaf6c258553b5a17b91677

Best regards,
-- 
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>

On Thu, Jan 15, 2026 at 04:40:53PM +0100, Bartosz Golaszewski wrote:
> 
> On Thu, 15 Jan 2026 15:09:56 +0000, Stafford Horne wrote:
> > Since v5:
> >  - Adjust dt-binding patch based on suggestions from Geert and Krzysztof.
> >  - Add reviewed-by's on the dt-binding patch.
> > Since v4:
> >  - Rebased the series on linux-next to allow patches to be incremental.
> >  - Rewrote the dt-bindings patch as an incremental patch, Due to this I
> >    dropped reviewed-by's.
> >  - Added acked-by to the IPI fix patch.
> > Since v3:
> >  - Switch order of gpio-mmio driver and bindings patches to patch binding
> >    first before driver.  Suggested by Krzysztof.
> >  - Removed example form binding suggested by Krzysztof.
> >  - Added Reviewed-by's from Geert and Linus W.
> > Since v2:
> >  - Fixup (replace) gpio-mmio patch to update driver compatible list and just add
> >    opencores,gpio to mmio-gpio bindings.  Discussed with Geert and Linus W
> >    because the 8-bit opencores,gpio is not the same as the 32-bit broadcom
> >    chip. [1].
> >  - Update new device trees to use proper ordering, remove debug options, remove
> >    unneeded "status" properties.  Suggested by Geert.
> > Since v1:
> >  - Use proper schema in gpio-mmio suggsted by Conor Dooley
> >  - Remove 0 clock-frequency definitions in dtsi file
> > 
> > [...]
> 
> Applied, thanks!
> 
> [1/6] dt-bindings: gpio-mmio: Correct opencores GPIO
>       commit: b2b8d247ad8ee1abe860598cae70e2dbe8a09128
> [2/6] gpio: mmio: Add compatible for opencores GPIO
>       commit: 3a6a36a3fc4e18e202eaf6c258553b5a17b91677

Thanks, now that these commits are on gpio-next I would like to apply the rest
of the patches to my openrisc/for-next branch.  Since the other patches depend
on the GPIO patches for system functionality, do you think it would be safe for
me to merge the gpio-next branch into my branch?

It seems a bit messy, Maybe I should just wait for the next cycle.  But if you
have any suggestions of experience with this any comments would be appreciated.

-Stafford

On 16/01/2026 12:57, Stafford Horne wrote:
> On Thu, Jan 15, 2026 at 04:40:53PM +0100, Bartosz Golaszewski wrote:
>>
>> On Thu, 15 Jan 2026 15:09:56 +0000, Stafford Horne wrote:
>>> Since v5:
>>>  - Adjust dt-binding patch based on suggestions from Geert and Krzysztof.
>>>  - Add reviewed-by's on the dt-binding patch.
>>> Since v4:
>>>  - Rebased the series on linux-next to allow patches to be incremental.
>>>  - Rewrote the dt-bindings patch as an incremental patch, Due to this I
>>>    dropped reviewed-by's.
>>>  - Added acked-by to the IPI fix patch.
>>> Since v3:
>>>  - Switch order of gpio-mmio driver and bindings patches to patch binding
>>>    first before driver.  Suggested by Krzysztof.
>>>  - Removed example form binding suggested by Krzysztof.
>>>  - Added Reviewed-by's from Geert and Linus W.
>>> Since v2:
>>>  - Fixup (replace) gpio-mmio patch to update driver compatible list and just add
>>>    opencores,gpio to mmio-gpio bindings.  Discussed with Geert and Linus W
>>>    because the 8-bit opencores,gpio is not the same as the 32-bit broadcom
>>>    chip. [1].
>>>  - Update new device trees to use proper ordering, remove debug options, remove
>>>    unneeded "status" properties.  Suggested by Geert.
>>> Since v1:
>>>  - Use proper schema in gpio-mmio suggsted by Conor Dooley
>>>  - Remove 0 clock-frequency definitions in dtsi file
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [1/6] dt-bindings: gpio-mmio: Correct opencores GPIO
>>       commit: b2b8d247ad8ee1abe860598cae70e2dbe8a09128
>> [2/6] gpio: mmio: Add compatible for opencores GPIO
>>       commit: 3a6a36a3fc4e18e202eaf6c258553b5a17b91677
> 
> Thanks, now that these commits are on gpio-next I would like to apply the rest
> of the patches to my openrisc/for-next branch.  Since the other patches depend
> on the GPIO patches for system functionality, do you think it would be safe for
> me to merge the gpio-next branch into my branch?

They do not depend, unless I missed something. DTS cannot depend on
drivers because it is an independent (huh, so circular logic) hardware
description. It's also more explained in maintainer-soc-profile and DT
submitting patches document.

There is no single dependency here and you should never pull gpio-next
or any other subsystem driver into your DTS branches.

> 
> It seems a bit messy, Maybe I should just wait for the next cycle.  But if you

There is no mess, you do not have to wait for anything. Please follow
standard rules like we follow for all other SoC-based architectures
(arm, arm64, riscv).

What happens when you apply *independently* DTS? What is broken, which
was not broken so far? What features stop working? What existing DTS is
affected? What existing code is doing worse than before?

> have any suggestions of experience with this any comments would be appreciated.
> 
> -Stafford


Best regards,
Krzysztof

On Fri, Jan 16, 2026 at 01:02:15PM +0100, Krzysztof Kozlowski wrote:
> On 16/01/2026 12:57, Stafford Horne wrote:
> > On Thu, Jan 15, 2026 at 04:40:53PM +0100, Bartosz Golaszewski wrote:
> >>
> >> On Thu, 15 Jan 2026 15:09:56 +0000, Stafford Horne wrote:
> >>> Since v5:
> >>>  - Adjust dt-binding patch based on suggestions from Geert and Krzysztof.
> >>>  - Add reviewed-by's on the dt-binding patch.
> >>> Since v4:
> >>>  - Rebased the series on linux-next to allow patches to be incremental.
> >>>  - Rewrote the dt-bindings patch as an incremental patch, Due to this I
> >>>    dropped reviewed-by's.
> >>>  - Added acked-by to the IPI fix patch.
> >>> Since v3:
> >>>  - Switch order of gpio-mmio driver and bindings patches to patch binding
> >>>    first before driver.  Suggested by Krzysztof.
> >>>  - Removed example form binding suggested by Krzysztof.
> >>>  - Added Reviewed-by's from Geert and Linus W.
> >>> Since v2:
> >>>  - Fixup (replace) gpio-mmio patch to update driver compatible list and just add
> >>>    opencores,gpio to mmio-gpio bindings.  Discussed with Geert and Linus W
> >>>    because the 8-bit opencores,gpio is not the same as the 32-bit broadcom
> >>>    chip. [1].
> >>>  - Update new device trees to use proper ordering, remove debug options, remove
> >>>    unneeded "status" properties.  Suggested by Geert.
> >>> Since v1:
> >>>  - Use proper schema in gpio-mmio suggsted by Conor Dooley
> >>>  - Remove 0 clock-frequency definitions in dtsi file
> >>>
> >>> [...]
> >>
> >> Applied, thanks!
> >>
> >> [1/6] dt-bindings: gpio-mmio: Correct opencores GPIO
> >>       commit: b2b8d247ad8ee1abe860598cae70e2dbe8a09128
> >> [2/6] gpio: mmio: Add compatible for opencores GPIO
> >>       commit: 3a6a36a3fc4e18e202eaf6c258553b5a17b91677
> > 
> > Thanks, now that these commits are on gpio-next I would like to apply the rest
> > of the patches to my openrisc/for-next branch.  Since the other patches depend
> > on the GPIO patches for system functionality, do you think it would be safe for
> > me to merge the gpio-next branch into my branch?
> 
> They do not depend, unless I missed something. DTS cannot depend on
> drivers because it is an independent (huh, so circular logic) hardware
> description. It's also more explained in maintainer-soc-profile and DT
> submitting patches document.
> 
> There is no single dependency here and you should never pull gpio-next
> or any other subsystem driver into your DTS branches.
>
> > 
> > It seems a bit messy, Maybe I should just wait for the next cycle.  But if you
> 
> There is no mess, you do not have to wait for anything. Please follow
> standard rules like we follow for all other SoC-based architectures
> (arm, arm64, riscv).
> 
> What happens when you apply *independently* DTS? What is broken, which
> was not broken so far? What features stop working? What existing DTS is
> affected? What existing code is doing worse than before?

Hi Krzysztof,

You are right, there is no build time dependency here only a dependency at
runtime.  Also the dtbs_check will warn about missing "opencores,gpio" bindings
for the new soc devicestrees on my branch.  Now, I understand that is no issue.

I was overthinking this, I will just apply the remaining bits to the OpenRISC
queue as per the maintainer-soc-profile.  Thanks for pointing that out.

Thanks,

-Stafford

> > have any suggestions of experience with this any comments would be appreciated.
> > 
> > -Stafford
> 
> 
> Best regards,
> Krzysztof

On 16/01/2026 17:36, Stafford Horne wrote:
>>> It seems a bit messy, Maybe I should just wait for the next cycle.  But if you
>>
>> There is no mess, you do not have to wait for anything. Please follow
>> standard rules like we follow for all other SoC-based architectures
>> (arm, arm64, riscv).
>>
>> What happens when you apply *independently* DTS? What is broken, which
>> was not broken so far? What features stop working? What existing DTS is
>> affected? What existing code is doing worse than before?
> 
> Hi Krzysztof,
> 
> You are right, there is no build time dependency here only a dependency at
> runtime.  Also the dtbs_check will warn about missing "opencores,gpio" bindings
> for the new soc devicestrees on my branch.  Now, I understand that is no issue.

That warning is expected and everything is "fine" as long as linux-next
does not have it. "Fine" as a meaning part of current process, but far
from optimal. But you should not pull the drivers into DTS branch just
to solve it. You could pull only the binding file, although no one does
it currently just for that (there was such proposal and Rob did not
immediately reject it so maybe that's where it could go).



Best regards,
Krzysztof