mbox series

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

Message ID 20231222061208.3009970-1-sumit.garg@linaro.org
Headers show
Series An effort to bring DT bindings compliance within U-Boot | expand

Message

Sumit Garg Dec. 22, 2023, 6:12 a.m. UTC
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

Comments

Krzysztof Kozlowski Dec. 22, 2023, 8:17 a.m. UTC | #1
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
Sumit Garg Dec. 22, 2023, 1:43 p.m. UTC | #2
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
>
Krzysztof Kozlowski Dec. 22, 2023, 3:38 p.m. UTC | #3
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
Conor Dooley Dec. 22, 2023, 3:45 p.m. UTC | #4
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/
Tom Rini Dec. 22, 2023, 3:46 p.m. UTC | #5
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.
Krzysztof Kozlowski Dec. 22, 2023, 3:53 p.m. UTC | #6
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
Krzysztof Kozlowski Dec. 22, 2023, 3:55 p.m. UTC | #7
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
Tom Rini Dec. 22, 2023, 4:03 p.m. UTC | #8
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?
Sumit Garg Dec. 26, 2023, 7:53 a.m. UTC | #9
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
Krzysztof Kozlowski Dec. 26, 2023, 9:16 a.m. UTC | #10
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
Sumit Garg Dec. 26, 2023, 9:36 a.m. UTC | #11
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