[PATCH v2 0/5] Add Laguna/Tensor G5 SoC and Frankel, Blazer & Mustang boards

[PATCH v2 0/5] Add Laguna/Tensor G5 SoC and Frankel, Blazer & Mustang boards

[Peter Griffin]

Hi folks,

This series adds initial basic support for Laguna (Tensor G5 SoC)
found in Frankel (Pixel 10), Blazer (Pixel 10 Pro) and Mustang (Pixel
10 Pro XL) phones.

Whilst Tensor G1 to G4 SoCs (found in Pixel 6 to Pixel 9 and Pixel
10a) were offshoots from the Samsung Exynos family. Laguna is an
entirely in-house Google designed SoC.

Currently this series adds very basic DT capable of booting to a
initramfs busybox shell and is a v2 of Dougs original submission with
the contentious DT overlay parts removed.

Whilst there is still interest in resolving the DT overlay topic (as
I believe many vendors use this approach). I would like to decouple
merging initial Laguna / Pixel 10  support from resolving that
particular issue. I believe Doug intends to revisit the topic again at
Linux Plumbers in Prague later this year.

In v2 I've updated to use the usual upstream approach of having
individual board files e.g. lga-frankel.dtb, lga-blazer.dtb,
lga-mustang.dtb  the same as gs101-oriole.dtb and gs101-raven.dtb.

It is worth noting, that with what is currently supported upstream there
aren't any known differences versus pre mass production boards yet. So
lga-blazer.dtb boots fine on my EVT 1.1 board with A0 silicon.

At the point where differences do arise, we may need to either add A0
silicon cut and other board variants upstream, or keep upstream as
purely MP/B0 silicon and maintain a separate out of tree DT that uses
overlays for Googlers needing to use pre MP devices. So far at least
with Pixel 6 that wasn't necessary.

Folks interested in trying this out and booting a pure upstream kernel
on their own Pixel 10 device may wish to use the build system and docs
found here:

https://gitlab.com/LinaroLtd/googlelt/pixelscripts

Example commands:

make RUNTARGET=frankel flash
make RUNTARGET=blazer flash

Also in v2 I've added support for ramoops reserved-memory carveout and
tested with `console=pstore` kernel argument. Additionally carveouts
for the ABL bootloader are added (which is used when doing a debug
boot (e.g. after a watchdog timeout). This allows for the extraction
of various logs via fastboot oem commands (bootloader / kernel
logs). The bootloader log can also be quite useful as it contains some
amount of on device debug parsing which can provide some hints after a
crash.

regards,

Peter

Changes in v2:
 * Enable CONFIG_ARCH_GOOGLE in arm64 defconfig
 * Remove all the pre-production dt binding support (EVT, DVT, a0)
 * Remove dtbo overlays and add individual board dts
 * Update to lga-pixel-common naming like gs101-pixel-common
 * Reorder nodes alpha-numerically by the node name
 * Add ramoops reserved-memory (tested with console=pstore)
 * Add reserved-memory for bootloader & gsa logs
 * Add reserved-memory for Android BootLoader ABL (used on Watchdog
   reset to extract boolotader logs / parse breadcrumbs / ramdump etc).
 * Add osc 38.4Mhz fixed-clock

v1: https://lore.kernel.org/lkml/20251111192422.4180216-1-dianders@chromium.org/

To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: André Draszik <andre.draszik@linaro.org>
To: Tudor Ambarus <tudor.ambarus@linaro.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Jiri Slaby <jirislaby@kernel.org>
To: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
To: Krzysztof Kozlowski <krzk@kernel.org>
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Linus Walleij <linusw@kernel.org>
To: Drew Fustini <fustini@kernel.org>
To: Kees Cook <kees@kernel.org>
To: Tony Luck <tony.luck@intel.com>
To: Guilherme G. Piccoli <gpiccoli@igalia.com>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Juan Yescas <jyescas@google.com>
Cc: RD Babiera <rdbabiera@google.com>
Cc: Brian Norris <briannorris@google.com>
Cc: William McVicker <willmcvicker@google.com>
Cc: devicetree@vger.kernel.org
Cc: kernel-team@android.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-serial@vger.kernel.org
Cc: soc@lists.linux.dev

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
Douglas Anderson (3):
      dt-bindings: serial: snps-dw-apb-uart: Add "google,lga-uart"
      arm64: dts: google: Add dts directory for Google-designed silicon
      arm64: dts: google: Add initial dts for frankel/blazer/mustang

Peter Griffin (2):
      dt-bindings: arm: google: Add dt bindings for frankel/blazer/mustang
      arm64: defconfig: enable Tensor G5 SoC family

 Documentation/devicetree/bindings/arm/google.yaml  |  48 ++-
 .../bindings/serial/snps-dw-apb-uart.yaml          |   1 +
 MAINTAINERS                                        |   1 +
 arch/arm64/Kconfig.platforms                       |   8 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/google/Makefile                |   6 +
 arch/arm64/boot/dts/google/lga-blazer.dts          |  15 +
 arch/arm64/boot/dts/google/lga-frankel.dts         |  16 +
 arch/arm64/boot/dts/google/lga-mustang.dts         |  15 +
 arch/arm64/boot/dts/google/lga-pixel-common.dtsi   |  23 ++
 arch/arm64/boot/dts/google/lga.dtsi                | 423 +++++++++++++++++++++
 arch/arm64/configs/defconfig                       |   1 +
 12 files changed, 539 insertions(+), 19 deletions(-)
---
base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
change-id: 20260710-contrib-pg-pixel10-initial-dts-49f5ec657b66

Best regards,
-- 
Peter Griffin <peter.griffin@linaro.org>

[PATCH v2 1/5] dt-bindings: arm: google: Add dt bindings for frankel/blazer/mustang

[Peter Griffin]

Add binding documentation for Tensor G5 SoC (Laguna) which is referred
to in code as "lga" and three of the boards that use the Laguna SoC
Frankel (Pixel 10), Blazer (Pixel 10 Pro) and Mustang (Pixel 10 Pro XL).

Additionally update to use a more efficient and scalable way to express
the various names a SoC is known by.

Co-developed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
Changes in v2:
 * Update ect rule as per Krysztof suggestion
 * Remove all the pre-production variants (EVT, DVT etc)
 * The equivalent patch in the previous submission is
   https://lore.kernel.org/lkml/05c833f0-15bc-4a86-9ac4-daf835fe4393@kernel.org/
   but this is now almost entirely different diff. I've added the
   co-developed-by tag as I've kept the more efficient way to express
   the names a SoC is known by.
---
 Documentation/devicetree/bindings/arm/google.yaml | 48 ++++++++++++++---------
 1 file changed, 29 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
index 99961e5282e5..b5977e20f393 100644
--- a/Documentation/devicetree/bindings/arm/google.yaml
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -13,27 +13,16 @@ description: |
   ARM platforms using SoCs designed by Google branded "Tensor" used in Pixel
   devices.
 
-  Currently upstream this is devices using "gs101" SoC which is found in Pixel
-  6, Pixel 6 Pro and Pixel 6a.
-
-  Google have a few different names for the SoC:
-  - Marketing name ("Tensor")
-  - Codename ("Whitechapel")
-  - SoC ID ("gs101")
-  - Die ID ("S5P9845")
-
-  Likewise there are a couple of names for the actual device
-  - Marketing name ("Pixel 6")
-  - Codename ("Oriole")
-
-  Devicetrees should use the lowercased SoC ID and lowercased board codename,
-  e.g. gs101 and gs101-oriole.
+  Currently upstream this is devices using gs101 SoC which is found in Pixel
+  6, Pixel 6 Pro and Pixel 6a and Laguna SoC canonically referred to as lga
+  found in Pixel 10, Pixel 10 Pro and Pixel 10 Pro XL.
 
 properties:
   $nodename:
     const: '/'
   compatible:
     oneOf:
+      # Google Tensor G1 AKA gs101 AKA whitechapel AKA Die ID S5P9845 boards
       - description: Google Pixel 6 or 6 Pro (Oriole or Raven)
         items:
           - enum:
@@ -41,14 +30,35 @@ properties:
               - google,gs101-raven
           - const: google,gs101
 
-  # Bootloader requires empty ect node to be present
+      # Google Tensor G5 AKA lga (laguna) SoC and boards
+      - description:
+          Google Pixel 10, 10 Pro, 10 Pro XL (Frankel, Blazer,
+          Mustang).
+        items:
+          - enum:
+              - google,lga-blazer
+              - google,lga-frankel
+              - google,lga-mustang
+          - const: google,lga
+
   ect:
     type: object
     additionalProperties: false
 
-required:
-  - ect
-
 additionalProperties: true
 
+allOf:
+  # Bootloader requires empty ect node to be present
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101
+    then:
+      required:
+        - ect
+    else:
+      properties:
+        ect: false
+
 ...

-- 
2.55.0.229.g6434b31f56-goog

[PATCH v2 2/5] dt-bindings: serial: snps-dw-apb-uart: Add "google,lga-uart"

[Peter Griffin]

From: Douglas Anderson <dianders@chromium.org>

The Google Tensor G5 SoC (known as "laguna" and canonically written in
code as "lga") has a UART based on Designware IP. The UART appears to
work reasonably well, at least for serial console, with the existing
driver in Linux. Add a compatible for this UART based on the canonical
"lga" name for this SoC with a fallback to the existing
"snps,dw-apb-uart".

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
index 685c1eceb782..24589466a4be 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -54,6 +54,7 @@ properties:
               - anlogic,dr1v90-uart
               - brcm,bcm11351-dw-apb-uart
               - brcm,bcm21664-dw-apb-uart
+              - google,lga-uart
               - rockchip,px30-uart
               - rockchip,rk1808-uart
               - rockchip,rk3036-uart

-- 
2.55.0.229.g6434b31f56-goog

[PATCH v2 3/5] arm64: dts: google: Add dts directory for Google-designed silicon

[Peter Griffin]

From: Douglas Anderson <dianders@chromium.org>

The first four Google Tensor SoCs were offshoots of Samsung Exynos
SoCs and their device trees were organized under the "exynos/google"
directory. Starting with the Google Tensor G5 SoC in Pixel 10 phones,
Google Tensor SoCs are now of Google's own design. Add a location in
the tree to store these device tree files.

Changes by Peter Griffin
 * update config symbol help with at least 4 lines to avoid checkpatch
   warning

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 MAINTAINERS                         | 1 +
 arch/arm64/Kconfig.platforms        | 8 ++++++++
 arch/arm64/boot/dts/Makefile        | 1 +
 arch/arm64/boot/dts/google/Makefile | 1 +
 4 files changed, 11 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c61ef65d71ef..010d4de81a1b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11012,6 +11012,7 @@ F:	Documentation/devicetree/bindings/phy/google,lga-usb-phy.yaml
 F:	Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
 F:	Documentation/devicetree/bindings/usb/google,lga-dwc3.yaml
 F:	arch/arm64/boot/dts/exynos/google/
+F:	arch/arm64/boot/dts/google/
 F:	drivers/clk/samsung/clk-gs101.c
 F:	drivers/phy/phy-google-usb.c
 F:	drivers/soc/samsung/gs101-pmu.c
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 72c812e76b0b..f83eb4ea878c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -147,6 +147,14 @@ config ARCH_EXYNOS
 	help
 	  This enables support for ARMv8 based Samsung Exynos SoC family.
 
+config ARCH_GOOGLE
+	bool "Google-Designed SoC family"
+	help
+	  This enables support for Google Tensor SoCs starting at the
+	  Google Tensor G5 (Laguna) found in Pixel 10 and later phones.
+	  Tensor G1 to G4 are offshoots of the Exynos family and are
+	  enabled via ARCH_EXYNOS.
+
 config ARCH_K3
 	bool "Texas Instruments Inc. K3 multicore SoC architecture"
 	select SOC_TI
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 98ec8f1b76e4..566f0c863d55 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -18,6 +18,7 @@ subdir-y += cavium
 subdir-y += cix
 subdir-y += exynos
 subdir-y += freescale
+subdir-y += google
 subdir-y += hisilicon
 subdir-y += intel
 subdir-y += lg
diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
new file mode 100644
index 000000000000..a6b187e2d631
--- /dev/null
+++ b/arch/arm64/boot/dts/google/Makefile
@@ -0,0 +1 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)

-- 
2.55.0.229.g6434b31f56-goog

[PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Peter Griffin]

From: Douglas Anderson <dianders@chromium.org>

Add initial device trees for frankel (Pixel 10), blazer (Pixel 10
Pro) and mustang (Pixel 10 Pro XL). These device trees are enough to
boot to a serial prompt using an initramfs.

Currently only Laguna B0 silicon found in mass production phones is
officially supported. Further revisions such as A0 silicon and EVT
devices maybe added in the future if they are useful. As of today,
these device trees boot fine on EVT devices with A0 silicon.

Many things can be noted about these device trees:

1. Even newer versions of the bootloader will still error out if they
   don't find a UFS node to add calibration data to. Until UFS is
   supported, we provide a bogus UFS node for the bootloader. While
   the bootloader could be changed, there is no long-term benefit
   since eventually the device tree will have a UFS node.
2. They purposely choose to use the full 64-bit address and size cells
   for the root node and the `soc@0` node. Although I haven't tested
   the need for this, I presume the arguments made in
   commit bede7d2dc8f3 ("arm64: dts: qcom: sdm845: Increase address
   and size cells for soc") would apply here.
3. Though it looks as if the UART is never enabled, the bootloader
   knows to enable the UART when the console is turned on. Baud rate
   is configurable in the bootloader so is never hardcoded in the
   device tree.

Changes by Peter Griffin:
 - Remove dtbo overlay approach and add individual board dts
 - Update to lga-pixel-common naming like gs101-pixel-common
 - Reorder nodes alpha-numerically by the node name
 - Add ramoops reserved-memory (tested with console=pstore)
 - Add reserved-memory for bootloader & gsa logs
 - Add reserved-memory for Android BootLoader ABL (used on Watchdog
   reset to extract boolotader logs / parse breadcrumbs / ramdump etc).
 - Add osc 38.4Mhz fixed-clock

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Co-developed-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
Changes in v2 (by Peter Griffin):
 * Remove dtbo overlay approach and add individual board dts
 * Update to lga-pixel-common naming like gs101-pixel-common
 * Reorder nodes alpha-numerically by the node name
 * Add ramoops reserved-memory (tested with console=pstore)
 * Add reserved-memory for bootloader & gsa logs
 * Add reserved-memory for Android BootLoader ABL (used on Watchdog
 reset to extract boolotader logs / parse breadcrumbs / ramdump etc).
 * Add osc 38.4Mhz fixed-clock
---
 arch/arm64/boot/dts/google/Makefile              |   5 +
 arch/arm64/boot/dts/google/lga-blazer.dts        |  15 +
 arch/arm64/boot/dts/google/lga-frankel.dts       |  16 +
 arch/arm64/boot/dts/google/lga-mustang.dts       |  15 +
 arch/arm64/boot/dts/google/lga-pixel-common.dtsi |  23 ++
 arch/arm64/boot/dts/google/lga.dtsi              | 423 +++++++++++++++++++++++
 6 files changed, 497 insertions(+)

diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
index a6b187e2d631..4e833b2561e0 100644
--- a/arch/arm64/boot/dts/google/Makefile
+++ b/arch/arm64/boot/dts/google/Makefile
@@ -1 +1,6 @@
 # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+
+dtb-$(CONFIG_ARCH_GOOGLE) += \
+	lga-blazer.dtb \
+	lga-frankel.dtb \
+	lga-mustang.dtb
diff --git a/arch/arm64/boot/dts/google/lga-blazer.dts b/arch/arm64/boot/dts/google/lga-blazer.dts
new file mode 100644
index 000000000000..0894606624f8
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-blazer.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Blazer Device Tree (Pixel 10 Pro)
+ *
+ * Copyright 2021-2023 Google LLC
+ */
+
+/dts-v1/;
+
+#include "lga-pixel-common.dtsi"
+
+/ {
+	model = "Blazer";
+	compatible = "google,lga-blazer", "google,lga";
+};
diff --git a/arch/arm64/boot/dts/google/lga-frankel.dts b/arch/arm64/boot/dts/google/lga-frankel.dts
new file mode 100644
index 000000000000..57df197a544f
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-frankel.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Frankel Device Tree (Pixel 10)
+ *
+ * Copyright 2021-2023 Google LLC
+ */
+
+/dts-v1/;
+
+#include "lga-pixel-common.dtsi"
+
+/ {
+	model = "Frankel";
+	compatible = "google,lga-frankel", "google,lga";
+};
+
diff --git a/arch/arm64/boot/dts/google/lga-mustang.dts b/arch/arm64/boot/dts/google/lga-mustang.dts
new file mode 100644
index 000000000000..6ac0b5ef22ff
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-mustang.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Mustang Device Tree (Pixel 10 Pro XL)
+ *
+ * Copyright 2021-2023 Google LLC
+ */
+
+/dts-v1/;
+
+#include "lga-pixel-common.dtsi"
+
+/ {
+	model = "Mustang";
+	compatible = "google,lga-mustang", "google,lga";
+};
diff --git a/arch/arm64/boot/dts/google/lga-pixel-common.dtsi b/arch/arm64/boot/dts/google/lga-pixel-common.dtsi
new file mode 100644
index 000000000000..57c318ab44c9
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-pixel-common.dtsi
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Google Pixel 10 family common dtsi.
+ *
+ * Copyright 2024-2025 Google LLC.
+ */
+
+#include "lga.dtsi"
+
+&{/} {
+	chosen {
+		stdout-path = "serial0";
+	};
+
+	aliases {
+		serial0 = "/soc@0/serial@db62000";	/* &lsion_cli16_uart */
+		ufs0 = "/ufs-placeholder";		/* &ufs - TODO "/soc@0/ufs@3c400000" */
+	};
+};
+
+&osc {
+	clock-frequency = <38400000>;
+};
diff --git a/arch/arm64/boot/dts/google/lga.dtsi b/arch/arm64/boot/dts/google/lga.dtsi
new file mode 100644
index 000000000000..343156a8c039
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga.dtsi
@@ -0,0 +1,423 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Google Tensor G5 (laguna) SoC rev B0
+ *
+ * Copyright 2024-2025 Google LLC.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/ {
+	#address-cells = <2>;
+	#size-cells = <2>;
+	interrupt-parent = <&gic>;
+
+	osc: clock-38400000 {
+		compatible = "fixed-clock";
+		#clock-cells = <0>;
+	};
+
+	cpus: cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		hayes_0: cpu@0 {
+			compatible = "arm,cortex-a520";
+			reg = <0x000>;
+
+			#cooling-cells = <2>;
+			capacity-dmips-mhz = <258>;
+			device_type = "cpu";
+			enable-method = "psci";
+			power-domain-names = "psci";
+			power-domains = <&cpu_pd0>;
+		};
+
+		hayes_1: cpu@100 {
+			compatible = "arm,cortex-a520";
+			reg = <0x100>;
+
+			#cooling-cells = <2>;
+			capacity-dmips-mhz = <258>;
+			device_type = "cpu";
+			enable-method = "psci";
+			power-domain-names = "psci";
+			power-domains = <&cpu_pd1>;
+		};
+
+		hunter_0: cpu@200 {
+			compatible = "arm,cortex-a725";
+			reg = <0x200>;
+
+			#cooling-cells = <2>;
+			capacity-dmips-mhz = <891>;
+			device_type = "cpu";
+			enable-method = "psci";
+			power-domain-names = "psci";
+			power-domains = <&cpu_pd2>;
+		};
+
+		hunter_1: cpu@300 {
+			compatible = "arm,cortex-a725";
+			reg = <0x300>;
+
+			#cooling-cells = <2>;
+			capacity-dmips-mhz = <891>;
+			device_type = "cpu";
+			enable-method = "psci";
+			power-domain-names = "psci";
+			power-domains = <&cpu_pd3>;
+		};
+
+		hunter_2: cpu@400 {
+			compatible = "arm,cortex-a725";
+			reg = <0x400>;
+
+			#cooling-cells = <2>;
+			capacity-dmips-mhz = <891>;
+			device_type = "cpu";
+			enable-method = "psci";
+			power-domain-names = "psci";
+			power-domains = <&cpu_pd4>;
+		};
+
+		hunter_3: cpu@500 {
+			compatible = "arm,cortex-a725";
+			reg = <0x500>;
+
+			#cooling-cells = <2>;
+			capacity-dmips-mhz = <891>;
+			device_type = "cpu";
+			enable-method = "psci";
+			power-domain-names = "psci";
+			power-domains = <&cpu_pd5>;
+		};
+
+		hunter_4: cpu@600 {
+			compatible = "arm,cortex-a725";
+			reg = <0x600>;
+
+			#cooling-cells = <2>;
+			capacity-dmips-mhz = <891>;
+			device_type = "cpu";
+			enable-method = "psci";
+			power-domain-names = "psci";
+			power-domains = <&cpu_pd6>;
+		};
+
+		hunterelp_0: cpu@700 {
+			compatible = "arm,cortex-x4";
+			reg = <0x700>;
+
+			#cooling-cells = <2>;
+			capacity-dmips-mhz = <1024>;
+			device_type = "cpu";
+			enable-method = "psci";
+			power-domain-names = "psci";
+			power-domains = <&cpu_pd7>;
+		};
+
+		cpu-map {
+			cluster0 {
+				core0 {
+					cpu = <&hayes_0>;
+				};
+				core1 {
+					cpu = <&hayes_1>;
+				};
+				core2 {
+					cpu = <&hunter_0>;
+				};
+				core3 {
+					cpu = <&hunter_1>;
+				};
+				core4 {
+					cpu = <&hunter_2>;
+				};
+				core5 {
+					cpu = <&hunter_3>;
+				};
+				core6 {
+					cpu = <&hunter_4>;
+				};
+				core7 {
+					cpu = <&hunterelp_0>;
+				};
+			};
+		};
+
+		idle-states {
+			entry-method = "psci";
+
+			cpu_lit_c2: cpu-lit-c2 {
+				compatible = "arm,idle-state";
+
+				entry-latency-us = <132>;
+				exit-latency-us = <296>;
+				min-residency-us = <3610>;
+
+				idle-state-name = "cpu-lit-c2";
+				local-timer-stop;
+
+				arm,psci-suspend-param = <0x40000003>;
+			};
+
+			cpu_mid1_c2: cpu-mid1-c2 {
+				compatible = "arm,idle-state";
+
+				entry-latency-us = <130>;
+				exit-latency-us = <274>;
+				min-residency-us = <2720>;
+
+				idle-state-name = "cpu-mid1-c2";
+				local-timer-stop;
+
+				arm,psci-suspend-param = <0x40000003>;
+			};
+
+			cpu_mid2_c2: cpu-mid2-c2 {
+				compatible = "arm,idle-state";
+
+				entry-latency-us = <130>;
+				exit-latency-us = <274>;
+				min-residency-us = <2720>;
+
+				idle-state-name = "cpu-mid2-c2";
+				local-timer-stop;
+
+				arm,psci-suspend-param = <0x40000003>;
+			};
+
+			cpu_big_c2: cpu-big-c2 {
+				compatible = "arm,idle-state";
+
+				entry-latency-us = <110>;
+				exit-latency-us = <413>;
+				min-residency-us = <3950>;
+
+				idle-state-name = "cpu-big-c2";
+				local-timer-stop;
+
+				arm,psci-suspend-param = <0x40000003>;
+			};
+		};
+
+		domain-idle-states {
+			cluster_1_c3: cluster-1-c3 {
+				compatible = "domain-idle-state";
+
+				entry-latency-us = <325>;
+				exit-latency-us = <553>;
+				min-residency-us = <10000>;
+
+				idle-state-name = "cluster-1-c3";
+
+				arm,psci-suspend-param = <0x40010033>;
+			};
+
+			cluster_2_c3: cluster-2-c3 {
+				compatible = "domain-idle-state";
+
+				entry-latency-us = <345>;
+				exit-latency-us = <673>;
+				min-residency-us = <10000>;
+
+				idle-state-name = "cluster-2-c3";
+
+				arm,psci-suspend-param = <0x40010033>;
+			};
+
+			cluster_c4_deep: cluster-c4-deep {
+				compatible = "domain-idle-state";
+
+				entry-latency-us = <510>;
+				exit-latency-us = <1027>;
+				min-residency-us = <10000>;
+
+				idle-state-name = "cluster-c4-deep";
+
+				arm,psci-suspend-param = <0x40020333>;
+			};
+		};
+	};
+
+	memory: memory@80000000 {
+		device_type = "memory";
+		/* We expect the bootloader to fill in the size */
+		reg = <0x0 0x80000000 0x0 0x0>;
+	};
+
+	psci {
+		compatible = "arm,psci-1.0";
+		method = "smc";
+
+		cpu_pd0: power-domain-cpu0 {
+			#power-domain-cells = <0>;
+			domain-idle-states = <&cpu_lit_c2>;
+			power-domains = <&cpu_top_cl>;
+		};
+
+		cpu_pd1: power-domain-cpu1 {
+			#power-domain-cells = <0>;
+			domain-idle-states =  <&cpu_lit_c2>;
+			power-domains = <&cpu_top_cl>;
+		};
+
+		cpu_pd2: power-domain-cpu2 {
+			#power-domain-cells = <0>;
+			domain-idle-states =  <&cpu_mid1_c2>;
+			power-domains = <&cpucl1>;
+		};
+
+		cpu_pd3: power-domain-cpu3 {
+			#power-domain-cells = <0>;
+			domain-idle-states =  <&cpu_mid1_c2>;
+			power-domains = <&cpucl1>;
+		};
+
+		cpu_pd4: power-domain-cpu4 {
+			#power-domain-cells = <0>;
+			domain-idle-states =  <&cpu_mid1_c2>;
+			power-domains = <&cpucl1>;
+		};
+
+		cpu_pd5: power-domain-cpu5 {
+			#power-domain-cells = <0>;
+			domain-idle-states =  <&cpu_mid2_c2>;
+			power-domains = <&cpucl2>;
+		};
+
+		cpu_pd6: power-domain-cpu6 {
+			#power-domain-cells = <0>;
+			domain-idle-states =  <&cpu_mid2_c2>;
+			power-domains = <&cpucl2>;
+		};
+
+		cpu_pd7: power-domain-cpu7 {
+			#power-domain-cells = <0>;
+			domain-idle-states =  <&cpu_big_c2>;
+			power-domains = <&cpucl2>;
+		};
+
+		cpucl1: power-domain-cluster-1 {
+			#power-domain-cells = <0>;
+			domain-idle-states = <&cluster_1_c3>;
+			power-domains = <&cpu_top_cl>;
+		};
+
+		cpucl2: power-domain-cluster-2 {
+			#power-domain-cells = <0>;
+			domain-idle-states = <&cluster_2_c3>;
+			power-domains = <&cpu_top_cl>;
+		};
+
+		cpu_top_cl: power-domain-top-cluster {
+			#power-domain-cells = <0>;
+			domain-idle-states = <&cluster_c4_deep>;
+		};
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/*
+		 * Store ramoops at a known location in DRAM, for access by the ABL
+		 * following a crash-reset.
+		 */
+		ramoops@95200000 {
+			compatible = "ramoops";
+			reg = <0x0 0x95200000 0x0 0x400000>;
+			console-size = <0x200000>;
+			pmsg-size = <0x200000>;
+		};
+
+		/* bootloader logs */
+		bldr_log_reserved: bldr-log-reserved@95600000 {
+			reg = <0x0 0x95600000 0x0 0x100000>;
+			no-map;
+		};
+
+		/* gsa logs */
+		gsa_reserved_log: gsa-reserved-log@a61b0000 {
+			reg = <0x0 0xa61b0000 0x0 0x00004000>;
+			no-map;
+		};
+
+		/* Android BootLoader (ABL) for ramdump/coredump processing */
+		abl@be000000 {
+			reg = <0x0 0xbe000000 0x0 0x1000000>;
+			no-map;
+		};
+	};
+
+	soc: soc@0 {
+		compatible = "simple-bus";
+		ranges = <0 0 0 0 0x10 0>;
+
+		dma-ranges = <0 0 0 0 0x10 0>;
+
+		#address-cells = <2>;
+		#size-cells = <2>;
+
+		gic: interrupt-controller@5880000 {
+			compatible = "arm,gic-v3";
+			reg = <0 0x05880000 0 0x10000>,
+			      <0 0x05900000 0 0x200000>;
+			ranges;
+
+			#address-cells = <2>;
+			#size-cells = <2>;
+
+			#interrupt-cells = <4>;
+			interrupt-controller;
+			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+
+			ppi-partitions {
+				ppi_cluster0: interrupt-partition-0 {
+					affinity = <&hayes_0 &hayes_1
+						    &hunter_0 &hunter_1 &hunter_2
+						    &hunter_3 &hunter_4>;
+				};
+
+				ppi_cluster1: interrupt-partition-1 {
+					affinity = <&hunterelp_0>;
+				};
+			};
+		};
+
+		lsion_cli16_uart: serial@db62000 {
+			compatible = "google,lga-uart", "snps,dw-apb-uart";
+			reg = <0 0x0db62000 0 0x100>;
+
+			clock-frequency = <200000000>;
+			interrupts = <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH 0>;
+			reg-io-width = <4>;
+			reg-shift = <2>;
+
+			status = "disabled";
+		};
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts =
+			<GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
+			<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
+			<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
+			<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>;
+	};
+
+	/*
+	 * The Pixel bootloader considers it a fatal error if it doesn't find
+	 * a `ufs0` alias so it can add calibration data to the node. Until
+	 * the proper UFS controller node is added under the SoC, create a
+	 * temporary node to make the bootloader happy.
+	 */
+	ufs: ufs-placeholder {
+	};
+};

-- 
2.55.0.229.g6434b31f56-goog

[PATCH v2 5/5] arm64: defconfig: enable Tensor G5 SoC family

[Peter Griffin]

Enable the Google Tensor G5 (Laguna) SoC family in the arm64
defconfig. This SoC family is found in Pixel 10 and later phones.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f4dfd0cc853c..930a4f27ee56 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -50,6 +50,7 @@ CONFIG_ARCH_BLAIZE=y
 CONFIG_ARCH_BST=y
 CONFIG_ARCH_CIX=y
 CONFIG_ARCH_EXYNOS=y
+CONFIG_ARCH_GOOGLE=y
 CONFIG_ARCH_SPARX5=y
 CONFIG_ARCH_K3=y
 CONFIG_ARCH_LG1K=y

-- 
2.55.0.229.g6434b31f56-goog

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Invalid use of GIC_CPU_MASK_SIMPLE(1) in a GICv3 interrupt specifier.
--

--- Patch [4]: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang ---
commit 70ad3c51746ae3a6716daf5117667c85c92e2de0
Author: Douglas Anderson <dianders@chromium.org>

arm64: dts: google: Add initial dts for frankel/blazer/mustang

Add initial device trees for frankel (Pixel 10), blazer (Pixel 10
Pro) and mustang (Pixel 10 Pro XL). These device trees are enough to
boot to a serial prompt using an initramfs.

> diff --git a/arch/arm64/boot/dts/google/lga.dtsi b/arch/arm64/boot/dts/google/lga.dtsi
> new file mode 100644
> index 0000000000000..343156a8c0390
> --- /dev/null
> +++ b/arch/arm64/boot/dts/google/lga.dtsi

[ ... ]

> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts =
> +			<GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
> +			<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
> +			<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
> +			<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>;

[Severity: Low]
Does this incorrectly use GIC_CPU_MASK_SIMPLE(1) for a GICv3 interrupt controller?

Since this device tree uses a GICv3 controller, the CPU mask in the flags cell 
for PPI interrupts is deprecated. While the Linux kernel dynamically masks this 
out, other operating systems or hypervisors consuming this device tree might 
strictly evaluate it and incorrectly limit the per-CPU timer to CPU 0, or 
reject the device tree outright.

> +	};

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260722-contrib-pg-pixel10-initial-dts-v2-0-3abae9717feb@linaro.org?part=4

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Brian Norris]

Hi Peter,

On Wed, Jul 22, 2026 at 10:55:55AM +0100, Peter Griffin wrote:
> diff --git a/arch/arm64/boot/dts/google/lga-pixel-common.dtsi b/arch/arm64/boot/dts/google/lga-pixel-common.dtsi
> new file mode 100644
> index 000000000000..57c318ab44c9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/google/lga-pixel-common.dtsi

> +	aliases {
> +		serial0 = "/soc@0/serial@db62000";	/* &lsion_cli16_uart */
> +		ufs0 = "/ufs-placeholder";		/* &ufs - TODO "/soc@0/ufs@3c400000" */

I'm going to go out on a limb here and guess that these aliases are
being spelled literally (with comments pointing at their label) because
they used to be formed as overlays (where the label won't resolve
properly, I expect?).

Do we still want to spell it this way? This looks generally nicer, and
won't need an update when we get a real ufs node:

		serial0 = &lsion_cli16_uart;
		ufs0 = &ufs;

IMO, we can cross the overlay bridge when we come to it.

Brian

> +	};

Re: [PATCH v2 0/5] Add Laguna/Tensor G5 SoC and Frankel, Blazer & Mustang boards

[Brian Norris]

On Wed, Jul 22, 2026 at 10:55:51AM +0100, Peter Griffin wrote:
> Hi folks,
> 
> This series adds initial basic support for Laguna (Tensor G5 SoC)
> found in Frankel (Pixel 10), Blazer (Pixel 10 Pro) and Mustang (Pixel
> 10 Pro XL) phones.

...

>       arm64: defconfig: enable Tensor G5 SoC family

I'm not able to apply this one cleanly in my tree, although resolving
the context conflict is trivial.

> 
>  Documentation/devicetree/bindings/arm/google.yaml  |  48 ++-
>  .../bindings/serial/snps-dw-apb-uart.yaml          |   1 +
>  MAINTAINERS                                        |   1 +
>  arch/arm64/Kconfig.platforms                       |   8 +
>  arch/arm64/boot/dts/Makefile                       |   1 +
>  arch/arm64/boot/dts/google/Makefile                |   6 +
>  arch/arm64/boot/dts/google/lga-blazer.dts          |  15 +
>  arch/arm64/boot/dts/google/lga-frankel.dts         |  16 +
>  arch/arm64/boot/dts/google/lga-mustang.dts         |  15 +
>  arch/arm64/boot/dts/google/lga-pixel-common.dtsi   |  23 ++
>  arch/arm64/boot/dts/google/lga.dtsi                | 423 +++++++++++++++++++++
>  arch/arm64/configs/defconfig                       |   1 +
>  12 files changed, 539 insertions(+), 19 deletions(-)
> ---
> base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90

I don't find this base commit in Linus's tree. I only found it in
linux-next after fetching this hash directly -- it's a linux-next tag
from 20260507? Seems like an odd old choice. Might be worth refreshing
your base.

Apart from that and a small note on patch 4, it works for me:

Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>

Thanks!

> change-id: 20260710-contrib-pg-pixel10-initial-dts-49f5ec657b66
> 
> Best regards,
> -- 
> Peter Griffin <peter.griffin@linaro.org>
> 

Re: [PATCH v2 0/5] Add Laguna/Tensor G5 SoC and Frankel, Blazer & Mustang boards

[Krzysztof Kozlowski]

On Wed, Jul 22, 2026 at 04:58:02PM -0700, Brian Norris wrote:
> On Wed, Jul 22, 2026 at 10:55:51AM +0100, Peter Griffin wrote:
> > Hi folks,
> > 
> > This series adds initial basic support for Laguna (Tensor G5 SoC)
> > found in Frankel (Pixel 10), Blazer (Pixel 10 Pro) and Mustang (Pixel
> > 10 Pro XL) phones.
> 
> ...
> 
> >       arm64: defconfig: enable Tensor G5 SoC family
> 
> I'm not able to apply this one cleanly in my tree, although resolving
> the context conflict is trivial.
> 
> > 
> >  Documentation/devicetree/bindings/arm/google.yaml  |  48 ++-
> >  .../bindings/serial/snps-dw-apb-uart.yaml          |   1 +
> >  MAINTAINERS                                        |   1 +
> >  arch/arm64/Kconfig.platforms                       |   8 +
> >  arch/arm64/boot/dts/Makefile                       |   1 +
> >  arch/arm64/boot/dts/google/Makefile                |   6 +
> >  arch/arm64/boot/dts/google/lga-blazer.dts          |  15 +
> >  arch/arm64/boot/dts/google/lga-frankel.dts         |  16 +
> >  arch/arm64/boot/dts/google/lga-mustang.dts         |  15 +
> >  arch/arm64/boot/dts/google/lga-pixel-common.dtsi   |  23 ++
> >  arch/arm64/boot/dts/google/lga.dtsi                | 423 +++++++++++++++++++++
> >  arch/arm64/configs/defconfig                       |   1 +
> >  12 files changed, 539 insertions(+), 19 deletions(-)
> > ---
> > base-commit: 17c7841d09ee7d33557fd075562d9289b6018c90
> 
> I don't find this base commit in Linus's tree. I only found it in
> linux-next after fetching this hash directly -- it's a linux-next tag
> from 20260507? Seems like an odd old choice. Might be worth refreshing
> your base.
> 
> Apart from that and a small note on patch 4, it works for me:
> 
> Tested-by: Brian Norris <briannorris@chromium.org>

This does not apply to 60% of patches here. Really, you could just reply
to each email.

I expect incorrect tags won't be picked up.

Best regards,
Krzysztof

Re: [PATCH v2 1/5] dt-bindings: arm: google: Add dt bindings for frankel/blazer/mustang

[Krzysztof Kozlowski]

On Wed, Jul 22, 2026 at 10:55:52AM +0100, Peter Griffin wrote:
> Add binding documentation for Tensor G5 SoC (Laguna) which is referred
> to in code as "lga" and three of the boards that use the Laguna SoC
> Frankel (Pixel 10), Blazer (Pixel 10 Pro) and Mustang (Pixel 10 Pro XL).
> 
> Additionally update to use a more efficient and scalable way to express
> the various names a SoC is known by.
> 
> Co-developed-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v2 3/5] arm64: dts: google: Add dts directory for Google-designed silicon

[Krzysztof Kozlowski]

On Wed, Jul 22, 2026 at 10:55:54AM +0100, Peter Griffin wrote:
> From: Douglas Anderson <dianders@chromium.org>
> 
> The first four Google Tensor SoCs were offshoots of Samsung Exynos
> SoCs and their device trees were organized under the "exynos/google"
> directory. Starting with the Google Tensor G5 SoC in Pixel 10 phones,
> Google Tensor SoCs are now of Google's own design. Add a location in
> the tree to store these device tree files.
> 
> Changes by Peter Griffin
>  * update config symbol help with at least 4 lines to avoid checkpatch
>    warning
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  MAINTAINERS                         | 1 +
>  arch/arm64/Kconfig.platforms        | 8 ++++++++
>  arch/arm64/boot/dts/Makefile        | 1 +
>  arch/arm64/boot/dts/google/Makefile | 1 +
>  4 files changed, 11 insertions(+)
> 

This is not Samsung derivative, but new top-level SoC platform, thus
usual way is that you send it after review to soc@ (see maintainer-soc
profile).

OTOH, the maintainers entry is the same as Google Tensor GS, thus maybe
you want me to pick this up via Samsung SoC tree?

Both will work, up to you.

Patch looks good.

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Krzysztof Kozlowski]

On Wed, Jul 22, 2026 at 10:55:55AM +0100, Peter Griffin wrote:
> diff --git a/arch/arm64/boot/dts/google/lga-pixel-common.dtsi b/arch/arm64/boot/dts/google/lga-pixel-common.dtsi
> new file mode 100644
> index 000000000000..57c318ab44c9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/google/lga-pixel-common.dtsi
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Google Pixel 10 family common dtsi.
> + *
> + * Copyright 2024-2025 Google LLC.
> + */
> +
> +#include "lga.dtsi"
> +
> +&{/} {

This is overlay style, but the file is DTSI. Just use standard '/ {' -
that's simple and obvious enough path.

> +	chosen {
> +		stdout-path = "serial0";
> +	};
> +
> +	aliases {
> +		serial0 = "/soc@0/serial@db62000";	/* &lsion_cli16_uart */
> +		ufs0 = "/ufs-placeholder";		/* &ufs - TODO "/soc@0/ufs@3c400000" */

UFS does not have aliases, please drop.

> +	};
> +};
> +
> +&osc {
> +	clock-frequency = <38400000>;
> +};
> diff --git a/arch/arm64/boot/dts/google/lga.dtsi b/arch/arm64/boot/dts/google/lga.dtsi
> new file mode 100644
> index 000000000000..343156a8c039
> --- /dev/null
> +++ b/arch/arm64/boot/dts/google/lga.dtsi
> @@ -0,0 +1,423 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Google Tensor G5 (laguna) SoC rev B0
> + *
> + * Copyright 2024-2025 Google LLC.
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +
> +/ {
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +	interrupt-parent = <&gic>;
> +
> +	osc: clock-38400000 {
> +		compatible = "fixed-clock";
> +		#clock-cells = <0>;
> +	};
> +
> +	cpus: cpus {
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		hayes_0: cpu@0 {
> +			compatible = "arm,cortex-a520";
> +			reg = <0x000>;
> +
> +			#cooling-cells = <2>;
> +			capacity-dmips-mhz = <258>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			power-domain-names = "psci";
> +			power-domains = <&cpu_pd0>;
> +		};
> +
> +		hayes_1: cpu@100 {
> +			compatible = "arm,cortex-a520";
> +			reg = <0x100>;
> +
> +			#cooling-cells = <2>;
> +			capacity-dmips-mhz = <258>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			power-domain-names = "psci";
> +			power-domains = <&cpu_pd1>;
> +		};
> +
> +		hunter_0: cpu@200 {
> +			compatible = "arm,cortex-a725";
> +			reg = <0x200>;
> +
> +			#cooling-cells = <2>;
> +			capacity-dmips-mhz = <891>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			power-domain-names = "psci";
> +			power-domains = <&cpu_pd2>;
> +		};
> +
> +		hunter_1: cpu@300 {
> +			compatible = "arm,cortex-a725";
> +			reg = <0x300>;
> +
> +			#cooling-cells = <2>;
> +			capacity-dmips-mhz = <891>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			power-domain-names = "psci";
> +			power-domains = <&cpu_pd3>;
> +		};
> +
> +		hunter_2: cpu@400 {
> +			compatible = "arm,cortex-a725";
> +			reg = <0x400>;
> +
> +			#cooling-cells = <2>;
> +			capacity-dmips-mhz = <891>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			power-domain-names = "psci";
> +			power-domains = <&cpu_pd4>;
> +		};
> +
> +		hunter_3: cpu@500 {
> +			compatible = "arm,cortex-a725";
> +			reg = <0x500>;
> +
> +			#cooling-cells = <2>;
> +			capacity-dmips-mhz = <891>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			power-domain-names = "psci";
> +			power-domains = <&cpu_pd5>;
> +		};
> +
> +		hunter_4: cpu@600 {
> +			compatible = "arm,cortex-a725";
> +			reg = <0x600>;
> +
> +			#cooling-cells = <2>;
> +			capacity-dmips-mhz = <891>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			power-domain-names = "psci";
> +			power-domains = <&cpu_pd6>;
> +		};
> +
> +		hunterelp_0: cpu@700 {
> +			compatible = "arm,cortex-x4";
> +			reg = <0x700>;
> +
> +			#cooling-cells = <2>;
> +			capacity-dmips-mhz = <1024>;
> +			device_type = "cpu";
> +			enable-method = "psci";
> +			power-domain-names = "psci";
> +			power-domains = <&cpu_pd7>;
> +		};
> +
> +		cpu-map {
> +			cluster0 {
> +				core0 {
> +					cpu = <&hayes_0>;
> +				};
> +				core1 {
> +					cpu = <&hayes_1>;
> +				};
> +				core2 {
> +					cpu = <&hunter_0>;
> +				};
> +				core3 {
> +					cpu = <&hunter_1>;
> +				};
> +				core4 {
> +					cpu = <&hunter_2>;
> +				};
> +				core5 {
> +					cpu = <&hunter_3>;
> +				};
> +				core6 {
> +					cpu = <&hunter_4>;
> +				};
> +				core7 {
> +					cpu = <&hunterelp_0>;
> +				};
> +			};
> +		};
> +
> +		idle-states {
> +			entry-method = "psci";
> +
> +			cpu_lit_c2: cpu-lit-c2 {
> +				compatible = "arm,idle-state";
> +
> +				entry-latency-us = <132>;
> +				exit-latency-us = <296>;
> +				min-residency-us = <3610>;
> +
> +				idle-state-name = "cpu-lit-c2";
> +				local-timer-stop;
> +
> +				arm,psci-suspend-param = <0x40000003>;
> +			};
> +
> +			cpu_mid1_c2: cpu-mid1-c2 {
> +				compatible = "arm,idle-state";
> +
> +				entry-latency-us = <130>;
> +				exit-latency-us = <274>;
> +				min-residency-us = <2720>;
> +
> +				idle-state-name = "cpu-mid1-c2";
> +				local-timer-stop;
> +
> +				arm,psci-suspend-param = <0x40000003>;
> +			};
> +
> +			cpu_mid2_c2: cpu-mid2-c2 {
> +				compatible = "arm,idle-state";
> +
> +				entry-latency-us = <130>;
> +				exit-latency-us = <274>;
> +				min-residency-us = <2720>;
> +
> +				idle-state-name = "cpu-mid2-c2";
> +				local-timer-stop;
> +
> +				arm,psci-suspend-param = <0x40000003>;
> +			};
> +
> +			cpu_big_c2: cpu-big-c2 {
> +				compatible = "arm,idle-state";
> +
> +				entry-latency-us = <110>;
> +				exit-latency-us = <413>;
> +				min-residency-us = <3950>;
> +
> +				idle-state-name = "cpu-big-c2";
> +				local-timer-stop;
> +
> +				arm,psci-suspend-param = <0x40000003>;
> +			};
> +		};
> +
> +		domain-idle-states {
> +			cluster_1_c3: cluster-1-c3 {
> +				compatible = "domain-idle-state";
> +
> +				entry-latency-us = <325>;
> +				exit-latency-us = <553>;
> +				min-residency-us = <10000>;
> +
> +				idle-state-name = "cluster-1-c3";
> +
> +				arm,psci-suspend-param = <0x40010033>;
> +			};
> +
> +			cluster_2_c3: cluster-2-c3 {
> +				compatible = "domain-idle-state";
> +
> +				entry-latency-us = <345>;
> +				exit-latency-us = <673>;
> +				min-residency-us = <10000>;
> +
> +				idle-state-name = "cluster-2-c3";
> +
> +				arm,psci-suspend-param = <0x40010033>;
> +			};
> +
> +			cluster_c4_deep: cluster-c4-deep {
> +				compatible = "domain-idle-state";
> +
> +				entry-latency-us = <510>;
> +				exit-latency-us = <1027>;
> +				min-residency-us = <10000>;
> +
> +				idle-state-name = "cluster-c4-deep";
> +
> +				arm,psci-suspend-param = <0x40020333>;
> +			};
> +		};
> +	};
> +
> +	memory: memory@80000000 {
> +		device_type = "memory";
> +		/* We expect the bootloader to fill in the size */
> +		reg = <0x0 0x80000000 0x0 0x0>;
> +	};

The memory node should go to the DTS (or common DTSI). It's not part of
SoC usually.

Also, add short comment why do you need label. It will cause
dt-style-check warning.


> +
> +	psci {
> +		compatible = "arm,psci-1.0";
> +		method = "smc";
> +
> +		cpu_pd0: power-domain-cpu0 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states = <&cpu_lit_c2>;
> +			power-domains = <&cpu_top_cl>;
> +		};
> +
> +		cpu_pd1: power-domain-cpu1 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states =  <&cpu_lit_c2>;
> +			power-domains = <&cpu_top_cl>;
> +		};
> +
> +		cpu_pd2: power-domain-cpu2 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states =  <&cpu_mid1_c2>;
> +			power-domains = <&cpucl1>;
> +		};
> +
> +		cpu_pd3: power-domain-cpu3 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states =  <&cpu_mid1_c2>;
> +			power-domains = <&cpucl1>;
> +		};
> +
> +		cpu_pd4: power-domain-cpu4 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states =  <&cpu_mid1_c2>;
> +			power-domains = <&cpucl1>;
> +		};
> +
> +		cpu_pd5: power-domain-cpu5 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states =  <&cpu_mid2_c2>;
> +			power-domains = <&cpucl2>;
> +		};
> +
> +		cpu_pd6: power-domain-cpu6 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states =  <&cpu_mid2_c2>;
> +			power-domains = <&cpucl2>;
> +		};
> +
> +		cpu_pd7: power-domain-cpu7 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states =  <&cpu_big_c2>;
> +			power-domains = <&cpucl2>;
> +		};
> +
> +		cpucl1: power-domain-cluster-1 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states = <&cluster_1_c3>;
> +			power-domains = <&cpu_top_cl>;
> +		};
> +
> +		cpucl2: power-domain-cluster-2 {
> +			#power-domain-cells = <0>;
> +			domain-idle-states = <&cluster_2_c3>;
> +			power-domains = <&cpu_top_cl>;
> +		};
> +
> +		cpu_top_cl: power-domain-top-cluster {
> +			#power-domain-cells = <0>;
> +			domain-idle-states = <&cluster_c4_deep>;
> +		};
> +	};
> +
> +	reserved_memory: reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		/*
> +		 * Store ramoops at a known location in DRAM, for access by the ABL
> +		 * following a crash-reset.
> +		 */
> +		ramoops@95200000 {
> +			compatible = "ramoops";
> +			reg = <0x0 0x95200000 0x0 0x400000>;
> +			console-size = <0x200000>;
> +			pmsg-size = <0x200000>;
> +		};
> +
> +		/* bootloader logs */
> +		bldr_log_reserved: bldr-log-reserved@95600000 {
> +			reg = <0x0 0x95600000 0x0 0x100000>;
> +			no-map;
> +		};
> +
> +		/* gsa logs */
> +		gsa_reserved_log: gsa-reserved-log@a61b0000 {
> +			reg = <0x0 0xa61b0000 0x0 0x00004000>;
> +			no-map;
> +		};
> +
> +		/* Android BootLoader (ABL) for ramdump/coredump processing */
> +		abl@be000000 {
> +			reg = <0x0 0xbe000000 0x0 0x1000000>;
> +			no-map;
> +		};
> +	};
> +
> +	soc: soc@0 {
> +		compatible = "simple-bus";
> +		ranges = <0 0 0 0 0x10 0>;
> +
> +		dma-ranges = <0 0 0 0 0x10 0>;
> +
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +
> +		gic: interrupt-controller@5880000 {
> +			compatible = "arm,gic-v3";
> +			reg = <0 0x05880000 0 0x10000>,
> +			      <0 0x05900000 0 0x200000>;

In some other places you use hex everywhere, also for '0' (so '0x0').
Switch to consistent 0x0 everywhere for new code.

> +			ranges;

Why ranges? There is no MSI child node with unit address.

> +
> +			#address-cells = <2>;
> +			#size-cells = <2>;
> +
> +			#interrupt-cells = <4>;
> +			interrupt-controller;
> +			interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
> +
> +			ppi-partitions {
> +				ppi_cluster0: interrupt-partition-0 {
> +					affinity = <&hayes_0 &hayes_1
> +						    &hunter_0 &hunter_1 &hunter_2
> +						    &hunter_3 &hunter_4>;
> +				};
> +
> +				ppi_cluster1: interrupt-partition-1 {
> +					affinity = <&hunterelp_0>;
> +				};
> +			};
> +		};
> +
> +		lsion_cli16_uart: serial@db62000 {
> +			compatible = "google,lga-uart", "snps,dw-apb-uart";
> +			reg = <0 0x0db62000 0 0x100>;
> +
> +			clock-frequency = <200000000>;
> +			interrupts = <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH 0>;
> +			reg-io-width = <4>;
> +			reg-shift = <2>;
> +
> +			status = "disabled";
> +		};
> +	};
> +
> +	timer {
> +		compatible = "arm,armv8-timer";
> +		interrupts =
> +			<GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,

Join line:

interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,

even if it goes beyond 80 char limit. That's fine, exceptions are
allowed and one line makes 'greps' or 'seds' easier.

> +			<GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
> +			<GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
> +			<GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>;
> +	};
> +
> +	/*
> +	 * The Pixel bootloader considers it a fatal error if it doesn't find
> +	 * a `ufs0` alias so it can add calibration data to the node. Until

Fake node is ok, but alias won't fly because aliases are not allowed for
ufs. Well, would work 10 years ago, but this is a device from ~2025 (so
SoC maybe a bit earlier), thus Google already knew that they MUST talk
with upstream open source maintainers before they ship such ABI.

They did not talk, so you reap what you sow.

There is no more excuse for a vendor to ignore open source and push
whatever-ABI-they-wish into their product, if they ever want to upstream
that product.

I know it is not your fault, obviously. And I know that not much you can
do, so that is not rant towards you nor towards Doug.

You will have to keep this part of patch out of tree or fix the Pixel
bootloader.

> +	 * the proper UFS controller node is added under the SoC, create a
> +	 * temporary node to make the bootloader happy.
> +	 */
> +	ufs: ufs-placeholder {
> +	};

Best regards,
Krzysztof

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Doug Anderson]

Hi,

On Fri, Jul 24, 2026 at 12:00 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> > +                     <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
> > +                     <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>,
> > +                     <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW) 0>;
> > +     };
> > +
> > +     /*
> > +      * The Pixel bootloader considers it a fatal error if it doesn't find
> > +      * a `ufs0` alias so it can add calibration data to the node. Until
>
> Fake node is ok, but alias won't fly because aliases are not allowed for
> ufs. Well, would work 10 years ago, but this is a device from ~2025 (so
> SoC maybe a bit earlier), thus Google already knew that they MUST talk
> with upstream open source maintainers before they ship such ABI.
>
> They did not talk, so you reap what you sow.
>
> There is no more excuse for a vendor to ignore open source and push
> whatever-ABI-they-wish into their product, if they ever want to upstream
> that product.
>
> I know it is not your fault, obviously. And I know that not much you can
> do, so that is not rant towards you nor towards Doug.
>
> You will have to keep this part of patch out of tree or fix the Pixel
> bootloader.

FWIW, it actually _is_ a rant towards me, since I added the "ufs0" alias. :-P

When I was originally bringing up Pixel 10 with upstream, the
bootloader had a hardcoded path to the UFS node. It looked for it at
"/ufs@3c400000". That certainly wasn't going to work. Downstream
_still_ hasn't transitioned to having a "soc@0" node to put all the
MMIO peripherals under, so the equivalent upstream path would be
"/soc@0/ufs@3c400000"

Now, I certainly could have made the bootloader search both paths, but
that seemed bad to me because:

1. As I understand it, DT paths aren't ABI. While it feels unlikely
upstream would change "/soc@0/ufs@3c400000" to something else, I
believe upstream would feel free to and not consider it a "breaking"
change. This makes it feel unwise to hardcode the path in the
bootloader. In the past, upstream has renamed nodes to clean them up
and it wasn't considered a violation of the sanctity of the
device-tree ABI.

2. If #1 is untrue and we consider DT paths as ABI, it's still a bit
awkward. We have one bootloader base that supports multiple SoCs. The
unit address differs across SoCs, even though the IP block is nearly
the same (bootloader still adds the same type of calibration data to
the node). The code I started with had a bunch of #if statements for
the paths in various SoC variants, and that went away with the alias.
I suppose the bootloader needs to know the UFS base address anyway so
I could have probably constructed the node name based on other
#defines, but it still was a bit awkward.

3. I certainly could have searched the whole device tree for the UFS
node by "compatible" string, but the Pixel 10 (and future) UFS
controllers aren't upstream yet. We wouldn't be able to land the Pixel
10 device tree without the UFS bindings landed yet and I think we're a
bit far away from getting the Pixel 10 UFS bindings landed...

With all that, the "aliases" seemed like a pretty clean way for the
bootloader to find the UFS node. It also matched my understanding of
an appropriate use of an "alias".

Any suggestions for how to resolve this? Do we go back to hardcoding a
path in the bootloader and cross our fingers that upstream never
cleans up anything that changes the path to the UFS node? Would it
really be terrible to allow a "ufs0" alias for this case?

As a side note, I did "talk" to upstream shortly after adding the
"ufs0" node by sending the Pixel 10 patches upstream, but I guess we
were so focused on the overlay topic that nobody thought to comment on
the "ufs0" node? At the time, I'm fairly certain my resulting device
tree files passed schema validation at the time, too...


-Doug

Re: [PATCH v2 1/5] dt-bindings: arm: google: Add dt bindings for frankel/blazer/mustang

[Doug Anderson]

Hi,

On Wed, Jul 22, 2026 at 2:56 AM Peter Griffin <peter.griffin@linaro.org> wrote:
>
> -  # Bootloader requires empty ect node to be present
> +      # Google Tensor G5 AKA lga (laguna) SoC and boards
> +      - description:
> +          Google Pixel 10, 10 Pro, 10 Pro XL (Frankel, Blazer,
> +          Mustang).
> +        items:
> +          - enum:
> +              - google,lga-blazer
> +              - google,lga-frankel
> +              - google,lga-mustang
> +          - const: google,lga

I'm not sure I really want to make a big stink here since I'm
certainly interested in getting something landed. That being said, I
at least want to ask about the "google,lga" entry in the above
snippet. "google,lga" represents the SoC and I don't think that's
technically required in the top-level compatible string.

I had a previous email about this that essentially went nowhere [1],
but I'm hoping to continue the discussion (along with other similar
topics) and Plumbers. The essence of the question is: how much data do
we really want to jam into the top-level compatible string, and is the
top-level compatible string truly the best place to indicate which SoC
is present in the system? While many boards put the SoC here, I don't
think anything in the DT spec requires it, and I'm hoping that we can
stop doing it for new boards. When/if we need the SoC info in the
device tree, it seems like we could put it somewhere better...

[1] https://lore.kernel.org/r/CAD=FV=W+jE_L_LLgAhD8K_4+CtivSD9-9t7Xe63XuKrKjfyfeQ@mail.gmail.com/

Re: [PATCH v2 5/5] arm64: defconfig: enable Tensor G5 SoC family

[Doug Anderson]

Hi,

On Wed, Jul 22, 2026 at 2:56 AM Peter Griffin <peter.griffin@linaro.org> wrote:
>
> Enable the Google Tensor G5 (Laguna) SoC family in the arm64
> defconfig. This SoC family is found in Pixel 10 and later phones.
>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)

In case having a tag helps:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Doug Anderson]

Hi,

On Thu, Jul 30, 2026 at 4:32 PM Doug Anderson <dianders@chromium.org> wrote:
>
> > > +     /*
> > > +      * The Pixel bootloader considers it a fatal error if it doesn't find
> > > +      * a `ufs0` alias so it can add calibration data to the node. Until
> >
> > Fake node is ok, but alias won't fly because aliases are not allowed for
> > ufs. Well, would work 10 years ago, but this is a device from ~2025 (so
> > SoC maybe a bit earlier), thus Google already knew that they MUST talk
> > with upstream open source maintainers before they ship such ABI.
> >
> > They did not talk, so you reap what you sow.
> >
> > There is no more excuse for a vendor to ignore open source and push
> > whatever-ABI-they-wish into their product, if they ever want to upstream
> > that product.
> >
> > I know it is not your fault, obviously. And I know that not much you can
> > do, so that is not rant towards you nor towards Doug.
> >
> > You will have to keep this part of patch out of tree or fix the Pixel
> > bootloader.
>
> FWIW, it actually _is_ a rant towards me, since I added the "ufs0" alias. :-P
>
> When I was originally bringing up Pixel 10 with upstream, the
> bootloader had a hardcoded path to the UFS node. It looked for it at
> "/ufs@3c400000". That certainly wasn't going to work. Downstream
> _still_ hasn't transitioned to having a "soc@0" node to put all the
> MMIO peripherals under, so the equivalent upstream path would be
> "/soc@0/ufs@3c400000"
>
> Now, I certainly could have made the bootloader search both paths, but
> that seemed bad to me because:
>
> 1. As I understand it, DT paths aren't ABI. While it feels unlikely
> upstream would change "/soc@0/ufs@3c400000" to something else, I
> believe upstream would feel free to and not consider it a "breaking"
> change. This makes it feel unwise to hardcode the path in the
> bootloader. In the past, upstream has renamed nodes to clean them up
> and it wasn't considered a violation of the sanctity of the
> device-tree ABI.
>
> 2. If #1 is untrue and we consider DT paths as ABI, it's still a bit
> awkward. We have one bootloader base that supports multiple SoCs. The
> unit address differs across SoCs, even though the IP block is nearly
> the same (bootloader still adds the same type of calibration data to
> the node). The code I started with had a bunch of #if statements for
> the paths in various SoC variants, and that went away with the alias.
> I suppose the bootloader needs to know the UFS base address anyway so
> I could have probably constructed the node name based on other
> #defines, but it still was a bit awkward.
>
> 3. I certainly could have searched the whole device tree for the UFS
> node by "compatible" string, but the Pixel 10 (and future) UFS
> controllers aren't upstream yet. We wouldn't be able to land the Pixel
> 10 device tree without the UFS bindings landed yet and I think we're a
> bit far away from getting the Pixel 10 UFS bindings landed...
>
> With all that, the "aliases" seemed like a pretty clean way for the
> bootloader to find the UFS node. It also matched my understanding of
> an appropriate use of an "alias".
>
> Any suggestions for how to resolve this? Do we go back to hardcoding a
> path in the bootloader and cross our fingers that upstream never
> cleans up anything that changes the path to the UFS node? Would it
> really be terrible to allow a "ufs0" alias for this case?
>
> As a side note, I did "talk" to upstream shortly after adding the
> "ufs0" node by sending the Pixel 10 patches upstream, but I guess we
> were so focused on the overlay topic that nobody thought to comment on
> the "ufs0" node? At the time, I'm fairly certain my resulting device
> tree files passed schema validation at the time, too...

I guess no response / silence == my email was so dumb that it wasn't
worth responding to? Even despite that, we still need to find a way to
move forward, so popping back here...

I did some digging. As far as I can tell:

* Nothing in the DeviceTree specification 0.4 [1] mentions that
aliases are deprecated.

* Nothing in the dt-schema repository [2] causes validation to fail
when you use new aliases and there is no "allowlist" of old aliases
that are allowed for historical reasons.

* There is a single reference in the kernel "Documentation/devicetree"
about not using aliases to assign an "instance ID" [3].

Is there some other documentation saying "aliases == evil" that I
missed? Maybe some email thread we're all supposed to have read?

Is the only issue here the fact that the alias ends with a "0" and
thus implicitly provides an "instance ID"?  Would it be OK if I
changed my alias name to "ufs-primary" or "ufs-internal" or "ufs-boot"
or just "ufs"? We're not using the alias to get an instance ID, but
when I added the alias I followed the pattern of all the other aliases
and put an number at the end.

I'm happy to attempt to fix our bootloader using whatever scheme
upstream suggests. I'm trying to "talk to upstream" as requested, but
for it to work I need upstream to talk back. :-)

[1] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.4
[2] https://github.com/devicetree-org/dt-schema.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6a57cf210711c068a650bd86acae4a88303dfd5d

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Linus Walleij]

Hi Doug,

note: I know what it is like to be in active product development
with a product organization with one finger constantly on the
fast forward button to get products out the door. This creates
unacceptable stress for engineers trying to at the same time
establish standards and pass formal and slow reviews.

On Wed, Aug 19, 2026 at 12:13 AM Doug Anderson <dianders@chromium.org> wrote:

> Is there some other documentation saying "aliases == evil" that I
> missed? Maybe some email thread we're all supposed to have read?

Yes, kind of, it was 10 years ago and about MMC aliases for
selecting a primary device for boot:
https://lore.kernel.org/lkml/CAD=FV=XLuPWKjQBMLApRQxk0K30p_TPcztB7g_1DB7iRA9BGRQ@mail.gmail.com/T/
and you were in the thread, it's not pretty, leaves a bad aftertaste.
For, I think, reasons stated in my initial paragraph.

The takeway is something like "the device enumeration is policy,
not hardware information, so it should not be encoded into
the device tree", and that is not an argument about aliases
per se.

As a result (as I think, I may be wrong) MMC gained a few
properties such as:
non-removable;
no-sd;
no-mmc;
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml

These provide a heuristic for which devices to inspect for boot.
Then on top of that I think people use schemes like EFI for finding
boot devices. (Or they still live with their quirks...)

Now this ufs0 node seems to be about calibration of some sort,
which is a more hardware adjacent subject. Is there a way to
add the entity that needs this calibration to the device tree and
reference the UFS device with a phandle along the lines of:

calibration-storage = <&ufs_node>;

?

Even say adding a synthetic modem node if the calibration is
for a modem is probably going to be more acceptable than an
alias.

Yours,
Linus Walleij

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Krzysztof Kozlowski]

On 19/08/2026 00:13, Doug Anderson wrote:
> Hi,
> 
> On Thu, Jul 30, 2026 at 4:32 PM Doug Anderson <dianders@chromium.org> wrote:
>>
>>>> +     /*
>>>> +      * The Pixel bootloader considers it a fatal error if it doesn't find
>>>> +      * a `ufs0` alias so it can add calibration data to the node. Until
>>>
>>> Fake node is ok, but alias won't fly because aliases are not allowed for
>>> ufs. Well, would work 10 years ago, but this is a device from ~2025 (so
>>> SoC maybe a bit earlier), thus Google already knew that they MUST talk
>>> with upstream open source maintainers before they ship such ABI.
>>>
>>> They did not talk, so you reap what you sow.
>>>
>>> There is no more excuse for a vendor to ignore open source and push
>>> whatever-ABI-they-wish into their product, if they ever want to upstream
>>> that product.
>>>
>>> I know it is not your fault, obviously. And I know that not much you can
>>> do, so that is not rant towards you nor towards Doug.
>>>
>>> You will have to keep this part of patch out of tree or fix the Pixel
>>> bootloader.
>>
>> FWIW, it actually _is_ a rant towards me, since I added the "ufs0" alias. :-P
>>
>> When I was originally bringing up Pixel 10 with upstream, the
>> bootloader had a hardcoded path to the UFS node. It looked for it at
>> "/ufs@3c400000". That certainly wasn't going to work. Downstream
>> _still_ hasn't transitioned to having a "soc@0" node to put all the
>> MMIO peripherals under, so the equivalent upstream path would be
>> "/soc@0/ufs@3c400000"
>>
>> Now, I certainly could have made the bootloader search both paths, but
>> that seemed bad to me because:
>>
>> 1. As I understand it, DT paths aren't ABI. While it feels unlikely
>> upstream would change "/soc@0/ufs@3c400000" to something else, I
>> believe upstream would feel free to and not consider it a "breaking"
>> change. This makes it feel unwise to hardcode the path in the
>> bootloader. In the past, upstream has renamed nodes to clean them up
>> and it wasn't considered a violation of the sanctity of the
>> device-tree ABI.
>>
>> 2. If #1 is untrue and we consider DT paths as ABI, it's still a bit
>> awkward. We have one bootloader base that supports multiple SoCs. The
>> unit address differs across SoCs, even though the IP block is nearly
>> the same (bootloader still adds the same type of calibration data to
>> the node). The code I started with had a bunch of #if statements for
>> the paths in various SoC variants, and that went away with the alias.
>> I suppose the bootloader needs to know the UFS base address anyway so
>> I could have probably constructed the node name based on other
>> #defines, but it still was a bit awkward.
>>
>> 3. I certainly could have searched the whole device tree for the UFS
>> node by "compatible" string, but the Pixel 10 (and future) UFS
>> controllers aren't upstream yet. We wouldn't be able to land the Pixel
>> 10 device tree without the UFS bindings landed yet and I think we're a
>> bit far away from getting the Pixel 10 UFS bindings landed...
>>
>> With all that, the "aliases" seemed like a pretty clean way for the
>> bootloader to find the UFS node. It also matched my understanding of
>> an appropriate use of an "alias".
>>
>> Any suggestions for how to resolve this? Do we go back to hardcoding a
>> path in the bootloader and cross our fingers that upstream never
>> cleans up anything that changes the path to the UFS node? Would it
>> really be terrible to allow a "ufs0" alias for this case?
>>
>> As a side note, I did "talk" to upstream shortly after adding the
>> "ufs0" node by sending the Pixel 10 patches upstream, but I guess we
>> were so focused on the overlay topic that nobody thought to comment on
>> the "ufs0" node? At the time, I'm fairly certain my resulting device
>> tree files passed schema validation at the time, too...
> 
> I guess no response / silence == my email was so dumb that it wasn't
> worth responding to? Even despite that, we still need to find a way to
> move forward, so popping back here...
> 
> I did some digging. As far as I can tell:
> 
> * Nothing in the DeviceTree specification 0.4 [1] mentions that
> aliases are deprecated.
> 
> * Nothing in the dt-schema repository [2] causes validation to fail
> when you use new aliases and there is no "allowlist" of old aliases
> that are allowed for historical reasons.
> 
> * There is a single reference in the kernel "Documentation/devicetree"
> about not using aliases to assign an "instance ID" [3].
> 
> Is there some other documentation saying "aliases == evil" that I
> missed? Maybe some email thread we're all supposed to have read?

A lot of rules are implied by other rules and this one, how Linus stated
in other thread, might be implied by no-Linuxisms as you want ordering
or stable naming of Linux /dev entries.

I understand your reason is actually different than above, but your code
does not suggest that.

Anyway, if you wanted to have aliases as ABI, it would have to be
documented. You cannot send post-factum DTS and say "we already use it".
Every ABI must be documented before usage.

And this is what my comment was about: "they MUST talk
with upstream open source maintainers before they ship such ABI."

And no, sending such DTS in your v1 is not documenting ABI. Does not count.

> 
> Is the only issue here the fact that the alias ends with a "0" and
> thus implicitly provides an "instance ID"?  Would it be OK if I
> changed my alias name to "ufs-primary" or "ufs-internal" or "ufs-boot"
> or just "ufs"? We're not using the alias to get an instance ID, but
> when I added the alias I followed the pattern of all the other aliases
> and put an number at the end.
> 
> I'm happy to attempt to fix our bootloader using whatever scheme
> upstream suggests. I'm trying to "talk to upstream" as requested, but
> for it to work I need upstream to talk back. :-)

Make your case - what is the purpose of it? Boot device? Then you have
"chosen" node for stuff between firmware and OS. There is even a
property called "bootsource". If this is not boot device, but some
calibration data for ONE given instance of IP, regardless whether you
boot from it or not, then I find such case as border-base and not worth
implementing, because basically one can come one month later with "I
need 1000 aliases because my bootloader is patching up every device
node". It's called overlays then...

Best regards,
Krzysztof

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Krzysztof Kozlowski]

On 19/08/2026 00:13, Doug Anderson wrote:
> I did some digging. As far as I can tell:
> 
> * Nothing in the DeviceTree specification 0.4 [1] mentions that
> aliases are deprecated.
> 
> * Nothing in the dt-schema repository [2] causes validation to fail
> when you use new aliases and there is no "allowlist" of old aliases
> that are allowed for historical reasons.
> 
> * There is a single reference in the kernel "Documentation/devicetree"
> about not using aliases to assign an "instance ID" [3].


No. The rule is saying: Do not add instance index properties OR custom
OF aliases.

Logical "OR" means here that for you this sentence is equal to:
"Do not add custom OF aliases."

It's true though that you did not add custom OF alias, but a generic
alias, yet you did not explain anywhere what this generic alias means as
an ABI.


Best regards,
Krzysztof

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Doug Anderson]

Hi,

On Wed, Aug 19, 2026 at 1:29 AM Linus Walleij <linusw@kernel.org> wrote:
>
> > Is there some other documentation saying "aliases == evil" that I
> > missed? Maybe some email thread we're all supposed to have read?
>
> Yes, kind of, it was 10 years ago and about MMC aliases for
> selecting a primary device for boot:
> https://lore.kernel.org/lkml/CAD=FV=XLuPWKjQBMLApRQxk0K30p_TPcztB7g_1DB7iRA9BGRQ@mail.gmail.com/T/
> and you were in the thread, it's not pretty, leaves a bad aftertaste.
> For, I think, reasons stated in my initial paragraph.
>
> The takeway is something like "the device enumeration is policy,
> not hardware information, so it should not be encoded into
> the device tree", and that is not an argument about aliases
> per se.
>
> As a result (as I think, I may be wrong) MMC gained a few
> properties such as:
> non-removable;
> no-sd;
> no-mmc;
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/mmc-controller-common.yaml
>
> These provide a heuristic for which devices to inspect for boot.
> Then on top of that I think people use schemes like EFI for finding
> boot devices. (Or they still live with their quirks...)

Yup, I was definitely involved in that conversation around mmc. ...and
yes, that was a frustrating topic. Though I guess I remember things a
bit differently / have a different takeaway. Specifically:

* The whole argument there was about people not liking the idea of
assigning "numbers" to MMC nodes. As I have said, I'm OK with not
having a number here and it's not central to my needs. Said another
way, people seemed to hate assigning a numeric ID to hardware devices,
which is not my goal here.

* The "mmc numbering" patches were (independently) sent again and
again by people because (shockingly, I know) people found it useful to
have their MMC devices enumerate with consistent numbers.

* In the end, support for "mmc aliases" was landed. See commit
fa2d0aa96941 ("mmc: core: Allow setting slot index via device tree
alias").


> Now this ufs0 node seems to be about calibration of some sort,
> which is a more hardware adjacent subject. Is there a way to
> add the entity that needs this calibration to the device tree and
> reference the UFS device with a phandle along the lines of:
>
> calibration-storage = <&ufs_node>;
>
> ?
>
> Even say adding a synthetic modem node if the calibration is
> for a modem is probably going to be more acceptable than an
> alias.

The crux of the issue is that the bootloader needs to add UFS
calibration to the device tree provided to it, and later the UFS
driver in Linux needs to find this calibration data. Since the device
tree lives outside the firmware and is provided to it, the firmware
should make the fewest assumptions about the device tree possible.

Having the firmware hardcode the path to the UFS node doesn't seem
ideal, since (I believe) device tree paths aren't guaranteed to stay
consistent according to the device tree ABI. This, and the current
downstream device tree path differs from what upstream would accept.

Using an alias seems (to me) to be a reasonable solution. However,
I've tried to express that I'm open to concrete ideas.

I appreciate your suggestion of having a separate node for calibration
storage. This feels more awkward to me than just giving up and having
the bootloader hardcode all known device-tree paths that the UFS node
might be found at. That being said, if everyone says that this would
be a great solution, I could try prototyping it. The trick would now
be that the Linux UFS driver would need to be able to find this
calibration data, so the Linux UFS driver would either need to be able
to find it at a specific hardcoded device tree path or the Linux UFS
driver would need to search the device tree for a specific
ufs-calibration compatible string.


-Doug

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Doug Anderson]

Hi,

On Wed, Aug 19, 2026 at 2:02 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> > Is there some other documentation saying "aliases == evil" that I
> > missed? Maybe some email thread we're all supposed to have read?
>
> A lot of rules are implied by other rules and this one, how Linus stated
> in other thread, might be implied by no-Linuxisms as you want ordering
> or stable naming of Linux /dev entries.
>
> I understand your reason is actually different than above, but your code
> does not suggest that.
>
> Anyway, if you wanted to have aliases as ABI, it would have to be
> documented. You cannot send post-factum DTS and say "we already use it".
> Every ABI must be documented before usage.

I'm happy to document. Can you please point to how / where I would
document this? As far as I can tell, no aliases are documented today,
so this would be the first. If you could give me a hint of where you'd
expect it, that would probably be better than me guessing.


> And this is what my comment was about: "they MUST talk
> with upstream open source maintainers before they ship such ABI."
>
> And no, sending such DTS in your v1 is not documenting ABI. Does not count.

Sure, sending a DTS isn't documenting, but it _is_ talking. Discussion
in responses to patches is where we figure things out. For that to
work, reviewers need to point out problems and then we need to have a
continued discussion until we can figure out a solution. When that
discussion just stops, it's incredibly hard to make progress.


> > thus implicitly provides an "instance ID"?  Would it be OK if I
> > changed my alias name to "ufs-primary" or "ufs-internal" or "ufs-boot"
> > or just "ufs"? We're not using the alias to get an instance ID, but
> > when I added the alias I followed the pattern of all the other aliases
> > and put an number at the end.
> >
> > I'm happy to attempt to fix our bootloader using whatever scheme
> > upstream suggests. I'm trying to "talk to upstream" as requested, but
> > for it to work I need upstream to talk back. :-)
>
> Make your case - what is the purpose of it? Boot device? Then you have
> "chosen" node for stuff between firmware and OS. There is even a
> property called "bootsource". If this is not boot device, but some
> calibration data for ONE given instance of IP, regardless whether you
> boot from it or not, then I find such case as border-base and not worth
> implementing, because basically one can come one month later with "I
> need 1000 aliases because my bootloader is patching up every device
> node".

I think I've presened my problem fairly concretely [1]. If you hate
aliases as a solution, I'd love for you to tell me which solution you
prefer so the firmware can add calibration data to the DT. To quickly
summarize options:

a) Hardcode the DT path to the UFS node in the bootloader.

b) Use some variant of aliases to find the UFS node.

c) Firmware finds the UFS node by searching the whole device-tree for
the right "compatible" string.

d) A separate "UFS calibration" node stored somewhere in the DT
(where?), as proposed by Linus W.

e) Something else?


[1] https://lore.kernel.org/all/CAD=FV=U0HUdjPcg+5Vx8_ag0zLd3CZx5w5SFr38p+YwRnC_G6w@mail.gmail.com/

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Doug Anderson]

Hi,

On Wed, Aug 19, 2026 at 2:26 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 19/08/2026 00:13, Doug Anderson wrote:
> > I did some digging. As far as I can tell:
> >
> > * Nothing in the DeviceTree specification 0.4 [1] mentions that
> > aliases are deprecated.
> >
> > * Nothing in the dt-schema repository [2] causes validation to fail
> > when you use new aliases and there is no "allowlist" of old aliases
> > that are allowed for historical reasons.
> >
> > * There is a single reference in the kernel "Documentation/devicetree"
> > about not using aliases to assign an "instance ID" [3].
>
>
> No. The rule is saying: Do not add instance index properties OR custom
> OF aliases.
>
> Logical "OR" means here that for you this sentence is equal to:
> "Do not add custom OF aliases."

That feels like a stretch. While that interpretation is correct if you
read just that sentence in isolation, in the context of the patch as a
whole it feels clear that the point was that you didn't want aliases
specifically because they were used to assign instance IDs. The
patch's subject is "Document discouraged instance IDs", not "document
that aliases are bad" or even "document a bunch of bad things". The
sentence is also in a paragraph that's all about instance IDs.

While I understand you authored the patch, it still feels hard to read
"all aliases are bad" from it.


-Doug

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Linus Walleij]

On Wed, Aug 19, 2026 at 7:03 PM Doug Anderson <dianders@chromium.org> wrote:

> I appreciate your suggestion of having a separate node for calibration
> storage. This feels more awkward to me than just giving up and having
> the bootloader hardcode all known device-tree paths that the UFS node
> might be found at. That being said, if everyone says that this would
> be a great solution, I could try prototyping it. The trick would now
> be that the Linux UFS driver would need to be able to find this
> calibration data, so the Linux UFS driver would either need to be able
> to find it at a specific hardcoded device tree path or the Linux UFS
> driver would need to search the device tree for a specific
> ufs-calibration compatible string.

Can't you just put the calibration data as a custom property inside
the UFS DT node? Just a long byte array or whatever it is.
The driver would certainly know where to find it that way.
I don't know who or how it has to be put there during manufacturing
or inserted by the boot loader into the node from wherever
manufacturing stores it though. (Assuming it's some calibration
added at manufacturing, I don't exactly know what it is...)
If the actual storage place is in something the OS can read
then we could probably use the nvmem to fetch it live?

The calibration business and what it is and where it is stored
evades me a bit...

Yours,
Linus Walleij

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Doug Anderson]

Hi,

On Wed, Aug 19, 2026 at 4:29 PM Linus Walleij <linusw@kernel.org> wrote:
>
> On Wed, Aug 19, 2026 at 7:03 PM Doug Anderson <dianders@chromium.org> wrote:
>
> > I appreciate your suggestion of having a separate node for calibration
> > storage. This feels more awkward to me than just giving up and having
> > the bootloader hardcode all known device-tree paths that the UFS node
> > might be found at. That being said, if everyone says that this would
> > be a great solution, I could try prototyping it. The trick would now
> > be that the Linux UFS driver would need to be able to find this
> > calibration data, so the Linux UFS driver would either need to be able
> > to find it at a specific hardcoded device tree path or the Linux UFS
> > driver would need to search the device tree for a specific
> > ufs-calibration compatible string.
>
> Can't you just put the calibration data as a custom property inside
> the UFS DT node? Just a long byte array or whatever it is.
> The driver would certainly know where to find it that way.
> I don't know who or how it has to be put there during manufacturing
> or inserted by the boot loader into the node from wherever
> manufacturing stores it though. (Assuming it's some calibration
> added at manufacturing, I don't exactly know what it is...)
> If the actual storage place is in something the OS can read
> then we could probably use the nvmem to fetch it live?
>
> The calibration business and what it is and where it is stored
> evades me a bit...

The problem we're facing is _finding_ the UFS node in the bootloader.

The device tree for the board is stored / maintained outside of the
bootloader codebase. It is compiled and stored on the device. The
bootloader runs, locates the device tree and then wants to make
changes to it.

The bootloader needs to _find_ the UFS node in the device tree in
order to make changes to it.

The question is: how does the bootloader find the UFS node?

* Does it hardcode the DT path to the UFS node?

* Does it use an "alias" to find the path to the UFS node?

* Does it search the whole device tree for a certain "compatible"
string and use that to locate the node?

Hardcoding the path is the easiest thing to do here, but then the
bootloader will break if the UFS node ever changes. We also know that
this path will differ for every SoC and is currently different between
the downstream device trees and the upstream ones (because downstream
device trees don't have a "soc@0" node). I've also been told that
device tree paths are not ABI, so hardcoding paths in the bootloader
seems less ideal.

We could just hardcode the path in the bootloader. If this
conversation goes nowhere I'll just change it to do that. If paths
ever break, then I guess we'll just have to get yelled at when folks
say "Why in the world would you hardcode DT paths in the bootloader?
That's not ABI!"

-Doug

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Krzysztof Kozlowski]

On 19/08/2026 19:04, Doug Anderson wrote:
> Hi,
> 
> On Wed, Aug 19, 2026 at 2:02 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>>> Is there some other documentation saying "aliases == evil" that I
>>> missed? Maybe some email thread we're all supposed to have read?
>>
>> A lot of rules are implied by other rules and this one, how Linus stated
>> in other thread, might be implied by no-Linuxisms as you want ordering
>> or stable naming of Linux /dev entries.
>>
>> I understand your reason is actually different than above, but your code
>> does not suggest that.
>>
>> Anyway, if you wanted to have aliases as ABI, it would have to be
>> documented. You cannot send post-factum DTS and say "we already use it".
>> Every ABI must be documented before usage.
> 
> I'm happy to document. Can you please point to how / where I would

Description of:
Documentation/devicetree/bindings/ufs/ufs-common.yaml
And obviously, as with every binding/ABI, you also need open-source,
upstream user of this.

> document this? As far as I can tell, no aliases are documented today,

git grep disagrees with you, e.g. second paragraph of serial.yaml.

> so this would be the first. If you could give me a hint of where you'd
> expect it, that would probably be better than me guessing.
> 
> 
>> And this is what my comment was about: "they MUST talk
>> with upstream open source maintainers before they ship such ABI."
>>
>> And no, sending such DTS in your v1 is not documenting ABI. Does not count.
> 
> Sure, sending a DTS isn't documenting, but it _is_ talking. Discussion
> in responses to patches is where we figure things out. For that to
> work, reviewers need to point out problems and then we need to have a
> continued discussion until we can figure out a solution. When that
> discussion just stops, it's incredibly hard to make progress.
> 
> 
>>> thus implicitly provides an "instance ID"?  Would it be OK if I
>>> changed my alias name to "ufs-primary" or "ufs-internal" or "ufs-boot"
>>> or just "ufs"? We're not using the alias to get an instance ID, but
>>> when I added the alias I followed the pattern of all the other aliases
>>> and put an number at the end.
>>>
>>> I'm happy to attempt to fix our bootloader using whatever scheme
>>> upstream suggests. I'm trying to "talk to upstream" as requested, but
>>> for it to work I need upstream to talk back. :-)
>>
>> Make your case - what is the purpose of it? Boot device? Then you have
>> "chosen" node for stuff between firmware and OS. There is even a
>> property called "bootsource". If this is not boot device, but some
>> calibration data for ONE given instance of IP, regardless whether you
>> boot from it or not, then I find such case as border-base and not worth
>> implementing, because basically one can come one month later with "I
>> need 1000 aliases because my bootloader is patching up every device
>> node".
> 
> I think I've presened my problem fairly concretely [1]. If you hate

There is no description of the problem at [1], except "bootloader adds
the same type of calibration data".

So I repeat my questions: to every UFS node? To every node? To one UFS
node (but how do you guarantee that?)?

I gave you two solutions, depending on actual upstream need of this. If
you have the second case - so not the boot device - then you basically
want to re-implement overlays which you cannot. Use overlays, which
gives you nice stable and build-time verifiable label/phandle.



Best regards,
Krzysztof

Re: [PATCH v2 4/5] arm64: dts: google: Add initial dts for frankel/blazer/mustang

[Linus Walleij]

Hi Doug,

On Thu, Aug 20, 2026 at 1:41 AM Doug Anderson <dianders@chromium.org> wrote:

> > The calibration business and what it is and where it is stored
> > evades me a bit...
>
> The problem we're facing is _finding_ the UFS node in the bootloader.
>
> The device tree for the board is stored / maintained outside of the
> bootloader codebase. It is compiled and stored on the device. The
> bootloader runs, locates the device tree and then wants to make
> changes to it.
>
> The bootloader needs to _find_ the UFS node in the device tree in
> order to make changes to it.

So, thebootloader needs to make changes to the calibration of
the UFS storage, and it needs to find the right UFS storage
to calibrate, right. I get that part.

But this is what boggles my mind. It is actually a pretty
deep philosophical subject.

A piece of software (the bootloader) want to make changes
to the calibration of a piece of hardware, which it somehow
has the calibration for.

This pretty much means that at some point *some* unit
of software producing that said calibration already had a
handle on the hardware.

So there is a missing piece of the puzzle here.

This is where the imperialistic ambition of device tree
kicks in: the piece of software - be that a manufacturing
run-it-once piece of code - that produced said calibration
should have *also* used device tree to find the thing it
was to calibrate. Supposedly looping over all UFS devices
in the device tree and calibrating them one at a time,
something like this.

Ideally that piece of software should have updated the
device tree too, but OK that is intervening with software
engineering, maybe it does not have the capability to
do that.

But that piece of software *should* have at least encoded
some kind of identifier for the thing it calibrated, like a
unique serial number from the hardware, or in worst case
at least the device tree node name.

So the information to locate the right node in the device
tree *should* have been present inside the calibration
binary blob thingy.

What is controversial with this patch is that an authority
on the side comes in and says with a device tree property:

"I have a random piece of calibration data and only I know
which UFS it is for, so I am going to encode that knowledge
into the device tree as an alias."

The device tree "thinks" that this should already be evident.

The device tree has the underlying assumption that
everything is using it. The kernel, the boot loader, the
secure operating environment, the GPU, accelerators...
also the manufacturing tools.

From the view of the device tree world, a manufacturing
tool not using device tree is a hack, and if it is a hack
then the system can put the information in there using
a hack, and this whole ambition of finding the UFS node
from the top down is moot. It's like polishing dirt.

Now, I know this way of thinking is oddly bureaucratic
and imperialistic, but it is in the core essence of how
device tree was thought out. It wants to be the authoritative
source of all hardware information, any other source
is a hack in the view of the device tree.

I don't know if this solves your problem other than saying
"go with any hack because this takes place in an imperfect
world", but at least it points out how this kind of problems
collide with some of the core philosophy of device tree.

Yours,
Linus Walleij