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:
> > 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