Re: (subset) [PATCH v6 0/6] OpenRISC de0 nano single and multicore boards

On Fri, Jan 16, 2026 at 01:02:15PM +0100, Krzysztof Kozlowski wrote:

On 16/01/2026 12:57, Stafford Horne wrote:

quoted

On Thu, Jan 15, 2026 at 04:40:53PM +0100, Bartosz Golaszewski wrote:

quoted

On Thu, 15 Jan 2026 15:09:56 +0000, Stafford Horne wrote:

quoted

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.

quoted

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

quoted

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

-Stafford

Best regards,
Krzysztof