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

[Tom Rini]

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
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.
Samsung platforms are only recently becoming more active in U-Boot as
well, so that's all understandable. On the other hand TI folks know, and
I expect the K3 families to switch over to this series ASAP, and STM32
and all of the AMD/Xilinx stuff too.

-- 
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/1c0becc6/attachment.sig>