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

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

[Sumit Garg]

Prerquisite
-----------

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):
  Azure 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 +-
 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 +-
 27 files changed, 204 insertions(+), 2730 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

-- 
2.34.1

[PATCH 1/8] Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks

[Sumit Garg]

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 .azure-pipelines.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index d6f3fa423c6..f100c4493e6 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -65,7 +65,8 @@ stages:
       # have no matches.
       - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_'
                   :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
-                  :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
+                  :^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&
+                  exit 1 || exit 0
 
   - job: docs
     displayName: 'Build documentation'
-- 
2.34.1

[PATCH 2/8] Makefile: Add support for DT bindings schema checks

[Sumit Garg]

This adds the build infrastructure for checking DT binding schema
documents and validating dtb files using the binding schema. Here we use
devicetree-rebasing directory to provide the DT bindings.

Dependency:
-----------

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

Testing:
--------

Build dts files and check using DT binding schema:
$ make dtbs_check

Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
use for validation. This makes it easier to find and fix errors
generated by a specific schema.

Note, at this point dtbs_check is an optional build target as there are
many warnings generated due to custom DT properties used by many
platforms in u-boot. It is expected with these checks that compliance
with DT bindings to take place. Once that's done it can be added to CI
builds to remain compliant with DT bindings.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 Makefile             | 20 ++++++++++++++++++--
 scripts/Makefile.lib | 17 +++++++++++++++--
 2 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 750bbdb1b71..d8d168cd4c3 100644
--- a/Makefile
+++ b/Makefile
@@ -1158,12 +1158,28 @@ endif
 	@# disabling OF_BOARD.
 	$(call cmd,ofcheck,$(KCONFIG_CONFIG))
 
-PHONY += dtbs
+PHONY += dtbs dtbs_check
 dtbs: dts/dt.dtb
 	@:
-dts/dt.dtb: u-boot
+dts/dt.dtb: dtbs_prepare u-boot
 	$(Q)$(MAKE) $(build)=dts dtbs
 
+dtbs_prepare: prepare3
+
+ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),)
+export CHECK_DTBS=y
+endif
+
+ifneq ($(CHECK_DTBS),)
+dtbs_prepare: dt_binding_check
+endif
+
+dtbs_check: dt_binding_check dtbs
+
+DT_BINDING_DIR := devicetree-rebasing/Bindings
+dt_binding_check: scripts_dtc
+	$(Q)$(MAKE) $(build)=$(DT_BINDING_DIR) $(DT_BINDING_DIR)/processed-schema.json
+
 quiet_cmd_copy = COPY    $@
       cmd_copy = cp $< $@
 
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 16bbc277a9f..27b9437027c 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -356,8 +356,21 @@ endif
 
 dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list)))
 
-$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
-	$(call if_changed_dep,dtc)
+ifneq ($(CHECK_DTBS),)
+DT_CHECKER ?= dt-validate
+DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m)
+DT_BINDING_DIR := devicetree-rebasing/Bindings
+DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json
+
+quiet_cmd_dtb = DTC_CHK $@
+      cmd_dtb = $(cmd_dtc) ; $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u $(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true
+else
+quiet_cmd_dtb = $(quiet_cmd_dtc)
+      cmd_dtb = $(cmd_dtc)
+endif
+
+$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) $(DT_TMP_SCHEMA) FORCE
+	$(call if_changed_dep,dtb)
 
 pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
 dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
-- 
2.34.1

[PATCH 3/8] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location

[Sumit Garg]

Allow u-boot to build DTB from a different directory tree such that
*-u-boot.dtsi files can be included from a common location. Currently
that location is arch/$(ARCH)/dts/, so statically define that common
location.

This is needed for platform owners to start building DTB files from
devicetree-rebasing directory but still being able to include
*-u-boot.dtsi files.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 scripts/Makefile.lib | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 27b9437027c..4a002b0e0ca 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -159,18 +159,20 @@ cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE)     \
 ld_flags       = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
 
 # Try these files in order to find the U-Boot-specific .dtsi include file
-u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
-	$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
-	$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
-	$(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
-	$(wildcard $(dir $<)u-boot.dtsi))
+UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/
+
+u_boot_dtsi_options = $(strip $(wildcard $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi) \
+	$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
+	$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
+	$(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
+	$(wildcard $(UBOOT_DTSI_LOC)u-boot.dtsi))
 
 u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
-	$(dir $<)$(basename $(notdir $<))-u-boot.dtsi \
-	$(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
-	$(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
-	$(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
-	$(dir $<)u-boot.dtsi ... \
+	$(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi \
+	$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
+	$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
+	$(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
+	$(UBOOT_DTSI_LOC)u-boot.dtsi ... \
 	found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))
 
 # Uncomment for debugging
@@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
 dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc                    \
 		 $(UBOOTINCLUDE)                                         \
 		 -I$(dir $<)                                             \
+		 -I$(UBOOT_DTSI_LOC)                                     \
 		 -I$(srctree)/arch/$(ARCH)/dts/include                   \
 		 -I$(srctree)/include                                    \
 		 -D__ASSEMBLY__                                          \
@@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
 	  echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
 	$(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \
 	$(DTC) -O dtb -o $@ -b 0 \
-		-i $(dir $<) $(DTC_FLAGS) \
+		-i $(dir $<) -i $(UBOOT_DTSI_LOC) $(DTC_FLAGS) \
 		-d $(depfile).dtc.tmp $(dtc-tmp) || \
 		(echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \
 		; \
-- 
2.34.1

[PATCH 4/8] dts: Add alternative location for upstream DTB builds

[Sumit Garg]

Allow platform owners to mirror devicetree files from devitree-rebasing
directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
directory.

This will help easy migration for platforms which currently are compliant
with upstream Linux kernel devicetree files.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 dts/Kconfig             | 11 +++++++++++
 dts/Makefile            | 17 ++++++++++++++---
 dts/arch/arm64/Makefile | 14 ++++++++++++++
 3 files changed, 39 insertions(+), 3 deletions(-)
 create mode 100644 dts/arch/arm64/Makefile

diff --git a/dts/Kconfig b/dts/Kconfig
index 00c0aeff893..96396f12b67 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -85,6 +85,17 @@ config OF_LIVE
 	  enables a live tree which is available after relocation,
 	  and can be adjusted as needed.
 
+config OF_UPSTREAM
+	bool "Enable use of devicetree imported from Linux kernel release"
+	help
+	  Traditionally, U-boot platforms used to have their custom devicetree
+	  files or copy devicetree files from Linux kernel which are hard to
+	  maintain and can usually get out-of-sync from Linux kernel. This
+	  option enables platforms to migrate to devicetree-rebasing repo where
+	  a regular sync will be maintained every major Linux kernel release
+	  cycle. However, platforms can still have some custom u-boot specific
+	  bits maintained as part of *-u-boot.dtsi files.
+
 choice
 	prompt "Provider of DTB for DT control"
 	depends on OF_CONTROL
diff --git a/dts/Makefile b/dts/Makefile
index 3437e54033d..8098bf8191a 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
 DEVICE_TREE := unset
 endif
 
+ifeq ($(CONFIG_OF_UPSTREAM),y)
+ifeq ($(CONFIG_ARM64),y)
+DEVICE_TREE_LOC := dts/arch/arm64
+else
+DEVICE_TREE_LOC := dts/arch/$(ARCH)
+endif
+else
+DEVICE_TREE_LOC := arch/$(ARCH)/dts
+endif
+
 ifneq ($(EXT_DTB),)
 DTB := $(EXT_DTB)
 else
-DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb
+DTB := $(DEVICE_TREE_LOC)/$(DEVICE_TREE).dtb
 endif
 
 $(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE
@@ -41,7 +51,7 @@ $(DTB): arch-dtbs
 
 PHONY += arch-dtbs
 arch-dtbs:
-	$(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
+	$(Q)$(MAKE) $(build)=$(DEVICE_TREE_LOC) dtbs
 
 ifeq ($(CONFIG_SPL_BUILD),y)
 obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o
@@ -65,4 +75,5 @@ clean-files := dt.dtb.S
 # Let clean descend into dts directories
 subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts	\
 	   ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts	\
-	   ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
+	   ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts	\
+	   ./arch/arm64 ./arch/$(ARCH)
diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
new file mode 100644
index 00000000000..16e9fea622d
--- /dev/null
+++ b/dts/arch/arm64/Makefile
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+include $(srctree)/scripts/Makefile.dts
+
+targets += $(dtb-y)
+
+# Add any required device tree compiler flags here
+DTC_FLAGS += -a 0x8
+
+PHONY += dtbs
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+	@:
+
+clean-files := */*.dtb */*.dtbo */*_HS
-- 
2.34.1

[PATCH 5/8] doc: devicetree: Updates for devicetree-rebasing subtree

[Sumit Garg]

Encourage SoC/board maintainers to migrate to using devicetree-rebasing
subtree and maintain a regular sync with Linux kernel devicetree files
and bindings.

Along with that add documentation regarding how to run DT bindings
schema checks.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 doc/develop/devicetree/control.rst | 108 +++++++++++++++++++++++------
 1 file changed, 86 insertions(+), 22 deletions(-)

diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
index cbb65c9b177..12ef55ed368 100644
--- a/doc/develop/devicetree/control.rst
+++ b/doc/develop/devicetree/control.rst
@@ -1,5 +1,6 @@
 .. SPDX-License-Identifier: GPL-2.0+
 .. sectionauthor:: Copyright 2011 The Chromium OS Authors
+.. Copyright 2023 Linaro Ltd.
 
 Devicetree Control in U-Boot
 ============================
@@ -22,12 +23,11 @@ for three reasons:
   hierarchical format
 - It is fairly efficient to read incrementally
 
-The arch/<arch>/dts directories contains a Makefile for building the devicetree
-blob and embedding it in the U-Boot image. This is useful since it allows
-U-Boot to configure itself according to what it finds there. If you have
-a number of similar boards with different peripherals, you can describe
-the features of each board in the devicetree file, and have a single
-generic source base.
+The U-boot Makefile infrastructure allows for building the devicetree blob
+and embedding it in the U-Boot image. This is useful since it allows U-Boot
+to configure itself according to what it finds there. If you have a number
+of similar boards with different peripherals, you can describe the features
+of each board in the devicetree file, and have a single generic source base.
 
 To enable this feature, add CONFIG_OF_CONTROL to your board config file.
 
@@ -68,8 +68,21 @@ a binary file. U-Boot adds its own `fdtgrep` for creating subsets of the file.
 Where do I get a devicetree file for my board?
 ----------------------------------------------
 
-You may find that the Linux kernel has a suitable file. Look in the
-kernel source in arch/<arch>/boot/dts.
+Linux kernel Git repository has been the place where devicetree files along
+with devicetree bindings are stored and maintained. There is devicetee-rebasing
+(dtrepo_) which maintains a forked copy of devicetree files along with bindings
+at every Linux kernel major release or intermideate release candidates.
+
+In order to maintain devicetree files sync, U-boot maintains a Git subtree for
+devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly
+kept 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
+
+You may find that the `devicetee-rebasing/` sub-directory has a suitable
+devicetree file for your board. Look in `devicetree-rebasing/src/<arch>/`.
 
 If not you might find other boards with suitable files that you can
 modify to your needs. Look in the board directories for files with a
@@ -81,18 +94,21 @@ Failing that, you could write one from scratch yourself!
 Configuration
 -------------
 
-Use::
+Traditionally, U-boot placed copies of devicetree source files from Linux
+kernel into `arch/<arch>/dts/<name>.dts` which can be selected via::
 
-   #define CONFIG_DEFAULT_DEVICE_TREE	"<name>"
+    #define CONFIG_DEFAULT_DEVICE_TREE	"<name>"
 
-to set the filename of the devicetree source. Then put your devicetree
-file into::
+However, it has become combersome over time for each SoC/board maintainer to
+keep devicetree files in sync with Linux kernel. Thereby, SoC/board maintainers
+are encouraged to migrate to use mirrored copies from `devicetree-rebasing/`
+into `dts/arch/<arch>/<vendor>` via::
 
-   arch/<arch>/dts/<name>.dts
+    #define CONFIG_OF_UPSTREAM=y
+    #define CONFIG_DEFAULT_DEVICE_TREE	"<vendor>/<name>"
 
-This should include your CPU or SOC's devicetree file, placed in
-`arch/<arch>/dts`, and then make any adjustments required using a u-boot-dtsi
-file for your board.
+This should include your CPU or SOC's devicetree file. On top of that any U-boot
+specific tweaks (see: dttweaks_) can be made for your board.
 
 If CONFIG_OF_EMBED is defined, then it will be picked up and built into
 the U-Boot image (including u-boot.bin). This is suitable for debugging
@@ -156,8 +172,9 @@ ways:
 Adding tweaks for U-Boot
 ------------------------
 
-It is strongly recommended that devicetree files in U-Boot are an exact copy of
-those in Linux, so that it is easy to sync them up from time to time.
+With devicetee-rebasing Git subtree, it is ensured that devicetree files in
+U-Boot are an exact copy of those in Linux kernel via mirroring into
+`dts/arch/<arch>/<vendor>`.
 
 U-Boot is of course a very different project from Linux, e.g. it operates under
 much more restrictive memory and code-size constraints. Where Linux may use a
@@ -170,8 +187,8 @@ constraints are even more extreme and the devicetree is shrunk to remove
 unwanted nodes, or even turned into C code to avoid access overhead.
 
 U-Boot automatically looks for and includes a file with updates to the standard
-devicetree for your board, searching for them in the same directory as the
-main file, in this order::
+devicetree for your board, searching for them in `arch/<arch>/dts/` in this
+order::
 
    <orig_filename>-u-boot.dtsi
    <CONFIG_SYS_SOC>-u-boot.dtsi
@@ -200,6 +217,52 @@ to specify a list of .dtsi files that will also be included when
 building .dtb files.
 
 
+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
+
+
 Relocation, SPL and TPL
 -----------------------
 
@@ -261,8 +324,9 @@ used it before Linux (e.g. snow). The two projects developed in parallel
 and there are still some differences in the bindings for certain boards.
 While there has been discussion of having a separate repository for devicetree
 files, in practice the Linux kernel Git repository has become the place where
-these are stored, with U-Boot taking copies and adding tweaks with u-boot.dtsi
-files.
+these are stored, with U-Boot taking copies via devicetree-rebasing repo
+(see: dtrepo_) and adding tweaks with u-boot.dtsi files.
 
 .. _dtspec: https://www.devicetree.org/specifications/
 .. _dtlist: https://www.spinics.net/lists/devicetree-compiler/
+.. _dtrepo: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
-- 
2.34.1

[PATCH 6/8] MAINTAINERS: Add myself as devicetree-rebasing maintainer

[Sumit Garg]

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 969514468cb..253092c345c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -951,6 +951,12 @@ F:	cmd/cyclic.c
 F:	common/cyclic.c
 F:	include/cyclic.h
 
+DEVICETREE REBASING SUBTREE
+M:	Sumit Garg <sumit.garg@linaro.org>
+S:	Maintained
+F:	devicetree-rebasing/
+F:	dts/arch/
+
 DFU
 M:	Lukasz Majewski <lukma@denx.de>
 M:	Mattijs Korpershoek <mkorpershoek@baylibre.com>
-- 
2.34.1

[PATCH 7/8] dts: meson-gxbb: Switch to using upstream DT

[Sumit Garg]

Although there were still some variations in board DTS files based on
meson-gxbb SoC but I think those were minor differences from upstream
and shouldn't impact boot on these devices.

So switch to upstream DT via mirroring amlogic/ directory from
devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly
building DTB from there including *-u-boot.dtsi files from
arch/$(ARCH)/dts/ directory.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 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 ++-
 dts/arch/arm64/Makefile               | 9 +++++++++
 dts/arch/arm64/amlogic                | 1 +
 9 files changed, 24 insertions(+), 7 deletions(-)
 create mode 120000 dts/arch/arm64/amlogic

diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig
index 41dbf7981f8..3db296916e9 100644
--- a/configs/nanopi-k2_defconfig
+++ b/configs/nanopi-k2_defconfig
@@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
index 5f9f323e06e..65857ff478c 100644
--- a/configs/odroid-c2_defconfig
+++ b/configs/odroid-c2_defconfig
@@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/p200_defconfig b/configs/p200_defconfig
index cd579ef5f14..c1792db51fd 100644
--- a/configs/p200_defconfig
+++ b/configs/p200_defconfig
@@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200"
+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p200"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/p201_defconfig b/configs/p201_defconfig
index b2f0a0ccdb4..202e1da5bcc 100644
--- a/configs/p201_defconfig
+++ b/configs/p201_defconfig
@@ -7,7 +7,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p201"
+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p201"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig
index 3eda8f14a21..d09333d3b96 100644
--- a/configs/videostrong-kii-pro_defconfig
+++ b/configs/videostrong-kii-pro_defconfig
@@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro"
+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-kii-pro"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig
index fd92b041e73..73f3d4aad5d 100644
--- a/configs/wetek-hub_defconfig
+++ b/configs/wetek-hub_defconfig
@@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-hub"
+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-hub"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig
index b887419a6ba..26f57b4214a 100644
--- a/configs/wetek-play2_defconfig
+++ b/configs/wetek-play2_defconfig
@@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
 CONFIG_ENV_SIZE=0x2000
 CONFIG_DM_GPIO=y
-CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-play2"
+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2"
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_DEBUG_UART_BASE=0xc81004c0
diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
index 16e9fea622d..d548584cf5c 100644
--- a/dts/arch/arm64/Makefile
+++ b/dts/arch/arm64/Makefile
@@ -1,5 +1,14 @@
 # SPDX-License-Identifier: GPL-2.0+
 
+dtb-$(CONFIG_ARCH_MESON) += \
+	amlogic/meson-gxbb-kii-pro.dtb \
+	amlogic/meson-gxbb-nanopi-k2.dtb \
+	amlogic/meson-gxbb-odroidc2.dtb \
+	amlogic/meson-gxbb-p200.dtb \
+	amlogic/meson-gxbb-p201.dtb \
+	amlogic/meson-gxbb-wetek-hub.dtb \
+	amlogic/meson-gxbb-wetek-play2.dtb
+
 include $(srctree)/scripts/Makefile.dts
 
 targets += $(dtb-y)
diff --git a/dts/arch/arm64/amlogic b/dts/arch/arm64/amlogic
new file mode 120000
index 00000000000..73f7c3e7bd0
--- /dev/null
+++ b/dts/arch/arm64/amlogic
@@ -0,0 +1 @@
+../../../devicetree-rebasing/src/arm64/amlogic/
\ No newline at end of file
-- 
2.34.1

[PATCH 8/8] dts: meson-gxbb: Drop redundant devicetree files

[Sumit Garg]

Since meson-gxbb based boards switched to using upstream DT, so drop
redundant files from arch/arm/dts directory. Only *-u-boot.dtsi files
kept in arch/arm/dts directory for these boards.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 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 ------------------------
 11 files changed, 2682 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

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 5fc888680b3..45bd1166029 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -212,14 +212,6 @@ dtb-$(CONFIG_ARCH_MESON) += \
 	meson-a1-ad401.dtb \
 	meson-axg-s400.dtb \
 	meson-axg-jethome-jethub-j100.dtb \
-	meson-gxbb-kii-pro.dtb \
-	meson-gxbb-nanopi-k2.dtb \
-	meson-gxbb-odroidc2.dtb \
-	meson-gxbb-nanopi-k2.dtb \
-	meson-gxbb-p200.dtb \
-	meson-gxbb-p201.dtb \
-	meson-gxbb-wetek-hub.dtb \
-	meson-gxbb-wetek-play2.dtb \
 	meson-gxl-s805x-libretech-ac.dtb \
 	meson-gxl-s905d-libretech-pc.dtb \
 	meson-gxl-s905w-jethome-jethub-j80.dtb \
diff --git a/arch/arm/dts/meson-gxbb-kii-pro.dts b/arch/arm/dts/meson-gxbb-kii-pro.dts
deleted file mode 100644
index e238f1f1012..00000000000
--- a/arch/arm/dts/meson-gxbb-kii-pro.dts
+++ /dev/null
@@ -1,140 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2019 Mohammad Rasim <mohammad.rasim96@gmail.com>
- */
-
-/dts-v1/;
-
-#include "meson-gxbb-p20x.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/leds/common.h>
-#include <dt-bindings/sound/meson-aiu.h>
-
-/ {
-	compatible = "videostrong,kii-pro", "amlogic,meson-gxbb";
-	model = "Videostrong KII Pro";
-
-	spdif_dit: audio-codec-0 {
-		#sound-dai-cells = <0>;
-		compatible = "linux,spdif-dit";
-		status = "okay";
-		sound-name-prefix = "DIT";
-	};
-
-	leds {
-		compatible = "gpio-leds";
-		led {
-			gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
-			color = <LED_COLOR_ID_RED>;
-			function = LED_FUNCTION_STATUS;
-			default-state = "off";
-		};
-	};
-
-	gpio-keys-polled {
-		compatible = "gpio-keys-polled";
-		poll-interval = <20>;
-
-		button-reset {
-			label = "reset";
-			linux,code = <KEY_POWER>;
-			gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
-		};
-	};
-
-	sound {
-		compatible = "amlogic,gx-sound-card";
-		model = "KII-PRO";
-		assigned-clocks = <&clkc CLKID_MPLL0>,
-				  <&clkc CLKID_MPLL1>,
-				  <&clkc CLKID_MPLL2>;
-		assigned-clock-parents = <0>, <0>, <0>;
-		assigned-clock-rates = <294912000>,
-				       <270950400>,
-				       <393216000>;
-
-		dai-link-0 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
-		};
-
-		dai-link-1 {
-			sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>;
-		};
-
-		dai-link-2 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
-			dai-format = "i2s";
-			mclk-fs = <256>;
-
-			codec-0 {
-				sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
-			};
-		};
-
-		dai-link-3 {
-			sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>;
-
-			codec-0 {
-				sound-dai = <&spdif_dit>;
-			};
-		};
-
-		dai-link-4 {
-			sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
-
-			codec-0 {
-				sound-dai = <&hdmi_tx>;
-			};
-		};
-	};
-};
-
-&aiu {
-	status = "okay";
-	pinctrl-0 = <&spdif_out_y_pins>;
-	pinctrl-names = "default";
-};
-
-&ethmac {
-	status = "okay";
-	pinctrl-0 = <&eth_rmii_pins>;
-	pinctrl-names = "default";
-
-	phy-handle = <&eth_phy0>;
-	phy-mode = "rmii";
-
-	mdio {
-		compatible = "snps,dwmac-mdio";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		eth_phy0: ethernet-phy@0 {
-			/* IC Plus IP101GR (0x02430c54) */
-			reg = <0>;
-			reset-assert-us = <10000>;
-			reset-deassert-us = <10000>;
-			reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
-		};
-	};
-};
-
-&ir {
-	linux,rc-map-name = "rc-videostrong-kii-pro";
-};
-
-&uart_A {
-	status = "okay";
-	pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
-	pinctrl-names = "default";
-	uart-has-rtscts;
-
-	bluetooth {
-		compatible = "brcm,bcm4335a0";
-		shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>;
-		host-wakeup-gpios = <&gpio GPIOX_21 GPIO_ACTIVE_HIGH>;
-		max-speed = <2000000>;
-		clocks = <&wifi32k>;
-		clock-names = "lpo";
-	};
-};
diff --git a/arch/arm/dts/meson-gxbb-nanopi-k2.dts b/arch/arm/dts/meson-gxbb-nanopi-k2.dts
deleted file mode 100644
index 7273eed5292..00000000000
--- a/arch/arm/dts/meson-gxbb-nanopi-k2.dts
+++ /dev/null
@@ -1,415 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2017 Andreas Färber
- */
-
-/dts-v1/;
-
-#include "meson-gxbb.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/sound/meson-aiu.h>
-
-/ {
-	compatible = "friendlyarm,nanopi-k2", "amlogic,meson-gxbb";
-	model = "FriendlyARM NanoPi K2";
-
-	aliases {
-		serial0 = &uart_AO;
-		ethernet0 = &ethmac;
-	};
-
-	chosen {
-		stdout-path = "serial0:115200n8";
-	};
-
-	memory@0 {
-		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
-	};
-
-	leds {
-		compatible = "gpio-leds";
-
-		led-stat {
-			label = "nanopi-k2:blue:stat";
-			gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>;
-			default-state = "on";
-			panic-indicator;
-		};
-	};
-
-	vdd_5v: regulator-vdd-5v {
-		compatible = "regulator-fixed";
-		regulator-name = "VDD_5V";
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-	};
-
-	vddio_ao18: regulator-vddio-ao18 {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDIO_AO18";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-	};
-
-	vddio_ao3v3: regulator-vddio-ao3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDIO_AO3.3V";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-	};
-
-	vddio_tf: regulator-vddio-tf {
-		compatible = "regulator-gpio";
-
-		regulator-name = "VDDIO_TF";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
-		gpios-states = <0>;
-
-		states = <3300000 0>,
-		         <1800000 1>;
-
-		regulator-settling-time-up-us = <100>;
-		regulator-settling-time-down-us = <5000>;
-	};
-
-	wifi_32k: wifi-32k {
-		compatible = "pwm-clock";
-		#clock-cells = <0>;
-		clock-frequency = <32768>;
-		pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
-	};
-
-	sdio_pwrseq: sdio-pwrseq {
-		compatible = "mmc-pwrseq-simple";
-		reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
-		clocks = <&wifi_32k>;
-		clock-names = "ext_clock";
-	};
-
-	vcc1v8: regulator-vcc1v8 {
-		compatible = "regulator-fixed";
-		regulator-name = "VCC1.8V";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-	};
-
-	vcc3v3: regulator-vcc3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "VCC3.3V";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-	};
-
-	emmc_pwrseq: emmc-pwrseq {
-		compatible = "mmc-pwrseq-emmc";
-		reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
-	};
-
-	/* CVBS is available on CON1 pin 36, disabled by default */
-	cvbs-connector {
-		compatible = "composite-video-connector";
-		status = "disabled";
-
-		port {
-			cvbs_connector_in: endpoint {
-				remote-endpoint = <&cvbs_vdac_out>;
-			};
-		};
-	};
-
-	hdmi-connector {
-		compatible = "hdmi-connector";
-		type = "a";
-
-		port {
-			hdmi_connector_in: endpoint {
-				remote-endpoint = <&hdmi_tx_tmds_out>;
-			};
-		};
-	};
-
-	sound {
-		compatible = "amlogic,gx-sound-card";
-		model = "NANOPI-K2";
-		assigned-clocks = <&clkc CLKID_MPLL0>,
-				  <&clkc CLKID_MPLL1>,
-				  <&clkc CLKID_MPLL2>;
-		assigned-clock-parents = <0>, <0>, <0>;
-		assigned-clock-rates = <294912000>,
-				       <270950400>,
-				       <393216000>;
-		status = "okay";
-
-		dai-link-0 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
-		};
-
-		dai-link-1 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
-			dai-format = "i2s";
-			mclk-fs = <256>;
-
-			codec-0 {
-				sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
-			};
-		};
-
-		dai-link-2 {
-			sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
-
-			codec-0 {
-				sound-dai = <&hdmi_tx>;
-			};
-		};
-	};
-};
-
-&aiu {
-	status = "okay";
-};
-
-&cec_AO {
-	status = "okay";
-	pinctrl-0 = <&ao_cec_pins>;
-	pinctrl-names = "default";
-	hdmi-phandle = <&hdmi_tx>;
-};
-
-&cvbs_vdac_port {
-	cvbs_vdac_out: endpoint {
-		remote-endpoint = <&cvbs_connector_in>;
-	};
-};
-
-&ethmac {
-	status = "okay";
-	pinctrl-0 = <&eth_rgmii_pins>;
-	pinctrl-names = "default";
-
-	phy-handle = <&eth_phy0>;
-	phy-mode = "rgmii";
-
-	amlogic,tx-delay-ns = <2>;
-
-	mdio {
-		compatible = "snps,dwmac-mdio";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		eth_phy0: ethernet-phy@0 {
-			/* Realtek RTL8211F (0x001cc916) */
-			reg = <0>;
-
-			reset-assert-us = <10000>;
-			reset-deassert-us = <80000>;
-			reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
-
-			interrupt-parent = <&gpio_intc>;
-			/* MAC_INTR on GPIOZ_15 */
-			interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
-		};
-	};
-};
-
-&hdmi_tx {
-	status = "okay";
-	pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
-	pinctrl-names = "default";
-};
-
-&hdmi_tx_tmds_port {
-	hdmi_tx_tmds_out: endpoint {
-		remote-endpoint = <&hdmi_connector_in>;
-	};
-};
-
-&ir {
-	status = "okay";
-	pinctrl-0 = <&remote_input_ao_pins>;
-	pinctrl-names = "default";
-};
-
-&gpio_ao {
-	gpio-line-names = "UART TX", "UART RX", "Power Control", "Power Key In",
-			  "VCCK En", "CON1 Header Pin31",
-			  "I2S Header Pin6", "IR In", "I2S Header Pin7",
-			  "I2S Header Pin3", "I2S Header Pin4",
-			  "I2S Header Pin5", "HDMI CEC", "SYS LED",
-			  /* GPIO_TEST_N */
-			  "";
-};
-
-&gpio {
-	gpio-line-names = /* Bank GPIOZ */
-			  "Eth MDIO", "Eth MDC", "Eth RGMII RX Clk",
-			  "Eth RX DV", "Eth RX D0", "Eth RX D1", "Eth RX D2",
-			  "Eth RX D3", "Eth RGMII TX Clk", "Eth TX En",
-			  "Eth TX D0", "Eth TX D1", "Eth TX D2", "Eth TX D3",
-			  "Eth PHY nRESET", "Eth PHY Intc",
-			  /* Bank GPIOH */
-			  "HDMI HPD", "HDMI DDC SDA", "HDMI DDC SCL",
-			  "CON1 Header Pin33",
-			  /* Bank BOOT */
-			  "eMMC D0", "eMMC D1", "eMMC D2", "eMMC D3", "eMMC D4",
-			  "eMMC D5", "eMMC D6", "eMMC D7", "eMMC Clk",
-			  "eMMC Reset", "eMMC CMD",
-			  "", "", "", "", "eMMC DS",
-			  "", "",
-			  /* Bank CARD */
-			  "SDCard D1", "SDCard D0", "SDCard CLK", "SDCard CMD",
-			  "SDCard D3", "SDCard D2", "SDCard Det",
-			  /* Bank GPIODV */
-			  "", "", "", "", "", "", "", "", "", "", "", "", "",
-			  "", "", "", "", "", "", "", "", "", "", "",
-			  "I2C A SDA", "I2C A SCK", "I2C B SDA", "I2C B SCK",
-			  "VDDEE Regulator", "VCCK Regulator",
-			  /* Bank GPIOY */
-			  "CON1 Header Pin7", "CON1 Header Pin11",
-			  "CON1 Header Pin13", "CON1 Header Pin15",
-			  "CON1 Header Pin18", "CON1 Header Pin19",
-			  "CON1 Header Pin22", "CON1 Header Pin21",
-			  "CON1 Header Pin24", "CON1 Header Pin23",
-			  "CON1 Header Pin26", "CON1 Header Pin29",
-			  "CON1 Header Pin32", "CON1 Header Pin8",
-			  "CON1 Header Pin10", "CON1 Header Pin16",
-			  "CON1 Header Pin12",
-			  /* Bank GPIOX */
-			  "WIFI SDIO D0", "WIFI SDIO D1", "WIFI SDIO D2",
-			  "WIFI SDIO D3", "WIFI SDIO CLK", "WIFI SDIO CMD",
-			  "WIFI Power Enable", "WIFI WAKE HOST",
-			  "Bluetooth PCM DOUT", "Bluetooth PCM DIN",
-			  "Bluetooth PCM SYNC", "Bluetooth PCM CLK",
-			  "Bluetooth UART TX", "Bluetooth UART RX",
-			  "Bluetooth UART CTS", "Bluetooth UART RTS",
-			  "", "", "", "WIFI 32K", "Bluetooth Enable",
-			  "Bluetooth WAKE HOST", "",
-			  /* Bank GPIOCLK */
-			  "", "CON1 Header Pin35", "", "";
-};
-
-&pwm_ef {
-	status = "okay";
-	pinctrl-0 = <&pwm_e_pins>;
-	pinctrl-names = "default";
-	clocks = <&clkc CLKID_FCLK_DIV4>;
-	clock-names = "clkin0";
-};
-
-&saradc {
-	status = "okay";
-	vref-supply = <&vddio_ao18>;
-};
-
-/* SDIO */
-&sd_emmc_a {
-	status = "okay";
-	pinctrl-0 = <&sdio_pins>, <&sdio_irq_pins>;
-	pinctrl-1 = <&sdio_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-	#address-cells = <1>;
-	#size-cells = <0>;
-
-	bus-width = <4>;
-	cap-sd-highspeed;
-	max-frequency = <50000000>;
-
-	non-removable;
-	disable-wp;
-
-	/* WiFi firmware requires power to be kept while in suspend */
-	keep-power-in-suspend;
-
-	mmc-pwrseq = <&sdio_pwrseq>;
-
-	vmmc-supply = <&vddio_ao3v3>;
-	vqmmc-supply = <&vddio_ao18>;
-
-	brcmf: wifi@1 {
-		compatible = "brcm,bcm4329-fmac";
-		reg = <1>;
-	};
-};
-
-/* SD */
-&sd_emmc_b {
-	status = "okay";
-	pinctrl-0 = <&sdcard_pins>;
-	pinctrl-1 = <&sdcard_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-
-	bus-width = <4>;
-	cap-sd-highspeed;
-	sd-uhs-sdr12;
-	sd-uhs-sdr25;
-	sd-uhs-sdr50;
-	sd-uhs-ddr50;
-	max-frequency = <100000000>;
-	disable-wp;
-
-	cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>;
-
-	vmmc-supply = <&vddio_ao3v3>;
-	vqmmc-supply = <&vddio_tf>;
-};
-
-/* eMMC */
-&sd_emmc_c {
-	status = "disabled";
-	pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
-	pinctrl-1 = <&emmc_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-
-	bus-width = <8>;
-	max-frequency = <200000000>;
-	non-removable;
-	disable-wp;
-	cap-mmc-highspeed;
-	mmc-ddr-1_8v;
-	mmc-hs200-1_8v;
-
-	mmc-pwrseq = <&emmc_pwrseq>;
-	vmmc-supply = <&vcc3v3>;
-	vqmmc-supply = <&vcc1v8>;
-};
-
-/* DBG_UART */
-&uart_AO {
-	status = "okay";
-	pinctrl-0 = <&uart_ao_a_pins>;
-	pinctrl-names = "default";
-};
-
-/* Bluetooth on AP6212 */
-&uart_A {
-	status = "disabled";
-	pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
-	pinctrl-names = "default";
-};
-
-/* 40-pin CON1 */
-&uart_C {
-	status = "disabled";
-	pinctrl-0 = <&uart_c_pins>;
-	pinctrl-names = "default";
-};
-
-&usb0_phy {
-	status = "okay";
-	phy-supply = <&vdd_5v>;
-};
-
-&usb1_phy {
-	status = "okay";
-};
-
-&usb0 {
-	status = "okay";
-};
-
-&usb1 {
-	status = "okay";
-};
diff --git a/arch/arm/dts/meson-gxbb-odroidc2.dts b/arch/arm/dts/meson-gxbb-odroidc2.dts
deleted file mode 100644
index 201596247fd..00000000000
--- a/arch/arm/dts/meson-gxbb-odroidc2.dts
+++ /dev/null
@@ -1,418 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2016 Andreas Färber
- * Copyright (c) 2016 BayLibre, Inc.
- * Author: Kevin Hilman <khilman@kernel.org>
- */
-
-/dts-v1/;
-
-#include "meson-gxbb.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/sound/meson-aiu.h>
-
-/ {
-	compatible = "hardkernel,odroid-c2", "amlogic,meson-gxbb";
-	model = "Hardkernel ODROID-C2";
-
-	aliases {
-		serial0 = &uart_AO;
-		ethernet0 = &ethmac;
-	};
-
-	chosen {
-		stdout-path = "serial0:115200n8";
-	};
-
-	memory@0 {
-		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x80000000>;
-	};
-
-	usb_otg_pwr: regulator-usb-pwrs {
-		compatible = "regulator-fixed";
-
-		regulator-name = "USB_OTG_PWR";
-
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-
-		/*
-		 * signal name from schematics: PWREN
-		 */
-		gpio = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-		/*
-		 * signal name from schematics: USB_POWER
-		 */
-		vin-supply = <&p5v0>;
-	};
-
-	leds {
-		compatible = "gpio-leds";
-		led-blue {
-			label = "c2:blue:alive";
-			gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_LOW>;
-			linux,default-trigger = "heartbeat";
-			default-state = "off";
-		};
-	};
-
-	p5v0: regulator-p5v0 {
-		compatible = "regulator-fixed";
-
-		regulator-name = "P5V0";
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		regulator-always-on;
-	};
-
-	hdmi_p5v0: regulator-hdmi_p5v0 {
-		compatible = "regulator-fixed";
-		regulator-name = "HDMI_P5V0";
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-		/* AP2331SA-7 */
-		vin-supply = <&p5v0>;
-	};
-
-	tflash_vdd: regulator-tflash_vdd {
-		compatible = "regulator-fixed";
-
-		regulator-name = "TFLASH_VDD";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-
-		/*
-		 * signal name from schematics: TFLASH_VDD_EN
-		 */
-		gpio = <&gpio GPIOY_12 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-		/* U16 RT9179GB */
-		vin-supply = <&vddio_ao3v3>;
-	};
-
-	tf_io: gpio-regulator-tf_io {
-		compatible = "regulator-gpio";
-
-		regulator-name = "TF_IO";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <3300000>;
-
-		/*
-		 * signal name from schematics: TF_3V3N_1V8_EN
-		 */
-		gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
-		gpios-states = <0>;
-
-		states = <3300000 0>,
-			 <1800000 1>;
-		/* U12/U13 RT9179GB */
-		vin-supply = <&vddio_ao3v3>;
-	};
-
-	vcc1v8: regulator-vcc1v8 {
-		compatible = "regulator-fixed";
-		regulator-name = "VCC1V8";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-		regulator-always-on;
-		/* U18 RT9179GB */
-		vin-supply = <&vddio_ao3v3>;
-	};
-
-	vcc3v3: regulator-vcc3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "VCC3V3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-	};
-
-	vddio_ao1v8: regulator-vddio-ao1v8 {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDIO_AO1V8";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-		regulator-always-on;
-		/* U17 RT9179GB */
-		vin-supply = <&p5v0>;
-	};
-
-	vddio_ao3v3: regulator-vddio-ao3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDIO_AO3V3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-		regulator-always-on;
-		/* U11 MP2161GJ-C499 */
-		vin-supply = <&p5v0>;
-	};
-
-	ddr3_1v5: regulator-ddr3_1v5 {
-		compatible = "regulator-fixed";
-		regulator-name = "DDR3_1V5";
-		regulator-min-microvolt = <1500000>;
-		regulator-max-microvolt = <1500000>;
-		regulator-always-on;
-		/* U15 MP2161GJ-C499 */
-		vin-supply = <&p5v0>;
-	};
-
-	emmc_pwrseq: emmc-pwrseq {
-		compatible = "mmc-pwrseq-emmc";
-		reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
-	};
-
-	hdmi-connector {
-		compatible = "hdmi-connector";
-		type = "a";
-
-		port {
-			hdmi_connector_in: endpoint {
-				remote-endpoint = <&hdmi_tx_tmds_out>;
-			};
-		};
-	};
-
-	sound {
-		compatible = "amlogic,gx-sound-card";
-		model = "ODROID-C2";
-		assigned-clocks = <&clkc CLKID_MPLL0>,
-				  <&clkc CLKID_MPLL1>,
-				  <&clkc CLKID_MPLL2>;
-		assigned-clock-parents = <0>, <0>, <0>;
-		assigned-clock-rates = <294912000>,
-				       <270950400>,
-				       <393216000>;
-		status = "okay";
-
-		dai-link-0 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
-		};
-
-		dai-link-1 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
-			dai-format = "i2s";
-			mclk-fs = <256>;
-
-			codec-0 {
-				sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
-			};
-		};
-
-		dai-link-2 {
-			sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
-
-			codec-0 {
-				sound-dai = <&hdmi_tx>;
-			};
-		};
-	};
-};
-
-&aiu {
-	status = "okay";
-};
-
-&cec_AO {
-	status = "okay";
-	pinctrl-0 = <&ao_cec_pins>;
-	pinctrl-names = "default";
-	hdmi-phandle = <&hdmi_tx>;
-};
-
-&ethmac {
-	status = "okay";
-	pinctrl-0 = <&eth_rgmii_pins>;
-	pinctrl-names = "default";
-	phy-handle = <&eth_phy0>;
-	phy-mode = "rgmii";
-
-	amlogic,tx-delay-ns = <2>;
-
-	mdio {
-		compatible = "snps,dwmac-mdio";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		eth_phy0: ethernet-phy@0 {
-			/* Realtek RTL8211F (0x001cc916) */
-			reg = <0>;
-
-			reset-assert-us = <10000>;
-			reset-deassert-us = <80000>;
-			reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
-
-			interrupt-parent = <&gpio_intc>;
-			/* MAC_INTR on GPIOZ_15 */
-			interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
-		};
-	};
-};
-
-&gpio_ao {
-	/*
-	 * WARNING: The USB Hub on the Odroid-C2 needs a reset signal
-	 * to be turned high in order to be detected by the USB Controller
-	 * This signal should be handled by a USB specific power sequence
-	 * in order to reset the Hub when USB bus is powered down.
-	 */
-	hog-0 {
-		gpio-hog;
-		gpios = <GPIOAO_4 GPIO_ACTIVE_HIGH>;
-		output-high;
-		line-name = "usb-hub-reset";
-	};
-};
-
-&hdmi_tx {
-	status = "okay";
-	pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
-	pinctrl-names = "default";
-	hdmi-supply = <&hdmi_p5v0>;
-};
-
-&hdmi_tx_tmds_port {
-	hdmi_tx_tmds_out: endpoint {
-		remote-endpoint = <&hdmi_connector_in>;
-	};
-};
-
-&i2c_A {
-	status = "okay";
-	pinctrl-0 = <&i2c_a_pins>;
-	pinctrl-names = "default";
-};
-
-&ir {
-	status = "okay";
-	pinctrl-0 = <&remote_input_ao_pins>;
-	pinctrl-names = "default";
-	linux,rc-map-name = "rc-odroid";
-};
-
-&gpio_ao {
-	gpio-line-names = "UART TX", "UART RX", "VCCK En", "TF 3V3/1V8 En",
-			  "USB HUB nRESET", "USB OTG Power En",
-			  "J7 Header Pin2", "IR In", "J7 Header Pin4",
-			  "J7 Header Pin6", "J7 Header Pin5", "J7 Header Pin7",
-			  "HDMI CEC", "SYS LED",
-			  /* GPIO_TEST_N */
-			  "";
-};
-
-&gpio {
-	gpio-line-names = /* Bank GPIOZ */
-			  "Eth MDIO", "Eth MDC", "Eth RGMII RX Clk",
-			  "Eth RX DV", "Eth RX D0", "Eth RX D1", "Eth RX D2",
-			  "Eth RX D3", "Eth RGMII TX Clk", "Eth TX En",
-			  "Eth TX D0", "Eth TX D1", "Eth TX D2", "Eth TX D3",
-			  "Eth PHY nRESET", "Eth PHY Intc",
-			  /* Bank GPIOH */
-			  "HDMI HPD", "HDMI DDC SDA", "HDMI DDC SCL", "",
-			  /* Bank BOOT */
-			  "eMMC D0", "eMMC D1", "eMMC D2", "eMMC D3", "eMMC D4",
-			  "eMMC D5", "eMMC D6", "eMMC D7", "eMMC Clk",
-			  "eMMC Reset", "eMMC CMD",
-			  "", "", "", "", "", "", "",
-			  /* Bank CARD */
-			  "SDCard D1", "SDCard D0", "SDCard CLK", "SDCard CMD",
-			  "SDCard D3", "SDCard D2", "SDCard Det",
-			  /* Bank GPIODV */
-			  "", "", "", "", "", "", "", "", "", "", "", "", "",
-			  "", "", "", "", "", "", "", "", "", "", "",
-			  "I2C A SDA", "I2C A SCK", "I2C B SDA", "I2C B SCK",
-			  "PWM D", "PWM B",
-			  /* Bank GPIOY */
-			  "Revision Bit0", "Revision Bit1", "",
-			  "J2 Header Pin35", "", "", "", "J2 Header Pin36",
-			  "J2 Header Pin31", "", "", "", "TF VDD En",
-			  "J2 Header Pin32", "J2 Header Pin26", "", "",
-			  /* Bank GPIOX */
-			  "J2 Header Pin29", "J2 Header Pin24",
-			  "J2 Header Pin23", "J2 Header Pin22",
-			  "J2 Header Pin21", "J2 Header Pin18",
-			  "J2 Header Pin33", "J2 Header Pin19",
-			  "J2 Header Pin16", "J2 Header Pin15",
-			  "J2 Header Pin12", "J2 Header Pin13",
-			  "J2 Header Pin8", "J2 Header Pin10",
-			  "", "", "", "", "",
-			  "J2 Header Pin11", "", "J2 Header Pin7", "",
-			  /* Bank GPIOCLK */
-			  "", "", "", "";
-};
-
-&saradc {
-	status = "okay";
-	vref-supply = <&vcc1v8>;
-};
-
-&scpi_clocks {
-	status = "disabled";
-};
-
-/* SD */
-&sd_emmc_b {
-	status = "okay";
-	pinctrl-0 = <&sdcard_pins>;
-	pinctrl-1 = <&sdcard_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-
-	bus-width = <4>;
-	cap-sd-highspeed;
-	sd-uhs-sdr12;
-	sd-uhs-sdr25;
-	sd-uhs-sdr50;
-	sd-uhs-ddr50;
-	max-frequency = <100000000>;
-	disable-wp;
-
-	cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>;
-
-	vmmc-supply = <&tflash_vdd>;
-	vqmmc-supply = <&tf_io>;
-};
-
-/* eMMC */
-&sd_emmc_c {
-	status = "okay";
-	pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
-	pinctrl-1 = <&emmc_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-
-	bus-width = <8>;
-	max-frequency = <200000000>;
-	non-removable;
-	disable-wp;
-	cap-mmc-highspeed;
-	mmc-ddr-1_8v;
-	mmc-hs200-1_8v;
-
-	mmc-pwrseq = <&emmc_pwrseq>;
-	vmmc-supply = <&vcc3v3>;
-	vqmmc-supply = <&vcc1v8>;
-};
-
-&uart_AO {
-	status = "okay";
-	pinctrl-0 = <&uart_ao_a_pins>;
-	pinctrl-names = "default";
-};
-
-&usb0_phy {
-	status = "disabled";
-	phy-supply = <&usb_otg_pwr>;
-};
-
-&usb1_phy {
-	status = "okay";
-	phy-supply = <&usb_otg_pwr>;
-};
-
-&usb0 {
-	status = "disabled";
-};
-
-&usb1 {
-	status = "okay";
-};
diff --git a/arch/arm/dts/meson-gxbb-p200.dts b/arch/arm/dts/meson-gxbb-p200.dts
deleted file mode 100644
index 3c93d1898b4..00000000000
--- a/arch/arm/dts/meson-gxbb-p200.dts
+++ /dev/null
@@ -1,100 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2016 Andreas Färber
- * Copyright (c) 2016 BayLibre, Inc.
- * Author: Kevin Hilman <khilman@kernel.org>
- */
-
-/dts-v1/;
-
-#include "meson-gxbb-p20x.dtsi"
-#include <dt-bindings/input/input.h>
-
-/ {
-	compatible = "amlogic,p200", "amlogic,meson-gxbb";
-	model = "Amlogic Meson GXBB P200 Development Board";
-
-	avdd18_usb_adc: regulator-avdd18_usb_adc {
-		compatible = "regulator-fixed";
-		regulator-name = "AVDD18_USB_ADC";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-	};
-
-	adc_keys {
-		compatible = "adc-keys";
-		io-channels = <&saradc 0>;
-		io-channel-names = "buttons";
-		keyup-threshold-microvolt = <1800000>;
-
-		button-home {
-			label = "Home";
-			linux,code = <KEY_HOME>;
-			press-threshold-microvolt = <900000>; /* 50% */
-		};
-
-		button-esc {
-			label = "Esc";
-			linux,code = <KEY_ESC>;
-			press-threshold-microvolt = <684000>; /* 38% */
-		};
-
-		button-up {
-			label = "Volume Up";
-			linux,code = <KEY_VOLUMEUP>;
-			press-threshold-microvolt = <468000>; /* 26% */
-		};
-
-		button-down {
-			label = "Volume Down";
-			linux,code = <KEY_VOLUMEDOWN>;
-			press-threshold-microvolt = <252000>; /* 14% */
-		};
-
-		button-menu {
-			label = "Menu";
-			linux,code = <KEY_MENU>;
-			press-threshold-microvolt = <0>; /* 0% */
-		};
-	};
-};
-
-&ethmac {
-	status = "okay";
-	pinctrl-0 = <&eth_rgmii_pins>;
-	pinctrl-names = "default";
-	phy-handle = <&eth_phy0>;
-	phy-mode = "rgmii";
-
-	amlogic,tx-delay-ns = <2>;
-
-	mdio {
-		compatible = "snps,dwmac-mdio";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		eth_phy0: ethernet-phy@3 {
-			/* Micrel KSZ9031 (0x00221620) */
-			reg = <3>;
-
-			reset-assert-us = <10000>;
-			reset-deassert-us = <30000>;
-			reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
-
-			interrupt-parent = <&gpio_intc>;
-			/* MAC_INTR on GPIOZ_15 */
-			interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
-		};
-	};
-};
-
-&i2c_B {
-	status = "okay";
-	pinctrl-0 = <&i2c_b_pins>;
-	pinctrl-names = "default";
-};
-
-&saradc {
-	status = "okay";
-	vref-supply = <&avdd18_usb_adc>;
-};
diff --git a/arch/arm/dts/meson-gxbb-p201.dts b/arch/arm/dts/meson-gxbb-p201.dts
deleted file mode 100644
index 150a82f3b2d..00000000000
--- a/arch/arm/dts/meson-gxbb-p201.dts
+++ /dev/null
@@ -1,26 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2016 Andreas Färber
- * Copyright (c) 2016 BayLibre, Inc.
- * Author: Kevin Hilman <khilman@kernel.org>
- */
-
-/dts-v1/;
-
-#include "meson-gxbb-p20x.dtsi"
-
-/ {
-	compatible = "amlogic,p201", "amlogic,meson-gxbb";
-	model = "Amlogic Meson GXBB P201 Development Board";
-};
-
-&ethmac {
-	status = "okay";
-	pinctrl-0 = <&eth_rmii_pins>;
-	pinctrl-names = "default";
-	phy-mode = "rmii";
-
-	snps,reset-gpio = <&gpio GPIOZ_14 0>;
-	snps,reset-delays-us = <0>, <10000>, <1000000>;
-	snps,reset-active-low;
-};
diff --git a/arch/arm/dts/meson-gxbb-p20x.dtsi b/arch/arm/dts/meson-gxbb-p20x.dtsi
deleted file mode 100644
index e803a466fe4..00000000000
--- a/arch/arm/dts/meson-gxbb-p20x.dtsi
+++ /dev/null
@@ -1,250 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2016 Andreas Färber
- * Copyright (c) 2016 BayLibre, Inc.
- * Author: Kevin Hilman <khilman@kernel.org>
- */
-
-#include "meson-gxbb.dtsi"
-
-/ {
-	aliases {
-		serial0 = &uart_AO;
-		ethernet0 = &ethmac;
-	};
-
-	chosen {
-		stdout-path = "serial0:115200n8";
-	};
-
-	memory@0 {
-		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x40000000>;
-	};
-
-	usb_pwr: regulator-usb-pwrs {
-		compatible = "regulator-fixed";
-
-		regulator-name = "USB_PWR";
-
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-
-		/* signal name in schematic: USB_PWR_EN */
-		gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-	};
-
-	vddio_card: gpio-regulator {
-		compatible = "regulator-gpio";
-
-		regulator-name = "VDDIO_CARD";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <3300000>;
-
-		gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
-		gpios-states = <1>;
-
-		/* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
-		states = <1800000 0>,
-			 <3300000 1>;
-
-		regulator-settling-time-up-us = <10000>;
-		regulator-settling-time-down-us = <150000>;
-	};
-
-	vddio_boot: regulator-vddio_boot {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDIO_BOOT";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-	};
-
-	vddao_3v3: regulator-vddao_3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDAO_3V3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-	};
-
-	vcc_3v3: regulator-vcc_3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "VCC_3V3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-	};
-
-	emmc_pwrseq: emmc-pwrseq {
-		compatible = "mmc-pwrseq-emmc";
-		reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
-	};
-
-	wifi32k: wifi32k {
-		compatible = "pwm-clock";
-		#clock-cells = <0>;
-		clock-frequency = <32768>;
-		pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
-	};
-
-	sdio_pwrseq: sdio-pwrseq {
-		compatible = "mmc-pwrseq-simple";
-		reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
-		clocks = <&wifi32k>;
-		clock-names = "ext_clock";
-	};
-
-	cvbs_connector: cvbs-connector {
-		compatible = "composite-video-connector";
-
-		port {
-			cvbs_connector_in: endpoint {
-				remote-endpoint = <&cvbs_vdac_out>;
-			};
-		};
-	};
-
-	hdmi-connector {
-		compatible = "hdmi-connector";
-		type = "a";
-
-		port {
-			hdmi_connector_in: endpoint {
-				remote-endpoint = <&hdmi_tx_tmds_out>;
-			};
-		};
-	};
-};
-
-&cec_AO {
-	status = "okay";
-	pinctrl-0 = <&ao_cec_pins>;
-	pinctrl-names = "default";
-	hdmi-phandle = <&hdmi_tx>;
-};
-
-&cvbs_vdac_port {
-	cvbs_vdac_out: endpoint {
-		remote-endpoint = <&cvbs_connector_in>;
-	};
-};
-
-&hdmi_tx {
-	status = "okay";
-	pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
-	pinctrl-names = "default";
-};
-
-&hdmi_tx_tmds_port {
-	hdmi_tx_tmds_out: endpoint {
-		remote-endpoint = <&hdmi_connector_in>;
-	};
-};
-
-&ir {
-	status = "okay";
-	pinctrl-0 = <&remote_input_ao_pins>;
-	pinctrl-names = "default";
-};
-
-&pwm_ef {
-	status = "okay";
-	pinctrl-0 = <&pwm_e_pins>;
-	pinctrl-names = "default";
-	clocks = <&clkc CLKID_FCLK_DIV4>;
-	clock-names = "clkin0";
-};
-
-/* Wireless SDIO Module */
-&sd_emmc_a {
-	status = "okay";
-	pinctrl-0 = <&sdio_pins>;
-	pinctrl-1 = <&sdio_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-	#address-cells = <1>;
-	#size-cells = <0>;
-
-	bus-width = <4>;
-	cap-sd-highspeed;
-	max-frequency = <50000000>;
-
-	non-removable;
-	disable-wp;
-
-	/* WiFi firmware requires power to be kept while in suspend */
-	keep-power-in-suspend;
-
-	mmc-pwrseq = <&sdio_pwrseq>;
-
-	vmmc-supply = <&vddao_3v3>;
-	vqmmc-supply = <&vddio_boot>;
-
-	brcmf: wifi@1 {
-		reg = <1>;
-		compatible = "brcm,bcm4329-fmac";
-	};
-};
-
-/* SD card */
-&sd_emmc_b {
-	status = "okay";
-	pinctrl-0 = <&sdcard_pins>;
-	pinctrl-1 = <&sdcard_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-
-	bus-width = <4>;
-	cap-sd-highspeed;
-	sd-uhs-sdr12;
-	sd-uhs-sdr25;
-	sd-uhs-sdr50;
-	max-frequency = <100000000>;
-	disable-wp;
-
-	cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>;
-
-	vmmc-supply = <&vddao_3v3>;
-	vqmmc-supply = <&vddio_card>;
-};
-
-/* eMMC */
-&sd_emmc_c {
-	status = "okay";
-	pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
-	pinctrl-1 = <&emmc_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-
-	bus-width = <8>;
-	cap-mmc-highspeed;
-	max-frequency = <200000000>;
-	non-removable;
-	disable-wp;
-	mmc-ddr-1_8v;
-	mmc-hs200-1_8v;
-
-	mmc-pwrseq = <&emmc_pwrseq>;
-	vmmc-supply = <&vcc_3v3>;
-	vqmmc-supply = <&vddio_boot>;
-};
-
-/* This UART is brought out to the DB9 connector */
-&uart_AO {
-	status = "okay";
-	pinctrl-0 = <&uart_ao_a_pins>;
-	pinctrl-names = "default";
-};
-
-&usb0_phy {
-	status = "okay";
-	phy-supply = <&usb_pwr>;
-};
-
-&usb1_phy {
-	status = "okay";
-};
-
-&usb0 {
-	status = "okay";
-};
-
-&usb1 {
-	status = "okay";
-};
diff --git a/arch/arm/dts/meson-gxbb-wetek-hub.dts b/arch/arm/dts/meson-gxbb-wetek-hub.dts
deleted file mode 100644
index 58733017eda..00000000000
--- a/arch/arm/dts/meson-gxbb-wetek-hub.dts
+++ /dev/null
@@ -1,58 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2016 BayLibre, Inc.
- * Author: Neil Armstrong <narmstrong@baylibre.com>
- */
-
-/dts-v1/;
-
-#include "meson-gxbb-wetek.dtsi"
-#include <dt-bindings/sound/meson-aiu.h>
-
-/ {
-	compatible = "wetek,hub", "amlogic,meson-gxbb";
-	model = "WeTek Hub";
-
-	sound {
-		compatible = "amlogic,gx-sound-card";
-		model = "WETEK-HUB";
-		assigned-clocks = <&clkc CLKID_MPLL0>,
-				  <&clkc CLKID_MPLL1>,
-				  <&clkc CLKID_MPLL2>;
-		assigned-clock-parents = <0>, <0>, <0>;
-		assigned-clock-rates = <294912000>,
-				       <270950400>,
-				       <393216000>;
-		status = "okay";
-
-		dai-link-0 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
-		};
-
-		dai-link-1 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
-			dai-format = "i2s";
-			mclk-fs = <256>;
-
-			codec-0 {
-				sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
-			};
-		};
-
-		dai-link-2 {
-			sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
-
-			codec-0 {
-				sound-dai = <&hdmi_tx>;
-			};
-		};
-	};
-};
-
-&aiu {
-	status = "okay";
-};
-
-&ir {
-	linux,rc-map-name = "rc-wetek-hub";
-};
diff --git a/arch/arm/dts/meson-gxbb-wetek-play2.dts b/arch/arm/dts/meson-gxbb-wetek-play2.dts
deleted file mode 100644
index 505ffcd8eb7..00000000000
--- a/arch/arm/dts/meson-gxbb-wetek-play2.dts
+++ /dev/null
@@ -1,119 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2016 BayLibre, Inc.
- * Author: Neil Armstrong <narmstrong@baylibre.com>
- */
-
-/dts-v1/;
-
-#include "meson-gxbb-wetek.dtsi"
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/sound/meson-aiu.h>
-
-/ {
-	compatible = "wetek,play2", "amlogic,meson-gxbb";
-	model = "WeTek Play 2";
-
-	spdif_dit: audio-codec-0 {
-		#sound-dai-cells = <0>;
-		compatible = "linux,spdif-dit";
-		status = "okay";
-		sound-name-prefix = "DIT";
-	};
-
-	leds {
-		led-wifi {
-			label = "wetek-play:wifi-status";
-			gpios = <&gpio GPIODV_26 GPIO_ACTIVE_HIGH>;
-			default-state = "off";
-		};
-
-		led-ethernet {
-			label = "wetek-play:ethernet-status";
-			gpios = <&gpio GPIODV_27 GPIO_ACTIVE_HIGH>;
-			default-state = "off";
-		};
-	};
-
-	gpio-keys-polled {
-		compatible = "gpio-keys-polled";
-		poll-interval = <100>;
-
-		button {
-			label = "reset";
-			linux,code = <KEY_RESTART>;
-			gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_LOW>;
-		};
-	};
-
-	sound {
-		compatible = "amlogic,gx-sound-card";
-		model = "WETEK-PLAY2";
-		assigned-clocks = <&clkc CLKID_MPLL0>,
-				  <&clkc CLKID_MPLL1>,
-				  <&clkc CLKID_MPLL2>;
-		assigned-clock-parents = <0>, <0>, <0>;
-		assigned-clock-rates = <294912000>,
-				       <270950400>,
-				       <393216000>;
-		status = "okay";
-
-		dai-link-0 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_FIFO>;
-		};
-
-		dai-link-1 {
-			sound-dai = <&aiu AIU_CPU CPU_SPDIF_FIFO>;
-		};
-
-		dai-link-2 {
-			sound-dai = <&aiu AIU_CPU CPU_I2S_ENCODER>;
-			dai-format = "i2s";
-			mclk-fs = <256>;
-
-			codec-0 {
-				sound-dai = <&aiu AIU_HDMI CTRL_I2S>;
-			};
-		};
-
-		dai-link-3 {
-			sound-dai = <&aiu AIU_CPU CPU_SPDIF_ENCODER>;
-
-			codec-0 {
-				sound-dai = <&spdif_dit>;
-			};
-		};
-
-		dai-link-4 {
-			sound-dai = <&aiu AIU_HDMI CTRL_OUT>;
-
-			codec-0 {
-				sound-dai = <&hdmi_tx>;
-			};
-		};
-	};
-};
-
-&aiu {
-	status = "okay";
-	pinctrl-0 = <&spdif_out_y_pins>;
-	pinctrl-names = "default";
-};
-
-&i2c_A {
-	status = "okay";
-	pinctrl-0 = <&i2c_a_pins>;
-	pinctrl-names = "default";
-};
-
-&usb1_phy {
-	status = "okay";
-};
-
-&usb1 {
-	status = "okay";
-};
-
-&ir {
-	linux,rc-map-name = "rc-wetek-play2";
-};
diff --git a/arch/arm/dts/meson-gxbb-wetek.dtsi b/arch/arm/dts/meson-gxbb-wetek.dtsi
deleted file mode 100644
index 94dafb95530..00000000000
--- a/arch/arm/dts/meson-gxbb-wetek.dtsi
+++ /dev/null
@@ -1,292 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2016 Andreas Färber
- * Copyright (c) 2016 BayLibre, Inc.
- * Author: Kevin Hilman <khilman@kernel.org>
- */
-
-#include "meson-gxbb.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
-
-/ {
-	aliases {
-		serial0 = &uart_AO;
-		ethernet0 = &ethmac;
-	};
-
-	chosen {
-		stdout-path = "serial0:115200n8";
-	};
-
-	memory@0 {
-		device_type = "memory";
-		reg = <0x0 0x0 0x0 0x40000000>;
-	};
-
-	leds {
-		compatible = "gpio-leds";
-
-		led-power {
-			/* red in suspend or power-off */
-			color = <LED_COLOR_ID_BLUE>;
-			function = LED_FUNCTION_POWER;
-			gpios = <&gpio_ao GPIOAO_13 GPIO_ACTIVE_HIGH>;
-			default-state = "on";
-			panic-indicator;
-		};
-	};
-
-	usb_pwr: regulator-usb-pwrs {
-		compatible = "regulator-fixed";
-
-		regulator-name = "USB_PWR";
-
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-
-		gpio = <&gpio GPIODV_24 GPIO_ACTIVE_HIGH>;
-		enable-active-high;
-	};
-
-	vddio_boot: regulator-vddio_boot {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDIO_BOOT";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-	};
-
-	vddao_3v3: regulator-vddao_3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDAO_3V3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-	};
-
-	vddio_ao18: regulator-vddio_ao18 {
-		compatible = "regulator-fixed";
-		regulator-name = "VDDIO_AO18";
-		regulator-min-microvolt = <1800000>;
-		regulator-max-microvolt = <1800000>;
-		regulator-always-on;
-	};
-
-	vcc_3v3: regulator-vcc_3v3 {
-		compatible = "regulator-fixed";
-		regulator-name = "VCC_3V3";
-		regulator-min-microvolt = <3300000>;
-		regulator-max-microvolt = <3300000>;
-	};
-
-	emmc_pwrseq: emmc-pwrseq {
-		compatible = "mmc-pwrseq-emmc";
-		reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
-	};
-
-	wifi32k: wifi32k {
-		compatible = "pwm-clock";
-		#clock-cells = <0>;
-		clock-frequency = <32768>;
-		pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
-	};
-
-	sdio_pwrseq: sdio-pwrseq {
-		compatible = "mmc-pwrseq-simple";
-		reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
-		clocks = <&wifi32k>;
-		clock-names = "ext_clock";
-	};
-
-	cvbs-connector {
-		compatible = "composite-video-connector";
-
-		port {
-			cvbs_connector_in: endpoint {
-				remote-endpoint = <&cvbs_vdac_out>;
-			};
-		};
-	};
-
-	hdmi-connector {
-		compatible = "hdmi-connector";
-		type = "a";
-
-		port {
-			hdmi_connector_in: endpoint {
-				remote-endpoint = <&hdmi_tx_tmds_out>;
-			};
-		};
-	};
-};
-
-&cec_AO {
-	status = "okay";
-	pinctrl-0 = <&ao_cec_pins>;
-	pinctrl-names = "default";
-	hdmi-phandle = <&hdmi_tx>;
-};
-
-&cvbs_vdac_port {
-	cvbs_vdac_out: endpoint {
-		remote-endpoint = <&cvbs_connector_in>;
-	};
-};
-
-&ethmac {
-	status = "okay";
-	pinctrl-0 = <&eth_rgmii_pins>;
-	pinctrl-names = "default";
-
-	phy-handle = <&eth_phy0>;
-	phy-mode = "rgmii";
-
-	amlogic,tx-delay-ns = <2>;
-
-	mdio {
-		compatible = "snps,dwmac-mdio";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		eth_phy0: ethernet-phy@0 {
-			/* Realtek RTL8211F (0x001cc916) */
-			reg = <0>;
-
-			reset-assert-us = <10000>;
-			reset-deassert-us = <80000>;
-			reset-gpios = <&gpio GPIOZ_14 GPIO_ACTIVE_LOW>;
-
-			interrupt-parent = <&gpio_intc>;
-			/* MAC_INTR on GPIOZ_15 */
-			interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
-		};
-	};
-};
-
-&hdmi_tx {
-	status = "okay";
-	pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
-	pinctrl-names = "default";
-	hdmi-supply = <&vddio_ao18>;
-};
-
-&hdmi_tx_tmds_port {
-	hdmi_tx_tmds_out: endpoint {
-		remote-endpoint = <&hdmi_connector_in>;
-	};
-};
-
-&ir {
-	status = "okay";
-	pinctrl-0 = <&remote_input_ao_pins>;
-	pinctrl-names = "default";
-};
-
-&pwm_ef {
-	status = "okay";
-	pinctrl-0 = <&pwm_e_pins>;
-	pinctrl-names = "default";
-	clocks = <&clkc CLKID_FCLK_DIV4>;
-	clock-names = "clkin0";
-};
-
-&saradc {
-	status = "okay";
-	vref-supply = <&vddio_ao18>;
-};
-
-/* Wireless SDIO Module */
-&sd_emmc_a {
-	status = "okay";
-	pinctrl-0 = <&sdio_pins>;
-	pinctrl-1 = <&sdio_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-	#address-cells = <1>;
-	#size-cells = <0>;
-
-	bus-width = <4>;
-	cap-sd-highspeed;
-	max-frequency = <50000000>;
-
-	non-removable;
-	disable-wp;
-
-	/* WiFi firmware requires power to be kept while in suspend */
-	keep-power-in-suspend;
-
-	mmc-pwrseq = <&sdio_pwrseq>;
-
-	vmmc-supply = <&vddao_3v3>;
-	vqmmc-supply = <&vddio_boot>;
-
-	brcmf: wifi@1 {
-		reg = <1>;
-		compatible = "brcm,bcm4329-fmac";
-	};
-};
-
-/* SD card */
-&sd_emmc_b {
-	status = "okay";
-	pinctrl-0 = <&sdcard_pins>;
-	pinctrl-1 = <&sdcard_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-
-	bus-width = <4>;
-	cap-sd-highspeed;
-	max-frequency = <50000000>;
-	disable-wp;
-
-	cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_LOW>;
-
-	vmmc-supply = <&vddao_3v3>;
-	vqmmc-supply = <&vcc_3v3>;
-};
-
-/* eMMC */
-&sd_emmc_c {
-	status = "okay";
-	pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
-	pinctrl-1 = <&emmc_clk_gate_pins>;
-	pinctrl-names = "default", "clk-gate";
-
-	bus-width = <8>;
-	cap-mmc-highspeed;
-	max-frequency = <200000000>;
-	non-removable;
-	disable-wp;
-	mmc-ddr-1_8v;
-	mmc-hs200-1_8v;
-
-	mmc-pwrseq = <&emmc_pwrseq>;
-	vmmc-supply = <&vcc_3v3>;
-	vqmmc-supply = <&vddio_boot>;
-};
-
-/* This is connected to the Bluetooth module: */
-&uart_A {
-	status = "okay";
-	pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
-	pinctrl-names = "default";
-	uart-has-rtscts;
-
-	bluetooth {
-		compatible = "brcm,bcm43438-bt";
-		shutdown-gpios = <&gpio GPIOX_20 GPIO_ACTIVE_HIGH>;
-	};
-};
-
-/* This UART is brought out to the DB9 connector */
-&uart_AO {
-	status = "okay";
-	pinctrl-0 = <&uart_ao_a_pins>;
-	pinctrl-names = "default";
-};
-
-&usb0_phy {
-	status = "okay";
-	phy-supply = <&usb_pwr>;
-};
-
-&usb0 {
-	status = "okay";
-};
diff --git a/arch/arm/dts/meson-gxbb.dtsi b/arch/arm/dts/meson-gxbb.dtsi
deleted file mode 100644
index 7c029f552a2..00000000000
--- a/arch/arm/dts/meson-gxbb.dtsi
+++ /dev/null
@@ -1,856 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * Copyright (c) 2016 Andreas Färber
- */
-
-#include "meson-gx.dtsi"
-#include "meson-gx-mali450.dtsi"
-#include <dt-bindings/gpio/meson-gxbb-gpio.h>
-#include <dt-bindings/reset/amlogic,meson-gxbb-reset.h>
-#include <dt-bindings/clock/gxbb-clkc.h>
-#include <dt-bindings/clock/gxbb-aoclkc.h>
-#include <dt-bindings/reset/gxbb-aoclkc.h>
-
-/ {
-	compatible = "amlogic,meson-gxbb";
-
-	soc {
-		usb0_phy: phy@c0000000 {
-			compatible = "amlogic,meson-gxbb-usb2-phy";
-			#phy-cells = <0>;
-			reg = <0x0 0xc0000000 0x0 0x20>;
-			resets = <&reset RESET_USB_OTG>;
-			clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB0>;
-			clock-names = "usb_general", "usb";
-			status = "disabled";
-		};
-
-		usb1_phy: phy@c0000020 {
-			compatible = "amlogic,meson-gxbb-usb2-phy";
-			#phy-cells = <0>;
-			reg = <0x0 0xc0000020 0x0 0x20>;
-			resets = <&reset RESET_USB_OTG>;
-			clocks = <&clkc CLKID_USB>, <&clkc CLKID_USB1>;
-			clock-names = "usb_general", "usb";
-			status = "disabled";
-		};
-
-		usb0: usb@c9000000 {
-			compatible = "amlogic,meson-gxbb-usb", "snps,dwc2";
-			reg = <0x0 0xc9000000 0x0 0x40000>;
-			interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&clkc CLKID_USB0_DDR_BRIDGE>;
-			clock-names = "otg";
-			phys = <&usb0_phy>;
-			phy-names = "usb2-phy";
-			dr_mode = "host";
-			status = "disabled";
-		};
-
-		usb1: usb@c9100000 {
-			compatible = "amlogic,meson-gxbb-usb", "snps,dwc2";
-			reg = <0x0 0xc9100000 0x0 0x40000>;
-			interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
-			clocks = <&clkc CLKID_USB1_DDR_BRIDGE>;
-			clock-names = "otg";
-			phys = <&usb1_phy>;
-			phy-names = "usb2-phy";
-			dr_mode = "host";
-			status = "disabled";
-		};
-	};
-};
-
-&aiu {
-	compatible = "amlogic,aiu-gxbb", "amlogic,aiu";
-	clocks = <&clkc CLKID_AIU_GLUE>,
-		 <&clkc CLKID_I2S_OUT>,
-		 <&clkc CLKID_AOCLK_GATE>,
-		 <&clkc CLKID_CTS_AMCLK>,
-		 <&clkc CLKID_MIXER_IFACE>,
-		 <&clkc CLKID_IEC958>,
-		 <&clkc CLKID_IEC958_GATE>,
-		 <&clkc CLKID_CTS_MCLK_I958>,
-		 <&clkc CLKID_CTS_I958>;
-	clock-names = "pclk",
-		      "i2s_pclk",
-		      "i2s_aoclk",
-		      "i2s_mclk",
-		      "i2s_mixer",
-		      "spdif_pclk",
-		      "spdif_aoclk",
-		      "spdif_mclk",
-		      "spdif_mclk_sel";
-	resets = <&reset RESET_AIU>;
-};
-
-&aobus {
-	pinctrl_aobus: pinctrl@14 {
-		compatible = "amlogic,meson-gxbb-aobus-pinctrl";
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
-
-		gpio_ao: bank@14 {
-			reg = <0x0 0x00014 0x0 0x8>,
-			      <0x0 0x0002c 0x0 0x4>,
-			      <0x0 0x00024 0x0 0x8>;
-			reg-names = "mux", "pull", "gpio";
-			gpio-controller;
-			#gpio-cells = <2>;
-			gpio-ranges = <&pinctrl_aobus 0 0 14>;
-		};
-
-		uart_ao_a_pins: uart_ao_a {
-			mux {
-				groups = "uart_tx_ao_a", "uart_rx_ao_a";
-				function = "uart_ao";
-				bias-disable;
-			};
-		};
-
-		uart_ao_a_cts_rts_pins: uart_ao_a_cts_rts {
-			mux {
-				groups = "uart_cts_ao_a",
-				       "uart_rts_ao_a";
-				function = "uart_ao";
-				bias-disable;
-			};
-		};
-
-		uart_ao_b_pins: uart_ao_b {
-			mux {
-				groups = "uart_tx_ao_b", "uart_rx_ao_b";
-				function = "uart_ao_b";
-				bias-disable;
-			};
-		};
-
-		uart_ao_b_cts_rts_pins: uart_ao_b_cts_rts {
-			mux {
-				groups = "uart_cts_ao_b",
-				       "uart_rts_ao_b";
-				function = "uart_ao_b";
-				bias-disable;
-			};
-		};
-
-		remote_input_ao_pins: remote_input_ao {
-			mux {
-				groups = "remote_input_ao";
-				function = "remote_input_ao";
-				bias-disable;
-			};
-		};
-
-		i2c_ao_pins: i2c_ao {
-			mux {
-				groups = "i2c_sck_ao",
-				       "i2c_sda_ao";
-				function = "i2c_ao";
-				bias-disable;
-			};
-		};
-
-		pwm_ao_a_3_pins: pwm_ao_a_3 {
-			mux {
-				groups = "pwm_ao_a_3";
-				function = "pwm_ao_a_3";
-				bias-disable;
-			};
-		};
-
-		pwm_ao_a_6_pins: pwm_ao_a_6 {
-			mux {
-				groups = "pwm_ao_a_6";
-				function = "pwm_ao_a_6";
-				bias-disable;
-			};
-		};
-
-		pwm_ao_a_12_pins: pwm_ao_a_12 {
-			mux {
-				groups = "pwm_ao_a_12";
-				function = "pwm_ao_a_12";
-				bias-disable;
-			};
-		};
-
-		pwm_ao_b_pins: pwm_ao_b {
-			mux {
-				groups = "pwm_ao_b";
-				function = "pwm_ao_b";
-				bias-disable;
-			};
-		};
-
-		i2s_am_clk_pins: i2s_am_clk {
-			mux {
-				groups = "i2s_am_clk";
-				function = "i2s_out_ao";
-				bias-disable;
-			};
-		};
-
-		i2s_out_ao_clk_pins: i2s_out_ao_clk {
-			mux {
-				groups = "i2s_out_ao_clk";
-				function = "i2s_out_ao";
-				bias-disable;
-			};
-		};
-
-		i2s_out_lr_clk_pins: i2s_out_lr_clk {
-			mux {
-				groups = "i2s_out_lr_clk";
-				function = "i2s_out_ao";
-				bias-disable;
-			};
-		};
-
-		i2s_out_ch01_ao_pins: i2s_out_ch01_ao {
-			mux {
-				groups = "i2s_out_ch01_ao";
-				function = "i2s_out_ao";
-				bias-disable;
-			};
-		};
-
-		i2s_out_ch23_ao_pins: i2s_out_ch23_ao {
-			mux {
-				groups = "i2s_out_ch23_ao";
-				function = "i2s_out_ao";
-				bias-disable;
-			};
-		};
-
-		i2s_out_ch45_ao_pins: i2s_out_ch45_ao {
-			mux {
-				groups = "i2s_out_ch45_ao";
-				function = "i2s_out_ao";
-				bias-disable;
-			};
-		};
-
-		spdif_out_ao_6_pins: spdif_out_ao_6 {
-			mux {
-				groups = "spdif_out_ao_6";
-				function = "spdif_out_ao";
-			};
-		};
-
-		spdif_out_ao_13_pins: spdif_out_ao_13 {
-			mux {
-				groups = "spdif_out_ao_13";
-				function = "spdif_out_ao";
-				bias-disable;
-			};
-		};
-
-		ao_cec_pins: ao_cec {
-			mux {
-				groups = "ao_cec";
-				function = "cec_ao";
-				bias-disable;
-			};
-		};
-
-		ee_cec_pins: ee_cec {
-			mux {
-				groups = "ee_cec";
-				function = "cec_ao";
-				bias-disable;
-			};
-		};
-	};
-};
-
-&cbus {
-	spifc: spi@8c80 {
-		compatible = "amlogic,meson-gxbb-spifc";
-		reg = <0x0 0x08c80 0x0 0x80>;
-		#address-cells = <1>;
-		#size-cells = <0>;
-		clocks = <&clkc CLKID_SPI>;
-		status = "disabled";
-	};
-};
-
-&cec_AO {
-	clocks = <&clkc_AO CLKID_AO_CEC_32K>;
-	clock-names = "core";
-};
-
-&clkc_AO {
-	compatible = "amlogic,meson-gxbb-aoclkc", "amlogic,meson-gx-aoclkc";
-	clocks = <&xtal>, <&clkc CLKID_CLK81>;
-	clock-names = "xtal", "mpeg-clk";
-};
-
-&efuse {
-	clocks = <&clkc CLKID_EFUSE>;
-};
-
-&ethmac {
-	clocks = <&clkc CLKID_ETH>,
-		 <&clkc CLKID_FCLK_DIV2>,
-		 <&clkc CLKID_MPLL2>,
-		 <&clkc CLKID_FCLK_DIV2>;
-	clock-names = "stmmaceth", "clkin0", "clkin1", "timing-adjustment";
-};
-
-&gpio_intc {
-	compatible = "amlogic,meson-gpio-intc",
-		     "amlogic,meson-gxbb-gpio-intc";
-	status = "okay";
-};
-
-&hdmi_tx {
-	compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
-	resets = <&reset RESET_HDMITX_CAPB3>,
-		 <&reset RESET_HDMI_SYSTEM_RESET>,
-		 <&reset RESET_HDMI_TX>;
-	reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
-	clocks = <&clkc CLKID_HDMI_PCLK>,
-		 <&clkc CLKID_CLK81>,
-		 <&clkc CLKID_GCLK_VENCI_INT0>;
-	clock-names = "isfr", "iahb", "venci";
-};
-
-&sysctrl {
-	clkc: clock-controller {
-		compatible = "amlogic,gxbb-clkc";
-		#clock-cells = <1>;
-		clocks = <&xtal>;
-		clock-names = "xtal";
-	};
-};
-
-&hwrng {
-	clocks = <&clkc CLKID_RNG0>;
-	clock-names = "core";
-};
-
-&i2c_A {
-	clocks = <&clkc CLKID_I2C>;
-};
-
-&i2c_AO {
-	clocks = <&clkc CLKID_AO_I2C>;
-};
-
-&i2c_B {
-	clocks = <&clkc CLKID_I2C>;
-};
-
-&i2c_C {
-	clocks = <&clkc CLKID_I2C>;
-};
-
-&mali {
-	compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
-
-	clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
-	clock-names = "bus", "core";
-
-	assigned-clocks = <&clkc CLKID_GP0_PLL>;
-	assigned-clock-rates = <744000000>;
-};
-
-&periphs {
-	pinctrl_periphs: pinctrl@4b0 {
-		compatible = "amlogic,meson-gxbb-periphs-pinctrl";
-		#address-cells = <2>;
-		#size-cells = <2>;
-		ranges;
-
-		gpio: bank@4b0 {
-			reg = <0x0 0x004b0 0x0 0x28>,
-			      <0x0 0x004e8 0x0 0x14>,
-			      <0x0 0x00520 0x0 0x14>,
-			      <0x0 0x00430 0x0 0x40>;
-			reg-names = "mux", "pull", "pull-enable", "gpio";
-			gpio-controller;
-			#gpio-cells = <2>;
-			gpio-ranges = <&pinctrl_periphs 0 0 119>;
-		};
-
-		emmc_pins: emmc {
-			mux-0 {
-				groups = "emmc_nand_d07",
-				       "emmc_cmd";
-				function = "emmc";
-				bias-pull-up;
-			};
-
-			mux-1 {
-				groups = "emmc_clk";
-				function = "emmc";
-				bias-disable;
-			};
-		};
-
-		emmc_ds_pins: emmc-ds {
-			mux {
-				groups = "emmc_ds";
-				function = "emmc";
-				bias-pull-down;
-			};
-		};
-
-		emmc_clk_gate_pins: emmc_clk_gate {
-			mux {
-				groups = "BOOT_8";
-				function = "gpio_periphs";
-				bias-pull-down;
-			};
-		};
-
-		nor_pins: nor {
-			mux {
-				groups = "nor_d",
-				       "nor_q",
-				       "nor_c",
-				       "nor_cs";
-				function = "nor";
-				bias-disable;
-			};
-		};
-
-		spi_pins: spi-pins {
-			mux {
-				groups = "spi_miso",
-					"spi_mosi",
-					"spi_sclk";
-				function = "spi";
-				bias-disable;
-			};
-		};
-
-		spi_ss0_pins: spi-ss0 {
-			mux {
-				groups = "spi_ss0";
-				function = "spi";
-				bias-disable;
-			};
-		};
-
-		sdcard_pins: sdcard {
-			mux-0 {
-				groups = "sdcard_d0",
-				       "sdcard_d1",
-				       "sdcard_d2",
-				       "sdcard_d3",
-				       "sdcard_cmd";
-				function = "sdcard";
-				bias-pull-up;
-			};
-
-			mux-1 {
-				groups = "sdcard_clk";
-				function = "sdcard";
-				bias-disable;
-			};
-		};
-
-		sdcard_clk_gate_pins: sdcard_clk_gate {
-			mux {
-				groups = "CARD_2";
-				function = "gpio_periphs";
-				bias-pull-down;
-			};
-		};
-
-		sdio_pins: sdio {
-			mux-0 {
-				groups = "sdio_d0",
-				       "sdio_d1",
-				       "sdio_d2",
-				       "sdio_d3",
-				       "sdio_cmd";
-				function = "sdio";
-				bias-pull-up;
-			};
-
-			mux-1 {
-				groups = "sdio_clk";
-				function = "sdio";
-				bias-disable;
-			};
-		};
-
-		sdio_clk_gate_pins: sdio_clk_gate {
-			mux {
-				groups = "GPIOX_4";
-				function = "gpio_periphs";
-				bias-pull-down;
-			};
-		};
-
-		sdio_irq_pins: sdio_irq {
-			mux {
-				groups = "sdio_irq";
-				function = "sdio";
-				bias-disable;
-			};
-		};
-
-		uart_a_pins: uart_a {
-			mux {
-				groups = "uart_tx_a",
-				       "uart_rx_a";
-				function = "uart_a";
-				bias-disable;
-			};
-		};
-
-		uart_a_cts_rts_pins: uart_a_cts_rts {
-			mux {
-				groups = "uart_cts_a",
-				       "uart_rts_a";
-				function = "uart_a";
-				bias-disable;
-			};
-		};
-
-		uart_b_pins: uart_b {
-			mux {
-				groups = "uart_tx_b",
-				       "uart_rx_b";
-				function = "uart_b";
-				bias-disable;
-			};
-		};
-
-		uart_b_cts_rts_pins: uart_b_cts_rts {
-			mux {
-				groups = "uart_cts_b",
-				       "uart_rts_b";
-				function = "uart_b";
-				bias-disable;
-			};
-		};
-
-		uart_c_pins: uart_c {
-			mux {
-				groups = "uart_tx_c",
-				       "uart_rx_c";
-				function = "uart_c";
-				bias-disable;
-			};
-		};
-
-		uart_c_cts_rts_pins: uart_c_cts_rts {
-			mux {
-				groups = "uart_cts_c",
-				       "uart_rts_c";
-				function = "uart_c";
-				bias-disable;
-			};
-		};
-
-		i2c_a_pins: i2c_a {
-			mux {
-				groups = "i2c_sck_a",
-				       "i2c_sda_a";
-				function = "i2c_a";
-				bias-disable;
-			};
-		};
-
-		i2c_b_pins: i2c_b {
-			mux {
-				groups = "i2c_sck_b",
-				       "i2c_sda_b";
-				function = "i2c_b";
-				bias-disable;
-			};
-		};
-
-		i2c_c_pins: i2c_c {
-			mux {
-				groups = "i2c_sck_c",
-				       "i2c_sda_c";
-				function = "i2c_c";
-				bias-disable;
-			};
-		};
-
-		eth_rgmii_pins: eth-rgmii {
-			mux {
-				groups = "eth_mdio",
-				       "eth_mdc",
-				       "eth_clk_rx_clk",
-				       "eth_rx_dv",
-				       "eth_rxd0",
-				       "eth_rxd1",
-				       "eth_rxd2",
-				       "eth_rxd3",
-				       "eth_rgmii_tx_clk",
-				       "eth_tx_en",
-				       "eth_txd0",
-				       "eth_txd1",
-				       "eth_txd2",
-				       "eth_txd3";
-				function = "eth";
-				bias-disable;
-			};
-		};
-
-		eth_rmii_pins: eth-rmii {
-			mux {
-				groups = "eth_mdio",
-				       "eth_mdc",
-				       "eth_clk_rx_clk",
-				       "eth_rx_dv",
-				       "eth_rxd0",
-				       "eth_rxd1",
-				       "eth_tx_en",
-				       "eth_txd0",
-				       "eth_txd1";
-				function = "eth";
-				bias-disable;
-			};
-		};
-
-		pwm_a_x_pins: pwm_a_x {
-			mux {
-				groups = "pwm_a_x";
-				function = "pwm_a_x";
-				bias-disable;
-			};
-		};
-
-		pwm_a_y_pins: pwm_a_y {
-			mux {
-				groups = "pwm_a_y";
-				function = "pwm_a_y";
-				bias-disable;
-			};
-		};
-
-		pwm_b_pins: pwm_b {
-			mux {
-				groups = "pwm_b";
-				function = "pwm_b";
-				bias-disable;
-			};
-		};
-
-		pwm_d_pins: pwm_d {
-			mux {
-				groups = "pwm_d";
-				function = "pwm_d";
-				bias-disable;
-			};
-		};
-
-		pwm_e_pins: pwm_e {
-			mux {
-				groups = "pwm_e";
-				function = "pwm_e";
-				bias-disable;
-			};
-		};
-
-		pwm_f_x_pins: pwm_f_x {
-			mux {
-				groups = "pwm_f_x";
-				function = "pwm_f_x";
-				bias-disable;
-			};
-		};
-
-		pwm_f_y_pins: pwm_f_y {
-			mux {
-				groups = "pwm_f_y";
-				function = "pwm_f_y";
-				bias-disable;
-			};
-		};
-
-		hdmi_hpd_pins: hdmi_hpd {
-			mux {
-				groups = "hdmi_hpd";
-				function = "hdmi_hpd";
-				bias-disable;
-			};
-		};
-
-		hdmi_i2c_pins: hdmi_i2c {
-			mux {
-				groups = "hdmi_sda", "hdmi_scl";
-				function = "hdmi_i2c";
-				bias-disable;
-			};
-		};
-
-		i2sout_ch23_y_pins: i2sout_ch23_y {
-			mux {
-				groups = "i2sout_ch23_y";
-				function = "i2s_out";
-				bias-disable;
-			};
-		};
-
-		i2sout_ch45_y_pins: i2sout_ch45_y {
-			mux {
-				groups = "i2sout_ch45_y";
-				function = "i2s_out";
-				bias-disable;
-			};
-		};
-
-		i2sout_ch67_y_pins: i2sout_ch67_y {
-			mux {
-				groups = "i2sout_ch67_y";
-				function = "i2s_out";
-				bias-disable;
-			};
-		};
-
-		spdif_out_y_pins: spdif_out_y {
-			mux {
-				groups = "spdif_out_y";
-				function = "spdif_out";
-				bias-disable;
-			};
-		};
-	};
-};
-
-&pwrc {
-	resets = <&reset RESET_VIU>,
-		 <&reset RESET_VENC>,
-		 <&reset RESET_VCBUS>,
-		 <&reset RESET_BT656>,
-		 <&reset RESET_DVIN_RESET>,
-		 <&reset RESET_RDMA>,
-		 <&reset RESET_VENCI>,
-		 <&reset RESET_VENCP>,
-		 <&reset RESET_VDAC>,
-		 <&reset RESET_VDI6>,
-		 <&reset RESET_VENCL>,
-		 <&reset RESET_VID_LOCK>;
-	reset-names = "viu", "venc", "vcbus", "bt656",
-		      "dvin", "rdma", "venci", "vencp",
-		      "vdac", "vdi6", "vencl", "vid_lock";
-	clocks = <&clkc CLKID_VPU>,
-	         <&clkc CLKID_VAPB>;
-	clock-names = "vpu", "vapb";
-	/*
-	 * VPU clocking is provided by two identical clock paths
-	 * VPU_0 and VPU_1 muxed to a single clock by a glitch
-	 * free mux to safely change frequency while running.
-	 * Same for VAPB but with a final gate after the glitch free mux.
-	 */
-	assigned-clocks = <&clkc CLKID_VPU_0_SEL>,
-			  <&clkc CLKID_VPU_0>,
-			  <&clkc CLKID_VPU>, /* Glitch free mux */
-			  <&clkc CLKID_VAPB_0_SEL>,
-			  <&clkc CLKID_VAPB_0>,
-			  <&clkc CLKID_VAPB_SEL>; /* Glitch free mux */
-	assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
-				 <0>, /* Do Nothing */
-				 <&clkc CLKID_VPU_0>,
-				 <&clkc CLKID_FCLK_DIV4>,
-				 <0>, /* Do Nothing */
-				 <&clkc CLKID_VAPB_0>;
-	assigned-clock-rates = <0>, /* Do Nothing */
-			       <666666666>,
-			       <0>, /* Do Nothing */
-			       <0>, /* Do Nothing */
-			       <250000000>,
-			       <0>; /* Do Nothing */
-};
-
-&saradc {
-	compatible = "amlogic,meson-gxbb-saradc", "amlogic,meson-saradc";
-	clocks = <&xtal>,
-		 <&clkc CLKID_SAR_ADC>,
-		 <&clkc CLKID_SAR_ADC_CLK>,
-		 <&clkc CLKID_SAR_ADC_SEL>;
-	clock-names = "clkin", "core", "adc_clk", "adc_sel";
-};
-
-&sd_emmc_a {
-	clocks = <&clkc CLKID_SD_EMMC_A>,
-		 <&clkc CLKID_SD_EMMC_A_CLK0>,
-		 <&clkc CLKID_FCLK_DIV2>;
-	clock-names = "core", "clkin0", "clkin1";
-	resets = <&reset RESET_SD_EMMC_A>;
-};
-
-&sd_emmc_b {
-	clocks = <&clkc CLKID_SD_EMMC_B>,
-		 <&clkc CLKID_SD_EMMC_B_CLK0>,
-		 <&clkc CLKID_FCLK_DIV2>;
-	clock-names = "core", "clkin0", "clkin1";
-	resets = <&reset RESET_SD_EMMC_B>;
-};
-
-&sd_emmc_c {
-	clocks = <&clkc CLKID_SD_EMMC_C>,
-		 <&clkc CLKID_SD_EMMC_C_CLK0>,
-		 <&clkc CLKID_FCLK_DIV2>;
-	clock-names = "core", "clkin0", "clkin1";
-	resets = <&reset RESET_SD_EMMC_C>;
-};
-
-&simplefb_hdmi {
-	clocks = <&clkc CLKID_HDMI_PCLK>,
-		 <&clkc CLKID_CLK81>,
-		 <&clkc CLKID_GCLK_VENCI_INT0>;
-};
-
-&spicc {
-	clocks = <&clkc CLKID_SPICC>;
-	clock-names = "core";
-	resets = <&reset RESET_PERIPHS_SPICC>;
-	num-cs = <1>;
-};
-
-&spifc {
-	clocks = <&clkc CLKID_SPI>;
-};
-
-&uart_A {
-	clocks = <&xtal>, <&clkc CLKID_UART0>, <&xtal>;
-	clock-names = "xtal", "pclk", "baud";
-};
-
-&uart_AO {
-	clocks = <&xtal>, <&clkc_AO CLKID_AO_UART1>, <&xtal>;
-	clock-names = "xtal", "pclk", "baud";
-};
-
-&uart_AO_B {
-	clocks = <&xtal>, <&clkc_AO CLKID_AO_UART2>, <&xtal>;
-	clock-names = "xtal", "pclk", "baud";
-};
-
-&uart_B {
-	clocks = <&xtal>, <&clkc CLKID_UART1>, <&xtal>;
-	clock-names = "xtal", "pclk", "baud";
-};
-
-&uart_C {
-	clocks = <&xtal>, <&clkc CLKID_UART2>, <&xtal>;
-	clock-names = "xtal", "pclk", "baud";
-};
-
-&vpu {
-	compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
-	power-domains = <&pwrc PWRC_GXBB_VPU_ID>;
-};
-
-&vdec {
-	compatible = "amlogic,gxbb-vdec", "amlogic,gx-vdec";
-	clocks = <&clkc CLKID_DOS_PARSER>,
-		 <&clkc CLKID_DOS>,
-		 <&clkc CLKID_VDEC_1>,
-		 <&clkc CLKID_VDEC_HEVC>;
-	clock-names = "dos_parser", "dos", "vdec_1", "vdec_hevc";
-	resets = <&reset RESET_PARSER>;
-	reset-names = "esparser";
-};
-- 
2.34.1

Re: [PATCH 1/8] Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Thu, Dec 14, 2023 at 07:20:56PM +0530, Sumit Garg wrote:
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  .azure-pipelines.yml | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> index d6f3fa423c6..f100c4493e6 100644
> --- a/.azure-pipelines.yml
> +++ b/.azure-pipelines.yml
> @@ -65,7 +65,8 @@ stages:
>        # have no matches.
>        - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_'
>                    :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
> -                  :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
> +                  :^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&
> +                  exit 1 || exit 0
>  
>    - job: docs
>      displayName: 'Build documentation'

The GitLab tests needs an equivalent change.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 1/8] Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks

[Sumit Garg]

On Thu, 14 Dec 2023 at 19:57, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 14, 2023 at 07:20:56PM +0530, Sumit Garg wrote:
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  .azure-pipelines.yml | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index d6f3fa423c6..f100c4493e6 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -65,7 +65,8 @@ stages:
> >        # have no matches.
> >        - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_'
> >                    :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
> > -                  :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
> > +                  :^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&
> > +                  exit 1 || exit 0
> >
> >    - job: docs
> >      displayName: 'Build documentation'
>
> The GitLab tests needs an equivalent change.
>

Sure I will do that in the next spin of this patch-set, thanks for catching it.

-Sumit

> --
> Tom

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[neil.armstrong]

Hi,

On 14/12/2023 14:50, Sumit Garg wrote:
> Prerquisite

s/Prerquisite/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

So I think the big question is: when should the subtree be updated ?

Because as we discussed in the previous GH pull request, if a bindings changes
was made in the upstream Linux DT, then the subtree update should wait until
the u-boot support is merged before updating. This could cause a lot of frustration.

And this could cause a lot of regressions, even more if both Linux and U-boot are
not maintained by the same people.

Neil

> 
> 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):
>    Azure 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 +-
>   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 +-
>   27 files changed, 204 insertions(+), 2730 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
> 

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1744 bytes --]

On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
> Hi,
> 
> On 14/12/2023 14:50, Sumit Garg wrote:
> > Prerquisite
> 
> s/Prerquisite/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
> 
> So I think the big question is: when should the subtree be updated ?
> 
> Because as we discussed in the previous GH pull request, if a bindings changes
> was made in the upstream Linux DT, then the subtree update should wait until
> the u-boot support is merged before updating. This could cause a lot of frustration.
> 
> And this could cause a lot of regressions, even more if both Linux and U-boot are
> not maintained by the same people.

I think some of the important questions to ask are, how often / likely
are the breakages to occur? It seems like these days it's either:
- U-Boot had an early version of the binding and we already state we
  don't support backwards compatibility here. It should be on the
  maintainer to be proactive in this case.
- It's a "the DT was wrong about the hardware, sorry not sorry it's an
  incompatible DTS change now". This too is hopefully the kind of thing
  that at least board maintainers will be more actively aware of needing
  to deal with in U-Boot, if it's really a problem.

So I would plan on grabbing only full kernel releases and in to -next as
soon as possible. Our cadences don't match up exactly, but I think do
fairly well enough.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Rob Herring]

On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
> > Hi,
> >
> > On 14/12/2023 14:50, Sumit Garg wrote:
> > > Prerquisite
> >
> > s/Prerquisite/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
> >
> > So I think the big question is: when should the subtree be updated ?
> >
> > Because as we discussed in the previous GH pull request, if a bindings changes
> > was made in the upstream Linux DT, then the subtree update should wait until
> > the u-boot support is merged before updating. This could cause a lot of frustration.
> >
> > And this could cause a lot of regressions, even more if both Linux and U-boot are
> > not maintained by the same people.
>
> I think some of the important questions to ask are, how often / likely
> are the breakages to occur? It seems like these days it's either:
> - U-Boot had an early version of the binding and we already state we
>   don't support backwards compatibility here. It should be on the
>   maintainer to be proactive in this case.
> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
>   incompatible DTS change now". This too is hopefully the kind of thing
>   that at least board maintainers will be more actively aware of needing
>   to deal with in U-Boot, if it's really a problem.

A common issue in the kernel is with forward compatibility when
platforms add new resources from a new provider. Then the kernel
expects a driver for the provider and waits for the dependency. Of
course, older kernels don't have that provider driver and so the
dependency is never met. Not sure if u-boot will have similar issues?
At least you should/could know if the provider driver exists or not.
(The kernel doesn't because modules.)

Rob

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote:
> On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
> > > Hi,
> > >
> > > On 14/12/2023 14:50, Sumit Garg wrote:
> > > > Prerquisite
> > >
> > > s/Prerquisite/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
> > >
> > > So I think the big question is: when should the subtree be updated ?
> > >
> > > Because as we discussed in the previous GH pull request, if a bindings changes
> > > was made in the upstream Linux DT, then the subtree update should wait until
> > > the u-boot support is merged before updating. This could cause a lot of frustration.
> > >
> > > And this could cause a lot of regressions, even more if both Linux and U-boot are
> > > not maintained by the same people.
> >
> > I think some of the important questions to ask are, how often / likely
> > are the breakages to occur? It seems like these days it's either:
> > - U-Boot had an early version of the binding and we already state we
> >   don't support backwards compatibility here. It should be on the
> >   maintainer to be proactive in this case.
> > - It's a "the DT was wrong about the hardware, sorry not sorry it's an
> >   incompatible DTS change now". This too is hopefully the kind of thing
> >   that at least board maintainers will be more actively aware of needing
> >   to deal with in U-Boot, if it's really a problem.
> 
> A common issue in the kernel is with forward compatibility when
> platforms add new resources from a new provider. Then the kernel
> expects a driver for the provider and waits for the dependency. Of
> course, older kernels don't have that provider driver and so the
> dependency is never met. Not sure if u-boot will have similar issues?
> At least you should/could know if the provider driver exists or not.
> (The kernel doesn't because modules.)

I think we'll be fine, but time will tell. And perhaps the more frequent
re-syncing will make any sort of corner cases show up more quickly and
be something we can figure out how to resolve going forward really.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Sumit Garg]

On Thu, 14 Dec 2023 at 23:53, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
> > Hi,
> >
> > On 14/12/2023 14:50, Sumit Garg wrote:
> > > Prerquisite
> >
> > s/Prerquisite/Prerequisite/
> >

Ack.

> > > -----------
> > >
> > > 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
> >
> > So I think the big question is: when should the subtree be updated ?
> >
> > Because as we discussed in the previous GH pull request, if a bindings changes
> > was made in the upstream Linux DT, then the subtree update should wait until
> > the u-boot support is merged before updating. This could cause a lot of frustration.
> >
> > And this could cause a lot of regressions, even more if both Linux and U-boot are
> > not maintained by the same people.
>
> I think some of the important questions to ask are, how often / likely
> are the breakages to occur? It seems like these days it's either:
> - U-Boot had an early version of the binding and we already state we
>   don't support backwards compatibility here. It should be on the
>   maintainer to be proactive in this case.
> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
>   incompatible DTS change now". This too is hopefully the kind of thing
>   that at least board maintainers will be more actively aware of needing
>   to deal with in U-Boot, if it's really a problem.

Agree, also per discussion with Linux DT maintainers, they do care for
DT backwards and forward compatibility. I expect the ABI changes to be
rare. In case there is an ABI change then it will be great if Linux DT
maintainers can ask contributors to CC corresponding U-boot platform
maintainers too.

BTW, Rob is already working on a tool to detect ABI changes as he
described here [1]. If U-boot platform maintainers have any ideas
regarding what would constitute an ABI change then feel free to share
those.

[1] https://lore.kernel.org/all/CAL_JsqLo4nXrJ93dDsfp3UYLs08V02aMnbCCnsDj0MBBomc35w@mail.gmail.com/

>
> So I would plan on grabbing only full kernel releases and in to -next as
> soon as possible. Our cadences don't match up exactly, but I think do
> fairly well enough.

I suppose that would give ample time to the U-boot platform/board
maintainer to fix any ABI change regression found in the -next branch.
That being said we aren't completely immune to changes to
devicetree-rebasing subtree. If there is an DT ABI change that will
take significant effort to fix in U-boot then we are open to accepting
a revert given that it will be fixed before next uprev.

-Sumit

>
> --
> Tom

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Sumit Garg]

On Fri, 15 Dec 2023 at 01:45, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote:
> > On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
> > > > Hi,
> > > >
> > > > On 14/12/2023 14:50, Sumit Garg wrote:
> > > > > Prerquisite
> > > >
> > > > s/Prerquisite/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
> > > >
> > > > So I think the big question is: when should the subtree be updated ?
> > > >
> > > > Because as we discussed in the previous GH pull request, if a bindings changes
> > > > was made in the upstream Linux DT, then the subtree update should wait until
> > > > the u-boot support is merged before updating. This could cause a lot of frustration.
> > > >
> > > > And this could cause a lot of regressions, even more if both Linux and U-boot are
> > > > not maintained by the same people.
> > >
> > > I think some of the important questions to ask are, how often / likely
> > > are the breakages to occur? It seems like these days it's either:
> > > - U-Boot had an early version of the binding and we already state we
> > >   don't support backwards compatibility here. It should be on the
> > >   maintainer to be proactive in this case.
> > > - It's a "the DT was wrong about the hardware, sorry not sorry it's an
> > >   incompatible DTS change now". This too is hopefully the kind of thing
> > >   that at least board maintainers will be more actively aware of needing
> > >   to deal with in U-Boot, if it's really a problem.
> >
> > A common issue in the kernel is with forward compatibility when
> > platforms add new resources from a new provider. Then the kernel
> > expects a driver for the provider and waits for the dependency. Of
> > course, older kernels don't have that provider driver and so the
> > dependency is never met. Not sure if u-boot will have similar issues?
> > At least you should/could know if the provider driver exists or not.
> > (The kernel doesn't because modules.)
>
> I think we'll be fine, but time will tell. And perhaps the more frequent
> re-syncing will make any sort of corner cases show up more quickly and
> be something we can figure out how to resolve going forward really.
>

Agree, frequent re-syncing is something we should aim for. However, if
required then we can always revisit our approach.

-Sumit

> --
> Tom

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Krzysztof Kozlowski]

On 14/12/2023 20:48, Rob Herring wrote:
>>
>> I think some of the important questions to ask are, how often / likely
>> are the breakages to occur? It seems like these days it's either:
>> - U-Boot had an early version of the binding and we already state we
>>   don't support backwards compatibility here. It should be on the
>>   maintainer to be proactive in this case.
>> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
>>   incompatible DTS change now". This too is hopefully the kind of thing
>>   that at least board maintainers will be more actively aware of needing
>>   to deal with in U-Boot, if it's really a problem.
> 
> A common issue in the kernel is with forward compatibility when
> platforms add new resources from a new provider. Then the kernel
> expects a driver for the provider and waits for the dependency. Of
> course, older kernels don't have that provider driver and so the
> dependency is never met. Not sure if u-boot will have similar issues?
> At least you should/could know if the provider driver exists or not.
> (The kernel doesn't because modules.)

If some U-Boot platform decides to aggressively sync with kernel DTS,
then probably the kernel subarch maintainer should be aware of it.
Mentioned forward compatibility issue is a result of assumption that
there are no out-of-tree upstream consumers of our DTS. I am certainly
not aware of any such consumer for Samsung. If someone told me (me
wearing Samsung hat), hey U-Boot now cares, I would start caring as well.

The usual argument of contributors wanting to break the backward and
forward compatibility, is "there is no other OS depending on this"
(recent discussion with Johan about order of interrupts:
https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ).
You need to tell the maintainers of that platform, that now they have
other OS/firmware/bootloader depending on DTS compatibility.

Best regards,
Krzysztof

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[neil.armstrong]

On 14/12/2023 21:15, Tom Rini wrote:
> On Thu, Dec 14, 2023 at 01:48:42PM -0600, Rob Herring wrote:
>> On Thu, Dec 14, 2023 at 12:23 PM Tom Rini <trini@konsulko.com> wrote:
>>>
>>> On Thu, Dec 14, 2023 at 03:53:11PM +0100, neil.armstrong@linaro.org wrote:
>>>> Hi,
>>>>
>>>> On 14/12/2023 14:50, Sumit Garg wrote:
>>>>> Prerquisite
>>>>
>>>> s/Prerquisite/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
>>>>
>>>> So I think the big question is: when should the subtree be updated ?
>>>>
>>>> Because as we discussed in the previous GH pull request, if a bindings changes
>>>> was made in the upstream Linux DT, then the subtree update should wait until
>>>> the u-boot support is merged before updating. This could cause a lot of frustration.
>>>>
>>>> And this could cause a lot of regressions, even more if both Linux and U-boot are
>>>> not maintained by the same people.
>>>
>>> I think some of the important questions to ask are, how often / likely
>>> are the breakages to occur? It seems like these days it's either:
>>> - U-Boot had an early version of the binding and we already state we
>>>    don't support backwards compatibility here. It should be on the
>>>    maintainer to be proactive in this case.
>>> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
>>>    incompatible DTS change now". This too is hopefully the kind of thing
>>>    that at least board maintainers will be more actively aware of needing
>>>    to deal with in U-Boot, if it's really a problem.
>>
>> A common issue in the kernel is with forward compatibility when
>> platforms add new resources from a new provider. Then the kernel
>> expects a driver for the provider and waits for the dependency. Of
>> course, older kernels don't have that provider driver and so the
>> dependency is never met. Not sure if u-boot will have similar issues?
>> At least you should/could know if the provider driver exists or not.
>> (The kernel doesn't because modules.)
> 
> I think we'll be fine, but time will tell. And perhaps the more frequent
> re-syncing will make any sort of corner cases show up more quickly and
> be something we can figure out how to resolve going forward really.
> 

Sure, I suppose I'll only switch the stable boards, and keep the in-progress ones
with manual sync.
And I'll need to make a prerequisite to any breaking DT change to have the corresponding
U-Boot change submitted before (and probably other OSes like *BSD*s)

Neil

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2605 bytes --]

On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
> On 14/12/2023 20:48, Rob Herring wrote:
> >>
> >> I think some of the important questions to ask are, how often / likely
> >> are the breakages to occur? It seems like these days it's either:
> >> - U-Boot had an early version of the binding and we already state we
> >>   don't support backwards compatibility here. It should be on the
> >>   maintainer to be proactive in this case.
> >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
> >>   incompatible DTS change now". This too is hopefully the kind of thing
> >>   that at least board maintainers will be more actively aware of needing
> >>   to deal with in U-Boot, if it's really a problem.
> > 
> > A common issue in the kernel is with forward compatibility when
> > platforms add new resources from a new provider. Then the kernel
> > expects a driver for the provider and waits for the dependency. Of
> > course, older kernels don't have that provider driver and so the
> > dependency is never met. Not sure if u-boot will have similar issues?
> > At least you should/could know if the provider driver exists or not.
> > (The kernel doesn't because modules.)
> 
> If some U-Boot platform decides to aggressively sync with kernel DTS,
> then probably the kernel subarch maintainer should be aware of it.
> Mentioned forward compatibility issue is a result of assumption that
> there are no out-of-tree upstream consumers of our DTS. I am certainly
> not aware of any such consumer for Samsung. If someone told me (me
> wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
> 
> The usual argument of contributors wanting to break the backward and
> forward compatibility, is "there is no other OS depending on this"
> (recent discussion with Johan about order of interrupts:
> https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ).
> You need to tell the maintainers of that platform, that now they have
> other OS/firmware/bootloader depending on DTS compatibility.

I think this hints at one of the bigger impacts this might have.
Reminding everyone that other projects do use the device trees and have
for years. Without rehashing history, BSD does use the trees as-is and
for platforms U-Boot supports they are supposed to be re-synced
periodically. This series moves us from an ad-hoc method to a defined
schedule.

And presumably some of the Samsung platforms will get moved over to this
framework, especially the newer ones being submitted recently :)

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 4713 bytes --]

On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote:
> On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
> > On 14/12/2023 20:48, Rob Herring wrote:
> > >>
> > >> I think some of the important questions to ask are, how often / likely
> > >> are the breakages to occur? It seems like these days it's either:
> > >> - U-Boot had an early version of the binding and we already state we
> > >>   don't support backwards compatibility here. It should be on the
> > >>   maintainer to be proactive in this case.
> > >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
> > >>   incompatible DTS change now". This too is hopefully the kind of thing
> > >>   that at least board maintainers will be more actively aware of needing
> > >>   to deal with in U-Boot, if it's really a problem.
> > > 
> > > A common issue in the kernel is with forward compatibility when
> > > platforms add new resources from a new provider. Then the kernel
> > > expects a driver for the provider and waits for the dependency. Of
> > > course, older kernels don't have that provider driver and so the
> > > dependency is never met. Not sure if u-boot will have similar issues?
> > > At least you should/could know if the provider driver exists or not.
> > > (The kernel doesn't because modules.)
> > 
> > If some U-Boot platform decides to aggressively sync with kernel DTS,
> > then probably the kernel subarch maintainer should be aware of it.
> > Mentioned forward compatibility issue is a result of assumption that
> > there are no out-of-tree upstream consumers of our DTS. I am certainly
> > not aware of any such consumer for Samsung. If someone told me (me
> > wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
> > 
> > The usual argument of contributors wanting to break the backward and
> > forward compatibility, is "there is no other OS depending on this"
> > (recent discussion with Johan about order of interrupts:
> > https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ).
> > You need to tell the maintainers of that platform, that now they have
> > other OS/firmware/bootloader depending on DTS compatibility.
> 
> I think this hints at one of the bigger impacts this might have.
> Reminding everyone that other projects do use the device trees and have
> for years.

TBF, we do try to ask these questions as much as possible, usually (for
me at least) citing U-Boot or the BSDs as users. It largely seems to me
like we are all bark and no bite though, so a project like U-Boot having
a defined "schedule" as you suggest below would add more meaning to our
questioning.

> Without rehashing history, BSD does use the trees as-is and
> for platforms U-Boot supports they are supposed to be re-synced
> periodically.

I know this is the theory, but I also know that how well this is
implemented varies wildly per-platform. I generally don't pay all
that much attention to the various arm platforms, but I do pay
attention to what's going on for RISC-V and there appear to be no
active maintainers of individual platforms and the architecture
maintainers are not aware of the status of the equivalent patches
for Linux when they apply patches.

In recent memory, this has lead to the clock indices in the DT
differing between U-Boot and Linux for one such platform, which, IMO,
is an insidious difference that is hard to spot during review and highly
unlikely to crop up while comparing dts files, since the defines were named
identically. To be clear, I am not expecting the architecture code
maintainers to be aware of the minutiae of the various RISC-V platforms,
but rather suggesting they might have an easier time reviewing if both
projects' dts files and binding headers were tied together.

That said, automatically synced devicetrees will, as has been pointed out,
require the platform maintainers in Linux to be more aware of the affect of
what they accept on other users, but it will also require the equivalent
maintainers on the U-Boot side to engage too, so that the "upstream" dts
files do not change in a way that screws the usecase in U-Boot.

Also, if people send fixes to the U-Boot copies of these devicetrees,
would the plan be to request that these are sent to Linux and the fixes
pulled in via a resync after each -rc release of Linux (or similar, just
throwing some example schedule out there)?

Cheers,
Conor.

> This series moves us from an ad-hoc method to a defined
> schedule.
> 
> And presumably some of the Samsung platforms will get moved over to this
> framework, especially the newer ones being submitted recently :)




[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5306 bytes --]

On Fri, Dec 15, 2023 at 02:45:11PM +0000, Conor Dooley wrote:
> On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote:
> > On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
> > > On 14/12/2023 20:48, Rob Herring wrote:
> > > >>
> > > >> I think some of the important questions to ask are, how often / likely
> > > >> are the breakages to occur? It seems like these days it's either:
> > > >> - U-Boot had an early version of the binding and we already state we
> > > >>   don't support backwards compatibility here. It should be on the
> > > >>   maintainer to be proactive in this case.
> > > >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
> > > >>   incompatible DTS change now". This too is hopefully the kind of thing
> > > >>   that at least board maintainers will be more actively aware of needing
> > > >>   to deal with in U-Boot, if it's really a problem.
> > > > 
> > > > A common issue in the kernel is with forward compatibility when
> > > > platforms add new resources from a new provider. Then the kernel
> > > > expects a driver for the provider and waits for the dependency. Of
> > > > course, older kernels don't have that provider driver and so the
> > > > dependency is never met. Not sure if u-boot will have similar issues?
> > > > At least you should/could know if the provider driver exists or not.
> > > > (The kernel doesn't because modules.)
> > > 
> > > If some U-Boot platform decides to aggressively sync with kernel DTS,
> > > then probably the kernel subarch maintainer should be aware of it.
> > > Mentioned forward compatibility issue is a result of assumption that
> > > there are no out-of-tree upstream consumers of our DTS. I am certainly
> > > not aware of any such consumer for Samsung. If someone told me (me
> > > wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
> > > 
> > > The usual argument of contributors wanting to break the backward and
> > > forward compatibility, is "there is no other OS depending on this"
> > > (recent discussion with Johan about order of interrupts:
> > > https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ).
> > > You need to tell the maintainers of that platform, that now they have
> > > other OS/firmware/bootloader depending on DTS compatibility.
> > 
> > I think this hints at one of the bigger impacts this might have.
> > Reminding everyone that other projects do use the device trees and have
> > for years.
> 
> TBF, we do try to ask these questions as much as possible, usually (for
> me at least) citing U-Boot or the BSDs as users. It largely seems to me
> like we are all bark and no bite though, so a project like U-Boot having
> a defined "schedule" as you suggest below would add more meaning to our
> questioning.
> 
> > Without rehashing history, BSD does use the trees as-is and
> > for platforms U-Boot supports they are supposed to be re-synced
> > periodically.
> 
> I know this is the theory, but I also know that how well this is
> implemented varies wildly per-platform. I generally don't pay all
> that much attention to the various arm platforms, but I do pay
> attention to what's going on for RISC-V and there appear to be no
> active maintainers of individual platforms and the architecture
> maintainers are not aware of the status of the equivalent patches
> for Linux when they apply patches.
> 
> In recent memory, this has lead to the clock indices in the DT
> differing between U-Boot and Linux for one such platform, which, IMO,
> is an insidious difference that is hard to spot during review and highly
> unlikely to crop up while comparing dts files, since the defines were named
> identically. To be clear, I am not expecting the architecture code
> maintainers to be aware of the minutiae of the various RISC-V platforms,
> but rather suggesting they might have an easier time reviewing if both
> projects' dts files and binding headers were tied together.
> 
> That said, automatically synced devicetrees will, as has been pointed out,
> require the platform maintainers in Linux to be more aware of the affect of
> what they accept on other users, but it will also require the equivalent
> maintainers on the U-Boot side to engage too, so that the "upstream" dts
> files do not change in a way that screws the usecase in U-Boot.

Yeah, it will hopefully lead to better coordination between maintainers
in some places. There are SoCs where the kernel DTS people are the
U-Boot DTS people too. All in all, I should probably CC more people than
I usually do on these resync patches just to try and head off any
tricky changes like you've mentioned above.

> Also, if people send fixes to the U-Boot copies of these devicetrees,
> would the plan be to request that these are sent to Linux and the fixes
> pulled in via a resync after each -rc release of Linux (or similar, just
> throwing some example schedule out there)?

The way we've always tried to operate is that changes should be pushed
to Linux and resynced down, or at least submitted simultaneously. If
there's some specific bugfixes that need to come in out of cycle I
_think_ subtree handles cherry picked commits in a reasonable fashion.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Sumit Garg]

On Sat, 16 Dec 2023 at 00:49, Tom Rini <trini@konsulko.com> wrote:
>
> On Fri, Dec 15, 2023 at 02:45:11PM +0000, Conor Dooley wrote:
> > On Fri, Dec 15, 2023 at 08:37:43AM -0500, Tom Rini wrote:
> > > On Fri, Dec 15, 2023 at 08:50:51AM +0100, Krzysztof Kozlowski wrote:
> > > > On 14/12/2023 20:48, Rob Herring wrote:
> > > > >>
> > > > >> I think some of the important questions to ask are, how often / likely
> > > > >> are the breakages to occur? It seems like these days it's either:
> > > > >> - U-Boot had an early version of the binding and we already state we
> > > > >>   don't support backwards compatibility here. It should be on the
> > > > >>   maintainer to be proactive in this case.
> > > > >> - It's a "the DT was wrong about the hardware, sorry not sorry it's an
> > > > >>   incompatible DTS change now". This too is hopefully the kind of thing
> > > > >>   that at least board maintainers will be more actively aware of needing
> > > > >>   to deal with in U-Boot, if it's really a problem.
> > > > >
> > > > > A common issue in the kernel is with forward compatibility when
> > > > > platforms add new resources from a new provider. Then the kernel
> > > > > expects a driver for the provider and waits for the dependency. Of
> > > > > course, older kernels don't have that provider driver and so the
> > > > > dependency is never met. Not sure if u-boot will have similar issues?
> > > > > At least you should/could know if the provider driver exists or not.
> > > > > (The kernel doesn't because modules.)
> > > >
> > > > If some U-Boot platform decides to aggressively sync with kernel DTS,
> > > > then probably the kernel subarch maintainer should be aware of it.
> > > > Mentioned forward compatibility issue is a result of assumption that
> > > > there are no out-of-tree upstream consumers of our DTS. I am certainly
> > > > not aware of any such consumer for Samsung. If someone told me (me
> > > > wearing Samsung hat), hey U-Boot now cares, I would start caring as well.
> > > >
> > > > The usual argument of contributors wanting to break the backward and
> > > > forward compatibility, is "there is no other OS depending on this"
> > > > (recent discussion with Johan about order of interrupts:
> > > > https://lore.kernel.org/all/ZWcPZPX-eT-xHAOv@hovoldconsulting.com/ ).
> > > > You need to tell the maintainers of that platform, that now they have
> > > > other OS/firmware/bootloader depending on DTS compatibility.
> > >
> > > I think this hints at one of the bigger impacts this might have.
> > > Reminding everyone that other projects do use the device trees and have
> > > for years.
> >
> > TBF, we do try to ask these questions as much as possible, usually (for
> > me at least) citing U-Boot or the BSDs as users. It largely seems to me
> > like we are all bark and no bite though, so a project like U-Boot having
> > a defined "schedule" as you suggest below would add more meaning to our
> > questioning.
> >
> > > Without rehashing history, BSD does use the trees as-is and
> > > for platforms U-Boot supports they are supposed to be re-synced
> > > periodically.
> >
> > I know this is the theory, but I also know that how well this is
> > implemented varies wildly per-platform. I generally don't pay all
> > that much attention to the various arm platforms, but I do pay
> > attention to what's going on for RISC-V and there appear to be no
> > active maintainers of individual platforms and the architecture
> > maintainers are not aware of the status of the equivalent patches
> > for Linux when they apply patches.
> >
> > In recent memory, this has lead to the clock indices in the DT
> > differing between U-Boot and Linux for one such platform, which, IMO,
> > is an insidious difference that is hard to spot during review and highly
> > unlikely to crop up while comparing dts files, since the defines were named
> > identically. To be clear, I am not expecting the architecture code
> > maintainers to be aware of the minutiae of the various RISC-V platforms,
> > but rather suggesting they might have an easier time reviewing if both
> > projects' dts files and binding headers were tied together.
> >
> > That said, automatically synced devicetrees will, as has been pointed out,
> > require the platform maintainers in Linux to be more aware of the affect of
> > what they accept on other users, but it will also require the equivalent
> > maintainers on the U-Boot side to engage too, so that the "upstream" dts
> > files do not change in a way that screws the usecase in U-Boot.
>
> Yeah, it will hopefully lead to better coordination between maintainers
> in some places. There are SoCs where the kernel DTS people are the
> U-Boot DTS people too. All in all, I should probably CC more people than
> I usually do on these resync patches just to try and head off any
> tricky changes like you've mentioned above.

Makes sense.

>
> > Also, if people send fixes to the U-Boot copies of these devicetrees,
> > would the plan be to request that these are sent to Linux and the fixes
> > pulled in via a resync after each -rc release of Linux (or similar, just
> > throwing some example schedule out there)?
>
> The way we've always tried to operate is that changes should be pushed
> to Linux and resynced down, or at least submitted simultaneously. If
> there's some specific bugfixes that need to come in out of cycle I
> _think_ subtree handles cherry picked commits in a reasonable fashion.
>

Agree.

-Sumit

> --
> Tom

Re: [PATCH 1/8] Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks

[Simon Glass]

Hi Sumit,

On Thu, 14 Dec 2023 at 07:46, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Thu, 14 Dec 2023 at 19:57, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 14, 2023 at 07:20:56PM +0530, Sumit Garg wrote:
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > ---
> > >  .azure-pipelines.yml | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > index d6f3fa423c6..f100c4493e6 100644
> > > --- a/.azure-pipelines.yml
> > > +++ b/.azure-pipelines.yml
> > > @@ -65,7 +65,8 @@ stages:
> > >        # have no matches.
> > >        - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_'
> > >                    :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
> > > -                  :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
> > > +                  :^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&
> > > +                  exit 1 || exit 0
> > >
> > >    - job: docs
> > >      displayName: 'Build documentation'
> >
> > The GitLab tests needs an equivalent change.
> >
>
> Sure I will do that in the next spin of this patch-set, thanks for catching it.

Also, please add a commit message with that :-)

Regards,
Simon

Re: [PATCH 2/8] Makefile: Add support for DT bindings schema checks

[Simon Glass]

Hi Sumit,

On Thu, 14 Dec 2023 at 06:51, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> This adds the build infrastructure for checking DT binding schema
> documents and validating dtb files using the binding schema. Here we use
> devicetree-rebasing directory to provide the DT bindings.
>
> Dependency:
> -----------
>
> 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
>
> Testing:
> --------
>
> Build dts files and check using DT binding schema:
> $ make dtbs_check
>
> Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
> use for validation. This makes it easier to find and fix errors
> generated by a specific schema.
>
> Note, at this point dtbs_check is an optional build target as there are
> many warnings generated due to custom DT properties used by many
> platforms in u-boot. It is expected with these checks that compliance
> with DT bindings to take place. Once that's done it can be added to CI
> builds to remain compliant with DT bindings.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  Makefile             | 20 ++++++++++++++++++--
>  scripts/Makefile.lib | 17 +++++++++++++++--
>  2 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 750bbdb1b71..d8d168cd4c3 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1158,12 +1158,28 @@ endif
>         @# disabling OF_BOARD.
>         $(call cmd,ofcheck,$(KCONFIG_CONFIG))
>
> -PHONY += dtbs
> +PHONY += dtbs dtbs_check
>  dtbs: dts/dt.dtb
>         @:
> -dts/dt.dtb: u-boot
> +dts/dt.dtb: dtbs_prepare u-boot
>         $(Q)$(MAKE) $(build)=dts dtbs
>
> +dtbs_prepare: prepare3
> +
> +ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),)
> +export CHECK_DTBS=y
> +endif
> +
> +ifneq ($(CHECK_DTBS),)
> +dtbs_prepare: dt_binding_check
> +endif
> +
> +dtbs_check: dt_binding_check dtbs
> +
> +DT_BINDING_DIR := devicetree-rebasing/Bindings
> +dt_binding_check: scripts_dtc
> +       $(Q)$(MAKE) $(build)=$(DT_BINDING_DIR) $(DT_BINDING_DIR)/processed-schema.json
> +
>  quiet_cmd_copy = COPY    $@
>        cmd_copy = cp $< $@
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 16bbc277a9f..27b9437027c 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -356,8 +356,21 @@ endif
>
>  dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list)))
>
> -$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
> -       $(call if_changed_dep,dtc)
> +ifneq ($(CHECK_DTBS),)
> +DT_CHECKER ?= dt-validate
> +DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m)
> +DT_BINDING_DIR := devicetree-rebasing/Bindings
> +DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json
> +
> +quiet_cmd_dtb = DTC_CHK $@
> +      cmd_dtb = $(cmd_dtc) ; $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u $(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true
> +else
> +quiet_cmd_dtb = $(quiet_cmd_dtc)
> +      cmd_dtb = $(cmd_dtc)
> +endif
> +
> +$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) $(DT_TMP_SCHEMA) FORCE
> +       $(call if_changed_dep,dtb)
>
>  pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
>  dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
> --
> 2.34.1
>

This is great.

Can you put the commit message in doc/ somewhere?

Regards,
Simon

Re: [PATCH 3/8] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location

[Simon Glass]

Hi Sumit,

On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Allow u-boot to build DTB from a different directory tree such that
> *-u-boot.dtsi files can be included from a common location. Currently
> that location is arch/$(ARCH)/dts/, so statically define that common
> location.
>
> This is needed for platform owners to start building DTB files from
> devicetree-rebasing directory but still being able to include
> *-u-boot.dtsi files.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  scripts/Makefile.lib | 25 ++++++++++++++-----------
>  1 file changed, 14 insertions(+), 11 deletions(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 27b9437027c..4a002b0e0ca 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -159,18 +159,20 @@ cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE)     \
>  ld_flags       = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
>
>  # Try these files in order to find the U-Boot-specific .dtsi include file
> -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
> -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
> -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> -       $(wildcard $(dir $<)u-boot.dtsi))
> +UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/

How about lower case since it is internal. Also we know it is U-Boot,
so perhap dtsi_loc ?

Otherwise looks OK to me.

> +
> +u_boot_dtsi_options = $(strip $(wildcard $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi) \
> +       $(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
> +       $(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> +       $(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> +       $(wildcard $(UBOOT_DTSI_LOC)u-boot.dtsi))
>
>  u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
> -       $(dir $<)$(basename $(notdir $<))-u-boot.dtsi \
> -       $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
> -       $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
> -       $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
> -       $(dir $<)u-boot.dtsi ... \
> +       $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi \
> +       $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
> +       $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
> +       $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
> +       $(UBOOT_DTSI_LOC)u-boot.dtsi ... \
>         found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))
>
>  # Uncomment for debugging
> @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
>  dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc                    \
>                  $(UBOOTINCLUDE)                                         \
>                  -I$(dir $<)                                             \
> +                -I$(UBOOT_DTSI_LOC)                                     \
>                  -I$(srctree)/arch/$(ARCH)/dts/include                   \
>                  -I$(srctree)/include                                    \
>                  -D__ASSEMBLY__                                          \
> @@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
>           echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
>         $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \
>         $(DTC) -O dtb -o $@ -b 0 \
> -               -i $(dir $<) $(DTC_FLAGS) \
> +               -i $(dir $<) -i $(UBOOT_DTSI_LOC) $(DTC_FLAGS) \
>                 -d $(depfile).dtc.tmp $(dtc-tmp) || \
>                 (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \
>                 ; \
> --
> 2.34.1
>

Regards,
Simon

Re: [PATCH 4/8] dts: Add alternative location for upstream DTB builds

[Simon Glass]

Hi Sumit,

On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Allow platform owners to mirror devicetree files from devitree-rebasing
> directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> directory.

Also add a new Makefile for arm64.

>
> This will help easy migration for platforms which currently are compliant
> with upstream Linux kernel devicetree files.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  dts/Kconfig             | 11 +++++++++++
>  dts/Makefile            | 17 ++++++++++++++---
>  dts/arch/arm64/Makefile | 14 ++++++++++++++
>  3 files changed, 39 insertions(+), 3 deletions(-)
>  create mode 100644 dts/arch/arm64/Makefile
>
> diff --git a/dts/Kconfig b/dts/Kconfig
> index 00c0aeff893..96396f12b67 100644
> --- a/dts/Kconfig
> +++ b/dts/Kconfig
> @@ -85,6 +85,17 @@ config OF_LIVE
>           enables a live tree which is available after relocation,
>           and can be adjusted as needed.
>
> +config OF_UPSTREAM
> +       bool "Enable use of devicetree imported from Linux kernel release"
> +       help
> +         Traditionally, U-boot platforms used to have their custom devicetree

U-Boot

(I think I mentioned this, but you thought I said U-boot...but it
really is U-Boot). Perhaps grep your patches next time.

> +         files or copy devicetree files from Linux kernel which are hard to
> +         maintain and can usually get out-of-sync from Linux kernel. This
> +         option enables platforms to migrate to devicetree-rebasing repo where
> +         a regular sync will be maintained every major Linux kernel release
> +         cycle. However, platforms can still have some custom u-boot specific
> +         bits maintained as part of *-u-boot.dtsi files.

I'm a bit nervous about this. It means that boards chose between this
dir of the local files. It means there is some effort to switch.

I wonder if we could default to using the rebasing thing, with boards
having to 'opt out'? So this should be 'default y' ?


> +
>  choice
>         prompt "Provider of DTB for DT control"
>         depends on OF_CONTROL
> diff --git a/dts/Makefile b/dts/Makefile
> index 3437e54033d..8098bf8191a 100644
> --- a/dts/Makefile
> +++ b/dts/Makefile
> @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
>  DEVICE_TREE := unset
>  endif
>
> +ifeq ($(CONFIG_OF_UPSTREAM),y)
> +ifeq ($(CONFIG_ARM64),y)
> +DEVICE_TREE_LOC := dts/arch/arm64

dt_dir ?

Should we move the arm64 DTs to arch/arm64 ?

What about the subdirs used in Linux?

> +else
> +DEVICE_TREE_LOC := dts/arch/$(ARCH)
> +endif
> +else
> +DEVICE_TREE_LOC := arch/$(ARCH)/dts
> +endif
> +
>  ifneq ($(EXT_DTB),)
>  DTB := $(EXT_DTB)

>
>  else
> -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb
> +DTB := $(DEVICE_TREE_LOC)/$(DEVICE_TREE).dtb
>  endif
>
>  $(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE
> @@ -41,7 +51,7 @@ $(DTB): arch-dtbs
>
>  PHONY += arch-dtbs
>  arch-dtbs:
> -       $(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
> +       $(Q)$(MAKE) $(build)=$(DEVICE_TREE_LOC) dtbs
>
>  ifeq ($(CONFIG_SPL_BUILD),y)
>  obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o
> @@ -65,4 +75,5 @@ clean-files := dt.dtb.S
>  # Let clean descend into dts directories
>  subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts     \
>            ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts     \
> -          ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
> +          ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts        \
> +          ./arch/arm64 ./arch/$(ARCH)
> diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
> new file mode 100644
> index 00000000000..16e9fea622d
> --- /dev/null
> +++ b/dts/arch/arm64/Makefile
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +include $(srctree)/scripts/Makefile.dts
> +
> +targets += $(dtb-y)
> +
> +# Add any required device tree compiler flags here
> +DTC_FLAGS += -a 0x8
> +
> +PHONY += dtbs
> +dtbs: $(addprefix $(obj)/, $(dtb-y))
> +       @:
> +
> +clean-files := */*.dtb */*.dtbo */*_HS
> --
> 2.34.1

Regards,
Simon

Re: [PATCH 5/8] doc: devicetree: Updates for devicetree-rebasing subtree

[Simon Glass]

Hi Sumit,

On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Encourage SoC/board maintainers to migrate to using devicetree-rebasing
> subtree and maintain a regular sync with Linux kernel devicetree files
> and bindings.
>
> Along with that add documentation regarding how to run DT bindings
> schema checks.
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  doc/develop/devicetree/control.rst | 108 +++++++++++++++++++++++------
>  1 file changed, 86 insertions(+), 22 deletions(-)
>
> diff --git a/doc/develop/devicetree/control.rst b/doc/develop/devicetree/control.rst
> index cbb65c9b177..12ef55ed368 100644
> --- a/doc/develop/devicetree/control.rst
> +++ b/doc/develop/devicetree/control.rst
> @@ -1,5 +1,6 @@
>  .. SPDX-License-Identifier: GPL-2.0+
>  .. sectionauthor:: Copyright 2011 The Chromium OS Authors
> +.. Copyright 2023 Linaro Ltd.
>
>  Devicetree Control in U-Boot
>  ============================
> @@ -22,12 +23,11 @@ for three reasons:
>    hierarchical format
>  - It is fairly efficient to read incrementally
>
> -The arch/<arch>/dts directories contains a Makefile for building the devicetree
> -blob and embedding it in the U-Boot image. This is useful since it allows
> -U-Boot to configure itself according to what it finds there. If you have
> -a number of similar boards with different peripherals, you can describe
> -the features of each board in the devicetree file, and have a single
> -generic source base.
> +The U-boot Makefile infrastructure allows for building the devicetree blob
> +and embedding it in the U-Boot image. This is useful since it allows U-Boot
> +to configure itself according to what it finds there. If you have a number
> +of similar boards with different peripherals, you can describe the features
> +of each board in the devicetree file, and have a single generic source base.
>
>  To enable this feature, add CONFIG_OF_CONTROL to your board config file.
>
> @@ -68,8 +68,21 @@ a binary file. U-Boot adds its own `fdtgrep` for creating subsets of the file.
>  Where do I get a devicetree file for my board?
>  ----------------------------------------------
>
> -You may find that the Linux kernel has a suitable file. Look in the
> -kernel source in arch/<arch>/boot/dts.
> +Linux kernel Git repository has been the place where devicetree files along
> +with devicetree bindings are stored and maintained. There is devicetee-rebasing
> +(dtrepo_) which maintains a forked copy of devicetree files along with bindings
> +at every Linux kernel major release or intermideate release candidates.
> +
> +In order to maintain devicetree files sync, U-boot maintains a Git subtree for
> +devicetee-rebasing repo as `devicetee-rebasing/` sub-directory. It is regularly
> +kept 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
> +
> +You may find that the `devicetee-rebasing/` sub-directory has a suitable
> +devicetree file for your board. Look in `devicetree-rebasing/src/<arch>/`.
>
>  If not you might find other boards with suitable files that you can
>  modify to your needs. Look in the board directories for files with a
> @@ -81,18 +94,21 @@ Failing that, you could write one from scratch yourself!
>  Configuration
>  -------------
>
> -Use::
> +Traditionally, U-boot placed copies of devicetree source files from Linux
> +kernel into `arch/<arch>/dts/<name>.dts` which can be selected via::
>
> -   #define CONFIG_DEFAULT_DEVICE_TREE  "<name>"
> +    #define CONFIG_DEFAULT_DEVICE_TREE "<name>"
>
> -to set the filename of the devicetree source. Then put your devicetree
> -file into::
> +However, it has become combersome over time for each SoC/board maintainer to
> +keep devicetree files in sync with Linux kernel. Thereby, SoC/board maintainers
> +are encouraged to migrate to use mirrored copies from `devicetree-rebasing/`
> +into `dts/arch/<arch>/<vendor>` via::
>
> -   arch/<arch>/dts/<name>.dts
> +    #define CONFIG_OF_UPSTREAM=y
> +    #define CONFIG_DEFAULT_DEVICE_TREE "<vendor>/<name>"
>
> -This should include your CPU or SOC's devicetree file, placed in
> -`arch/<arch>/dts`, and then make any adjustments required using a u-boot-dtsi
> -file for your board.
> +This should include your CPU or SOC's devicetree file. On top of that any U-boot
> +specific tweaks (see: dttweaks_) can be made for your board.
>
>  If CONFIG_OF_EMBED is defined, then it will be picked up and built into
>  the U-Boot image (including u-boot.bin). This is suitable for debugging
> @@ -156,8 +172,9 @@ ways:
>  Adding tweaks for U-Boot
>  ------------------------
>
> -It is strongly recommended that devicetree files in U-Boot are an exact copy of
> -those in Linux, so that it is easy to sync them up from time to time.
> +With devicetee-rebasing Git subtree, it is ensured that devicetree files in
> +U-Boot are an exact copy of those in Linux kernel via mirroring into
> +`dts/arch/<arch>/<vendor>`.
>
>  U-Boot is of course a very different project from Linux, e.g. it operates under
>  much more restrictive memory and code-size constraints. Where Linux may use a
> @@ -170,8 +187,8 @@ constraints are even more extreme and the devicetree is shrunk to remove
>  unwanted nodes, or even turned into C code to avoid access overhead.
>
>  U-Boot automatically looks for and includes a file with updates to the standard
> -devicetree for your board, searching for them in the same directory as the
> -main file, in this order::
> +devicetree for your board, searching for them in `arch/<arch>/dts/` in this
> +order::
>
>     <orig_filename>-u-boot.dtsi
>     <CONFIG_SYS_SOC>-u-boot.dtsi
> @@ -200,6 +217,52 @@ to specify a list of .dtsi files that will also be included when
>  building .dtb files.
>
>
> +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
> +
> +
>  Relocation, SPL and TPL
>  -----------------------
>
> @@ -261,8 +324,9 @@ used it before Linux (e.g. snow). The two projects developed in parallel
>  and there are still some differences in the bindings for certain boards.
>  While there has been discussion of having a separate repository for devicetree
>  files, in practice the Linux kernel Git repository has become the place where
> -these are stored, with U-Boot taking copies and adding tweaks with u-boot.dtsi
> -files.
> +these are stored, with U-Boot taking copies via devicetree-rebasing repo
> +(see: dtrepo_) and adding tweaks with u-boot.dtsi files.
>
>  .. _dtspec: https://www.devicetree.org/specifications/
>  .. _dtlist: https://www.spinics.net/lists/devicetree-compiler/
> +.. _dtrepo: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
> --
> 2.34.1
>

OK, ignore my comment about docs.

Regards,
Simon

Re: [PATCH 6/8] MAINTAINERS: Add myself as devicetree-rebasing maintainer

[Simon Glass]

On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  MAINTAINERS | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 969514468cb..253092c345c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -951,6 +951,12 @@ F: cmd/cyclic.c
>  F:     common/cyclic.c
>  F:     include/cyclic.h
>
> +DEVICETREE REBASING SUBTREE
> +M:     Sumit Garg <sumit.garg@linaro.org>
> +S:     Maintained
> +F:     devicetree-rebasing/
> +F:     dts/arch/
> +
>  DFU
>  M:     Lukasz Majewski <lukma@denx.de>
>  M:     Mattijs Korpershoek <mkorpershoek@baylibre.com>
> --
> 2.34.1
>

Reviewed-by: Simon Glass <sjg@chromium.org>

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Michal Simek]

Hi Sumit,

On 12/14/23 14:50, Sumit Garg wrote:
> Prerquisite
> -----------
> 
> 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

Do you also plan to extend this to cover dt overlay + dt base generation and 
check it against DT schema.

Thanks,
Michal

Re: [PATCH 7/8] dts: meson-gxbb: Switch to using upstream DT

[neil.armstrong]

On 14/12/2023 14:51, Sumit Garg wrote:
> Although there were still some variations in board DTS files based on
> meson-gxbb SoC but I think those were minor differences from upstream
> and shouldn't impact boot on these devices.
> 
> So switch to upstream DT via mirroring amlogic/ directory from
> devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly
> building DTB from there including *-u-boot.dtsi files from
> arch/$(ARCH)/dts/ directory.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>   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 ++-
>   dts/arch/arm64/Makefile               | 9 +++++++++
>   dts/arch/arm64/amlogic                | 1 +
>   9 files changed, 24 insertions(+), 7 deletions(-)
>   create mode 120000 dts/arch/arm64/amlogic
> 
> diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig
> index 41dbf7981f8..3db296916e9 100644
> --- a/configs/nanopi-k2_defconfig
> +++ b/configs/nanopi-k2_defconfig
> @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
>   CONFIG_ENV_SIZE=0x2000
>   CONFIG_DM_GPIO=y
> -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
>   CONFIG_OF_LIBFDT_OVERLAY=y
>   CONFIG_DM_RESET=y
>   CONFIG_DEBUG_UART_BASE=0xc81004c0
> diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
> index 5f9f323e06e..65857ff478c 100644
> --- a/configs/odroid-c2_defconfig
> +++ b/configs/odroid-c2_defconfig
> @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
>   CONFIG_ENV_SIZE=0x2000
>   CONFIG_DM_GPIO=y
> -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
>   CONFIG_OF_LIBFDT_OVERLAY=y
>   CONFIG_DM_RESET=y
>   CONFIG_DEBUG_UART_BASE=0xc81004c0
> diff --git a/configs/p200_defconfig b/configs/p200_defconfig
> index cd579ef5f14..c1792db51fd 100644
> --- a/configs/p200_defconfig
> +++ b/configs/p200_defconfig
> @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
>   CONFIG_ENV_SIZE=0x2000
>   CONFIG_DM_GPIO=y
> -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200"
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p200"
>   CONFIG_OF_LIBFDT_OVERLAY=y
>   CONFIG_DM_RESET=y
>   CONFIG_DEBUG_UART_BASE=0xc81004c0
> diff --git a/configs/p201_defconfig b/configs/p201_defconfig
> index b2f0a0ccdb4..202e1da5bcc 100644
> --- a/configs/p201_defconfig
> +++ b/configs/p201_defconfig
> @@ -7,7 +7,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
>   CONFIG_ENV_SIZE=0x2000
>   CONFIG_DM_GPIO=y
> -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p201"
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p201"
>   CONFIG_OF_LIBFDT_OVERLAY=y
>   CONFIG_DM_RESET=y
>   CONFIG_DEBUG_UART_BASE=0xc81004c0
> diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig
> index 3eda8f14a21..d09333d3b96 100644
> --- a/configs/videostrong-kii-pro_defconfig
> +++ b/configs/videostrong-kii-pro_defconfig
> @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
>   CONFIG_ENV_SIZE=0x2000
>   CONFIG_DM_GPIO=y
> -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro"
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-kii-pro"
>   CONFIG_OF_LIBFDT_OVERLAY=y
>   CONFIG_DM_RESET=y
>   CONFIG_DEBUG_UART_BASE=0xc81004c0
> diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig
> index fd92b041e73..73f3d4aad5d 100644
> --- a/configs/wetek-hub_defconfig
> +++ b/configs/wetek-hub_defconfig
> @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
>   CONFIG_ENV_SIZE=0x2000
>   CONFIG_DM_GPIO=y
> -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-hub"
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-hub"
>   CONFIG_OF_LIBFDT_OVERLAY=y
>   CONFIG_DM_RESET=y
>   CONFIG_DEBUG_UART_BASE=0xc81004c0
> diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig
> index b887419a6ba..26f57b4214a 100644
> --- a/configs/wetek-play2_defconfig
> +++ b/configs/wetek-play2_defconfig
> @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
>   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
>   CONFIG_ENV_SIZE=0x2000
>   CONFIG_DM_GPIO=y
> -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-play2"
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2"
>   CONFIG_OF_LIBFDT_OVERLAY=y
>   CONFIG_DM_RESET=y
>   CONFIG_DEBUG_UART_BASE=0xc81004c0
> diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
> index 16e9fea622d..d548584cf5c 100644
> --- a/dts/arch/arm64/Makefile
> +++ b/dts/arch/arm64/Makefile
> @@ -1,5 +1,14 @@
>   # SPDX-License-Identifier: GPL-2.0+
>   
> +dtb-$(CONFIG_ARCH_MESON) += \
> +	amlogic/meson-gxbb-kii-pro.dtb \
> +	amlogic/meson-gxbb-nanopi-k2.dtb \
> +	amlogic/meson-gxbb-odroidc2.dtb \
> +	amlogic/meson-gxbb-p200.dtb \
> +	amlogic/meson-gxbb-p201.dtb \
> +	amlogic/meson-gxbb-wetek-hub.dtb \
> +	amlogic/meson-gxbb-wetek-play2.dtb
> +
>   include $(srctree)/scripts/Makefile.dts
>   
>   targets += $(dtb-y)
> diff --git a/dts/arch/arm64/amlogic b/dts/arch/arm64/amlogic
> new file mode 120000
> index 00000000000..73f7c3e7bd0
> --- /dev/null
> +++ b/dts/arch/arm64/amlogic
> @@ -0,0 +1 @@
> +../../../devicetree-rebasing/src/arm64/amlogic/
> \ No newline at end of file

Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>

Note: with https://lore.kernel.org/all/8c32e92f-810f-434b-ba77-3074490458bd@linaro.org/ merged it could be be extended to GXL/GXM aswell

Thanks,
Neil

Re: [PATCH 1/8] Azure CI: Exclude devicetree-rebasing subtree for CONFIG checks

[Sumit Garg]

On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Sumit,
>
> On Thu, 14 Dec 2023 at 07:46, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > On Thu, 14 Dec 2023 at 19:57, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 14, 2023 at 07:20:56PM +0530, Sumit Garg wrote:
> > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > ---
> > > >  .azure-pipelines.yml | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > > index d6f3fa423c6..f100c4493e6 100644
> > > > --- a/.azure-pipelines.yml
> > > > +++ b/.azure-pipelines.yml
> > > > @@ -65,7 +65,8 @@ stages:
> > > >        # have no matches.
> > > >        - script: git grep -E '^#[[:blank:]]*(define|undef)[[:blank:]]*CONFIG_'
> > > >                    :^doc/ :^arch/arm/dts/ :^scripts/kconfig/lkc.h
> > > > -                  :^include/linux/kconfig.h :^tools/ && exit 1 || exit 0
> > > > +                  :^include/linux/kconfig.h :^tools/ :^devicetree-rebasing/ &&
> > > > +                  exit 1 || exit 0
> > > >
> > > >    - job: docs
> > > >      displayName: 'Build documentation'
> > >
> > > The GitLab tests needs an equivalent change.
> > >
> >
> > Sure I will do that in the next spin of this patch-set, thanks for catching it.
>
> Also, please add a commit message with that :-)
>

Ack.

-Sumit

> Regards,
> Simon

Re: [PATCH 2/8] Makefile: Add support for DT bindings schema checks

[Sumit Garg]

On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Sumit,
>
> On Thu, 14 Dec 2023 at 06:51, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > This adds the build infrastructure for checking DT binding schema
> > documents and validating dtb files using the binding schema. Here we use
> > devicetree-rebasing directory to provide the DT bindings.
> >
> > Dependency:
> > -----------
> >
> > 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
> >
> > Testing:
> > --------
> >
> > Build dts files and check using DT binding schema:
> > $ make dtbs_check
> >
> > Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
> > use for validation. This makes it easier to find and fix errors
> > generated by a specific schema.
> >
> > Note, at this point dtbs_check is an optional build target as there are
> > many warnings generated due to custom DT properties used by many
> > platforms in u-boot. It is expected with these checks that compliance
> > with DT bindings to take place. Once that's done it can be added to CI
> > builds to remain compliant with DT bindings.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  Makefile             | 20 ++++++++++++++++++--
> >  scripts/Makefile.lib | 17 +++++++++++++++--
> >  2 files changed, 33 insertions(+), 4 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 750bbdb1b71..d8d168cd4c3 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1158,12 +1158,28 @@ endif
> >         @# disabling OF_BOARD.
> >         $(call cmd,ofcheck,$(KCONFIG_CONFIG))
> >
> > -PHONY += dtbs
> > +PHONY += dtbs dtbs_check
> >  dtbs: dts/dt.dtb
> >         @:
> > -dts/dt.dtb: u-boot
> > +dts/dt.dtb: dtbs_prepare u-boot
> >         $(Q)$(MAKE) $(build)=dts dtbs
> >
> > +dtbs_prepare: prepare3
> > +
> > +ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),)
> > +export CHECK_DTBS=y
> > +endif
> > +
> > +ifneq ($(CHECK_DTBS),)
> > +dtbs_prepare: dt_binding_check
> > +endif
> > +
> > +dtbs_check: dt_binding_check dtbs
> > +
> > +DT_BINDING_DIR := devicetree-rebasing/Bindings
> > +dt_binding_check: scripts_dtc
> > +       $(Q)$(MAKE) $(build)=$(DT_BINDING_DIR) $(DT_BINDING_DIR)/processed-schema.json
> > +
> >  quiet_cmd_copy = COPY    $@
> >        cmd_copy = cp $< $@
> >
> > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > index 16bbc277a9f..27b9437027c 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -356,8 +356,21 @@ endif
> >
> >  dtsi_include_list_deps = $(addprefix $(obj)/,$(subst $(quote),,$(dtsi_include_list)))
> >
> > -$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) FORCE
> > -       $(call if_changed_dep,dtc)
> > +ifneq ($(CHECK_DTBS),)
> > +DT_CHECKER ?= dt-validate
> > +DT_CHECKER_FLAGS ?= $(if $(DT_SCHEMA_FILES),-l $(DT_SCHEMA_FILES),-m)
> > +DT_BINDING_DIR := devicetree-rebasing/Bindings
> > +DT_TMP_SCHEMA := $(objtree)/$(DT_BINDING_DIR)/processed-schema.json
> > +
> > +quiet_cmd_dtb = DTC_CHK $@
> > +      cmd_dtb = $(cmd_dtc) ; $(DT_CHECKER) $(DT_CHECKER_FLAGS) -u $(srctree)/$(DT_BINDING_DIR) -p $(DT_TMP_SCHEMA) $@ || true
> > +else
> > +quiet_cmd_dtb = $(quiet_cmd_dtc)
> > +      cmd_dtb = $(cmd_dtc)
> > +endif
> > +
> > +$(obj)/%.dtb: $(src)/%.dts $(DTC) $(dtsi_include_list_deps) $(DT_TMP_SCHEMA) FORCE
> > +       $(call if_changed_dep,dtb)
> >
> >  pre-tmp = $(subst $(comma),_,$(dot-target).pre.tmp)
> >  dtc-tmp = $(subst $(comma),_,$(dot-target).dts.tmp)
> > --
> > 2.34.1
> >
>
> This is great.
>
> Can you put the commit message in doc/ somewhere?

As per your comment on the doc patch, this is already addressed.

-Sumit

>
> Regards,
> Simon

Re: [PATCH 3/8] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location

[Sumit Garg]

On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Sumit,
>
> On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Allow u-boot to build DTB from a different directory tree such that
> > *-u-boot.dtsi files can be included from a common location. Currently
> > that location is arch/$(ARCH)/dts/, so statically define that common
> > location.
> >
> > This is needed for platform owners to start building DTB files from
> > devicetree-rebasing directory but still being able to include
> > *-u-boot.dtsi files.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  scripts/Makefile.lib | 25 ++++++++++++++-----------
> >  1 file changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > index 27b9437027c..4a002b0e0ca 100644
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -159,18 +159,20 @@ cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE)     \
> >  ld_flags       = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
> >
> >  # Try these files in order to find the U-Boot-specific .dtsi include file
> > -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
> > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
> > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> > -       $(wildcard $(dir $<)u-boot.dtsi))
> > +UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/
>
> How about lower case since it is internal. Also we know it is U-Boot,
> so perhap  ?

Although I just named it after *-u-boot.dtsi, I am fine with dtsi_loc
too. So I will use that instead.

>
> Otherwise looks OK to me.

Thanks,
-Sumit

>
> > +
> > +u_boot_dtsi_options = $(strip $(wildcard $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi) \
> > +       $(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
> > +       $(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> > +       $(wildcard $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> > +       $(wildcard $(UBOOT_DTSI_LOC)u-boot.dtsi))
> >
> >  u_boot_dtsi_options_raw = $(warning Automatic .dtsi inclusion: options: \
> > -       $(dir $<)$(basename $(notdir $<))-u-boot.dtsi \
> > -       $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
> > -       $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
> > -       $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
> > -       $(dir $<)u-boot.dtsi ... \
> > +       $(UBOOT_DTSI_LOC)$(basename $(notdir $<))-u-boot.dtsi \
> > +       $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi \
> > +       $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi \
> > +       $(UBOOT_DTSI_LOC)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi \
> > +       $(UBOOT_DTSI_LOC)u-boot.dtsi ... \
> >         found: $(if $(u_boot_dtsi_options),"$(u_boot_dtsi_options)",nothing!))
> >
> >  # Uncomment for debugging
> > @@ -190,6 +192,7 @@ dtsi_include_list += $(CONFIG_DEVICE_TREE_INCLUDES)
> >  dtc_cpp_flags  = -Wp,-MD,$(depfile).pre.tmp -nostdinc                    \
> >                  $(UBOOTINCLUDE)                                         \
> >                  -I$(dir $<)                                             \
> > +                -I$(UBOOT_DTSI_LOC)                                     \
> >                  -I$(srctree)/arch/$(ARCH)/dts/include                   \
> >                  -I$(srctree)/include                                    \
> >                  -D__ASSEMBLY__                                          \
> > @@ -328,7 +331,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> >           echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
> >         $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $(pre-tmp) ; \
> >         $(DTC) -O dtb -o $@ -b 0 \
> > -               -i $(dir $<) $(DTC_FLAGS) \
> > +               -i $(dir $<) -i $(UBOOT_DTSI_LOC) $(DTC_FLAGS) \
> >                 -d $(depfile).dtc.tmp $(dtc-tmp) || \
> >                 (echo "Check $(shell pwd)/$(pre-tmp) for errors" && false) \
> >                 ; \
> > --
> > 2.34.1
> >
>
> Regards,
> Simon

Re: [PATCH 4/8] dts: Add alternative location for upstream DTB builds

[Sumit Garg]

Hi Simon,

On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Sumit,
>
> On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Allow platform owners to mirror devicetree files from devitree-rebasing
> > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > directory.
>
> Also add a new Makefile for arm64.

I suppose you are referring to dts/arch/arm64/Makefile which has been
added by this patch.

>
> >
> > This will help easy migration for platforms which currently are compliant
> > with upstream Linux kernel devicetree files.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  dts/Kconfig             | 11 +++++++++++
> >  dts/Makefile            | 17 ++++++++++++++---
> >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> >  3 files changed, 39 insertions(+), 3 deletions(-)
> >  create mode 100644 dts/arch/arm64/Makefile
> >
> > diff --git a/dts/Kconfig b/dts/Kconfig
> > index 00c0aeff893..96396f12b67 100644
> > --- a/dts/Kconfig
> > +++ b/dts/Kconfig
> > @@ -85,6 +85,17 @@ config OF_LIVE
> >           enables a live tree which is available after relocation,
> >           and can be adjusted as needed.
> >
> > +config OF_UPSTREAM
> > +       bool "Enable use of devicetree imported from Linux kernel release"
> > +       help
> > +         Traditionally, U-boot platforms used to have their custom devicetree
>
> U-Boot
>
> (I think I mentioned this, but you thought I said U-boot...but it
> really is U-Boot). Perhaps grep your patches next time.

Ah, I see. It looks like I missed that bit, and will take care of it
in the next revision.

>
> > +         files or copy devicetree files from Linux kernel which are hard to
> > +         maintain and can usually get out-of-sync from Linux kernel. This
> > +         option enables platforms to migrate to devicetree-rebasing repo where
> > +         a regular sync will be maintained every major Linux kernel release
> > +         cycle. However, platforms can still have some custom u-boot specific
> > +         bits maintained as part of *-u-boot.dtsi files.
>
> I'm a bit nervous about this. It means that boards chose between this
> dir of the local files. It means there is some effort to switch.
>
> I wonder if we could default to using the rebasing thing, with boards
> having to 'opt out'? So this should be 'default y' ?

Ideally that should be our migration path going forward once we get
enough boards migrated to use rebasing repo. But at this initial stage
we have to put some effort on migrating boards to use rebasing
subtree, although effort should be just adding (given DT bindings
compliance) following to defconfig (see patch #7):

CONFIG_OF_UPSTREAM=y
CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"

and create a mirrored copy of:
../../../devicetree-rebasing/src/arm64/amlogic/ into
dts/arch/arm64/amlogic/ with modifications to add targets to
dts/arch/arm64/Makefile.

I am happy to put in that effort but certainly for new board support
that would like to import DT from Linux it should be the default. That
stands true for the Qcom platform series for which Caleb is currently
working on.

>
>
> > +
> >  choice
> >         prompt "Provider of DTB for DT control"
> >         depends on OF_CONTROL
> > diff --git a/dts/Makefile b/dts/Makefile
> > index 3437e54033d..8098bf8191a 100644
> > --- a/dts/Makefile
> > +++ b/dts/Makefile
> > @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
> >  DEVICE_TREE := unset
> >  endif
> >
> > +ifeq ($(CONFIG_OF_UPSTREAM),y)
> > +ifeq ($(CONFIG_ARM64),y)
> > +DEVICE_TREE_LOC := dts/arch/arm64
>
> dt_dir ?

Okay I will rename it.

>
> Should we move the arm64 DTs to arch/arm64 ?

IMO, the migration path should be to use rebasing subtree via
dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from
arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems
like a redundant change to me.

>
> What about the subdirs used in Linux?

I hope I have described above regarding how subdirs are mirrored.
However, have a look at patch #7 for the amlogic/ subdir example.

-Sumit

>
> > +else
> > +DEVICE_TREE_LOC := dts/arch/$(ARCH)
> > +endif
> > +else
> > +DEVICE_TREE_LOC := arch/$(ARCH)/dts
> > +endif
> > +
> >  ifneq ($(EXT_DTB),)
> >  DTB := $(EXT_DTB)
>
> >
> >  else
> > -DTB := arch/$(ARCH)/dts/$(DEVICE_TREE).dtb
> > +DTB := $(DEVICE_TREE_LOC)/$(DEVICE_TREE).dtb
> >  endif
> >
> >  $(obj)/dt-$(SPL_NAME).dtb: dts/dt.dtb $(objtree)/tools/fdtgrep FORCE
> > @@ -41,7 +51,7 @@ $(DTB): arch-dtbs
> >
> >  PHONY += arch-dtbs
> >  arch-dtbs:
> > -       $(Q)$(MAKE) $(build)=arch/$(ARCH)/dts dtbs
> > +       $(Q)$(MAKE) $(build)=$(DEVICE_TREE_LOC) dtbs
> >
> >  ifeq ($(CONFIG_SPL_BUILD),y)
> >  obj-$(CONFIG_OF_EMBED) := dt-spl.dtb.o
> > @@ -65,4 +75,5 @@ clean-files := dt.dtb.S
> >  # Let clean descend into dts directories
> >  subdir- += ../arch/arc/dts ../arch/arm/dts ../arch/m68k/dts ../arch/microblaze/dts     \
> >            ../arch/mips/dts ../arch/nios2/dts ../arch/powerpc/dts ../arch/riscv/dts     \
> > -          ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts
> > +          ../arch/sandbox/dts ../arch/sh/dts ../arch/x86/dts ../arch/xtensa/dts        \
> > +          ./arch/arm64 ./arch/$(ARCH)
> > diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
> > new file mode 100644
> > index 00000000000..16e9fea622d
> > --- /dev/null
> > +++ b/dts/arch/arm64/Makefile
> > @@ -0,0 +1,14 @@
> > +# SPDX-License-Identifier: GPL-2.0+
> > +
> > +include $(srctree)/scripts/Makefile.dts
> > +
> > +targets += $(dtb-y)
> > +
> > +# Add any required device tree compiler flags here
> > +DTC_FLAGS += -a 0x8
> > +
> > +PHONY += dtbs
> > +dtbs: $(addprefix $(obj)/, $(dtb-y))
> > +       @:
> > +
> > +clean-files := */*.dtb */*.dtbo */*_HS
> > --
> > 2.34.1
>
> Regards,
> Simon

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Sumit Garg]

Hi Michal,

On Wed, 20 Dec 2023 at 16:14, Michal Simek <michal.simek@amd.com> wrote:
>
> Hi Sumit,
>
> On 12/14/23 14:50, Sumit Garg wrote:
> > Prerquisite
> > -----------
> >
> > 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
>
> Do you also plan to extend this to cover dt overlay + dt base generation and
> check it against DT schema.

I suppose here you are referring to DT schema checks for *.dtso ->
*.dtbo generation. I don't see corresponding checks enabled in Linux
kernel [1]. Probably Rob can share plans over there.

U-Boot tries to follow Linux kernel kbuild framework. However, if
needed we can add checks for *.dtbo generation too as a follow up
patch.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/scripts/Makefile.lib#n421

-Sumit

>
> Thanks,
> Michal
>

Re: [PATCH 7/8] dts: meson-gxbb: Switch to using upstream DT

[Sumit Garg]

On Wed, 20 Dec 2023 at 16:23, <neil.armstrong@linaro.org> wrote:
>
> On 14/12/2023 14:51, Sumit Garg wrote:
> > Although there were still some variations in board DTS files based on
> > meson-gxbb SoC but I think those were minor differences from upstream
> > and shouldn't impact boot on these devices.
> >
> > So switch to upstream DT via mirroring amlogic/ directory from
> > devicetree-rebasing/src/arm64/amlogic/ directory. And thereby directly
> > building DTB from there including *-u-boot.dtsi files from
> > arch/$(ARCH)/dts/ directory.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >   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 ++-
> >   dts/arch/arm64/Makefile               | 9 +++++++++
> >   dts/arch/arm64/amlogic                | 1 +
> >   9 files changed, 24 insertions(+), 7 deletions(-)
> >   create mode 120000 dts/arch/arm64/amlogic
> >
> > diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig
> > index 41dbf7981f8..3db296916e9 100644
> > --- a/configs/nanopi-k2_defconfig
> > +++ b/configs/nanopi-k2_defconfig
> > @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
> >   CONFIG_ENV_SIZE=0x2000
> >   CONFIG_DM_GPIO=y
> > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-nanopi-k2"
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
> >   CONFIG_OF_LIBFDT_OVERLAY=y
> >   CONFIG_DM_RESET=y
> >   CONFIG_DEBUG_UART_BASE=0xc81004c0
> > diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig
> > index 5f9f323e06e..65857ff478c 100644
> > --- a/configs/odroid-c2_defconfig
> > +++ b/configs/odroid-c2_defconfig
> > @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
> >   CONFIG_ENV_SIZE=0x2000
> >   CONFIG_DM_GPIO=y
> > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-odroidc2"
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
> >   CONFIG_OF_LIBFDT_OVERLAY=y
> >   CONFIG_DM_RESET=y
> >   CONFIG_DEBUG_UART_BASE=0xc81004c0
> > diff --git a/configs/p200_defconfig b/configs/p200_defconfig
> > index cd579ef5f14..c1792db51fd 100644
> > --- a/configs/p200_defconfig
> > +++ b/configs/p200_defconfig
> > @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
> >   CONFIG_ENV_SIZE=0x2000
> >   CONFIG_DM_GPIO=y
> > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200"
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p200"
> >   CONFIG_OF_LIBFDT_OVERLAY=y
> >   CONFIG_DM_RESET=y
> >   CONFIG_DEBUG_UART_BASE=0xc81004c0
> > diff --git a/configs/p201_defconfig b/configs/p201_defconfig
> > index b2f0a0ccdb4..202e1da5bcc 100644
> > --- a/configs/p201_defconfig
> > +++ b/configs/p201_defconfig
> > @@ -7,7 +7,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
> >   CONFIG_ENV_SIZE=0x2000
> >   CONFIG_DM_GPIO=y
> > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p201"
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-p201"
> >   CONFIG_OF_LIBFDT_OVERLAY=y
> >   CONFIG_DM_RESET=y
> >   CONFIG_DEBUG_UART_BASE=0xc81004c0
> > diff --git a/configs/videostrong-kii-pro_defconfig b/configs/videostrong-kii-pro_defconfig
> > index 3eda8f14a21..d09333d3b96 100644
> > --- a/configs/videostrong-kii-pro_defconfig
> > +++ b/configs/videostrong-kii-pro_defconfig
> > @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
> >   CONFIG_ENV_SIZE=0x2000
> >   CONFIG_DM_GPIO=y
> > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-kii-pro"
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-kii-pro"
> >   CONFIG_OF_LIBFDT_OVERLAY=y
> >   CONFIG_DM_RESET=y
> >   CONFIG_DEBUG_UART_BASE=0xc81004c0
> > diff --git a/configs/wetek-hub_defconfig b/configs/wetek-hub_defconfig
> > index fd92b041e73..73f3d4aad5d 100644
> > --- a/configs/wetek-hub_defconfig
> > +++ b/configs/wetek-hub_defconfig
> > @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
> >   CONFIG_ENV_SIZE=0x2000
> >   CONFIG_DM_GPIO=y
> > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-hub"
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-hub"
> >   CONFIG_OF_LIBFDT_OVERLAY=y
> >   CONFIG_DM_RESET=y
> >   CONFIG_DEBUG_UART_BASE=0xc81004c0
> > diff --git a/configs/wetek-play2_defconfig b/configs/wetek-play2_defconfig
> > index b887419a6ba..26f57b4214a 100644
> > --- a/configs/wetek-play2_defconfig
> > +++ b/configs/wetek-play2_defconfig
> > @@ -6,7 +6,8 @@ CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
> >   CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x20000000
> >   CONFIG_ENV_SIZE=0x2000
> >   CONFIG_DM_GPIO=y
> > -CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-wetek-play2"
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-wetek-play2"
> >   CONFIG_OF_LIBFDT_OVERLAY=y
> >   CONFIG_DM_RESET=y
> >   CONFIG_DEBUG_UART_BASE=0xc81004c0
> > diff --git a/dts/arch/arm64/Makefile b/dts/arch/arm64/Makefile
> > index 16e9fea622d..d548584cf5c 100644
> > --- a/dts/arch/arm64/Makefile
> > +++ b/dts/arch/arm64/Makefile
> > @@ -1,5 +1,14 @@
> >   # SPDX-License-Identifier: GPL-2.0+
> >
> > +dtb-$(CONFIG_ARCH_MESON) += \
> > +     amlogic/meson-gxbb-kii-pro.dtb \
> > +     amlogic/meson-gxbb-nanopi-k2.dtb \
> > +     amlogic/meson-gxbb-odroidc2.dtb \
> > +     amlogic/meson-gxbb-p200.dtb \
> > +     amlogic/meson-gxbb-p201.dtb \
> > +     amlogic/meson-gxbb-wetek-hub.dtb \
> > +     amlogic/meson-gxbb-wetek-play2.dtb
> > +
> >   include $(srctree)/scripts/Makefile.dts
> >
> >   targets += $(dtb-y)
> > diff --git a/dts/arch/arm64/amlogic b/dts/arch/arm64/amlogic
> > new file mode 120000
> > index 00000000000..73f7c3e7bd0
> > --- /dev/null
> > +++ b/dts/arch/arm64/amlogic
> > @@ -0,0 +1 @@
> > +../../../devicetree-rebasing/src/arm64/amlogic/
> > \ No newline at end of file
>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
>

Thanks.

> Note: with https://lore.kernel.org/all/8c32e92f-810f-434b-ba77-3074490458bd@linaro.org/ merged it could be be extended to GXL/GXM aswell

Sure, I will convert GXL/GXM too once your PR is merged and this series lands.

-Sumit

>
> Thanks,
> Neil

Re: [PATCH 3/8] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

On Wed, Dec 20, 2023 at 05:00:20PM +0530, Sumit Garg wrote:
> On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Sumit,
> >
> > On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > Allow u-boot to build DTB from a different directory tree such that
> > > *-u-boot.dtsi files can be included from a common location. Currently
> > > that location is arch/$(ARCH)/dts/, so statically define that common
> > > location.
> > >
> > > This is needed for platform owners to start building DTB files from
> > > devicetree-rebasing directory but still being able to include
> > > *-u-boot.dtsi files.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > ---
> > >  scripts/Makefile.lib | 25 ++++++++++++++-----------
> > >  1 file changed, 14 insertions(+), 11 deletions(-)
> > >
> > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > > index 27b9437027c..4a002b0e0ca 100644
> > > --- a/scripts/Makefile.lib
> > > +++ b/scripts/Makefile.lib
> > > @@ -159,18 +159,20 @@ cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE)     \
> > >  ld_flags       = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
> > >
> > >  # Try these files in order to find the U-Boot-specific .dtsi include file
> > > -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
> > > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
> > > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> > > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> > > -       $(wildcard $(dir $<)u-boot.dtsi))
> > > +UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/
> >
> > How about lower case since it is internal. Also we know it is U-Boot,
> > so perhap  ?
> 
> Although I just named it after *-u-boot.dtsi, I am fine with dtsi_loc
> too. So I will use that instead.

I was going to say lets use "uboot_dtsi_loc" so it's both clear what the
variable does and for future re-syncs.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 3/8] scripts/Makefile.lib: Statically define *-u-boot.dtsi files location

[Sumit Garg]

On Wed, 20 Dec 2023 at 18:59, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Dec 20, 2023 at 05:00:20PM +0530, Sumit Garg wrote:
> > On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Sumit,
> > >
> > > On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
> > > >
> > > > Allow u-boot to build DTB from a different directory tree such that
> > > > *-u-boot.dtsi files can be included from a common location. Currently
> > > > that location is arch/$(ARCH)/dts/, so statically define that common
> > > > location.
> > > >
> > > > This is needed for platform owners to start building DTB files from
> > > > devicetree-rebasing directory but still being able to include
> > > > *-u-boot.dtsi files.
> > > >
> > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > ---
> > > >  scripts/Makefile.lib | 25 ++++++++++++++-----------
> > > >  1 file changed, 14 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> > > > index 27b9437027c..4a002b0e0ca 100644
> > > > --- a/scripts/Makefile.lib
> > > > +++ b/scripts/Makefile.lib
> > > > @@ -159,18 +159,20 @@ cpp_flags      = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(UBOOTINCLUDE)     \
> > > >  ld_flags       = $(KBUILD_LDFLAGS) $(ldflags-y) $(LDFLAGS_$(@F))
> > > >
> > > >  # Try these files in order to find the U-Boot-specific .dtsi include file
> > > > -u_boot_dtsi_options = $(strip $(wildcard $(dir $<)$(basename $(notdir $<))-u-boot.dtsi) \
> > > > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_SOC))-u-boot.dtsi) \
> > > > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_CPU))-u-boot.dtsi) \
> > > > -       $(wildcard $(dir $<)$(subst $\",,$(CONFIG_SYS_VENDOR))-u-boot.dtsi) \
> > > > -       $(wildcard $(dir $<)u-boot.dtsi))
> > > > +UBOOT_DTSI_LOC = $(srctree)/arch/$(ARCH)/dts/
> > >
> > > How about lower case since it is internal. Also we know it is U-Boot,
> > > so perhap  ?
> >
> > Although I just named it after *-u-boot.dtsi, I am fine with dtsi_loc
> > too. So I will use that instead.
>
> I was going to say lets use "uboot_dtsi_loc" so it's both clear what the
> variable does and for future re-syncs.

Okay that makes further sense. I will use it if I don't see any
objection from Simon.

-Sumit

>
> --
> Tom

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:

> Prerquisite
> -----------
> 
> 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

So, I've played with subtree a little and I think this is the right way
forward in these cases. If anyone wants to take a look at how this works
in practice, take a look at:
https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
In that tree I started with the v6.1-dts tag, sync'd all the configs (to
have an example of a normal commit) and then did a merge of each tag
until v6.6-dts, so provide some history. And git log looks like what I
want to see, the squash commit has clear references to what we are
getting and I make a merge commit that says what I did. If you pull the
tree and checkout the branch, all the code is right there already,
nothing further to do. Same with tarball releases. The only thing I
don't like is the size growth there, but we'll reclaim some of it when
we delete our obsolete bindings, and then obsolete dts files.

Maxim, please switch (back, sorry!) to subtree for the next lwIP
patchset and just not in the prerequisite steps what the subtree command
is, and make sure the docs have an example of what future re-sync
"subtree pull" commands should look like. For CI testing, you'll have to
do that to start with and just not include that patch in the ML part.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Simon Glass]

Hi,

On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
>
> > Prerquisite
> > -----------
> >
> > 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
>
> So, I've played with subtree a little and I think this is the right way
> forward in these cases. If anyone wants to take a look at how this works
> in practice, take a look at:
> https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> have an example of a normal commit) and then did a merge of each tag
> until v6.6-dts, so provide some history. And git log looks like what I
> want to see, the squash commit has clear references to what we are
> getting and I make a merge commit that says what I did. If you pull the
> tree and checkout the branch, all the code is right there already,
> nothing further to do. Same with tarball releases. The only thing I
> don't like is the size growth there, but we'll reclaim some of it when
> we delete our obsolete bindings, and then obsolete dts files.

I spent a bit of time with subtree as well, as part of reviewing this
series, using the instructions Sumit provided. It seems OK to me. We
have to accept that it adds code and there will be changes/churn, but
it is not too different to accepting patches on those files within
U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
does support a good proportion of the boards supported by Linux, so I
don't see that as a big cost.

From my experimentation, subtrees seem to have no impact on buildman,
which is great. Am I missing anything?

I still worry about the board-level 'switch' between U-Boot DT and
upstream ones. I believe that should be at the SoC level instead.

>
> Maxim, please switch (back, sorry!) to subtree for the next lwIP
> patchset and just not in the prerequisite steps what the subtree command
> is, and make sure the docs have an example of what future re-sync
> "subtree pull" commands should look like. For CI testing, you'll have to
> do that to start with and just not include that patch in the ML part.

Regards,
Simon

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Sumit Garg]

On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote:
>
> Hi,
>
> On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> >
> > > Prerquisite
> > > -----------
> > >
> > > 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
> >
> > So, I've played with subtree a little and I think this is the right way
> > forward in these cases. If anyone wants to take a look at how this works
> > in practice, take a look at:
> > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > have an example of a normal commit) and then did a merge of each tag
> > until v6.6-dts, so provide some history. And git log looks like what I
> > want to see, the squash commit has clear references to what we are
> > getting and I make a merge commit that says what I did. If you pull the
> > tree and checkout the branch, all the code is right there already,
> > nothing further to do. Same with tarball releases. The only thing I
> > don't like is the size growth there, but we'll reclaim some of it when
> > we delete our obsolete bindings, and then obsolete dts files.
>
> I spent a bit of time with subtree as well, as part of reviewing this
> series, using the instructions Sumit provided. It seems OK to me. We
> have to accept that it adds code and there will be changes/churn, but
> it is not too different to accepting patches on those files within
> U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> does support a good proportion of the boards supported by Linux, so I
> don't see that as a big cost.
>
> From my experimentation, subtrees seem to have no impact on buildman,
> which is great. Am I missing anything?

No it shouldn't cause any regression on existing tools/CI/build
systems. It is just a version controlled way of importing third party
source code as a tarball.

>
> I still worry about the board-level 'switch' between U-Boot DT and
> upstream ones. I believe that should be at the SoC level instead.
>

Probably I wasn't clear enough in my earlier replies but this series
motivates for a SoC level switch only. Patch #7 is essentially a
switch for Amlogic meson-gxbb SoC and its derived boards.

-Sumit

> >
> > Maxim, please switch (back, sorry!) to subtree for the next lwIP
> > patchset and just not in the prerequisite steps what the subtree command
> > is, and make sure the docs have an example of what future re-sync
> > "subtree pull" commands should look like. For CI testing, you'll have to
> > do that to start with and just not include that patch in the ML part.
>
> Regards,
> Simon

Re: [PATCH 4/8] dts: Add alternative location for upstream DTB builds

[Simon Glass]

Hi Sumit,

On Wed, Dec 20, 2023 at 12:01 PM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Hi Simon,
>
> On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Sumit,
> >
> > On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > directory.
> >
> > Also add a new Makefile for arm64.
>
> I suppose you are referring to dts/arch/arm64/Makefile which has been
> added by this patch.

Yes, I just mean that you should mention this in the commit message

>
> >
> > >
> > > This will help easy migration for platforms which currently are compliant
> > > with upstream Linux kernel devicetree files.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > ---
> > >  dts/Kconfig             | 11 +++++++++++
> > >  dts/Makefile            | 17 ++++++++++++++---
> > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > >  create mode 100644 dts/arch/arm64/Makefile
> > >
> > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > index 00c0aeff893..96396f12b67 100644
> > > --- a/dts/Kconfig
> > > +++ b/dts/Kconfig
> > > @@ -85,6 +85,17 @@ config OF_LIVE
> > >           enables a live tree which is available after relocation,
> > >           and can be adjusted as needed.
> > >
> > > +config OF_UPSTREAM
> > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > +       help
> > > +         Traditionally, U-boot platforms used to have their custom devicetree
> >
> > U-Boot
> >
> > (I think I mentioned this, but you thought I said U-boot...but it
> > really is U-Boot). Perhaps grep your patches next time.
>
> Ah, I see. It looks like I missed that bit, and will take care of it
> in the next revision.
>
> >
> > > +         files or copy devicetree files from Linux kernel which are hard to
> > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > +         a regular sync will be maintained every major Linux kernel release
> > > +         cycle. However, platforms can still have some custom u-boot specific
> > > +         bits maintained as part of *-u-boot.dtsi files.
> >
> > I'm a bit nervous about this. It means that boards chose between this
> > dir of the local files. It means there is some effort to switch.
> >
> > I wonder if we could default to using the rebasing thing, with boards
> > having to 'opt out'? So this should be 'default y' ?
>
> Ideally that should be our migration path going forward once we get
> enough boards migrated to use rebasing repo. But at this initial stage
> we have to put some effort on migrating boards to use rebasing
> subtree, although effort should be just adding (given DT bindings
> compliance) following to defconfig (see patch #7):
>
> CONFIG_OF_UPSTREAM=y
> CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
>
> and create a mirrored copy of:
> ../../../devicetree-rebasing/src/arm64/amlogic/ into
> dts/arch/arm64/amlogic/ with modifications to add targets to
> dts/arch/arm64/Makefile.
>
> I am happy to put in that effort but certainly for new board support
> that would like to import DT from Linux it should be the default. That
> stands true for the Qcom platform series for which Caleb is currently
> working on.

The problem I see is that this is board-by-board, so will never
happen. Changing one board (e.g. rockpro64-rk3399) typically involves
changing the .dtsi files it includes (e.g. rk3399.dtsi) so it is
hard/impossible to do one board without doing all.

So this is why I believe the setting should be on an SoC basis, not on
a board basis.

>
> >
> >
> > > +
> > >  choice
> > >         prompt "Provider of DTB for DT control"
> > >         depends on OF_CONTROL
> > > diff --git a/dts/Makefile b/dts/Makefile
> > > index 3437e54033d..8098bf8191a 100644
> > > --- a/dts/Makefile
> > > +++ b/dts/Makefile
> > > @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
> > >  DEVICE_TREE := unset
> > >  endif
> > >
> > > +ifeq ($(CONFIG_OF_UPSTREAM),y)
> > > +ifeq ($(CONFIG_ARM64),y)
> > > +DEVICE_TREE_LOC := dts/arch/arm64
> >
> > dt_dir ?
>
> Okay I will rename it.
>
> >
> > Should we move the arm64 DTs to arch/arm64 ?
>
> IMO, the migration path should be to use rebasing subtree via
> dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from
> arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems
> like a redundant change to me.

I can see that argument, but having two different directory structures
would be confusing.

>
> >
> > What about the subdirs used in Linux?
>
> I hope I have described above regarding how subdirs are mirrored.
> However, have a look at patch #7 for the amlogic/ subdir example.

OK

Regards,
Simon

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Simon Glass]

Hi Sumit,

On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi,
> >
> > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> > >
> > > > Prerquisite
> > > > -----------
> > > >
> > > > 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
> > >
> > > So, I've played with subtree a little and I think this is the right way
> > > forward in these cases. If anyone wants to take a look at how this works
> > > in practice, take a look at:
> > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > > have an example of a normal commit) and then did a merge of each tag
> > > until v6.6-dts, so provide some history. And git log looks like what I
> > > want to see, the squash commit has clear references to what we are
> > > getting and I make a merge commit that says what I did. If you pull the
> > > tree and checkout the branch, all the code is right there already,
> > > nothing further to do. Same with tarball releases. The only thing I
> > > don't like is the size growth there, but we'll reclaim some of it when
> > > we delete our obsolete bindings, and then obsolete dts files.
> >
> > I spent a bit of time with subtree as well, as part of reviewing this
> > series, using the instructions Sumit provided. It seems OK to me. We
> > have to accept that it adds code and there will be changes/churn, but
> > it is not too different to accepting patches on those files within
> > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> > does support a good proportion of the boards supported by Linux, so I
> > don't see that as a big cost.
> >
> > From my experimentation, subtrees seem to have no impact on buildman,
> > which is great. Am I missing anything?
>
> No it shouldn't cause any regression on existing tools/CI/build
> systems. It is just a version controlled way of importing third party
> source code as a tarball.
>
> >
> > I still worry about the board-level 'switch' between U-Boot DT and
> > upstream ones. I believe that should be at the SoC level instead.
> >
>
> Probably I wasn't clear enough in my earlier replies but this series
> motivates for a SoC level switch only. Patch #7 is essentially a
> switch for Amlogic meson-gxbb SoC and its derived boards.

OK good...but that's not quite what I mean. You have a fragment like
this in multiple defconfig files:

+CONFIG_OF_UPSTREAM=y
+CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"

instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the
Kconfig. We should not have to specify the filename like this. It is
laborious and error-prone.

Regards,
Simon

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Sumit Garg]

Hi Simon,

On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Sumit,
>
> On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi,
> > >
> > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> > > >
> > > > > Prerquisite
> > > > > -----------
> > > > >
> > > > > 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
> > > >
> > > > So, I've played with subtree a little and I think this is the right way
> > > > forward in these cases. If anyone wants to take a look at how this works
> > > > in practice, take a look at:
> > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > > > have an example of a normal commit) and then did a merge of each tag
> > > > until v6.6-dts, so provide some history. And git log looks like what I
> > > > want to see, the squash commit has clear references to what we are
> > > > getting and I make a merge commit that says what I did. If you pull the
> > > > tree and checkout the branch, all the code is right there already,
> > > > nothing further to do. Same with tarball releases. The only thing I
> > > > don't like is the size growth there, but we'll reclaim some of it when
> > > > we delete our obsolete bindings, and then obsolete dts files.
> > >
> > > I spent a bit of time with subtree as well, as part of reviewing this
> > > series, using the instructions Sumit provided. It seems OK to me. We
> > > have to accept that it adds code and there will be changes/churn, but
> > > it is not too different to accepting patches on those files within
> > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> > > does support a good proportion of the boards supported by Linux, so I
> > > don't see that as a big cost.
> > >
> > > From my experimentation, subtrees seem to have no impact on buildman,
> > > which is great. Am I missing anything?
> >
> > No it shouldn't cause any regression on existing tools/CI/build
> > systems. It is just a version controlled way of importing third party
> > source code as a tarball.
> >
> > >
> > > I still worry about the board-level 'switch' between U-Boot DT and
> > > upstream ones. I believe that should be at the SoC level instead.
> > >
> >
> > Probably I wasn't clear enough in my earlier replies but this series
> > motivates for a SoC level switch only. Patch #7 is essentially a
> > switch for Amlogic meson-gxbb SoC and its derived boards.
>
> OK good...but that's not quite what I mean. You have a fragment like
> this in multiple defconfig files:
>
> +CONFIG_OF_UPSTREAM=y
> +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
>
> instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the
> Kconfig.

Okay I got your point. It makes sense to me. I will do that for v3.

> We should not have to specify the filename like this. It is
> laborious and error-prone.

The only differentiation in naming here is just silicon vendor prefix
addition (amlogic/ in this case). The reason for this being that I
just want to mirror the whole silicon vendor directory from DT
rebasing rather than mirroring individual DT files. Given this do you
have any better alternatives?

-Sumit

Re: [PATCH 4/8] dts: Add alternative location for upstream DTB builds

[Sumit Garg]

On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Sumit,
>
> On Wed, Dec 20, 2023 at 12:01 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Sumit,
> > >
> > > On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
> > > >
> > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > directory.
> > >
> > > Also add a new Makefile for arm64.
> >
> > I suppose you are referring to dts/arch/arm64/Makefile which has been
> > added by this patch.
>
> Yes, I just mean that you should mention this in the commit message
>

Okay, I will append the commit message.

> >
> > >
> > > >
> > > > This will help easy migration for platforms which currently are compliant
> > > > with upstream Linux kernel devicetree files.
> > > >
> > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > ---
> > > >  dts/Kconfig             | 11 +++++++++++
> > > >  dts/Makefile            | 17 ++++++++++++++---
> > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > >  create mode 100644 dts/arch/arm64/Makefile
> > > >
> > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > index 00c0aeff893..96396f12b67 100644
> > > > --- a/dts/Kconfig
> > > > +++ b/dts/Kconfig
> > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > >           enables a live tree which is available after relocation,
> > > >           and can be adjusted as needed.
> > > >
> > > > +config OF_UPSTREAM
> > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > +       help
> > > > +         Traditionally, U-boot platforms used to have their custom devicetree
> > >
> > > U-Boot
> > >
> > > (I think I mentioned this, but you thought I said U-boot...but it
> > > really is U-Boot). Perhaps grep your patches next time.
> >
> > Ah, I see. It looks like I missed that bit, and will take care of it
> > in the next revision.
> >
> > >
> > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > +         a regular sync will be maintained every major Linux kernel release
> > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > +         bits maintained as part of *-u-boot.dtsi files.
> > >
> > > I'm a bit nervous about this. It means that boards chose between this
> > > dir of the local files. It means there is some effort to switch.
> > >
> > > I wonder if we could default to using the rebasing thing, with boards
> > > having to 'opt out'? So this should be 'default y' ?
> >
> > Ideally that should be our migration path going forward once we get
> > enough boards migrated to use rebasing repo. But at this initial stage
> > we have to put some effort on migrating boards to use rebasing
> > subtree, although effort should be just adding (given DT bindings
> > compliance) following to defconfig (see patch #7):
> >
> > CONFIG_OF_UPSTREAM=y
> > CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
> >
> > and create a mirrored copy of:
> > ../../../devicetree-rebasing/src/arm64/amlogic/ into
> > dts/arch/arm64/amlogic/ with modifications to add targets to
> > dts/arch/arm64/Makefile.
> >
> > I am happy to put in that effort but certainly for new board support
> > that would like to import DT from Linux it should be the default. That
> > stands true for the Qcom platform series for which Caleb is currently
> > working on.
>
> The problem I see is that this is board-by-board, so will never
> happen. Changing one board (e.g. rockpro64-rk3399) typically involves
> changing the .dtsi files it includes (e.g. rk3399.dtsi) so it is
> hard/impossible to do one board without doing all.
>
> So this is why I believe the setting should be on an SoC basis, not on
> a board basis.

Sure, I will enable OF_UPSTREAM on a per SoC basis.

>
> >
> > >
> > >
> > > > +
> > > >  choice
> > > >         prompt "Provider of DTB for DT control"
> > > >         depends on OF_CONTROL
> > > > diff --git a/dts/Makefile b/dts/Makefile
> > > > index 3437e54033d..8098bf8191a 100644
> > > > --- a/dts/Makefile
> > > > +++ b/dts/Makefile
> > > > @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
> > > >  DEVICE_TREE := unset
> > > >  endif
> > > >
> > > > +ifeq ($(CONFIG_OF_UPSTREAM),y)
> > > > +ifeq ($(CONFIG_ARM64),y)
> > > > +DEVICE_TREE_LOC := dts/arch/arm64
> > >
> > > dt_dir ?
> >
> > Okay I will rename it.
> >
> > >
> > > Should we move the arm64 DTs to arch/arm64 ?
> >
> > IMO, the migration path should be to use rebasing subtree via
> > dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from
> > arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems
> > like a redundant change to me.
>
> I can see that argument, but having two different directory structures
> would be confusing.

I can see your point but U-Boot arch arm64 code is also contained in
arch/arm/. However, I would suggest first migrating to DT rebasing and
then we can do a move for the leftovers (*-u-boot.dtsi and such). A
double move won't add much value.

-Sumit

>
> >
> > >
> > > What about the subdirs used in Linux?
> >
> > I hope I have described above regarding how subdirs are mirrored.
> > However, have a look at patch #7 for the amlogic/ subdir example.
>
> OK
>
> Regards,
> Simon

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Tony Dinh]

Hi Sumit
Hi Simon,

On Tue, Dec 26, 2023 at 2:13 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Hi Simon,
>
> On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Sumit,
> >
> > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> > > > >
> > > > > > Prerquisite
> > > > > > -----------
> > > > > >
> > > > > > 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
> > > > >
> > > > > So, I've played with subtree a little and I think this is the right way
> > > > > forward in these cases. If anyone wants to take a look at how this works
> > > > > in practice, take a look at:
> > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > > > > have an example of a normal commit) and then did a merge of each tag
> > > > > until v6.6-dts, so provide some history. And git log looks like what I
> > > > > want to see, the squash commit has clear references to what we are
> > > > > getting and I make a merge commit that says what I did. If you pull the
> > > > > tree and checkout the branch, all the code is right there already,
> > > > > nothing further to do. Same with tarball releases. The only thing I
> > > > > don't like is the size growth there, but we'll reclaim some of it when
> > > > > we delete our obsolete bindings, and then obsolete dts files.
> > > >
> > > > I spent a bit of time with subtree as well, as part of reviewing this
> > > > series, using the instructions Sumit provided. It seems OK to me. We
> > > > have to accept that it adds code and there will be changes/churn, but
> > > > it is not too different to accepting patches on those files within
> > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> > > > does support a good proportion of the boards supported by Linux, so I
> > > > don't see that as a big cost.
> > > >
> > > > From my experimentation, subtrees seem to have no impact on buildman,
> > > > which is great. Am I missing anything?
> > >
> > > No it shouldn't cause any regression on existing tools/CI/build
> > > systems. It is just a version controlled way of importing third party
> > > source code as a tarball.
> > >
> > > >
> > > > I still worry about the board-level 'switch' between U-Boot DT and
> > > > upstream ones. I believe that should be at the SoC level instead.
> > > >
> > >
> > > Probably I wasn't clear enough in my earlier replies but this series
> > > motivates for a SoC level switch only. Patch #7 is essentially a
> > > switch for Amlogic meson-gxbb SoC and its derived boards.
> >
> > OK good...but that's not quite what I mean. You have a fragment like
> > this in multiple defconfig files:
> >
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
> >
> > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the
> > Kconfig.
>
> Okay I got your point. It makes sense to me. I will do that for v3.
>
> > We should not have to specify the filename like this. It is
> > laborious and error-prone.
>
> The only differentiation in naming here is just silicon vendor prefix
> addition (amlogic/ in this case). The reason for this being that I
> just want to mirror the whole silicon vendor directory from DT
> rebasing rather than mirroring individual DT files. Given this do you
> have any better alternatives?
>

So how do we handle the case where the DTS exists in u-boot, but not
in Linux? For example, the DTS was developed for u-boot first and has
not been accepted in the Linux device tree yet. Can we set in the
board defconfig like:

# CONFIG_OF_UPSTREAM is not set

Would that allow the DTS to remain in arch/<architecture>/dts?

Thanks,
Tony

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Sumit Garg]

Hi Tony,

On Wed, 27 Dec 2023 at 10:11, Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Sumit
> Hi Simon,
>
> On Tue, Dec 26, 2023 at 2:13 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Sumit,
> > >
> > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > >
> > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> > > > > >
> > > > > > > Prerquisite
> > > > > > > -----------
> > > > > > >
> > > > > > > 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
> > > > > >
> > > > > > So, I've played with subtree a little and I think this is the right way
> > > > > > forward in these cases. If anyone wants to take a look at how this works
> > > > > > in practice, take a look at:
> > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > > > > > have an example of a normal commit) and then did a merge of each tag
> > > > > > until v6.6-dts, so provide some history. And git log looks like what I
> > > > > > want to see, the squash commit has clear references to what we are
> > > > > > getting and I make a merge commit that says what I did. If you pull the
> > > > > > tree and checkout the branch, all the code is right there already,
> > > > > > nothing further to do. Same with tarball releases. The only thing I
> > > > > > don't like is the size growth there, but we'll reclaim some of it when
> > > > > > we delete our obsolete bindings, and then obsolete dts files.
> > > > >
> > > > > I spent a bit of time with subtree as well, as part of reviewing this
> > > > > series, using the instructions Sumit provided. It seems OK to me. We
> > > > > have to accept that it adds code and there will be changes/churn, but
> > > > > it is not too different to accepting patches on those files within
> > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> > > > > does support a good proportion of the boards supported by Linux, so I
> > > > > don't see that as a big cost.
> > > > >
> > > > > From my experimentation, subtrees seem to have no impact on buildman,
> > > > > which is great. Am I missing anything?
> > > >
> > > > No it shouldn't cause any regression on existing tools/CI/build
> > > > systems. It is just a version controlled way of importing third party
> > > > source code as a tarball.
> > > >
> > > > >
> > > > > I still worry about the board-level 'switch' between U-Boot DT and
> > > > > upstream ones. I believe that should be at the SoC level instead.
> > > > >
> > > >
> > > > Probably I wasn't clear enough in my earlier replies but this series
> > > > motivates for a SoC level switch only. Patch #7 is essentially a
> > > > switch for Amlogic meson-gxbb SoC and its derived boards.
> > >
> > > OK good...but that's not quite what I mean. You have a fragment like
> > > this in multiple defconfig files:
> > >
> > > +CONFIG_OF_UPSTREAM=y
> > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
> > >
> > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the
> > > Kconfig.
> >
> > Okay I got your point. It makes sense to me. I will do that for v3.
> >
> > > We should not have to specify the filename like this. It is
> > > laborious and error-prone.
> >
> > The only differentiation in naming here is just silicon vendor prefix
> > addition (amlogic/ in this case). The reason for this being that I
> > just want to mirror the whole silicon vendor directory from DT
> > rebasing rather than mirroring individual DT files. Given this do you
> > have any better alternatives?
> >
>
> So how do we handle the case where the DTS exists in u-boot, but not
> in Linux? For example, the DTS was developed for u-boot first and has
> not been accepted in the Linux device tree yet. Can we set in the
> board defconfig like:
>
> # CONFIG_OF_UPSTREAM is not set
>
> Would that allow the DTS to remain in arch/<architecture>/dts?

Yeah that is expected until DTS becomes available in the DT rebasing tree.

-Sumit

>
> Thanks,
> Tony

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Simon Glass]

Hi Sumit,

On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Hi Simon,
>
> On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Sumit,
> >
> > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> > > > >
> > > > > > Prerquisite
> > > > > > -----------
> > > > > >
> > > > > > 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
> > > > >
> > > > > So, I've played with subtree a little and I think this is the right way
> > > > > forward in these cases. If anyone wants to take a look at how this works
> > > > > in practice, take a look at:
> > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > > > > have an example of a normal commit) and then did a merge of each tag
> > > > > until v6.6-dts, so provide some history. And git log looks like what I
> > > > > want to see, the squash commit has clear references to what we are
> > > > > getting and I make a merge commit that says what I did. If you pull the
> > > > > tree and checkout the branch, all the code is right there already,
> > > > > nothing further to do. Same with tarball releases. The only thing I
> > > > > don't like is the size growth there, but we'll reclaim some of it when
> > > > > we delete our obsolete bindings, and then obsolete dts files.
> > > >
> > > > I spent a bit of time with subtree as well, as part of reviewing this
> > > > series, using the instructions Sumit provided. It seems OK to me. We
> > > > have to accept that it adds code and there will be changes/churn, but
> > > > it is not too different to accepting patches on those files within
> > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> > > > does support a good proportion of the boards supported by Linux, so I
> > > > don't see that as a big cost.
> > > >
> > > > From my experimentation, subtrees seem to have no impact on buildman,
> > > > which is great. Am I missing anything?
> > >
> > > No it shouldn't cause any regression on existing tools/CI/build
> > > systems. It is just a version controlled way of importing third party
> > > source code as a tarball.
> > >
> > > >
> > > > I still worry about the board-level 'switch' between U-Boot DT and
> > > > upstream ones. I believe that should be at the SoC level instead.
> > > >
> > >
> > > Probably I wasn't clear enough in my earlier replies but this series
> > > motivates for a SoC level switch only. Patch #7 is essentially a
> > > switch for Amlogic meson-gxbb SoC and its derived boards.
> >
> > OK good...but that's not quite what I mean. You have a fragment like
> > this in multiple defconfig files:
> >
> > +CONFIG_OF_UPSTREAM=y
> > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
> >
> > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the
> > Kconfig.
>
> Okay I got your point. It makes sense to me. I will do that for v3.
>
> > We should not have to specify the filename like this. It is
> > laborious and error-prone.
>
> The only differentiation in naming here is just silicon vendor prefix
> addition (amlogic/ in this case). The reason for this being that I
> just want to mirror the whole silicon vendor directory from DT
> rebasing rather than mirroring individual DT files. Given this do you
> have any better alternatives?

My current opinion is that a better approach would be to move the
files first (in the U-Boot tree). That would be easier if we could
just copy the Linux arch/xxx/boot/dts Makefiles but for now that is
not possible. The Kconfig options for each SoC are similar but there
are various differences.

Having a different layout is just a pain and it will get worse, as
people add new boards, since they need to know to add the correct
directory.

I will see if I can devise a small series to point this in what I
consider to be the right direction, in line with Linux, and the U-Boot
commit 3284c8b8 ("dts: generate multiple device tree blobs").

Regards,
Simon

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5551 bytes --]

On Wed, Dec 27, 2023 at 07:56:26AM +0000, Simon Glass wrote:
> Hi Sumit,
> 
> On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote:
> > >
> > > Hi Sumit,
> > >
> > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > >
> > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> > > > > >
> > > > > > > Prerquisite
> > > > > > > -----------
> > > > > > >
> > > > > > > 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
> > > > > >
> > > > > > So, I've played with subtree a little and I think this is the right way
> > > > > > forward in these cases. If anyone wants to take a look at how this works
> > > > > > in practice, take a look at:
> > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > > > > > have an example of a normal commit) and then did a merge of each tag
> > > > > > until v6.6-dts, so provide some history. And git log looks like what I
> > > > > > want to see, the squash commit has clear references to what we are
> > > > > > getting and I make a merge commit that says what I did. If you pull the
> > > > > > tree and checkout the branch, all the code is right there already,
> > > > > > nothing further to do. Same with tarball releases. The only thing I
> > > > > > don't like is the size growth there, but we'll reclaim some of it when
> > > > > > we delete our obsolete bindings, and then obsolete dts files.
> > > > >
> > > > > I spent a bit of time with subtree as well, as part of reviewing this
> > > > > series, using the instructions Sumit provided. It seems OK to me. We
> > > > > have to accept that it adds code and there will be changes/churn, but
> > > > > it is not too different to accepting patches on those files within
> > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> > > > > does support a good proportion of the boards supported by Linux, so I
> > > > > don't see that as a big cost.
> > > > >
> > > > > From my experimentation, subtrees seem to have no impact on buildman,
> > > > > which is great. Am I missing anything?
> > > >
> > > > No it shouldn't cause any regression on existing tools/CI/build
> > > > systems. It is just a version controlled way of importing third party
> > > > source code as a tarball.
> > > >
> > > > >
> > > > > I still worry about the board-level 'switch' between U-Boot DT and
> > > > > upstream ones. I believe that should be at the SoC level instead.
> > > > >
> > > >
> > > > Probably I wasn't clear enough in my earlier replies but this series
> > > > motivates for a SoC level switch only. Patch #7 is essentially a
> > > > switch for Amlogic meson-gxbb SoC and its derived boards.
> > >
> > > OK good...but that's not quite what I mean. You have a fragment like
> > > this in multiple defconfig files:
> > >
> > > +CONFIG_OF_UPSTREAM=y
> > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
> > >
> > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the
> > > Kconfig.
> >
> > Okay I got your point. It makes sense to me. I will do that for v3.
> >
> > > We should not have to specify the filename like this. It is
> > > laborious and error-prone.
> >
> > The only differentiation in naming here is just silicon vendor prefix
> > addition (amlogic/ in this case). The reason for this being that I
> > just want to mirror the whole silicon vendor directory from DT
> > rebasing rather than mirroring individual DT files. Given this do you
> > have any better alternatives?
> 
> My current opinion is that a better approach would be to move the
> files first (in the U-Boot tree). That would be easier if we could
> just copy the Linux arch/xxx/boot/dts Makefiles but for now that is
> not possible. The Kconfig options for each SoC are similar but there
> are various differences.
> 
> Having a different layout is just a pain and it will get worse, as
> people add new boards, since they need to know to add the correct
> directory.
> 
> I will see if I can devise a small series to point this in what I
> consider to be the right direction, in line with Linux, and the U-Boot
> commit 3284c8b8 ("dts: generate multiple device tree blobs").

I think we should just go with the approach Sumit has already taken, and
encourage SoC maintainers to migrate sooner rather than later. There's
also nothing stopping people from adding vendor directories under arch/
at that point, and will likely have to happen anyhow for the case of
platforms that aren't yet in the devicetree-rebasing tree. I am hopeful
it won't be as much of an issue as my general feedback will change from
"what kernel release is this dts in?" to "why didn't you set
OF_UPSTREAM and use the existing tree?"

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [PATCH 4/8] dts: Add alternative location for upstream DTB builds

[Simon Glass]

Hi Sumit,

On Tue, Dec 26, 2023 at 10:20 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Sumit,
> >
> > On Wed, Dec 20, 2023 at 12:01 PM Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Wed, 20 Dec 2023 at 10:17, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Sumit,
> > > >
> > > > On Thu, 14 Dec 2023 at 06:52, Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > >
> > > > > Allow platform owners to mirror devicetree files from devitree-rebasing
> > > > > directory into dts/arch/$(ARCH) (special case for dts/arch/arm64). Then
> > > > > build then along with any *-u-boot.dtsi file present in arch/$(ARCH)/dts
> > > > > directory.
> > > >
> > > > Also add a new Makefile for arm64.
> > >
> > > I suppose you are referring to dts/arch/arm64/Makefile which has been
> > > added by this patch.
> >
> > Yes, I just mean that you should mention this in the commit message
> >
>
> Okay, I will append the commit message.
>
> > >
> > > >
> > > > >
> > > > > This will help easy migration for platforms which currently are compliant
> > > > > with upstream Linux kernel devicetree files.
> > > > >
> > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > ---
> > > > >  dts/Kconfig             | 11 +++++++++++
> > > > >  dts/Makefile            | 17 ++++++++++++++---
> > > > >  dts/arch/arm64/Makefile | 14 ++++++++++++++
> > > > >  3 files changed, 39 insertions(+), 3 deletions(-)
> > > > >  create mode 100644 dts/arch/arm64/Makefile
> > > > >
> > > > > diff --git a/dts/Kconfig b/dts/Kconfig
> > > > > index 00c0aeff893..96396f12b67 100644
> > > > > --- a/dts/Kconfig
> > > > > +++ b/dts/Kconfig
> > > > > @@ -85,6 +85,17 @@ config OF_LIVE
> > > > >           enables a live tree which is available after relocation,
> > > > >           and can be adjusted as needed.
> > > > >
> > > > > +config OF_UPSTREAM
> > > > > +       bool "Enable use of devicetree imported from Linux kernel release"
> > > > > +       help
> > > > > +         Traditionally, U-boot platforms used to have their custom devicetree
> > > >
> > > > U-Boot
> > > >
> > > > (I think I mentioned this, but you thought I said U-boot...but it
> > > > really is U-Boot). Perhaps grep your patches next time.
> > >
> > > Ah, I see. It looks like I missed that bit, and will take care of it
> > > in the next revision.
> > >
> > > >
> > > > > +         files or copy devicetree files from Linux kernel which are hard to
> > > > > +         maintain and can usually get out-of-sync from Linux kernel. This
> > > > > +         option enables platforms to migrate to devicetree-rebasing repo where
> > > > > +         a regular sync will be maintained every major Linux kernel release
> > > > > +         cycle. However, platforms can still have some custom u-boot specific
> > > > > +         bits maintained as part of *-u-boot.dtsi files.
> > > >
> > > > I'm a bit nervous about this. It means that boards chose between this
> > > > dir of the local files. It means there is some effort to switch.
> > > >
> > > > I wonder if we could default to using the rebasing thing, with boards
> > > > having to 'opt out'? So this should be 'default y' ?
> > >
> > > Ideally that should be our migration path going forward once we get
> > > enough boards migrated to use rebasing repo. But at this initial stage
> > > we have to put some effort on migrating boards to use rebasing
> > > subtree, although effort should be just adding (given DT bindings
> > > compliance) following to defconfig (see patch #7):
> > >
> > > CONFIG_OF_UPSTREAM=y
> > > CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-nanopi-k2"
> > >
> > > and create a mirrored copy of:
> > > ../../../devicetree-rebasing/src/arm64/amlogic/ into
> > > dts/arch/arm64/amlogic/ with modifications to add targets to
> > > dts/arch/arm64/Makefile.
> > >
> > > I am happy to put in that effort but certainly for new board support
> > > that would like to import DT from Linux it should be the default. That
> > > stands true for the Qcom platform series for which Caleb is currently
> > > working on.
> >
> > The problem I see is that this is board-by-board, so will never
> > happen. Changing one board (e.g. rockpro64-rk3399) typically involves
> > changing the .dtsi files it includes (e.g. rk3399.dtsi) so it is
> > hard/impossible to do one board without doing all.
> >
> > So this is why I believe the setting should be on an SoC basis, not on
> > a board basis.
>
> Sure, I will enable OF_UPSTREAM on a per SoC basis.
>
> >
> > >
> > > >
> > > >
> > > > > +
> > > > >  choice
> > > > >         prompt "Provider of DTB for DT control"
> > > > >         depends on OF_CONTROL
> > > > > diff --git a/dts/Makefile b/dts/Makefile
> > > > > index 3437e54033d..8098bf8191a 100644
> > > > > --- a/dts/Makefile
> > > > > +++ b/dts/Makefile
> > > > > @@ -10,10 +10,20 @@ ifeq ($(DEVICE_TREE),)
> > > > >  DEVICE_TREE := unset
> > > > >  endif
> > > > >
> > > > > +ifeq ($(CONFIG_OF_UPSTREAM),y)
> > > > > +ifeq ($(CONFIG_ARM64),y)
> > > > > +DEVICE_TREE_LOC := dts/arch/arm64
> > > >
> > > > dt_dir ?
> > >
> > > Okay I will rename it.
> > >
> > > >
> > > > Should we move the arm64 DTs to arch/arm64 ?
> > >
> > > IMO, the migration path should be to use rebasing subtree via
> > > dts/arch/arm64/ and dropping DTs except *-u-boot.dtsi from
> > > arch/$(ARCH)/dts. So moving DTs from arch/arm/ to arch/arm64/ seems
> > > like a redundant change to me.
> >
> > I can see that argument, but having two different directory structures
> > would be confusing.
>
> I can see your point but U-Boot arch arm64 code is also contained in
> arch/arm/. However, I would suggest first migrating to DT rebasing and
> then we can do a move for the leftovers (*-u-boot.dtsi and such). A
> double move won't add much value.

OK, so long as you are planning to do that next?

Regards,
Simon

Re: [PATCH 0/8] An effort to bring DT bindings compliance within U-boot

[Simon Glass]

Hi Tom,

On Wed, Dec 27, 2023 at 1:37 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Dec 27, 2023 at 07:56:26AM +0000, Simon Glass wrote:
> > Hi Sumit,
> >
> > On Tue, Dec 26, 2023 at 10:06 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > On Tue, 26 Dec 2023 at 15:17, Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > Hi Sumit,
> > > >
> > > > On Fri, Dec 22, 2023 at 5:34 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > > > >
> > > > > On Thu, 21 Dec 2023 at 20:48, Simon Glass <sjg@chromium.org> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Thu, Dec 21, 2023 at 3:03 PM Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Thu, Dec 14, 2023 at 07:20:55PM +0530, Sumit Garg wrote:
> > > > > > >
> > > > > > > > Prerquisite
> > > > > > > > -----------
> > > > > > > >
> > > > > > > > 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
> > > > > > >
> > > > > > > So, I've played with subtree a little and I think this is the right way
> > > > > > > forward in these cases. If anyone wants to take a look at how this works
> > > > > > > in practice, take a look at:
> > > > > > > https://source.denx.de/u-boot/u-boot/-/commits/WIP/u-boot-with-devicetree-rebasing-since-v6.1/?ref_type=heads
> > > > > > > In that tree I started with the v6.1-dts tag, sync'd all the configs (to
> > > > > > > have an example of a normal commit) and then did a merge of each tag
> > > > > > > until v6.6-dts, so provide some history. And git log looks like what I
> > > > > > > want to see, the squash commit has clear references to what we are
> > > > > > > getting and I make a merge commit that says what I did. If you pull the
> > > > > > > tree and checkout the branch, all the code is right there already,
> > > > > > > nothing further to do. Same with tarball releases. The only thing I
> > > > > > > don't like is the size growth there, but we'll reclaim some of it when
> > > > > > > we delete our obsolete bindings, and then obsolete dts files.
> > > > > >
> > > > > > I spent a bit of time with subtree as well, as part of reviewing this
> > > > > > series, using the instructions Sumit provided. It seems OK to me. We
> > > > > > have to accept that it adds code and there will be changes/churn, but
> > > > > > it is not too different to accepting patches on those files within
> > > > > > U-Boot. We will bring in files which U-Boot doesn't use, but U-Boot
> > > > > > does support a good proportion of the boards supported by Linux, so I
> > > > > > don't see that as a big cost.
> > > > > >
> > > > > > From my experimentation, subtrees seem to have no impact on buildman,
> > > > > > which is great. Am I missing anything?
> > > > >
> > > > > No it shouldn't cause any regression on existing tools/CI/build
> > > > > systems. It is just a version controlled way of importing third party
> > > > > source code as a tarball.
> > > > >
> > > > > >
> > > > > > I still worry about the board-level 'switch' between U-Boot DT and
> > > > > > upstream ones. I believe that should be at the SoC level instead.
> > > > > >
> > > > >
> > > > > Probably I wasn't clear enough in my earlier replies but this series
> > > > > motivates for a SoC level switch only. Patch #7 is essentially a
> > > > > switch for Amlogic meson-gxbb SoC and its derived boards.
> > > >
> > > > OK good...but that's not quite what I mean. You have a fragment like
> > > > this in multiple defconfig files:
> > > >
> > > > +CONFIG_OF_UPSTREAM=y
> > > > +CONFIG_DEFAULT_DEVICE_TREE="amlogic/meson-gxbb-odroidc2"
> > > >
> > > > instead, OF_UPSTREAM should be enabled via 'imply' for the SoC, in the
> > > > Kconfig.
> > >
> > > Okay I got your point. It makes sense to me. I will do that for v3.
> > >
> > > > We should not have to specify the filename like this. It is
> > > > laborious and error-prone.
> > >
> > > The only differentiation in naming here is just silicon vendor prefix
> > > addition (amlogic/ in this case). The reason for this being that I
> > > just want to mirror the whole silicon vendor directory from DT
> > > rebasing rather than mirroring individual DT files. Given this do you
> > > have any better alternatives?
> >
> > My current opinion is that a better approach would be to move the
> > files first (in the U-Boot tree). That would be easier if we could
> > just copy the Linux arch/xxx/boot/dts Makefiles but for now that is
> > not possible. The Kconfig options for each SoC are similar but there
> > are various differences.
> >
> > Having a different layout is just a pain and it will get worse, as
> > people add new boards, since they need to know to add the correct
> > directory.
> >
> > I will see if I can devise a small series to point this in what I
> > consider to be the right direction, in line with Linux, and the U-Boot
> > commit 3284c8b8 ("dts: generate multiple device tree blobs").
>
> I think we should just go with the approach Sumit has already taken, and
> encourage SoC maintainers to migrate sooner rather than later. There's
> also nothing stopping people from adding vendor directories under arch/
> at that point, and will likely have to happen anyhow for the case of
> platforms that aren't yet in the devicetree-rebasing tree. I am hopeful
> it won't be as much of an issue as my general feedback will change from
> "what kernel release is this dts in?" to "why didn't you set
> OF_UPSTREAM and use the existing tree?"

OK.

But I do want to see a move to using the same dir structure as Linux.

Regards,
Simon