| Message ID | 20250607093730.2249536-1-dario.binacchi@amarulasolutions.com |
|---|---|
| Headers | show |
| Series |
|
| Related | show |
On 6/7/25 11:37, Dario Binacchi wrote: > The series adds support for stm32h747-discovery board. > > Detailed information can be found at: > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > Dario Binacchi (9): > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > ARM: dts: stm32: add uart8 node for stm32h743 MCU > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > ARM: dts: stm32: support STM32h747i-disco board > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > board: stm32: add stm32h747-discovery board support Hi Dario For the whole series Applied to u-boot-stm32/next Thanks Patrice > > arch/arm/dts/stm32h747i-disco-u-boot.dtsi | 104 ++++++++++++++ > arch/arm/mach-stm32/stm32h7/Kconfig | 4 + > board/st/stm32h747-disco/Kconfig | 15 ++ > board/st/stm32h747-disco/MAINTAINERS | 7 + > board/st/stm32h747-disco/Makefile | 6 + > board/st/stm32h747-disco/stm32h747-disco.c | 42 ++++++ > configs/stm32h747-disco_defconfig | 35 +++++ > drivers/clk/stm32/clk-stm32h7.c | 5 + > dts/upstream/Bindings/arm/stm32/stm32.yaml | 4 + > .../include/dt-bindings/clock/stm32h7-clks.h | 4 +- > dts/upstream/src/arm/st/stm32h7-pinctrl.dtsi | 34 ++++- > dts/upstream/src/arm/st/stm32h743.dtsi | 8 ++ > dts/upstream/src/arm/st/stm32h743i-disco.dts | 2 +- > dts/upstream/src/arm/st/stm32h743i-eval.dts | 2 +- > dts/upstream/src/arm/st/stm32h747i-disco.dts | 136 ++++++++++++++++++ > dts/upstream/src/arm/st/stm32h750i-art-pi.dts | 6 +- > include/configs/stm32h747-disco.h | 32 +++++ > 17 files changed, 435 insertions(+), 11 deletions(-) > create mode 100644 arch/arm/dts/stm32h747i-disco-u-boot.dtsi > create mode 100644 board/st/stm32h747-disco/Kconfig > create mode 100644 board/st/stm32h747-disco/MAINTAINERS > create mode 100644 board/st/stm32h747-disco/Makefile > create mode 100644 board/st/stm32h747-disco/stm32h747-disco.c > create mode 100644 configs/stm32h747-disco_defconfig > create mode 100644 dts/upstream/src/arm/st/stm32h747i-disco.dts > create mode 100644 include/configs/stm32h747-disco.h > To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
Hi Patrice, On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > On 6/7/25 11:37, Dario Binacchi wrote: > > The series adds support for stm32h747-discovery board. > > > > Detailed information can be found at: > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > Dario Binacchi (9): > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > ARM: dts: stm32: support STM32h747i-disco board > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > board: stm32: add stm32h747-discovery board support > > > Hi Dario > > For the whole series > Applied to u-boot-stm32/next Please give some time for other maintainers to review this patch-set. The dts/upstream patches in this series aren't clean cherry pick from upstream. This has to be fixed as otherwise random patches are going to cause DT sync issues. -Sumit > > Thanks > Patrice > > > > > arch/arm/dts/stm32h747i-disco-u-boot.dtsi | 104 ++++++++++++++ > > arch/arm/mach-stm32/stm32h7/Kconfig | 4 + > > board/st/stm32h747-disco/Kconfig | 15 ++ > > board/st/stm32h747-disco/MAINTAINERS | 7 + > > board/st/stm32h747-disco/Makefile | 6 + > > board/st/stm32h747-disco/stm32h747-disco.c | 42 ++++++ > > configs/stm32h747-disco_defconfig | 35 +++++ > > drivers/clk/stm32/clk-stm32h7.c | 5 + > > dts/upstream/Bindings/arm/stm32/stm32.yaml | 4 + > > .../include/dt-bindings/clock/stm32h7-clks.h | 4 +- > > dts/upstream/src/arm/st/stm32h7-pinctrl.dtsi | 34 ++++- > > dts/upstream/src/arm/st/stm32h743.dtsi | 8 ++ > > dts/upstream/src/arm/st/stm32h743i-disco.dts | 2 +- > > dts/upstream/src/arm/st/stm32h743i-eval.dts | 2 +- > > dts/upstream/src/arm/st/stm32h747i-disco.dts | 136 ++++++++++++++++++ > > dts/upstream/src/arm/st/stm32h750i-art-pi.dts | 6 +- > > include/configs/stm32h747-disco.h | 32 +++++ > > 17 files changed, 435 insertions(+), 11 deletions(-) > > create mode 100644 arch/arm/dts/stm32h747i-disco-u-boot.dtsi > > create mode 100644 board/st/stm32h747-disco/Kconfig > > create mode 100644 board/st/stm32h747-disco/MAINTAINERS > > create mode 100644 board/st/stm32h747-disco/Makefile > > create mode 100644 board/st/stm32h747-disco/stm32h747-disco.c > > create mode 100644 configs/stm32h747-disco_defconfig > > create mode 100644 dts/upstream/src/arm/st/stm32h747i-disco.dts > > create mode 100644 include/configs/stm32h747-disco.h > > To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
Hi Sumit, On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > Hi Patrice, > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > The series adds support for stm32h747-discovery board. > > > > > > Detailed information can be found at: > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > Dario Binacchi (9): > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > ARM: dts: stm32: support STM32h747i-disco board > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > board: stm32: add stm32h747-discovery board support > > > > > > Hi Dario > > > > For the whole series > > Applied to u-boot-stm32/next > > Please give some time for other maintainers to review this patch-set. > The dts/upstream patches in this series aren't clean cherry pick from > upstream. All the commits are already in the mainline Linux kernel, specifically in v6.16-rc1. If you're referring to the fact that the patches can't be applied cleanly, I believe it's because the target path in the Linux kernel doesn't match the one in U-Boot. In fact, the DTS files are located in two different relative paths. Thanks and regards, Dario > This has to be fixed as otherwise random patches are going to > cause DT sync issues. > > -Sumit > > > > > Thanks > > Patrice > > > > > > > > arch/arm/dts/stm32h747i-disco-u-boot.dtsi | 104 ++++++++++++++ > > > arch/arm/mach-stm32/stm32h7/Kconfig | 4 + > > > board/st/stm32h747-disco/Kconfig | 15 ++ > > > board/st/stm32h747-disco/MAINTAINERS | 7 + > > > board/st/stm32h747-disco/Makefile | 6 + > > > board/st/stm32h747-disco/stm32h747-disco.c | 42 ++++++ > > > configs/stm32h747-disco_defconfig | 35 +++++ > > > drivers/clk/stm32/clk-stm32h7.c | 5 + > > > dts/upstream/Bindings/arm/stm32/stm32.yaml | 4 + > > > .../include/dt-bindings/clock/stm32h7-clks.h | 4 +- > > > dts/upstream/src/arm/st/stm32h7-pinctrl.dtsi | 34 ++++- > > > dts/upstream/src/arm/st/stm32h743.dtsi | 8 ++ > > > dts/upstream/src/arm/st/stm32h743i-disco.dts | 2 +- > > > dts/upstream/src/arm/st/stm32h743i-eval.dts | 2 +- > > > dts/upstream/src/arm/st/stm32h747i-disco.dts | 136 ++++++++++++++++++ > > > dts/upstream/src/arm/st/stm32h750i-art-pi.dts | 6 +- > > > include/configs/stm32h747-disco.h | 32 +++++ > > > 17 files changed, 435 insertions(+), 11 deletions(-) > > > create mode 100644 arch/arm/dts/stm32h747i-disco-u-boot.dtsi > > > create mode 100644 board/st/stm32h747-disco/Kconfig > > > create mode 100644 board/st/stm32h747-disco/MAINTAINERS > > > create mode 100644 board/st/stm32h747-disco/Makefile > > > create mode 100644 board/st/stm32h747-disco/stm32h747-disco.c > > > create mode 100644 configs/stm32h747-disco_defconfig > > > create mode 100644 dts/upstream/src/arm/st/stm32h747i-disco.dts > > > create mode 100644 include/configs/stm32h747-disco.h > > >
On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: > Hi Sumit, > > On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > > > Hi Patrice, > > > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > > The series adds support for stm32h747-discovery board. > > > > > > > > Detailed information can be found at: > > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > > > > Dario Binacchi (9): > > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > > ARM: dts: stm32: support STM32h747i-disco board > > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > > board: stm32: add stm32h747-discovery board support > > > > > > > > > Hi Dario > > > > > > For the whole series > > > Applied to u-boot-stm32/next > > > > Please give some time for other maintainers to review this patch-set. > > The dts/upstream patches in this series aren't clean cherry pick from > > upstream. > > All the commits are already in the mainline Linux kernel, specifically > in v6.16-rc1. > If you're referring to the fact that the patches can't be applied > cleanly, I believe it's > because the target path in the Linux kernel doesn't match the one in U-Boot. > In fact, the DTS files are located in two different relative paths. That's exactly why we have (refer here [1]): ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> You should have waited v6.16-rc1 tag to be synced into devicetree-rebasing [2] for the cherry-picks to work. This way of manually patching dts/upstream is not allowed since it is going to break DT syncs in one way or another. So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree and then send v2 with proper cherry picked patches. [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git -Sumit > > Thanks and regards, > Dario > > > This has to be fixed as otherwise random patches are going to > > cause DT sync issues. > > > > -Sumit > > > > > > > > Thanks > > > Patrice > > > > > > > > > > > arch/arm/dts/stm32h747i-disco-u-boot.dtsi | 104 ++++++++++++++ > > > > arch/arm/mach-stm32/stm32h7/Kconfig | 4 + > > > > board/st/stm32h747-disco/Kconfig | 15 ++ > > > > board/st/stm32h747-disco/MAINTAINERS | 7 + > > > > board/st/stm32h747-disco/Makefile | 6 + > > > > board/st/stm32h747-disco/stm32h747-disco.c | 42 ++++++ > > > > configs/stm32h747-disco_defconfig | 35 +++++ > > > > drivers/clk/stm32/clk-stm32h7.c | 5 + > > > > dts/upstream/Bindings/arm/stm32/stm32.yaml | 4 + > > > > .../include/dt-bindings/clock/stm32h7-clks.h | 4 +- > > > > dts/upstream/src/arm/st/stm32h7-pinctrl.dtsi | 34 ++++- > > > > dts/upstream/src/arm/st/stm32h743.dtsi | 8 ++ > > > > dts/upstream/src/arm/st/stm32h743i-disco.dts | 2 +- > > > > dts/upstream/src/arm/st/stm32h743i-eval.dts | 2 +- > > > > dts/upstream/src/arm/st/stm32h747i-disco.dts | 136 ++++++++++++++++++ > > > > dts/upstream/src/arm/st/stm32h750i-art-pi.dts | 6 +- > > > > include/configs/stm32h747-disco.h | 32 +++++ > > > > 17 files changed, 435 insertions(+), 11 deletions(-) > > > > create mode 100644 arch/arm/dts/stm32h747i-disco-u-boot.dtsi > > > > create mode 100644 board/st/stm32h747-disco/Kconfig > > > > create mode 100644 board/st/stm32h747-disco/MAINTAINERS > > > > create mode 100644 board/st/stm32h747-disco/Makefile > > > > create mode 100644 board/st/stm32h747-disco/stm32h747-disco.c > > > > create mode 100644 configs/stm32h747-disco_defconfig > > > > create mode 100644 dts/upstream/src/arm/st/stm32h747i-disco.dts > > > > create mode 100644 include/configs/stm32h747-disco.h > > > > > > > > -- > > Dario Binacchi > > Senior Embedded Linux Developer > > dario.binacchi@amarulasolutions.com > > __________________________________ > > > Amarula Solutions SRL > > Via Le Canevare 30, 31100 Treviso, Veneto, IT > > T. +39 042 243 5310 > info@amarulasolutions.com > > www.amarulasolutions.com To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
On Mon, Jun 09, 2025 at 04:40:43PM +0100, Sumit Garg wrote: > On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: > > Hi Sumit, > > > > On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > > > > > Hi Patrice, > > > > > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > > > The series adds support for stm32h747-discovery board. > > > > > > > > > > Detailed information can be found at: > > > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > > > > > > > Dario Binacchi (9): > > > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > > > ARM: dts: stm32: support STM32h747i-disco board > > > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > > > board: stm32: add stm32h747-discovery board support > > > > > > > > > > > > Hi Dario > > > > > > > > For the whole series > > > > Applied to u-boot-stm32/next > > > > > > Please give some time for other maintainers to review this patch-set. > > > The dts/upstream patches in this series aren't clean cherry pick from > > > upstream. > > > > All the commits are already in the mainline Linux kernel, specifically > > in v6.16-rc1. > > If you're referring to the fact that the patches can't be applied > > cleanly, I believe it's > > because the target path in the Linux kernel doesn't match the one in U-Boot. > > In fact, the DTS files are located in two different relative paths. > > That's exactly why we have (refer here [1]): > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > You should have waited v6.16-rc1 tag to be synced into > devicetree-rebasing [2] for the cherry-picks to work. This way of > manually patching dts/upstream is not allowed since it is going to break > DT syncs in one way or another. > > So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree > and then send v2 with proper cherry picked patches. > > [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git To be honest, I don't think this is a big deal. Git will be merging based on content and not specific hashes. And in the case of conflicts I just copy the file from the tag to our tree.
On Mon, Jun 09, 2025 at 09:50:19AM -0600, Tom Rini wrote: > On Mon, Jun 09, 2025 at 04:40:43PM +0100, Sumit Garg wrote: > > On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: > > > Hi Sumit, > > > > > > On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > > > > > > > Hi Patrice, > > > > > > > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > > > > > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > > > > The series adds support for stm32h747-discovery board. > > > > > > > > > > > > Detailed information can be found at: > > > > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > > > > > > > > > > Dario Binacchi (9): > > > > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > > > > ARM: dts: stm32: support STM32h747i-disco board > > > > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > > > > board: stm32: add stm32h747-discovery board support > > > > > > > > > > > > > > > Hi Dario > > > > > > > > > > For the whole series > > > > > Applied to u-boot-stm32/next > > > > > > > > Please give some time for other maintainers to review this patch-set. > > > > The dts/upstream patches in this series aren't clean cherry pick from > > > > upstream. > > > > > > All the commits are already in the mainline Linux kernel, specifically > > > in v6.16-rc1. > > > If you're referring to the fact that the patches can't be applied > > > cleanly, I believe it's > > > because the target path in the Linux kernel doesn't match the one in U-Boot. > > > In fact, the DTS files are located in two different relative paths. > > > > That's exactly why we have (refer here [1]): > > > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > > > You should have waited v6.16-rc1 tag to be synced into > > devicetree-rebasing [2] for the cherry-picks to work. This way of > > manually patching dts/upstream is not allowed since it is going to break > > DT syncs in one way or another. > > > > So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree > > and then send v2 with proper cherry picked patches. > > > > [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > To be honest, I don't think this is a big deal. Git will be merging > based on content and not specific hashes. And in the case of conflicts I > just copy the file from the tag to our tree. The essential problem here to me is we are going to allow manual patching of dts/upstream tree given this example? How do we keep track if all that manual patching landed in Linux DT mainline? The cherry picks ensured that we always keep in sync with mainline. Lets take an example what if Git automatically resolved a merge conflict for you with duplicated content or if manually patching a DTS file diverged from upstream and get unnoticed during DT syncs? IMHO, we should try to avoid manual patching of DT subtree otherwise it is hard to set a policy as to what level of manual patching is allowed or not. -Sumit To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
On Mon, Jun 09, 2025 at 05:07:40PM +0100, Sumit Garg wrote: > On Mon, Jun 09, 2025 at 09:50:19AM -0600, Tom Rini wrote: > > On Mon, Jun 09, 2025 at 04:40:43PM +0100, Sumit Garg wrote: > > > On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: > > > > Hi Sumit, > > > > > > > > On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > > > > > > > > > Hi Patrice, > > > > > > > > > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > > > > > > > > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > > > > > The series adds support for stm32h747-discovery board. > > > > > > > > > > > > > > Detailed information can be found at: > > > > > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > > > > > > > > > > > > > Dario Binacchi (9): > > > > > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > > > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > > > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > > > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > > > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > > > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > > > > > ARM: dts: stm32: support STM32h747i-disco board > > > > > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > > > > > board: stm32: add stm32h747-discovery board support > > > > > > > > > > > > > > > > > > Hi Dario > > > > > > > > > > > > For the whole series > > > > > > Applied to u-boot-stm32/next > > > > > > > > > > Please give some time for other maintainers to review this patch-set. > > > > > The dts/upstream patches in this series aren't clean cherry pick from > > > > > upstream. > > > > > > > > All the commits are already in the mainline Linux kernel, specifically > > > > in v6.16-rc1. > > > > If you're referring to the fact that the patches can't be applied > > > > cleanly, I believe it's > > > > because the target path in the Linux kernel doesn't match the one in U-Boot. > > > > In fact, the DTS files are located in two different relative paths. > > > > > > That's exactly why we have (refer here [1]): > > > > > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > > > > > You should have waited v6.16-rc1 tag to be synced into > > > devicetree-rebasing [2] for the cherry-picks to work. This way of > > > manually patching dts/upstream is not allowed since it is going to break > > > DT syncs in one way or another. > > > > > > So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree > > > and then send v2 with proper cherry picked patches. > > > > > > [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > To be honest, I don't think this is a big deal. Git will be merging > > based on content and not specific hashes. And in the case of conflicts I > > just copy the file from the tag to our tree. > > The essential problem here to me is we are going to allow manual > patching of dts/upstream tree given this example? How do we keep track > if all that manual patching landed in Linux DT mainline? The cherry > picks ensured that we always keep in sync with mainline. > > Lets take an example what if Git automatically resolved a merge conflict > for you with duplicated content or if manually patching a DTS file > diverged from upstream and get unnoticed during DT syncs? > > IMHO, we should try to avoid manual patching of DT subtree otherwise it > is hard to set a policy as to what level of manual patching is allowed > or not. Part of the problem here is that from the standpoint of applying posted patches there's no functional difference between what Dario did here and what could be done once v6.16-rc1-dts is tagged (if it's not already). It's essentially a "manual patch" either way. We make it clear that dts/upstream/ *only* gets changes that are in Linus' tree. If someone tries to be sneaky and push something in that's not quite what's upstream, it will get stomped on later and there's not going to be any sympathy for the now broken platform. Yes, we document saying to use the cherry-pick script, and that's what people should do in general. But I don't think there's value in adding a further delay between "in Linus' tree" and "in devicetree-rebasing". In the linux kernel, there's thousands of people working on things and so strict rules can be understandable (someone will be running a bot to look for "(cherry pick from commit $hash)" and fail things where $hash doesn't exist, makes sense). Here if the ST custodians are happy just verifying the kernel commit, OK, that's fine. Or if they want to wait, that's fine too. We can be a little relaxed and let custodians do what they see as best.
On Mon, Jun 09, 2025 at 10:22:39AM -0600, Tom Rini wrote: > On Mon, Jun 09, 2025 at 05:07:40PM +0100, Sumit Garg wrote: > > On Mon, Jun 09, 2025 at 09:50:19AM -0600, Tom Rini wrote: > > > On Mon, Jun 09, 2025 at 04:40:43PM +0100, Sumit Garg wrote: > > > > On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: > > > > > Hi Sumit, > > > > > > > > > > On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > > > > > > > > > > > Hi Patrice, > > > > > > > > > > > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > > > > > > > > > > > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > > > > > > The series adds support for stm32h747-discovery board. > > > > > > > > > > > > > > > > Detailed information can be found at: > > > > > > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > > > > > > > > > > > > > > > > Dario Binacchi (9): > > > > > > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > > > > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > > > > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > > > > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > > > > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > > > > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > > > > > > ARM: dts: stm32: support STM32h747i-disco board > > > > > > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > > > > > > board: stm32: add stm32h747-discovery board support > > > > > > > > > > > > > > > > > > > > > Hi Dario > > > > > > > > > > > > > > For the whole series > > > > > > > Applied to u-boot-stm32/next > > > > > > > > > > > > Please give some time for other maintainers to review this patch-set. > > > > > > The dts/upstream patches in this series aren't clean cherry pick from > > > > > > upstream. > > > > > > > > > > All the commits are already in the mainline Linux kernel, specifically > > > > > in v6.16-rc1. > > > > > If you're referring to the fact that the patches can't be applied > > > > > cleanly, I believe it's > > > > > because the target path in the Linux kernel doesn't match the one in U-Boot. > > > > > In fact, the DTS files are located in two different relative paths. > > > > > > > > That's exactly why we have (refer here [1]): > > > > > > > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > > > > > > > You should have waited v6.16-rc1 tag to be synced into > > > > devicetree-rebasing [2] for the cherry-picks to work. This way of > > > > manually patching dts/upstream is not allowed since it is going to break > > > > DT syncs in one way or another. > > > > > > > > So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree > > > > and then send v2 with proper cherry picked patches. > > > > > > > > [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > > > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > > > To be honest, I don't think this is a big deal. Git will be merging > > > based on content and not specific hashes. And in the case of conflicts I > > > just copy the file from the tag to our tree. > > > > The essential problem here to me is we are going to allow manual > > patching of dts/upstream tree given this example? How do we keep track > > if all that manual patching landed in Linux DT mainline? The cherry > > picks ensured that we always keep in sync with mainline. > > > > Lets take an example what if Git automatically resolved a merge conflict > > for you with duplicated content or if manually patching a DTS file > > diverged from upstream and get unnoticed during DT syncs? > > > > IMHO, we should try to avoid manual patching of DT subtree otherwise it > > is hard to set a policy as to what level of manual patching is allowed > > or not. > > Part of the problem here is that from the standpoint of applying posted > patches there's no functional difference between what Dario did here and > what could be done once v6.16-rc1-dts is tagged (if it's not already). > It's essentially a "manual patch" either way. Nope, there is a difference here. The cherry-pick from DT rebasing allows the custodian to rather just cherry pick corresponding DT patches rather than applying patches posted on mailing list. I usually do that when reviewing dts/upstream patches if they can be cherry-picked cleanly or not. So there won't be manual patching in that process. ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > We make it clear that > dts/upstream/ *only* gets changes that are in Linus' tree. If someone > tries to be sneaky and push something in that's not quite what's > upstream, it will get stomped on later and there's not going to be any > sympathy for the now broken platform. For us the upstream sync path is via DT rebasing tree only. It usually lags behind Linus' tree by maximum 1 week candence what I have noticed. > > Yes, we document saying to use the cherry-pick script, and that's what > people should do in general. But I don't think there's value in adding a > further delay between "in Linus' tree" and "in devicetree-rebasing". In > the linux kernel, there's thousands of people working on things and so > strict rules can be understandable (someone will be running a bot to > look for "(cherry pick from commit $hash)" and fail things where $hash > doesn't exist, makes sense). Here if the ST custodians are happy just > verifying the kernel commit, OK, that's fine. Or if they want to wait, > that's fine too. We can be a little relaxed and let custodians do what > they see as best. The reason we adopted OF_UPSTREAM was just to get rid of the manual DT patching and the syncs. So is it really that few days lag of DT rebasing tree which is again pushing us towards manual DT patching? I am just trying to understand the shortcomings that DT rebasing tree puts in front of us. -Sumit To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
On Tue, Jun 10, 2025 at 02:22:49PM +0530, Sumit Garg wrote: > On Mon, Jun 09, 2025 at 10:22:39AM -0600, Tom Rini wrote: > > On Mon, Jun 09, 2025 at 05:07:40PM +0100, Sumit Garg wrote: > > > On Mon, Jun 09, 2025 at 09:50:19AM -0600, Tom Rini wrote: > > > > On Mon, Jun 09, 2025 at 04:40:43PM +0100, Sumit Garg wrote: > > > > > On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: > > > > > > Hi Sumit, > > > > > > > > > > > > On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > > > > > > > > > > > > > Hi Patrice, > > > > > > > > > > > > > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > > > > > > > The series adds support for stm32h747-discovery board. > > > > > > > > > > > > > > > > > > Detailed information can be found at: > > > > > > > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > > > > > > > > > > > > > > > > > > > Dario Binacchi (9): > > > > > > > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > > > > > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > > > > > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > > > > > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > > > > > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > > > > > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > > > > > > > ARM: dts: stm32: support STM32h747i-disco board > > > > > > > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > > > > > > > board: stm32: add stm32h747-discovery board support > > > > > > > > > > > > > > > > > > > > > > > > Hi Dario > > > > > > > > > > > > > > > > For the whole series > > > > > > > > Applied to u-boot-stm32/next > > > > > > > > > > > > > > Please give some time for other maintainers to review this patch-set. > > > > > > > The dts/upstream patches in this series aren't clean cherry pick from > > > > > > > upstream. > > > > > > > > > > > > All the commits are already in the mainline Linux kernel, specifically > > > > > > in v6.16-rc1. > > > > > > If you're referring to the fact that the patches can't be applied > > > > > > cleanly, I believe it's > > > > > > because the target path in the Linux kernel doesn't match the one in U-Boot. > > > > > > In fact, the DTS files are located in two different relative paths. > > > > > > > > > > That's exactly why we have (refer here [1]): > > > > > > > > > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > > > > > > > > > You should have waited v6.16-rc1 tag to be synced into > > > > > devicetree-rebasing [2] for the cherry-picks to work. This way of > > > > > manually patching dts/upstream is not allowed since it is going to break > > > > > DT syncs in one way or another. > > > > > > > > > > So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree > > > > > and then send v2 with proper cherry picked patches. > > > > > > > > > > [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > > > > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > > > > > To be honest, I don't think this is a big deal. Git will be merging > > > > based on content and not specific hashes. And in the case of conflicts I > > > > just copy the file from the tag to our tree. > > > > > > The essential problem here to me is we are going to allow manual > > > patching of dts/upstream tree given this example? How do we keep track > > > if all that manual patching landed in Linux DT mainline? The cherry > > > picks ensured that we always keep in sync with mainline. > > > > > > Lets take an example what if Git automatically resolved a merge conflict > > > for you with duplicated content or if manually patching a DTS file > > > diverged from upstream and get unnoticed during DT syncs? > > > > > > IMHO, we should try to avoid manual patching of DT subtree otherwise it > > > is hard to set a policy as to what level of manual patching is allowed > > > or not. > > > > Part of the problem here is that from the standpoint of applying posted > > patches there's no functional difference between what Dario did here and > > what could be done once v6.16-rc1-dts is tagged (if it's not already). > > It's essentially a "manual patch" either way. > > Nope, there is a difference here. The cherry-pick from DT rebasing > allows the custodian to rather just cherry pick corresponding DT patches > rather than applying patches posted on mailing list. I usually do that > when reviewing dts/upstream patches if they can be cherry-picked cleanly > or not. So there won't be manual patching in that process. > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> Alright. I hadn't foreseen anyone doing that rather than "b4 {am,shazam} msg-id" to grab the series. > > We make it clear that > > dts/upstream/ *only* gets changes that are in Linus' tree. If someone > > tries to be sneaky and push something in that's not quite what's > > upstream, it will get stomped on later and there's not going to be any > > sympathy for the now broken platform. > > For us the upstream sync path is via DT rebasing tree only. It usually > lags behind Linus' tree by maximum 1 week candence what I have noticed. > > > > > Yes, we document saying to use the cherry-pick script, and that's what > > people should do in general. But I don't think there's value in adding a > > further delay between "in Linus' tree" and "in devicetree-rebasing". In > > the linux kernel, there's thousands of people working on things and so > > strict rules can be understandable (someone will be running a bot to > > look for "(cherry pick from commit $hash)" and fail things where $hash > > doesn't exist, makes sense). Here if the ST custodians are happy just > > verifying the kernel commit, OK, that's fine. Or if they want to wait, > > that's fine too. We can be a little relaxed and let custodians do what > > they see as best. > > The reason we adopted OF_UPSTREAM was just to get rid of the manual DT > patching and the syncs. So is it really that few days lag of DT rebasing > tree which is again pushing us towards manual DT patching? I am just > trying to understand the shortcomings that DT rebasing tree puts in > front of us. It's mainly that I want to be flexible. So long as we don't violate the content rules (Linus' tree *only*) I don't want to hinder the people eager to now upstream U-Boot support for purely process reasons (which happens, E Shattow on IRC was asking how to at least locally point dts/upstream at something else, at least for local testing).
On Tue, Jun 10, 2025 at 10:04:54AM -0600, Tom Rini wrote: > On Tue, Jun 10, 2025 at 02:22:49PM +0530, Sumit Garg wrote: > > On Mon, Jun 09, 2025 at 10:22:39AM -0600, Tom Rini wrote: > > > On Mon, Jun 09, 2025 at 05:07:40PM +0100, Sumit Garg wrote: > > > > On Mon, Jun 09, 2025 at 09:50:19AM -0600, Tom Rini wrote: > > > > > On Mon, Jun 09, 2025 at 04:40:43PM +0100, Sumit Garg wrote: > > > > > > On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: > > > > > > > Hi Sumit, > > > > > > > > > > > > > > On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > > > > > > > > > > > > > > > Hi Patrice, > > > > > > > > > > > > > > > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > > > > > > > > The series adds support for stm32h747-discovery board. > > > > > > > > > > > > > > > > > > > > Detailed information can be found at: > > > > > > > > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dario Binacchi (9): > > > > > > > > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > > > > > > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > > > > > > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > > > > > > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > > > > > > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > > > > > > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > > > > > > > > ARM: dts: stm32: support STM32h747i-disco board > > > > > > > > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > > > > > > > > board: stm32: add stm32h747-discovery board support > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Dario > > > > > > > > > > > > > > > > > > For the whole series > > > > > > > > > Applied to u-boot-stm32/next > > > > > > > > > > > > > > > > Please give some time for other maintainers to review this patch-set. > > > > > > > > The dts/upstream patches in this series aren't clean cherry pick from > > > > > > > > upstream. > > > > > > > > > > > > > > All the commits are already in the mainline Linux kernel, specifically > > > > > > > in v6.16-rc1. > > > > > > > If you're referring to the fact that the patches can't be applied > > > > > > > cleanly, I believe it's > > > > > > > because the target path in the Linux kernel doesn't match the one in U-Boot. > > > > > > > In fact, the DTS files are located in two different relative paths. > > > > > > > > > > > > That's exactly why we have (refer here [1]): > > > > > > > > > > > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > > > > > > > > > > > You should have waited v6.16-rc1 tag to be synced into > > > > > > devicetree-rebasing [2] for the cherry-picks to work. This way of > > > > > > manually patching dts/upstream is not allowed since it is going to break > > > > > > DT syncs in one way or another. > > > > > > > > > > > > So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree > > > > > > and then send v2 with proper cherry picked patches. > > > > > > > > > > > > [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > > > > > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > > > > > > > To be honest, I don't think this is a big deal. Git will be merging > > > > > based on content and not specific hashes. And in the case of conflicts I > > > > > just copy the file from the tag to our tree. > > > > > > > > The essential problem here to me is we are going to allow manual > > > > patching of dts/upstream tree given this example? How do we keep track > > > > if all that manual patching landed in Linux DT mainline? The cherry > > > > picks ensured that we always keep in sync with mainline. > > > > > > > > Lets take an example what if Git automatically resolved a merge conflict > > > > for you with duplicated content or if manually patching a DTS file > > > > diverged from upstream and get unnoticed during DT syncs? > > > > > > > > IMHO, we should try to avoid manual patching of DT subtree otherwise it > > > > is hard to set a policy as to what level of manual patching is allowed > > > > or not. > > > > > > Part of the problem here is that from the standpoint of applying posted > > > patches there's no functional difference between what Dario did here and > > > what could be done once v6.16-rc1-dts is tagged (if it's not already). > > > It's essentially a "manual patch" either way. > > > > Nope, there is a difference here. The cherry-pick from DT rebasing > > allows the custodian to rather just cherry pick corresponding DT patches > > rather than applying patches posted on mailing list. I usually do that > > when reviewing dts/upstream patches if they can be cherry-picked cleanly > > or not. So there won't be manual patching in that process. > > > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > Alright. I hadn't foreseen anyone doing that rather than "b4 {am,shazam} > msg-id" to grab the series. Maybe we need to have some custodian specific docs listing best practices. > > > > We make it clear that > > > dts/upstream/ *only* gets changes that are in Linus' tree. If someone > > > tries to be sneaky and push something in that's not quite what's > > > upstream, it will get stomped on later and there's not going to be any > > > sympathy for the now broken platform. > > > > For us the upstream sync path is via DT rebasing tree only. It usually > > lags behind Linus' tree by maximum 1 week candence what I have noticed. > > > > > > > > Yes, we document saying to use the cherry-pick script, and that's what > > > people should do in general. But I don't think there's value in adding a > > > further delay between "in Linus' tree" and "in devicetree-rebasing". In > > > the linux kernel, there's thousands of people working on things and so > > > strict rules can be understandable (someone will be running a bot to > > > look for "(cherry pick from commit $hash)" and fail things where $hash > > > doesn't exist, makes sense). Here if the ST custodians are happy just > > > verifying the kernel commit, OK, that's fine. Or if they want to wait, > > > that's fine too. We can be a little relaxed and let custodians do what > > > they see as best. > > > > The reason we adopted OF_UPSTREAM was just to get rid of the manual DT > > patching and the syncs. So is it really that few days lag of DT rebasing > > tree which is again pushing us towards manual DT patching? I am just > > trying to understand the shortcomings that DT rebasing tree puts in > > front of us. > > It's mainly that I want to be flexible. So long as we don't violate the > content rules (Linus' tree *only*) I don't want to hinder the people > eager to now upstream U-Boot support for purely process reasons This flexibility has a cost associated to it which I hopefully was able to clarify above. But finally it's your decision which prevails. BTW, DT rebasing has already got the v6.16-rc1 tag, so it was really just 3 days gap. Quentin (CCed) has already done some proper cherry picking from there [1]. [1] https://patchwork.ozlabs.org/project/uboot/list/?series=460450 > (which > happens, E Shattow on IRC was asking how to at least locally point > dts/upstream at something else, at least for local testing). > I would love to hear problems from people if that's for downstream development too. -Sumit To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
Hi all, On 6/11/25 2:08 PM, Sumit Garg wrote: > On Tue, Jun 10, 2025 at 10:04:54AM -0600, Tom Rini wrote: >> On Tue, Jun 10, 2025 at 02:22:49PM +0530, Sumit Garg wrote: >>> On Mon, Jun 09, 2025 at 10:22:39AM -0600, Tom Rini wrote: >>>> On Mon, Jun 09, 2025 at 05:07:40PM +0100, Sumit Garg wrote: >>>>> On Mon, Jun 09, 2025 at 09:50:19AM -0600, Tom Rini wrote: >>>>>> On Mon, Jun 09, 2025 at 04:40:43PM +0100, Sumit Garg wrote: >>>>>>> On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: >>>>>>>> Hi Sumit, >>>>>>>> >>>>>>>> On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: >>>>>>>>> >>>>>>>>> Hi Patrice, >>>>>>>>> >>>>>>>>> On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 6/7/25 11:37, Dario Binacchi wrote: >>>>>>>>>>> The series adds support for stm32h747-discovery board. >>>>>>>>>>> >>>>>>>>>>> Detailed information can be found at: >>>>>>>>>>> https://www.st.com/en/evaluation-tools/stm32h747i-disco.html >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Dario Binacchi (9): >>>>>>>>>>> ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles >>>>>>>>>>> dt-bindings: arm: stm32: add compatible for stm32h747i-disco board >>>>>>>>>>> dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK >>>>>>>>>>> ARM: dts: stm32: add uart8 node for stm32h743 MCU >>>>>>>>>>> ARM: dts: stm32: add pin map for UART8 controller on stm32h743 >>>>>>>>>>> ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 >>>>>>>>>>> ARM: dts: stm32: support STM32h747i-disco board >>>>>>>>>>> ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file >>>>>>>>>>> board: stm32: add stm32h747-discovery board support >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi Dario >>>>>>>>>> >>>>>>>>>> For the whole series >>>>>>>>>> Applied to u-boot-stm32/next >>>>>>>>> >>>>>>>>> Please give some time for other maintainers to review this patch-set. >>>>>>>>> The dts/upstream patches in this series aren't clean cherry pick from >>>>>>>>> upstream. >>>>>>>> >>>>>>>> All the commits are already in the mainline Linux kernel, specifically >>>>>>>> in v6.16-rc1. >>>>>>>> If you're referring to the fact that the patches can't be applied >>>>>>>> cleanly, I believe it's >>>>>>>> because the target path in the Linux kernel doesn't match the one in U-Boot. >>>>>>>> In fact, the DTS files are located in two different relative paths. >>>>>>> >>>>>>> That's exactly why we have (refer here [1]): >>>>>>> >>>>>>> ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> >>>>>>> >>>>>>> You should have waited v6.16-rc1 tag to be synced into >>>>>>> devicetree-rebasing [2] for the cherry-picks to work. This way of >>>>>>> manually patching dts/upstream is not allowed since it is going to break >>>>>>> DT syncs in one way or another. >>>>>>> >>>>>>> So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree >>>>>>> and then send v2 with proper cherry picked patches. >>>>>>> >>>>>>> [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing >>>>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git >>>>>> >>>>>> To be honest, I don't think this is a big deal. Git will be merging >>>>>> based on content and not specific hashes. And in the case of conflicts I >>>>>> just copy the file from the tag to our tree. >>>>> >>>>> The essential problem here to me is we are going to allow manual >>>>> patching of dts/upstream tree given this example? How do we keep track >>>>> if all that manual patching landed in Linux DT mainline? The cherry >>>>> picks ensured that we always keep in sync with mainline. >>>>> >>>>> Lets take an example what if Git automatically resolved a merge conflict >>>>> for you with duplicated content or if manually patching a DTS file >>>>> diverged from upstream and get unnoticed during DT syncs? >>>>> >>>>> IMHO, we should try to avoid manual patching of DT subtree otherwise it >>>>> is hard to set a policy as to what level of manual patching is allowed >>>>> or not. >>>> >>>> Part of the problem here is that from the standpoint of applying posted >>>> patches there's no functional difference between what Dario did here and >>>> what could be done once v6.16-rc1-dts is tagged (if it's not already). >>>> It's essentially a "manual patch" either way. >>> >>> Nope, there is a difference here. The cherry-pick from DT rebasing >>> allows the custodian to rather just cherry pick corresponding DT patches >>> rather than applying patches posted on mailing list. I usually do that >>> when reviewing dts/upstream patches if they can be cherry-picked cleanly >>> or not. So there won't be manual patching in that process. >>> >>> ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> >> >> Alright. I hadn't foreseen anyone doing that rather than "b4 {am,shazam} >> msg-id" to grab the series. > > Maybe we need to have some custodian specific docs listing best > practices. > Or extend https://docs.u-boot.org/en/latest/develop/devicetree/control.html#where-do-i-get-a-devicetree-file-for-my-board https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing ? >> >>>> We make it clear that >>>> dts/upstream/ *only* gets changes that are in Linus' tree. If someone >>>> tries to be sneaky and push something in that's not quite what's >>>> upstream, it will get stomped on later and there's not going to be any >>>> sympathy for the now broken platform. >>> >>> For us the upstream sync path is via DT rebasing tree only. It usually >>> lags behind Linus' tree by maximum 1 week candence what I have noticed. >>> >>>> >>>> Yes, we document saying to use the cherry-pick script, and that's what >>>> people should do in general. But I don't think there's value in adding a >>>> further delay between "in Linus' tree" and "in devicetree-rebasing". In >>>> the linux kernel, there's thousands of people working on things and so >>>> strict rules can be understandable (someone will be running a bot to >>>> look for "(cherry pick from commit $hash)" and fail things where $hash >>>> doesn't exist, makes sense). Here if the ST custodians are happy just >>>> verifying the kernel commit, OK, that's fine. Or if they want to wait, >>>> that's fine too. We can be a little relaxed and let custodians do what >>>> they see as best. >>> >>> The reason we adopted OF_UPSTREAM was just to get rid of the manual DT >>> patching and the syncs. So is it really that few days lag of DT rebasing >>> tree which is again pushing us towards manual DT patching? I am just >>> trying to understand the shortcomings that DT rebasing tree puts in >>> front of us. >> >> It's mainly that I want to be flexible. So long as we don't violate the >> content rules (Linus' tree *only*) I don't want to hinder the people >> eager to now upstream U-Boot support for purely process reasons > > This flexibility has a cost associated to it which I hopefully was able > to clarify above. But finally it's your decision which prevails. > > BTW, DT rebasing has already got the v6.16-rc1 tag, so it was really > just 3 days gap. Quentin (CCed) has already done some proper cherry > picking from there [1]. > Not sure why I was summoned here but I can give my (maybe undesired) 2 cents :) I (a contributor) **really** do not want to have hand-crafted patches in dts/upstream. Use tools/update-subtree.sh for patches in that tree. Only Tom is allowed to use pull because it's a mess to send a patch for it and he usually announces he's doing it and then pushes to the next branch directly, contributors can use pick instead. If a pick fails, backport everything needed for it to apply cleanly. Yes, this may be tedious. Make sure you do not break any other board as well. I was already surprised we have U-Boot specific files in dts/upstream (e.g. Makefiles :) ). 1) Doing it manually doesn't enforce the addition of the commit hash used for the backport/cherry-pick in the commit log, which may be problematic (how to quickly check that the patch contains what it should contain and not more, or less?). How to verify it actually was merged? In that state and not after other changes? Let's imagine an upstream patch that changes the SoC.dtsi and associated boards dts, if backporting manually one could be tempted to skip a conflicting board dts (because another commit needs to be picked before for it to apply cleanly). Also, until it's merged in master (which can take a long time depending where you are in the release cycle) there's no guarantee the patch is actually going to make it as is to the tree (it isn't unheard of to have reverts or even rebases in maintainer trees before sending a merge request to Linus). 2) If there are manual changes made to the patch that aren't upstreamed in the kernel (or dependencies (git context) are missing), if we diverge too much from upstream, Tom will have git conflicts when pulling new versions. How to resolve those conflicts will be interesting. 3) Worse, if there are non-upstreamed changes that aren't inducing any git conflict (via git context for example), then the merge/pull may not say anything about it and we'll carry non-upstream patches in dts/upstream. Maybe we should not even do a subtree pull/merge but erase everything and reimport everything every time we bump, to make sure 2 or 3) cannot happen? For what it's worth, I've caught some (Rockchip) contributors sending patches to dts/upstream that weren't even sent to the kernel mailing list. That wasn't done on purpose but there are probably a few patches already that went through the cracks. I am not sure how we could enforce that (which needs to be done with maintainer tools as there are already too many ways to contribute to U-boot (patman, git-send-email, b4, etc...)) or even if we want to. But making dts/upstream the new arch/arm/dts/ (for ARM) directory doesn't make much sense to me. If you cannot wait for devicetree-rebasing to receive the new tag, do the changes in -u-boot.dtsi and revert the changes once we update dts/upstream to a newer tag (or cherry-pick once available)? v6.16-rc1 took a bit longer this time to reach devicetree-rebasing I think, but it landed this morning (UTC) so it isn't THAT long compared to the push in master. We could ask devicetree-rebasing people to push the master branch more often to avoid the up-to 2-week delay between v6.15 and v6.16-rc1 for example. I have read nothing in this thread so this is absolutely not a jab at some contributor or maintainer in this series. On a side-note, I think we should add -s to tools/update-subtree.sh's git cherry-pick call to know who contributed the change to U-Boot (as the commit author will be the same as in the kernel as far as I remember). To be fair, the whole process is a bit constraining, especially for new boards. You may have to wait up to ~2 months (a full kernel release cycle) to see a tag with the device tree for your board, and only then can you support the board in U-Boot with OF_UPSTREAM. In Rockchip we typically force OF_UPSTREAM for new boards, but we also typically do not accept hand-crafted git commits to dts/upstream. I don't know if it's deterring contributors but we are still getting some contributions here and there. Not sure how we should be handling that :/ > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=460450 > >> (which >> happens, E Shattow on IRC was asking how to at least locally point >> dts/upstream at something else, at least for local testing). >> > > I would love to hear problems from people if that's for downstream > development too. > We can add things in https://docs.u-boot.org/en/latest/develop/devicetree/control.html#where-do-i-get-a-devicetree-file-for-my-board and https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing to be clearer on the limitations. Though til we enforce a check, this is just information. Cheers, Quentin To unsubscribe from this group and stop receiving emails from it, send an email to linux-amarula+unsubscribe@amarulasolutions.com.
On Wed, Jun 11, 2025 at 03:25:18PM +0200, Quentin Schulz wrote: > Hi all, > > On 6/11/25 2:08 PM, Sumit Garg wrote: > > On Tue, Jun 10, 2025 at 10:04:54AM -0600, Tom Rini wrote: > > > On Tue, Jun 10, 2025 at 02:22:49PM +0530, Sumit Garg wrote: > > > > On Mon, Jun 09, 2025 at 10:22:39AM -0600, Tom Rini wrote: > > > > > On Mon, Jun 09, 2025 at 05:07:40PM +0100, Sumit Garg wrote: > > > > > > On Mon, Jun 09, 2025 at 09:50:19AM -0600, Tom Rini wrote: > > > > > > > On Mon, Jun 09, 2025 at 04:40:43PM +0100, Sumit Garg wrote: > > > > > > > > On Mon, Jun 09, 2025 at 03:46:27PM +0200, Dario Binacchi wrote: > > > > > > > > > Hi Sumit, > > > > > > > > > > > > > > > > > > On Mon, Jun 9, 2025 at 3:25 PM Sumit Garg <sumit.garg@kernel.org> wrote: > > > > > > > > > > > > > > > > > > > > Hi Patrice, > > > > > > > > > > > > > > > > > > > > On Mon, Jun 09, 2025 at 03:15:14PM +0200, Patrice CHOTARD wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 6/7/25 11:37, Dario Binacchi wrote: > > > > > > > > > > > > The series adds support for stm32h747-discovery board. > > > > > > > > > > > > > > > > > > > > > > > > Detailed information can be found at: > > > > > > > > > > > > https://www.st.com/en/evaluation-tools/stm32h747i-disco.html > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dario Binacchi (9): > > > > > > > > > > > > ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles > > > > > > > > > > > > dt-bindings: arm: stm32: add compatible for stm32h747i-disco board > > > > > > > > > > > > dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK > > > > > > > > > > > > ARM: dts: stm32: add uart8 node for stm32h743 MCU > > > > > > > > > > > > ARM: dts: stm32: add pin map for UART8 controller on stm32h743 > > > > > > > > > > > > ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 > > > > > > > > > > > > ARM: dts: stm32: support STM32h747i-disco board > > > > > > > > > > > > ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file > > > > > > > > > > > > board: stm32: add stm32h747-discovery board support > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Dario > > > > > > > > > > > > > > > > > > > > > > For the whole series > > > > > > > > > > > Applied to u-boot-stm32/next > > > > > > > > > > > > > > > > > > > > Please give some time for other maintainers to review this patch-set. > > > > > > > > > > The dts/upstream patches in this series aren't clean cherry pick from > > > > > > > > > > upstream. > > > > > > > > > > > > > > > > > > All the commits are already in the mainline Linux kernel, specifically > > > > > > > > > in v6.16-rc1. > > > > > > > > > If you're referring to the fact that the patches can't be applied > > > > > > > > > cleanly, I believe it's > > > > > > > > > because the target path in the Linux kernel doesn't match the one in U-Boot. > > > > > > > > > In fact, the DTS files are located in two different relative paths. > > > > > > > > > > > > > > > > That's exactly why we have (refer here [1]): > > > > > > > > > > > > > > > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > > > > > > > > > > > > > > > You should have waited v6.16-rc1 tag to be synced into > > > > > > > > devicetree-rebasing [2] for the cherry-picks to work. This way of > > > > > > > > manually patching dts/upstream is not allowed since it is going to break > > > > > > > > DT syncs in one way or another. > > > > > > > > > > > > > > > > So I would suggest you to wait for v6.16-rc1 to land in DT rebasing tree > > > > > > > > and then send v2 with proper cherry picked patches. > > > > > > > > > > > > > > > > [1] https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > > > > > > > > [2] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git > > > > > > > > > > > > > > To be honest, I don't think this is a big deal. Git will be merging > > > > > > > based on content and not specific hashes. And in the case of conflicts I > > > > > > > just copy the file from the tag to our tree. > > > > > > > > > > > > The essential problem here to me is we are going to allow manual > > > > > > patching of dts/upstream tree given this example? How do we keep track > > > > > > if all that manual patching landed in Linux DT mainline? The cherry > > > > > > picks ensured that we always keep in sync with mainline. > > > > > > > > > > > > Lets take an example what if Git automatically resolved a merge conflict > > > > > > for you with duplicated content or if manually patching a DTS file > > > > > > diverged from upstream and get unnoticed during DT syncs? > > > > > > > > > > > > IMHO, we should try to avoid manual patching of DT subtree otherwise it > > > > > > is hard to set a policy as to what level of manual patching is allowed > > > > > > or not. > > > > > > > > > > Part of the problem here is that from the standpoint of applying posted > > > > > patches there's no functional difference between what Dario did here and > > > > > what could be done once v6.16-rc1-dts is tagged (if it's not already). > > > > > It's essentially a "manual patch" either way. > > > > > > > > Nope, there is a difference here. The cherry-pick from DT rebasing > > > > allows the custodian to rather just cherry pick corresponding DT patches > > > > rather than applying patches posted on mailing list. I usually do that > > > > when reviewing dts/upstream patches if they can be cherry-picked cleanly > > > > or not. So there won't be manual patching in that process. > > > > > > > > ./tools/update-subtree.sh pick dts <commit-id-to-be-picked> > > > > > > Alright. I hadn't foreseen anyone doing that rather than "b4 {am,shazam} > > > msg-id" to grab the series. > > > > Maybe we need to have some custodian specific docs listing best > > practices. > > > > Or extend > > https://docs.u-boot.org/en/latest/develop/devicetree/control.html#where-do-i-get-a-devicetree-file-for-my-board > https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > > ? > > > > > > > > > We make it clear that > > > > > dts/upstream/ *only* gets changes that are in Linus' tree. If someone > > > > > tries to be sneaky and push something in that's not quite what's > > > > > upstream, it will get stomped on later and there's not going to be any > > > > > sympathy for the now broken platform. > > > > > > > > For us the upstream sync path is via DT rebasing tree only. It usually > > > > lags behind Linus' tree by maximum 1 week candence what I have noticed. > > > > > > > > > > > > > > Yes, we document saying to use the cherry-pick script, and that's what > > > > > people should do in general. But I don't think there's value in adding a > > > > > further delay between "in Linus' tree" and "in devicetree-rebasing". In > > > > > the linux kernel, there's thousands of people working on things and so > > > > > strict rules can be understandable (someone will be running a bot to > > > > > look for "(cherry pick from commit $hash)" and fail things where $hash > > > > > doesn't exist, makes sense). Here if the ST custodians are happy just > > > > > verifying the kernel commit, OK, that's fine. Or if they want to wait, > > > > > that's fine too. We can be a little relaxed and let custodians do what > > > > > they see as best. > > > > > > > > The reason we adopted OF_UPSTREAM was just to get rid of the manual DT > > > > patching and the syncs. So is it really that few days lag of DT rebasing > > > > tree which is again pushing us towards manual DT patching? I am just > > > > trying to understand the shortcomings that DT rebasing tree puts in > > > > front of us. > > > > > > It's mainly that I want to be flexible. So long as we don't violate the > > > content rules (Linus' tree *only*) I don't want to hinder the people > > > eager to now upstream U-Boot support for purely process reasons > > > > This flexibility has a cost associated to it which I hopefully was able > > to clarify above. But finally it's your decision which prevails. > > > > BTW, DT rebasing has already got the v6.16-rc1 tag, so it was really > > just 3 days gap. Quentin (CCed) has already done some proper cherry > > picking from there [1]. > > > > Not sure why I was summoned here but I can give my (maybe undesired) 2 cents > :) > > I (a contributor) **really** do not want to have hand-crafted patches in > dts/upstream. Use tools/update-subtree.sh for patches in that tree. Only Tom > is allowed to use pull because it's a mess to send a patch for it and he > usually announces he's doing it and then pushes to the next branch directly, > contributors can use pick instead. If a pick fails, backport everything > needed for it to apply cleanly. Yes, this may be tedious. Make sure you do > not break any other board as well. > > I was already surprised we have U-Boot specific files in dts/upstream (e.g. > Makefiles :) ). > > 1) Doing it manually doesn't enforce the addition of the commit hash used > for the backport/cherry-pick in the commit log, which may be problematic > (how to quickly check that the patch contains what it should contain and not > more, or less?). How to verify it actually was merged? In that state and not > after other changes? Let's imagine an upstream patch that changes the > SoC.dtsi and associated boards dts, if backporting manually one could be > tempted to skip a conflicting board dts (because another commit needs to be > picked before for it to apply cleanly). Also, until it's merged in master > (which can take a long time depending where you are in the release cycle) > there's no guarantee the patch is actually going to make it as is to the > tree (it isn't unheard of to have reverts or even rebases in maintainer > trees before sending a merge request to Linus). > > 2) If there are manual changes made to the patch that aren't upstreamed in > the kernel (or dependencies (git context) are missing), if we diverge too > much from upstream, Tom will have git conflicts when pulling new versions. > How to resolve those conflicts will be interesting. > > 3) Worse, if there are non-upstreamed changes that aren't inducing any git > conflict (via git context for example), then the merge/pull may not say > anything about it and we'll carry non-upstream patches in dts/upstream. > > Maybe we should not even do a subtree pull/merge but erase everything and > reimport everything every time we bump, to make sure 2 or 3) cannot happen? > > For what it's worth, I've caught some (Rockchip) contributors sending > patches to dts/upstream that weren't even sent to the kernel mailing list. > That wasn't done on purpose but there are probably a few patches already > that went through the cracks. I am not sure how we could enforce that (which > needs to be done with maintainer tools as there are already too many ways to > contribute to U-boot (patman, git-send-email, b4, etc...)) or even if we > want to. But making dts/upstream the new arch/arm/dts/ (for ARM) directory > doesn't make much sense to me. > > If you cannot wait for devicetree-rebasing to receive the new tag, do the > changes in -u-boot.dtsi and revert the changes once we update dts/upstream > to a newer tag (or cherry-pick once available)? > > v6.16-rc1 took a bit longer this time to reach devicetree-rebasing I think, > but it landed this morning (UTC) so it isn't THAT long compared to the push > in master. We could ask devicetree-rebasing people to push the master branch > more often to avoid the up-to 2-week delay between v6.15 and v6.16-rc1 for > example. > > I have read nothing in this thread so this is absolutely not a jab at some > contributor or maintainer in this series. > > On a side-note, I think we should add -s to tools/update-subtree.sh's git > cherry-pick call to know who contributed the change to U-Boot (as the commit > author will be the same as in the kernel as far as I remember). > > To be fair, the whole process is a bit constraining, especially for new > boards. You may have to wait up to ~2 months (a full kernel release cycle) > to see a tag with the device tree for your board, and only then can you > support the board in U-Boot with OF_UPSTREAM. In Rockchip we typically force > OF_UPSTREAM for new boards, but we also typically do not accept hand-crafted > git commits to dts/upstream. I don't know if it's deterring contributors but > we are still getting some contributions here and there. Not sure how we > should be handling that :/ > > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=460450 > > > > > (which > > > happens, E Shattow on IRC was asking how to at least locally point > > > dts/upstream at something else, at least for local testing). > > > > > > > I would love to hear problems from people if that's for downstream > > development too. > > > > We can add things in https://docs.u-boot.org/en/latest/develop/devicetree/control.html#where-do-i-get-a-devicetree-file-for-my-board > and https://docs.u-boot.org/en/latest/develop/devicetree/control.html#resyncing-with-devicetree-rebasing > to be clearer on the limitations. Though til we enforce a check, this is > just information. Thank you for taking the time to provide your perspective on this Quentin. And while I had hoped to be able to look over the history of dts/upstream and see that it was just the Makefiles (which I don't think we can avoid) being the difference between devicetree-rebasing and us, that's not quite the case. So, yes, Sumit's opinion that we must cherry-pick seems best. The documentation needs to be updated a bit, and some more clear examples perhaps provided too. I've added some local scripting that will complain at me about changes that don't have the cherry-pick message or that the commit referenced doesn't exist. I may spend a little time figuring out how to dump each commit and make sure they're the same, but that too much get tricky.
The series adds support for stm32h747-discovery board. Detailed information can be found at: https://www.st.com/en/evaluation-tools/stm32h747i-disco.html Dario Binacchi (9): ARM: dts: stm32h7-pinctrl: add _a suffix to u[s]art_pins phandles dt-bindings: arm: stm32: add compatible for stm32h747i-disco board dt-bindings: clock: stm32h7: rename USART{7,8}_CK to UART{7,8}_CK ARM: dts: stm32: add uart8 node for stm32h743 MCU ARM: dts: stm32: add pin map for UART8 controller on stm32h743 ARM: dts: stm32: add an extra pin map for USART1 on stm32h743 ARM: dts: stm32: support STM32h747i-disco board ARM: dts: stm32: add stm32h747i-disco-u-boot DTS file board: stm32: add stm32h747-discovery board support arch/arm/dts/stm32h747i-disco-u-boot.dtsi | 104 ++++++++++++++ arch/arm/mach-stm32/stm32h7/Kconfig | 4 + board/st/stm32h747-disco/Kconfig | 15 ++ board/st/stm32h747-disco/MAINTAINERS | 7 + board/st/stm32h747-disco/Makefile | 6 + board/st/stm32h747-disco/stm32h747-disco.c | 42 ++++++ configs/stm32h747-disco_defconfig | 35 +++++ drivers/clk/stm32/clk-stm32h7.c | 5 + dts/upstream/Bindings/arm/stm32/stm32.yaml | 4 + .../include/dt-bindings/clock/stm32h7-clks.h | 4 +- dts/upstream/src/arm/st/stm32h7-pinctrl.dtsi | 34 ++++- dts/upstream/src/arm/st/stm32h743.dtsi | 8 ++ dts/upstream/src/arm/st/stm32h743i-disco.dts | 2 +- dts/upstream/src/arm/st/stm32h743i-eval.dts | 2 +- dts/upstream/src/arm/st/stm32h747i-disco.dts | 136 ++++++++++++++++++ dts/upstream/src/arm/st/stm32h750i-art-pi.dts | 6 +- include/configs/stm32h747-disco.h | 32 +++++ 17 files changed, 435 insertions(+), 11 deletions(-) create mode 100644 arch/arm/dts/stm32h747i-disco-u-boot.dtsi create mode 100644 board/st/stm32h747-disco/Kconfig create mode 100644 board/st/stm32h747-disco/MAINTAINERS create mode 100644 board/st/stm32h747-disco/Makefile create mode 100644 board/st/stm32h747-disco/stm32h747-disco.c create mode 100644 configs/stm32h747-disco_defconfig create mode 100644 dts/upstream/src/arm/st/stm32h747i-disco.dts create mode 100644 include/configs/stm32h747-disco.h