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
