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:

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?

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