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

[Conor Dooley]

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.

I don't think that adding U-Boot platform maintainers as reviewers for
the platforms in the kernel is a terrible idea. Certainly kernel
platform maintainers for which U-Boot platform maintainers are added to
the MAINTAINERS entry will be aware. That said, something like your
"strict dts compliance" maintainer profile entry [1] would be helpful I think
to denote which platforms' dts are being shared in this manner

1:
ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES
M:	Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
R:	Alim Akhtar <alim.akhtar at samsung.com>
L:	linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
L:	linux-samsung-soc at vger.kernel.org
S:	Maintained
P:	Documentation/process/maintainer-soc-clean-dts.rst
Q:	https://patchwork.kernel.org/project/linux-samsung-soc/list/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot-custodians/attachments/20231222/4656025d/attachment-0001.sig>