[0/9] Support stm32h747-discovery board

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
  

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.