[PATCH 0/9] Support stm32h747-discovery board

[Tom Rini]

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

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250609/d12e67c7/attachment.sig>