[PATCH 0/9] Support stm32h747-discovery board

[Sumit Garg]

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