[PATCH v2 0/8] An effort to bring DT bindings compliance within U-Boot

[Tom Rini]

On Fri, Dec 22, 2023 at 04:55:54PM +0100, Krzysztof Kozlowski wrote:
> On 22/12/2023 16:46, Tom Rini wrote:
> > On Fri, Dec 22, 2023 at 04:38:01PM +0100, Krzysztof Kozlowski wrote:
> >> On 22/12/2023 14:43, Sumit Garg wrote:
> >>> On Fri, 22 Dec 2023 at 13:48, Krzysztof Kozlowski
> >>> <krzysztof.kozlowski at linaro.org> wrote:
> >>>>
> >>>> On 22/12/2023 07:12, Sumit Garg wrote:
> >>>>> Changes in v2:
> >>>>> --------------
> >>>>> - Patch #1: excluded gitab CI config check and added commit description.
> >>>>> - Patch #3: s/UBOOT_DTSI_LOC/u_boot_dtsi_loc/
> >>>>> - Patch #4: s/DEVICE_TREE_LOC/dt_dir/ and s/U-boot/U-Boot/
> >>>>> - Patch #5: s/U-boot/U-Boot/
> >>>>> - Patch #6 and #7: Picked up review tags
> >>>>>
> >>>>> Prerequisite
> >>>>> ------------
> >>>>>
> >>>>> This patch series requires devicetree-rebasing git repo to be added as a
> >>>>> subtree to the main U-Boot repo via:
> >>>>>
> >>>>> $ git subtree add --prefix devicetree-rebasing \
> >>>>>       git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \
> >>>>>       v6.6-dts --squash
> >>>>>
> >>>>> Background
> >>>>> ----------
> >>>>>
> >>>>> This effort started while I was reviewing patch series corresponding to
> >>>>> Qcom platforms [1] which was about to import modified devicetree source
> >>>>> files from Linux kernel. I suppose keeping devicetree files sync with
> >>>>> Linux kernel without any DT bindings schema validation has been a pain
> >>>>> for U-Boot SoC/platform maintainers. There has been past discussions
> >>>>> about a single DT repo but that hasn't come up and Linux kernel remained
> >>>>> the place where DT source files as well as bindings are placed and
> >>>>> maintained.
> >>>>
> >>>> Thanks for doing this.
> >>>>
> >>>> I really suggest to store information that kernel DTS is directly
> >>>> re-used, thus DTS backward and forward compatibility matters, also in
> >>>> Linux kernel sources. The point is that sub-arch maintainers should be
> >>>> aware of it. I don't think that as DT maintainers we can efficiently
> >>>> keep an eye on it. Maybe create a subsystem profile and include it to
> >>>> maintainer entries of such affected platforms?
> >>>>
> >>>
> >>> From U-Boot point of view, currently we have the config option:
> >>> "CONFIG_OF_UPSTREAM=y" per platform which means directly re-use of
> >>> kernel DTS. So U-Boot sub-arch maintainers should be aware of
> >>> platforms which get converted to re-use kernel DTS.
> >>
> >> I was speaking about kernel.
> >>
> >>>
> >>> I suppose we have to relay information to kernel sub-arch maintainers
> >>> who aren't the same as maintaining U-Boot counterparts. How about
> >>> adding U-Boot ML to CC for whichever DT change gets submitted in the
> >>
> >> And every other project? Just setup lei filters.
> >>
> >>> kernel? Otherwise adding U-Boot sub-arch maintainers as reviewers for
> >>> corresponding kernel DT changes works too if that's acceptable.
> >>
> >> You just entirely ignored my proposal without addressing it... ok let it
> >> be. No, CC-ing U-boot maintainers changes nothing because as I said, I
> >> want kernel maintainers and contributors to be aware.
> > 
> > Maybe an underlying question is, what kernel maintainers aren't aware,
> > but should have been already? Then we can figure out how to address
> 
> None of them is aware.
> 
> > that. For example, with your Samsung hat on you weren't aware that
> > exynos 4/5/7 DTS files are cared about by U-Boot, but are now aware.
> 
> Hm, I am still not aware of this. I mean, you wrote it above, but it is
> the first time I see using directly usptream DTS for U-Boot on Samsung
> platforms.
> 
> Did anyone test it actually? I certainly did not. I think this patchset
> did not remove U-Boot-tree Samsung DTS, did it?

With this literal patchset, only the amlogic platforms Sumit is changing
have been tested, yes. In general, the U-Boot guideline has been "resync
your DTS files from the kernel as often as possible" as well as "start
with DTS files from the kernel, not hand-crafted". And some SoCs/vendors
have been better about following these rules than others. There's a good
number of commits under arch/arm/dts/ today syncing up with various
states of v6.6. Which I guess emphasises my question, what kernel
maintainers weren't aware that U-Boot has been consuming their DTS files
as-is (as much as possible) for a number of years now?

-- 
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-custodians/attachments/20231222/3d07bdbd/attachment.sig>