| Message ID | 20231222061208.3009970-1-sumit.garg@linaro.org |
|---|---|
| Headers | show |
| Series | An effort to bring DT bindings compliance within U-Boot | expand |
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? Best regards, Krzysztof Best regards, Krzysztof
On Fri, 22 Dec 2023 at 13:48, Krzysztof Kozlowski <krzysztof.kozlowski@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 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 kernel? Otherwise adding U-Boot sub-arch maintainers as reviewers for corresponding kernel DT changes works too if that's acceptable. -Sumit > Best regards, > Krzysztof > > Best regards, > Krzysztof >
On 22/12/2023 14:43, Sumit Garg wrote: > On Fri, 22 Dec 2023 at 13:48, Krzysztof Kozlowski > <krzysztof.kozlowski@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. Best regards, Krzysztof
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@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@linaro.org> R: Alim Akhtar <alim.akhtar@samsung.com> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) L: linux-samsung-soc@vger.kernel.org S: Maintained P: Documentation/process/maintainer-soc-clean-dts.rst Q: https://patchwork.kernel.org/project/linux-samsung-soc/list/
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@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.
On 22/12/2023 16:45, Conor Dooley wrote: >>> >>> 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 The point is it does not solve my concern here. I did not express problem that U-Boot maintainers are not aware. They can easily be aware by setting simple lei filters. The problem I want to solve is the kernel maintainers to be aware. Best regards, Krzysztof
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@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? Best regards, Krzysztof
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@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?
On Fri, 22 Dec 2023 at 21:23, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 22/12/2023 16:45, Conor Dooley wrote: > >>> > >>> 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 > > The point is it does not solve my concern here. I did not express > problem that U-Boot maintainers are not aware. They can easily be aware > by setting simple lei filters. I thought your major concern was how we can enforce DTS backward and forward compatibility although the DT ABI stability is already documented here [1]. My suggestion was really based on recognising people who really care about DT ABI for particular platforms. I think adding people from other projects would certainly help with DT ABI stability since the kernel is the single point of contribution. There will be DT contributors from other projects too like you may have already seen people contributing bootloader (U-Boot) specific bindings/DTS changes. [1] https://docs.kernel.org/process/maintainer-soc.html#devicetree-abi-stability > > The problem I want to solve is the kernel maintainers to be aware. > Although Tom has already expressed in the other thread that U-Boot has been a long time user of upstream DT but if we want to make it more formal from an enforcement point of view then I liked Conor's idea. If you agree then I can create maintainer profile entry as per following example for Amlogic platforms to start with: ARM/Amlogic Meson SoC support M: Neil Armstrong <neil.armstrong@linaro.org> M: Kevin Hilman <khilman@baylibre.com> R: Jerome Brunet <jbrunet@baylibre.com> R: Martin Blumenstingl <martin.blumenstingl@googlemail.com> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) L: linux-amlogic@lists.infradead.org S: Maintained P: Documentation/process/maintainer-soc-u-boot-dt-abi.rst W: http://linux-meson.com/ F: Documentation/devicetree/bindings/phy/amlogic* F: arch/arm/boot/dts/amlogic/ F: arch/arm/mach-meson/ F: arch/arm64/boot/dts/amlogic/ F: drivers/pmdomain/amlogic/ F: drivers/mmc/host/meson* F: drivers/phy/amlogic/ F: drivers/pinctrl/meson/ F: drivers/rtc/rtc-meson* F: drivers/soc/amlogic/ N: meson -Sumit
On 26/12/2023 08:53, Sumit Garg wrote: >> >> The problem I want to solve is the kernel maintainers to be aware. >> > > Although Tom has already expressed in the other thread that U-Boot has > been a long time user of upstream DT but if we want to make it more > formal from an enforcement point of view then I liked Conor's idea. If What did I write in my first email? "Maybe create a subsystem profile and include it to maintainer entries of such affected platforms?" You really keep ignoring my emails, so I'll stop responding here. Best regards, Krzysztof
On Tue, 26 Dec 2023 at 14:46, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 26/12/2023 08:53, Sumit Garg wrote: > >> > >> The problem I want to solve is the kernel maintainers to be aware. > >> > > > > Although Tom has already expressed in the other thread that U-Boot has > > been a long time user of upstream DT but if we want to make it more > > formal from an enforcement point of view then I liked Conor's idea. If > > What did I write in my first email? > > "Maybe create a subsystem profile and include it to > maintainer entries of such affected platforms?" Apologies, it was a miss on my part. I really thought it was about U-Boot maintainer awareness. I will propose this once this series lands in U-Boot. -Sumit
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. However, Linux kernel DT maintainers proposed [2] for U-Boot to rather use devicetree-rebasing repo [3] which is a forked copy from Linux kernel for DT source files as well as bindings. It is tagged at every Linux kernel major release or intermideate release candidates. So here I have tried to reuse that to bring DT bingings compliance as well as a standard way to maintain a regular sync of DT source files with Linux kernel. In order to maintain devicetree files sync, U-Boot will maintains a Git subtree for devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It will be regularly updated with every new kernel major release via subtree pull as follows: $ git subtree pull --prefix devicetree-rebasing \ git://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git \ <release-tag> --squash The RFC/prototype for this series has been discussed with Linux DT maintainers as well as U-Boot maintainers here [4]. Now we would like to reach out to wider U-Boot community to seek feedback. [1] https://lore.kernel.org/all/CAFA6WYMLUD9cnkr=R0Uur+1UeTMkKjM2zDdMJtXb3nmrLk+pDg@mail.gmail.com/ [2] https://lore.kernel.org/all/CAL_JsqKEjv2tSGmT+0ZiO7_qbBfhTycbGnhJhYpKDFzfO9jzDg@mail.gmail.com/ [3] https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ [4] https://github.com/u-boot/u-boot/pull/451 Changes ------- Traditionally, U-Boot placed copies of devicetree source files from Linux kernel into `arch/<arch>/dts/<name>.dts`, which can be selected via: CONFIG_DEFAULT_DEVICE_TREE "<name>" SoC/board maintainers are encouraged to migrate to using mirrored copies from `devicetree-rebasing/` into `dts/arch/<arch>/<vendor>` via: CONFIG_OF_UPSTREAM=y CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>" An example have been shown for Amlogic meson-gxbb SoC and corresponding derived boards via patch #7 and #8. Devicetree bindings schema checks --------------------------------- With devicetee-rebasing Git subtree, the devicetree bindings are also regularly synced with Linux kernel as `devicetree-rebasing/Bindings/` sub-directory. This allows U-Boot to run devicetree bindings schema checks which will bring compliance to U-Boot core/drivers regarding usage of devicetree. Dependencies ------------ The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip: $ pip3 install dtschema Note that 'dtschema' installation requires 'swig' and Python development files installed first. On Debian/Ubuntu systems: $ apt install swig python3-dev Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be installed. Ensure they are in your PATH (~/.local/bin by default). Recommended is also to install yamllint (used by dtschema when present). Running checks -------------- In order to perform validation of DTB files, use the ``dtbs_check`` target: $ make dtbs_check It is also possible to run checks with a subset of matching schema files by setting the ``DT_SCHEMA_FILES`` variable to 1 or more specific schema files or patterns (partial match of a fixed string). Each file or pattern should be separated by ':'. $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml:rtc.yaml $ make dtbs_check DT_SCHEMA_FILES=/gpio/ $ make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml Sumit Garg (8): CI: Exclude devicetree-rebasing subtree for CONFIG checks Makefile: Add support for DT bindings schema checks scripts/Makefile.lib: Statically define *-u-boot.dtsi files location dts: Add alternative location for upstream DTB builds doc: devicetree: Updates for devicetree-rebasing subtree MAINTAINERS: Add myself as devicetree-rebasing maintainer dts: meson-gxbb: Switch to using upstream DT dts: meson-gxbb: Drop redundant devicetree files .azure-pipelines.yml | 3 +- .gitlab-ci.yml | 3 +- MAINTAINERS | 6 + Makefile | 20 +- arch/arm/dts/Makefile | 8 - arch/arm/dts/meson-gxbb-kii-pro.dts | 140 ---- arch/arm/dts/meson-gxbb-nanopi-k2.dts | 415 ------------ arch/arm/dts/meson-gxbb-odroidc2.dts | 418 ------------ arch/arm/dts/meson-gxbb-p200.dts | 100 --- arch/arm/dts/meson-gxbb-p201.dts | 26 - arch/arm/dts/meson-gxbb-p20x.dtsi | 250 ------- arch/arm/dts/meson-gxbb-wetek-hub.dts | 58 -- arch/arm/dts/meson-gxbb-wetek-play2.dts | 119 ---- arch/arm/dts/meson-gxbb-wetek.dtsi | 292 -------- arch/arm/dts/meson-gxbb.dtsi | 856 ------------------------ configs/nanopi-k2_defconfig | 3 +- configs/odroid-c2_defconfig | 3 +- configs/p200_defconfig | 3 +- configs/p201_defconfig | 3 +- configs/videostrong-kii-pro_defconfig | 3 +- configs/wetek-hub_defconfig | 3 +- configs/wetek-play2_defconfig | 3 +- doc/develop/devicetree/control.rst | 108 ++- dts/Kconfig | 11 + dts/Makefile | 17 +- dts/arch/arm64/Makefile | 23 + dts/arch/arm64/amlogic | 1 + scripts/Makefile.lib | 42 +- 28 files changed, 206 insertions(+), 2731 deletions(-) delete mode 100644 arch/arm/dts/meson-gxbb-kii-pro.dts delete mode 100644 arch/arm/dts/meson-gxbb-nanopi-k2.dts delete mode 100644 arch/arm/dts/meson-gxbb-odroidc2.dts delete mode 100644 arch/arm/dts/meson-gxbb-p200.dts delete mode 100644 arch/arm/dts/meson-gxbb-p201.dts delete mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi delete mode 100644 arch/arm/dts/meson-gxbb-wetek-hub.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek-play2.dts delete mode 100644 arch/arm/dts/meson-gxbb-wetek.dtsi delete mode 100644 arch/arm/dts/meson-gxbb.dtsi create mode 100644 dts/arch/arm64/Makefile create mode 120000 dts/arch/arm64/amlogic