
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