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

[Krzysztof Kozlowski <krzk@kernel.org>]

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