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.kozlow...@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.kozlow...@linaro.org> R: Alim Akhtar <alim.akh...@samsung.com> L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-samsung-...@vger.kernel.org S: Maintained P: Documentation/process/maintainer-soc-clean-dts.rst Q: https://patchwork.kernel.org/project/linux-samsung-soc/list/
signature.asc
Description: PGP signature
