Postscript, On 10/13/25 14:52, E Shattow wrote: > Cherry-pick RISC-V Misc Devicetrees for v6.18 (Starfive, SiFive, Microchip) > > * tag 'riscv-dt-for-v6.18' of > https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: > riscv: dts: starfive: add Milk-V Mars CM Lite system-on-module > dt-bindings: riscv: starfive: add milkv,marscm-lite > riscv: dts: starfive: add Milk-V Mars CM system-on-module > dt-bindings: riscv: starfive: add milkv,marscm-emmc > riscv: dts: starfive: add common board dtsi for Milk-V Mars CM variants > riscv: dts: microchip: add a device tree for Discovery Kit > dt-bindings: riscv: microchip: document Discovery Kit > riscv: dts: microchip: rename icicle kit ccc clock and other minor fixes > riscv: dts: microchip: add icicle kit with production device > dt-bindings: riscv: microchip: document icicle kit with production device > riscv: dts: microchip: add common board dtsi for icicle kit variants > riscv: dts: starfive: jh7110-common: drop mmc post-power-on-delay-ms > riscv: dts: starfive: jh7110-common: drop no-mmc property from mmc1 > riscv: dts: starfive: jh7110: bootph-pre-ram hinting needed by boot loader > riscv: dts: starfive: jh7110: add DMC memory controller > dt-bindings: memory-controllers: add StarFive JH7110 SoC DMC > riscv: dts: starfive: jh7110-common: drop no-sdio property from mmc1 > riscv: dts: microchip: Minor whitespace cleanup > dt-bindings: riscv: Add SiFive vendor extensions description > > Link: https://lore.kernel.org/r/20250924-frighten-magazine-ee2f16e64638@spud > > [ upstream commit: 8c0650e0cef283fb31aca5dc7c72b891ff121a88 ] > > (cherry picked from commit 31727e081d77f1cde5ec261a72e0c33dae7ee3c2) ...snip...
Although this is probably okay to take, I cannot vouch for the parts that touch platforms other than starfive jh7110. Talking on IRC about how this should be done I learned that taking a merge commit is possible for U-Boot maintainer to resolve later without too much trouble. Individual commits are what I intended (and did not understand how to do). I would like to instead do this as just the commits I am interested in. I will be sending a series to make the control.rst document more helpful in this regard, and probably add a "log" operation to the tools/update-subtree.sh script. There's a logical step missing between adding the remote repository already knowing what the commit id is, and firstly explaining how to obtain that commit id. -E
