[PATCH 0/9] Support stm32h747-discovery board

[Sumit Garg]

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 at 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