[PATCH 0/4] arm64: google: Introduce frankel, blazer, and mustang boards

[PATCH 0/4] arm64: google: Introduce frankel, blazer, and mustang boards

[Douglas Anderson]

This series adds barebones device trees for Pixel 10 (frankel), Pixel
10 Pro (blazer), and Pixel 10 Pro XL (mustang). With a yet-unreleased
bootloader these can boot to a UART command prompt from an initramfs.

The end result of the device trees introduced in this series is really
pretty simple, so it's expected that most of the discussion in the
series will be about compatible strings, file organization, dts/dtso
organization, etc.


Douglas Anderson (4):
  dt-bindings: arm: google: Add bindings for frankel/blazer/mustang
  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, and mustang

 .../devicetree/bindings/arm/google.yaml       |  87 +++-
 .../bindings/serial/snps-dw-apb-uart.yaml     |   1 +
 MAINTAINERS                                   |   1 +
 arch/arm64/Kconfig.platforms                  |   6 +
 arch/arm64/boot/dts/Makefile                  |   1 +
 arch/arm64/boot/dts/google/Makefile           |  10 +
 arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
 .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
 .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
 .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
 .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
 11 files changed, 561 insertions(+), 19 deletions(-)
 create mode 100644 arch/arm64/boot/dts/google/Makefile
 create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
 create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
 create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
 create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
 create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi

-- 
2.51.2.1041.gc1ab5b90ca-goog

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

[Douglas Anderson]

Add top-level DT bindings useful for Pixel 10 (frankel), Pixel 10 Pro
(blazer), and Pixel 10 Pro XL (mustang).

Since overlays are fairly well-supported these days and the downstream
Pixel bootloader assumes that the SoC is the base overlay and specific
board revisions are overlays, reflect the SoC / board split in the
bindings.

The SoC in the Pixel 10 series has the marketing name of "Tensor
G5". Despite the fact that it sounds very similar to the "Tensor G4",
it's a very different chip. Tensor G4 was, for all intents and
purposes, a Samsung Exynos offshoot whereas Tensor G5 is entirely its
own SoC. This SoC is known internally as "laguna" and canonically
referred to in code as "lga". There are two known revisions of the
SoC: an A0 pre-production variant (ID 0x000500) and a B0 variant (ID
0x000510) used in production. The ID is canonicaly broken up into a
16-bit SoC product ID, a 4-bit major rev, and a 4-bit minor rev.

The dtb for all supported SoC revisions is appended to one of the boot
partitions and the bootloader will look at the device trees and pick
the correct one. The current bootloader uses a downstream
`soc_compatible` node to help it pick the correct device tree. It
looks like this:
  soc_compatible {
    B0 {
      description = "LGA B0";
      product_id = <0x5>;
      major = <0x1>;
      minor = <0x0>;
      pkg_mode = <0x0>;
    };
  };
Note that `pkg_mode` isn't currently part of the ID on the SoC and the
bootloader always assumes 0 for it.

In this patch, put the SoC IDs straight into the compatible. Though
the bootloader doesn't look at the compatible at the moment, this
should be easy to teach the bootloader about.

Boards all know their own platform_id / product_id / stage / major /
minor / variant. For instance, Google Pixel 10 Pro XL MP1 is:
* platform_id (8-bits): 0x07 - frankel/blazer/mustang
* product_id (8-bits):  0x05 - mustang
* stage (4-bits):       0x06 - MP
* major (8-bits):       0x01 - MP 1
* minor (8-bits):       0x00 - MP 1.0
* variant (8-bits):     0x00 - No special variant

When board overlays are packed into the "dtbo" partition, a tool
(`mkdtimg`) extracts a board ID and board rev from the overlay and
stores that as metadata with the overlay. Downstream, the dtso
intended for the Pixel 10 Pro XL MP1 has the following properties at
its top-level:
  board_id = <0x70506>;
  board_rev = <0x010000>;

The use of top-level IDs can probably be used for overlays upstream as
well, but also add the IDs to the compatible string in case it's
useful.

Compatible strings are added for all board revisions known to be
produced based on downstream sources.

A few notes:
* If you look at `/proc/device-tree/compatible` and
  `/proc/device-tree/model` on a running device, that won't
  necessarily be an exact description of the hardware you're running
  on. If the bootloader can't find a device tree that's an exact match
  then it will pick the best match (within reason--it will never pick
  a device tree for a different product--just for different revs of
  the same product).
* There is no merging of the top-level compatible from the SoC and
  board. The compatible string containing IDs for the SoC will not be
  found in the device-tree passed to the OS.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
In the past, attempts to have the SoC as a base device tree and boards
supported as overlays has been NAKed. From a previous discussion [1]
"Nope, boards are not overlays. Boards are DTB." I believe this needs
to be relitigated.

In the previous NAK, I didn't see any links to documentation
explicitly stating that DTBs have to represent boards. It's also
unclear, at least to me, _why_ a DTB would be limited to represent a
"board" nor what the definition of a "board" is.

As at least one stab at why someone might not want an overlay scheme
like this, one could point out that the top-level compatible can be a
bit of a mess. Specifically in this scheme the board "compatible" from
the overlay will fully replace/hide the SoC "compatible" from the base
SoC. If this is truly the main concern, it wouldn't be terribly hard
to add a new semantic (maybe selectable via a new additional
property?) that caused the compatible strings to be merged in a
reasonable way.

Aside from dealing with the compatible string, let's think about what
a "board" is. I will make the argument here that the SoC qualifies as
a "board" and that the main PCB of a phone can be looked at as a
"cape" for this SoC "board". While this may sound like a stretch, I
would invite a reader to propose a definition of "board" that excludes
this. Specifically, it can be noted:
* I have a development board at my desk that is "socketed". That is, I
  can pull the SoC out and put a different one in. I can swap in a
  "rev A0" or a "rev B0" SoC into this socket. Conceivably, I could
  even put a "Tensor G6", G7, G8, or G999 in the socket if it was
  compatible. In this sense, the "SoC" is a standalone thing that can
  be attached to the devboard "cape". The SoC being a standalone thing
  is in the name. It's a "system" on a chip.
* In case the definition of a board somehow needs a PCB involved, I
  can note that on my dev board the CPU socket is soldered onto to a
  CPU daughtercard (a PCB!) that then has a board-to-board connector
  to the main PCB.
* Perhaps one could argue that a dev board like I have describe would
  qualify for this SoC/board overlay scheme but that a normal cell
  phone wouldn't because the SoC isn't removable. Perhaps removability
  is a requirement here? If so, imagine if some company took a
  Raspberry Pi, soldered some components directly onto the "expansion"
  pins, and resold that to consumers. Does this mean they can't use
  overlays?

To me, the above arguments justify why SoC DTBs + "board" overlays
should be accepted. As far as I can tell, there is no downside and
many people who would be made happy with this.

[1] https://lore.kernel.org/all/dbeb28be-1aac-400b-87c1-9764aca3a799@kernel.org/

 .../devicetree/bindings/arm/google.yaml       | 87 +++++++++++++++----
 1 file changed, 68 insertions(+), 19 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
index 99961e5282e5..f9f9ea1c8050 100644
--- a/Documentation/devicetree/bindings/arm/google.yaml
+++ b/Documentation/devicetree/bindings/arm/google.yaml
@@ -13,27 +13,18 @@ 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.
+  These bindings for older Pixel devices don't use device tree overlays so
+  no separate SoC entry is added. This may change in the future.
 
-  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.
+  Newer Pixel devices are expected to have the SoC device tree as the base
+  and specific board device trees as overlays.
 
 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,13 +32,71 @@ properties:
               - google,gs101-raven
           - const: google,gs101
 
+      # Google Tensor G5 AKA lga (laguna) SoC and boards
+      - description: Tensor G5 SoC (laguna)
+        items:
+          - enum:
+              - google,soc-id-0005-rev-00  # A0
+              - google,soc-id-0005-rev-10  # B0
+          - const: google,lga
+      - description: Google Pixel 10 Board (Frankel)
+        items:
+          - enum:
+              - google,pixel-id-070302-rev-000000  # Proto 0
+              - google,pixel-id-070302-rev-010000  # Proto 1
+              - google,pixel-id-070302-rev-010100  # Proto 1.1
+              - google,pixel-id-070303-rev-010000  # EVT 1
+              - google,pixel-id-070303-rev-010100  # EVT 1.1
+              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
+              - google,pixel-id-070304-rev-010000  # DVT 1
+              - google,pixel-id-070305-rev-010000  # PVT 1
+              - google,pixel-id-070306-rev-010000  # MP 1
+          - const: google,lga-frankel
+          - const: google,lga
+      - description: Google Pixel 10 Pro Board (Blazer)
+        items:
+          - enum:
+              - google,pixel-id-070402-rev-000000  # Proto 0
+              - google,pixel-id-070402-rev-010000  # Proto 1
+              - google,pixel-id-070402-rev-010100  # Proto 1.1
+              - google,pixel-id-070403-rev-010000  # EVT 1
+              - google,pixel-id-070403-rev-010100  # EVT 1.1
+              - google,pixel-id-070404-rev-010000  # DVT 1
+              - google,pixel-id-070405-rev-010000  # PVT 1
+              - google,pixel-id-070406-rev-010000  # MP 1
+          - const: google,lga-blazer
+          - const: google,lga
+      - description: Google Pixel 10 Pro XL Board (Mustang)
+        items:
+          - enum:
+              - google,pixel-id-070502-rev-000000  # Proto 0
+              - google,pixel-id-070502-rev-010000  # Proto 1
+              - google,pixel-id-070502-rev-010100  # Proto 1.1
+              - google,pixel-id-070502-rev-010101  # Proto 1.1 Wingboard
+              - google,pixel-id-070503-rev-010000  # EVT 1
+              - google,pixel-id-070503-rev-010100  # EVT 1.1
+              - google,pixel-id-070503-rev-010101  # EVT 1.1 Wingboard
+              - google,pixel-id-070504-rev-010000  # DVT 1
+              - google,pixel-id-070505-rev-010000  # PVT 1
+              - google,pixel-id-070506-rev-010000  # MP 1
+          - const: google,lga-mustang
+          - const: google,lga
+
+allOf:
   # Bootloader requires empty ect node to be present
-  ect:
-    type: object
-    additionalProperties: false
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: google,gs101
+    then:
+      properties:
+        ect:
+          type: object
+          additionalProperties: false
 
-required:
-  - ect
+      required:
+        - ect
 
 additionalProperties: true
 
-- 
2.51.2.1041.gc1ab5b90ca-goog

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

[Krzysztof Kozlowski]

On 11/11/2025 20:22, Douglas Anderson wrote:
> Add top-level DT bindings useful for Pixel 10 (frankel), Pixel 10 Pro
> (blazer), and Pixel 10 Pro XL (mustang).
> 
> Since overlays are fairly well-supported these days and the downstream
> Pixel bootloader assumes that the SoC is the base overlay and specific
> board revisions are overlays, reflect the SoC / board split in the
> bindings.
> 
> The SoC in the Pixel 10 series has the marketing name of "Tensor
> G5". Despite the fact that it sounds very similar to the "Tensor G4",
> it's a very different chip. Tensor G4 was, for all intents and
> purposes, a Samsung Exynos offshoot whereas Tensor G5 is entirely its
> own SoC. This SoC is known internally as "laguna" and canonically
> referred to in code as "lga". There are two known revisions of the
> SoC: an A0 pre-production variant (ID 0x000500) and a B0 variant (ID
> 0x000510) used in production. The ID is canonicaly broken up into a
> 16-bit SoC product ID, a 4-bit major rev, and a 4-bit minor rev.
> 
> The dtb for all supported SoC revisions is appended to one of the boot
> partitions and the bootloader will look at the device trees and pick
> the correct one. The current bootloader uses a downstream
> `soc_compatible` node to help it pick the correct device tree. It
> looks like this:
>   soc_compatible {
>     B0 {
>       description = "LGA B0";
>       product_id = <0x5>;
>       major = <0x1>;
>       minor = <0x0>;
>       pkg_mode = <0x0>;
>     };
>   };
> Note that `pkg_mode` isn't currently part of the ID on the SoC and the
> bootloader always assumes 0 for it.
> 
> In this patch, put the SoC IDs straight into the compatible. Though
> the bootloader doesn't look at the compatible at the moment, this
> should be easy to teach the bootloader about.
> 
> Boards all know their own platform_id / product_id / stage / major /
> minor / variant. For instance, Google Pixel 10 Pro XL MP1 is:
> * platform_id (8-bits): 0x07 - frankel/blazer/mustang
> * product_id (8-bits):  0x05 - mustang
> * stage (4-bits):       0x06 - MP
> * major (8-bits):       0x01 - MP 1
> * minor (8-bits):       0x00 - MP 1.0
> * variant (8-bits):     0x00 - No special variant
> 
> When board overlays are packed into the "dtbo" partition, a tool
> (`mkdtimg`) extracts a board ID and board rev from the overlay and
> stores that as metadata with the overlay. Downstream, the dtso
> intended for the Pixel 10 Pro XL MP1 has the following properties at
> its top-level:
>   board_id = <0x70506>;
>   board_rev = <0x010000>;
> 
> The use of top-level IDs can probably be used for overlays upstream as
> well, but also add the IDs to the compatible string in case it's
> useful.
> 
> Compatible strings are added for all board revisions known to be
> produced based on downstream sources.
> 
> A few notes:
> * If you look at `/proc/device-tree/compatible` and
>   `/proc/device-tree/model` on a running device, that won't
>   necessarily be an exact description of the hardware you're running
>   on. If the bootloader can't find a device tree that's an exact match
>   then it will pick the best match (within reason--it will never pick
>   a device tree for a different product--just for different revs of
>   the same product).
> * There is no merging of the top-level compatible from the SoC and
>   board. The compatible string containing IDs for the SoC will not be
>   found in the device-tree passed to the OS.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> In the past, attempts to have the SoC as a base device tree and boards
> supported as overlays has been NAKed. From a previous discussion [1]
> "Nope, boards are not overlays. Boards are DTB." I believe this needs
> to be relitigated.
> 
> In the previous NAK, I didn't see any links to documentation
> explicitly stating that DTBs have to represent boards. It's also
> unclear, at least to me, _why_ a DTB would be limited to represent a
> "board" nor what the definition of a "board" is.
> 
> As at least one stab at why someone might not want an overlay scheme
> like this, one could point out that the top-level compatible can be a
> bit of a mess. Specifically in this scheme the board "compatible" from
> the overlay will fully replace/hide the SoC "compatible" from the base
> SoC. If this is truly the main concern, it wouldn't be terribly hard
> to add a new semantic (maybe selectable via a new additional
> property?) that caused the compatible strings to be merged in a
> reasonable way.
> 
> Aside from dealing with the compatible string, let's think about what
> a "board" is. I will make the argument here that the SoC qualifies as
> a "board" and that the main PCB of a phone can be looked at as a
> "cape" for this SoC "board". While this may sound like a stretch, I
> would invite a reader to propose a definition of "board" that excludes
> this. Specifically, it can be noted:
> * I have a development board at my desk that is "socketed". That is, I
>   can pull the SoC out and put a different one in. I can swap in a
>   "rev A0" or a "rev B0" SoC into this socket. Conceivably, I could
>   even put a "Tensor G6", G7, G8, or G999 in the socket if it was
>   compatible. In this sense, the "SoC" is a standalone thing that can
>   be attached to the devboard "cape". The SoC being a standalone thing
>   is in the name. It's a "system" on a chip.
> * In case the definition of a board somehow needs a PCB involved, I
>   can note that on my dev board the CPU socket is soldered onto to a
>   CPU daughtercard (a PCB!) that then has a board-to-board connector
>   to the main PCB.
> * Perhaps one could argue that a dev board like I have describe would
>   qualify for this SoC/board overlay scheme but that a normal cell
>   phone wouldn't because the SoC isn't removable. Perhaps removability
>   is a requirement here? If so, imagine if some company took a
>   Raspberry Pi, soldered some components directly onto the "expansion"
>   pins, and resold that to consumers. Does this mean they can't use
>   overlays?
> 
> To me, the above arguments justify why SoC DTBs + "board" overlays
> should be accepted. As far as I can tell, there is no downside and
> many people who would be made happy with this.
> 
> [1] https://lore.kernel.org/all/dbeb28be-1aac-400b-87c1-9764aca3a799@kernel.org/
> 
>  .../devicetree/bindings/arm/google.yaml       | 87 +++++++++++++++----
>  1 file changed, 68 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> index 99961e5282e5..f9f9ea1c8050 100644
> --- a/Documentation/devicetree/bindings/arm/google.yaml
> +++ b/Documentation/devicetree/bindings/arm/google.yaml
> @@ -13,27 +13,18 @@ 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.
> +  These bindings for older Pixel devices don't use device tree overlays so
> +  no separate SoC entry is added. This may change in the future.
>  
> -  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.
> +  Newer Pixel devices are expected to have the SoC device tree as the base
> +  and specific board device trees as overlays.
>  
>  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,13 +32,71 @@ properties:
>                - google,gs101-raven
>            - const: google,gs101
>  
> +      # Google Tensor G5 AKA lga (laguna) SoC and boards
> +      - description: Tensor G5 SoC (laguna)
> +        items:
> +          - enum:
> +              - google,soc-id-0005-rev-00  # A0
> +              - google,soc-id-0005-rev-10  # B0

SoCs cannot be final compatibles. Your commit msg does not explain what
is 'soc-id' or 'soc_id' in this context.

> +          - const: google,lga
> +      - description: Google Pixel 10 Board (Frankel)
> +        items:
> +          - enum:
> +              - google,pixel-id-070302-rev-000000  # Proto 0
> +              - google,pixel-id-070302-rev-010000  # Proto 1
> +              - google,pixel-id-070302-rev-010100  # Proto 1.1
> +              - google,pixel-id-070303-rev-010000  # EVT 1
> +              - google,pixel-id-070303-rev-010100  # EVT 1.1
> +              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
> +              - google,pixel-id-070304-rev-010000  # DVT 1
> +              - google,pixel-id-070305-rev-010000  # PVT 1
> +              - google,pixel-id-070306-rev-010000  # MP 1
> +          - const: google,lga-frankel
> +          - const: google,lga

So what is the lga? What is lga-frankel?

> +      - description: Google Pixel 10 Pro Board (Blazer)
> +        items:
> +          - enum:
> +              - google,pixel-id-070402-rev-000000  # Proto 0
> +              - google,pixel-id-070402-rev-010000  # Proto 1
> +              - google,pixel-id-070402-rev-010100  # Proto 1.1
> +              - google,pixel-id-070403-rev-010000  # EVT 1
> +              - google,pixel-id-070403-rev-010100  # EVT 1.1
> +              - google,pixel-id-070404-rev-010000  # DVT 1
> +              - google,pixel-id-070405-rev-010000  # PVT 1
> +              - google,pixel-id-070406-rev-010000  # MP 1
> +          - const: google,lga-blazer
> +          - const: google,lga
> +      - description: Google Pixel 10 Pro XL Board (Mustang)
> +        items:
> +          - enum:
> +              - google,pixel-id-070502-rev-000000  # Proto 0
> +              - google,pixel-id-070502-rev-010000  # Proto 1
> +              - google,pixel-id-070502-rev-010100  # Proto 1.1
> +              - google,pixel-id-070502-rev-010101  # Proto 1.1 Wingboard
> +              - google,pixel-id-070503-rev-010000  # EVT 1
> +              - google,pixel-id-070503-rev-010100  # EVT 1.1
> +              - google,pixel-id-070503-rev-010101  # EVT 1.1 Wingboard
> +              - google,pixel-id-070504-rev-010000  # DVT 1
> +              - google,pixel-id-070505-rev-010000  # PVT 1
> +              - google,pixel-id-070506-rev-010000  # MP 1
> +          - const: google,lga-mustang
> +          - const: google,lga
> +
> +allOf:
>    # Bootloader requires empty ect node to be present
> -  ect:
> -    type: object
> -    additionalProperties: false

Please keep it here

> +  - if:
> +      properties:
> +        compatible:

not:

> +          contains:
> +            const: google,gs101

> +    then:
> +      properties:
> +        ect:

ect: false, instead


Best regards,
Krzysztof

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

[Doug Anderson]

Hi,

On Tue, Nov 11, 2025 at 11:58 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 11/11/2025 20:22, Douglas Anderson wrote:
> > Add top-level DT bindings useful for Pixel 10 (frankel), Pixel 10 Pro
> > (blazer), and Pixel 10 Pro XL (mustang).
> >
> > Since overlays are fairly well-supported these days and the downstream
> > Pixel bootloader assumes that the SoC is the base overlay and specific
> > board revisions are overlays, reflect the SoC / board split in the
> > bindings.
> >
> > The SoC in the Pixel 10 series has the marketing name of "Tensor
> > G5". Despite the fact that it sounds very similar to the "Tensor G4",
> > it's a very different chip. Tensor G4 was, for all intents and
> > purposes, a Samsung Exynos offshoot whereas Tensor G5 is entirely its
> > own SoC. This SoC is known internally as "laguna" and canonically
> > referred to in code as "lga". There are two known revisions of the
> > SoC: an A0 pre-production variant (ID 0x000500) and a B0 variant (ID
> > 0x000510) used in production. The ID is canonicaly broken up into a
> > 16-bit SoC product ID, a 4-bit major rev, and a 4-bit minor rev.
> >
> > The dtb for all supported SoC revisions is appended to one of the boot
> > partitions and the bootloader will look at the device trees and pick
> > the correct one. The current bootloader uses a downstream
> > `soc_compatible` node to help it pick the correct device tree. It
> > looks like this:
> >   soc_compatible {
> >     B0 {
> >       description = "LGA B0";
> >       product_id = <0x5>;
> >       major = <0x1>;
> >       minor = <0x0>;
> >       pkg_mode = <0x0>;
> >     };
> >   };
> > Note that `pkg_mode` isn't currently part of the ID on the SoC and the
> > bootloader always assumes 0 for it.
> >
> > In this patch, put the SoC IDs straight into the compatible. Though
> > the bootloader doesn't look at the compatible at the moment, this
> > should be easy to teach the bootloader about.
> >
> > Boards all know their own platform_id / product_id / stage / major /
> > minor / variant. For instance, Google Pixel 10 Pro XL MP1 is:
> > * platform_id (8-bits): 0x07 - frankel/blazer/mustang
> > * product_id (8-bits):  0x05 - mustang
> > * stage (4-bits):       0x06 - MP
> > * major (8-bits):       0x01 - MP 1
> > * minor (8-bits):       0x00 - MP 1.0
> > * variant (8-bits):     0x00 - No special variant
> >
> > When board overlays are packed into the "dtbo" partition, a tool
> > (`mkdtimg`) extracts a board ID and board rev from the overlay and
> > stores that as metadata with the overlay. Downstream, the dtso
> > intended for the Pixel 10 Pro XL MP1 has the following properties at
> > its top-level:
> >   board_id = <0x70506>;
> >   board_rev = <0x010000>;
> >
> > The use of top-level IDs can probably be used for overlays upstream as
> > well, but also add the IDs to the compatible string in case it's
> > useful.
> >
> > Compatible strings are added for all board revisions known to be
> > produced based on downstream sources.
> >
> > A few notes:
> > * If you look at `/proc/device-tree/compatible` and
> >   `/proc/device-tree/model` on a running device, that won't
> >   necessarily be an exact description of the hardware you're running
> >   on. If the bootloader can't find a device tree that's an exact match
> >   then it will pick the best match (within reason--it will never pick
> >   a device tree for a different product--just for different revs of
> >   the same product).
> > * There is no merging of the top-level compatible from the SoC and
> >   board. The compatible string containing IDs for the SoC will not be
> >   found in the device-tree passed to the OS.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> > In the past, attempts to have the SoC as a base device tree and boards
> > supported as overlays has been NAKed. From a previous discussion [1]
> > "Nope, boards are not overlays. Boards are DTB." I believe this needs
> > to be relitigated.
> >
> > In the previous NAK, I didn't see any links to documentation
> > explicitly stating that DTBs have to represent boards. It's also
> > unclear, at least to me, _why_ a DTB would be limited to represent a
> > "board" nor what the definition of a "board" is.
> >
> > As at least one stab at why someone might not want an overlay scheme
> > like this, one could point out that the top-level compatible can be a
> > bit of a mess. Specifically in this scheme the board "compatible" from
> > the overlay will fully replace/hide the SoC "compatible" from the base
> > SoC. If this is truly the main concern, it wouldn't be terribly hard
> > to add a new semantic (maybe selectable via a new additional
> > property?) that caused the compatible strings to be merged in a
> > reasonable way.
> >
> > Aside from dealing with the compatible string, let's think about what
> > a "board" is. I will make the argument here that the SoC qualifies as
> > a "board" and that the main PCB of a phone can be looked at as a
> > "cape" for this SoC "board". While this may sound like a stretch, I
> > would invite a reader to propose a definition of "board" that excludes
> > this. Specifically, it can be noted:
> > * I have a development board at my desk that is "socketed". That is, I
> >   can pull the SoC out and put a different one in. I can swap in a
> >   "rev A0" or a "rev B0" SoC into this socket. Conceivably, I could
> >   even put a "Tensor G6", G7, G8, or G999 in the socket if it was
> >   compatible. In this sense, the "SoC" is a standalone thing that can
> >   be attached to the devboard "cape". The SoC being a standalone thing
> >   is in the name. It's a "system" on a chip.
> > * In case the definition of a board somehow needs a PCB involved, I
> >   can note that on my dev board the CPU socket is soldered onto to a
> >   CPU daughtercard (a PCB!) that then has a board-to-board connector
> >   to the main PCB.
> > * Perhaps one could argue that a dev board like I have describe would
> >   qualify for this SoC/board overlay scheme but that a normal cell
> >   phone wouldn't because the SoC isn't removable. Perhaps removability
> >   is a requirement here? If so, imagine if some company took a
> >   Raspberry Pi, soldered some components directly onto the "expansion"
> >   pins, and resold that to consumers. Does this mean they can't use
> >   overlays?
> >
> > To me, the above arguments justify why SoC DTBs + "board" overlays
> > should be accepted. As far as I can tell, there is no downside and
> > many people who would be made happy with this.
> >
> > [1] https://lore.kernel.org/all/dbeb28be-1aac-400b-87c1-9764aca3a799@kernel.org/
> >
> >  .../devicetree/bindings/arm/google.yaml       | 87 +++++++++++++++----
> >  1 file changed, 68 insertions(+), 19 deletions(-)

> > @@ -41,13 +32,71 @@ properties:
> >                - google,gs101-raven
> >            - const: google,gs101
> >
> > +      # Google Tensor G5 AKA lga (laguna) SoC and boards
> > +      - description: Tensor G5 SoC (laguna)
> > +        items:
> > +          - enum:
> > +              - google,soc-id-0005-rev-00  # A0
> > +              - google,soc-id-0005-rev-10  # B0
>
> SoCs cannot be final compatibles.

Right. I talked about this at length "after the cut" in my patch. See
above. I wish to relitigate this policy and wish to know more details
about where it is documented, the reasons for decision, and where the
boundary exactly lies between something that's allowed to be a final
compatible and something that's not. I made several arguments above
for why I think the SoC should be allowed as a final compatible, so it
would be great if you could respond to them and tell me where I got it
wrong.


> Your commit msg does not explain what
> is 'soc-id' or 'soc_id' in this context.

In the commit message I do say: "SoC: an A0 pre-production variant (ID
0x000500) and a B0 variant (ID 0x000510) used in production. The ID is
canonicaly broken up into a 16-bit SoC product ID, a 4-bit major rev,
and a 4-bit minor rev."

...then, I further say "In this patch, put the SoC IDs straight into
the compatible. Though the bootloader doesn't look at the compatible
at the moment, this should be easy to teach the bootloader about."

The idea here is for the bootloader, which can read the ID of the
current SoC, to be able to pick the right device tree from among
multiple. I am certainly not married to putting the SoC ID in the
compatible like this. As I mentioned above, in downstream device trees
the SoC is stored in a custom node and I thought upstream would hate
that. I also considered giving the `soc@0` node a custom compatible
string and adding properties about the SoC ID underneath that and
teaching the bootloader how to find this, and I can switch to this if
you prefer.

If you have an alternate technique for which the bootloader could pick
a device tree based on the current SoC ID or you have specific wording
that you think I should add to the commit message to explain my
current scheme, I'm happy to adjust things.


> > +          - const: google,lga
> > +      - description: Google Pixel 10 Board (Frankel)
> > +        items:
> > +          - enum:
> > +              - google,pixel-id-070302-rev-000000  # Proto 0
> > +              - google,pixel-id-070302-rev-010000  # Proto 1
> > +              - google,pixel-id-070302-rev-010100  # Proto 1.1
> > +              - google,pixel-id-070303-rev-010000  # EVT 1
> > +              - google,pixel-id-070303-rev-010100  # EVT 1.1
> > +              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
> > +              - google,pixel-id-070304-rev-010000  # DVT 1
> > +              - google,pixel-id-070305-rev-010000  # PVT 1
> > +              - google,pixel-id-070306-rev-010000  # MP 1
> > +          - const: google,lga-frankel
> > +          - const: google,lga
>
> So what is the lga?

"google,lga" is the name of the processor. I was under the impression
that the last entry in the top-level compatible string was supposed to
be the SoC compatible string. Certainly this was true in every board
I've worked with and I seem to even recall it being requested by DT
folks. It also seems to match what I see in examples in the kernel
docs [1].

At the moment, the fact that the SoC name is part of the top-level
compatible is used in the Linux driver
"drivers/cpufreq/cpufreq-dt-platdev.c" to implement its blocklist. The
extensive list of compatible strings there shows how prevalent this
concept is.

I seem to recall a previous discussion where Stephen Boyd proposed
that a better place for the SoC compatible string was under the
"soc@0" node. Ah yes, I found at least one [2]  post about it, though
I think there was some earlier discussion too. Do you want me to try
jumping that way?


> What is lga-frankel?

This was an attempt to add a slightly more generic name for the board
in case it was later found to be needed for some reason. I know that,
occasionally, code finds it useful to test a top-level compatible
string to apply a workaround to a specific class of boards. In this
case, if someone needed to detect that they were on a "frankel" board
but didn't care about the specific revision, they could test for this
string.

Alternatively, I could add something like "google,pixel-id-0703xx", or
"google,pixel-id-0703", or something similar which "means"
google,lga-frankel. If you'd prefer this, I'm happy to change it.

I also have no specific need to add the "lga-frankel" compatible
string here other than the fact that it shouldn't really hurt to have
it here, it seems to match the example I pointed to earlier in the
docs [1], and that it could be useful in the future. If you think I
should simply remove it, I can do that. If we later find some need for
it we can add some rules to deal with it then.


> > +allOf:
> >    # Bootloader requires empty ect node to be present
> > -  ect:
> > -    type: object
> > -    additionalProperties: false
>
> Please keep it here

"it" being "additionalProperties", I think? I'm not sure I understand,
but let's discuss below in the context of full examples and not diffs.


> > +  - if:
> > +      properties:
> > +        compatible:
>
> not:
>
> > +          contains:
> > +            const: google,gs101
>
> > +    then:
> > +      properties:
> > +        ect:
>
> ect: false, instead

Trying to understand the above is making my brain hurt. Perhaps I
didn't get enough sleep last night. ...or maybe my brain isn't meant
to directly parse diffs. It's probably easier to just look at
full-blown examples.

Before, we had this:

--

properties:
  ...
  ...
  # Bootloader requires empty ect node to be present
  ect:
    type: object
    additionalProperties: false

required:
  - ect

additionalProperties: true

--

In other words we were _required_ to have an "ect" node with no
properties under it. However, additional properties are allowed in the
root node.

After my patch:

--

properties:
  ..
  ..

allOf:
  # Bootloader requires empty ect node to be present
  - if:
      properties:
        compatible:
          contains:
            const: google,gs101
    then:
      properties:
        ect:
          type: object
          additionalProperties: false

      required:
        - ect

additionalProperties: true

--

In other words, on gs101 we're _required_ to have an "ect" node with
no properties under it. However, additional properties are allowed in
the root node. This seems correct.

The best my brain can parse your request, I think you're asking for this:

--

properties:
  ...
  ...
  ect:
    type: object
    additionalProperties: false

allOf:
  # Bootloader requires empty ect node to be present
  - if:
      properties:
        compatible:
          not:
            contains:
              const: google,gs101
    then:
      properties:
        ect: false
    else:
      required:
      - ect

additionalProperties: true

--

In other words, we still define the "ect" node in the main section and
say that it can't have any extra properties, but we enforce whether
it's required under the "if" statement.

The above has the "downside" compared to my syntax that it bans a node
named "ect" on non-gs101 devices. While this doesn't really hurt, it
also doesn't help. In my mind there's no reason to even think about
(let alone ban) the node "ect" on devices that don't have the gs101
bootloader requirement. Similarly, even though a node named "quack"
would also not really be allowed, we don't have any rule like "quack:
false". :-P

I could also leave the "ect" in the main section and just add the
"required" for "gs101" down below, but then I can't find a use for
your "not:" or "ect: false" lines.

In any case, I'm more than happy to use whatever syntax you prefer for
this, but I'd love it if you could just paste in what you'd like the
syntax to be so I don't need to kill 45 minutes trying to figure it
out, test various hypothesis of what you could mean, and respond. ;-)


[1] https://www.kernel.org/doc/html/v6.17/devicetree/usage-model.html#platform-identification
[2] https://lwn.net/ml/all/20250108012846.3275443-3-swboyd@chromium.org/

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

[Krzysztof Kozlowski]

On 12/11/2025 20:19, Doug Anderson wrote:
> Hi,
> 
> On Tue, Nov 11, 2025 at 11:58 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 11/11/2025 20:22, Douglas Anderson wrote:
>>> Add top-level DT bindings useful for Pixel 10 (frankel), Pixel 10 Pro
>>> (blazer), and Pixel 10 Pro XL (mustang).
>>>
>>> Since overlays are fairly well-supported these days and the downstream
>>> Pixel bootloader assumes that the SoC is the base overlay and specific
>>> board revisions are overlays, reflect the SoC / board split in the
>>> bindings.
>>>
>>> The SoC in the Pixel 10 series has the marketing name of "Tensor
>>> G5". Despite the fact that it sounds very similar to the "Tensor G4",
>>> it's a very different chip. Tensor G4 was, for all intents and
>>> purposes, a Samsung Exynos offshoot whereas Tensor G5 is entirely its
>>> own SoC. This SoC is known internally as "laguna" and canonically
>>> referred to in code as "lga". There are two known revisions of the
>>> SoC: an A0 pre-production variant (ID 0x000500) and a B0 variant (ID
>>> 0x000510) used in production. The ID is canonicaly broken up into a
>>> 16-bit SoC product ID, a 4-bit major rev, and a 4-bit minor rev.
>>>
>>> The dtb for all supported SoC revisions is appended to one of the boot
>>> partitions and the bootloader will look at the device trees and pick
>>> the correct one. The current bootloader uses a downstream
>>> `soc_compatible` node to help it pick the correct device tree. It
>>> looks like this:
>>>   soc_compatible {
>>>     B0 {
>>>       description = "LGA B0";
>>>       product_id = <0x5>;
>>>       major = <0x1>;
>>>       minor = <0x0>;
>>>       pkg_mode = <0x0>;
>>>     };
>>>   };
>>> Note that `pkg_mode` isn't currently part of the ID on the SoC and the
>>> bootloader always assumes 0 for it.
>>>
>>> In this patch, put the SoC IDs straight into the compatible. Though
>>> the bootloader doesn't look at the compatible at the moment, this
>>> should be easy to teach the bootloader about.
>>>
>>> Boards all know their own platform_id / product_id / stage / major /
>>> minor / variant. For instance, Google Pixel 10 Pro XL MP1 is:
>>> * platform_id (8-bits): 0x07 - frankel/blazer/mustang
>>> * product_id (8-bits):  0x05 - mustang
>>> * stage (4-bits):       0x06 - MP
>>> * major (8-bits):       0x01 - MP 1
>>> * minor (8-bits):       0x00 - MP 1.0
>>> * variant (8-bits):     0x00 - No special variant
>>>
>>> When board overlays are packed into the "dtbo" partition, a tool
>>> (`mkdtimg`) extracts a board ID and board rev from the overlay and
>>> stores that as metadata with the overlay. Downstream, the dtso
>>> intended for the Pixel 10 Pro XL MP1 has the following properties at
>>> its top-level:
>>>   board_id = <0x70506>;
>>>   board_rev = <0x010000>;
>>>
>>> The use of top-level IDs can probably be used for overlays upstream as
>>> well, but also add the IDs to the compatible string in case it's
>>> useful.
>>>
>>> Compatible strings are added for all board revisions known to be
>>> produced based on downstream sources.
>>>
>>> A few notes:
>>> * If you look at `/proc/device-tree/compatible` and
>>>   `/proc/device-tree/model` on a running device, that won't
>>>   necessarily be an exact description of the hardware you're running
>>>   on. If the bootloader can't find a device tree that's an exact match
>>>   then it will pick the best match (within reason--it will never pick
>>>   a device tree for a different product--just for different revs of
>>>   the same product).
>>> * There is no merging of the top-level compatible from the SoC and
>>>   board. The compatible string containing IDs for the SoC will not be
>>>   found in the device-tree passed to the OS.
>>>
>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>> ---
>>> In the past, attempts to have the SoC as a base device tree and boards
>>> supported as overlays has been NAKed. From a previous discussion [1]
>>> "Nope, boards are not overlays. Boards are DTB." I believe this needs
>>> to be relitigated.
>>>
>>> In the previous NAK, I didn't see any links to documentation
>>> explicitly stating that DTBs have to represent boards. It's also
>>> unclear, at least to me, _why_ a DTB would be limited to represent a
>>> "board" nor what the definition of a "board" is.
>>>
>>> As at least one stab at why someone might not want an overlay scheme
>>> like this, one could point out that the top-level compatible can be a
>>> bit of a mess. Specifically in this scheme the board "compatible" from
>>> the overlay will fully replace/hide the SoC "compatible" from the base
>>> SoC. If this is truly the main concern, it wouldn't be terribly hard
>>> to add a new semantic (maybe selectable via a new additional
>>> property?) that caused the compatible strings to be merged in a
>>> reasonable way.
>>>
>>> Aside from dealing with the compatible string, let's think about what
>>> a "board" is. I will make the argument here that the SoC qualifies as
>>> a "board" and that the main PCB of a phone can be looked at as a
>>> "cape" for this SoC "board". While this may sound like a stretch, I
>>> would invite a reader to propose a definition of "board" that excludes
>>> this. Specifically, it can be noted:
>>> * I have a development board at my desk that is "socketed". That is, I
>>>   can pull the SoC out and put a different one in. I can swap in a
>>>   "rev A0" or a "rev B0" SoC into this socket. Conceivably, I could
>>>   even put a "Tensor G6", G7, G8, or G999 in the socket if it was
>>>   compatible. In this sense, the "SoC" is a standalone thing that can
>>>   be attached to the devboard "cape". The SoC being a standalone thing
>>>   is in the name. It's a "system" on a chip.
>>> * In case the definition of a board somehow needs a PCB involved, I
>>>   can note that on my dev board the CPU socket is soldered onto to a
>>>   CPU daughtercard (a PCB!) that then has a board-to-board connector
>>>   to the main PCB.
>>> * Perhaps one could argue that a dev board like I have describe would
>>>   qualify for this SoC/board overlay scheme but that a normal cell
>>>   phone wouldn't because the SoC isn't removable. Perhaps removability
>>>   is a requirement here? If so, imagine if some company took a
>>>   Raspberry Pi, soldered some components directly onto the "expansion"
>>>   pins, and resold that to consumers. Does this mean they can't use
>>>   overlays?
>>>
>>> To me, the above arguments justify why SoC DTBs + "board" overlays
>>> should be accepted. As far as I can tell, there is no downside and
>>> many people who would be made happy with this.
>>>
>>> [1] https://lore.kernel.org/all/dbeb28be-1aac-400b-87c1-9764aca3a799@kernel.org/
>>>
>>>  .../devicetree/bindings/arm/google.yaml       | 87 +++++++++++++++----
>>>  1 file changed, 68 insertions(+), 19 deletions(-)
> 
>>> @@ -41,13 +32,71 @@ properties:
>>>                - google,gs101-raven
>>>            - const: google,gs101
>>>
>>> +      # Google Tensor G5 AKA lga (laguna) SoC and boards
>>> +      - description: Tensor G5 SoC (laguna)
>>> +        items:
>>> +          - enum:
>>> +              - google,soc-id-0005-rev-00  # A0
>>> +              - google,soc-id-0005-rev-10  # B0
>>
>> SoCs cannot be final compatibles.
> 
> Right. I talked about this at length "after the cut" in my patch. See
> above. I wish to relitigate this policy and wish to know more details
> about where it is documented, the reasons for decision, and where the
> boundary exactly lies between something that's allowed to be a final
> compatible and something that's not. I made several arguments above
> for why I think the SoC should be allowed as a final compatible, so it

Because this represents a actual device users run. It is electronically,
physically impossible to run the SoC alone.

There are few - one or two - exceptions for the SoMs, but never for SoC.

> would be great if you could respond to them and tell me where I got it
> wrong.
> 
> 
>> Your commit msg does not explain what
>> is 'soc-id' or 'soc_id' in this context.
> 
> In the commit message I do say: "SoC: an A0 pre-production variant (ID
> 0x000500) and a B0 variant (ID 0x000510) used in production. The ID is
> canonicaly broken up into a 16-bit SoC product ID, a 4-bit major rev,
> and a 4-bit minor rev."

> 
> ...then, I further say "In this patch, put the SoC IDs straight into

That's fine.

> the compatible. Though the bootloader doesn't look at the compatible
> at the moment, this should be easy to teach the bootloader about."

But nothing explains why this SoC can be run alone without board.
> 
> The idea here is for the bootloader, which can read the ID of the
> current SoC, to be able to pick the right device tree from among
> multiple. I am certainly not married to putting the SoC ID in the

I am not discussing about style of the compatible. I said - you cannot
have SoC compatible alone. None of above gives any argument for that.

> compatible like this. As I mentioned above, in downstream device trees
> the SoC is stored in a custom node and I thought upstream would hate
> that. I also considered giving the `soc@0` node a custom compatible
> string and adding properties about the SoC ID underneath that and
> teaching the bootloader how to find this, and I can switch to this if
> you prefer.
> 
> If you have an alternate technique for which the bootloader could pick
> a device tree based on the current SoC ID or you have specific wording
> that you think I should add to the commit message to explain my
> current scheme, I'm happy to adjust things.
> 
> 
>>> +          - const: google,lga
>>> +      - description: Google Pixel 10 Board (Frankel)
>>> +        items:
>>> +          - enum:
>>> +              - google,pixel-id-070302-rev-000000  # Proto 0
>>> +              - google,pixel-id-070302-rev-010000  # Proto 1
>>> +              - google,pixel-id-070302-rev-010100  # Proto 1.1
>>> +              - google,pixel-id-070303-rev-010000  # EVT 1
>>> +              - google,pixel-id-070303-rev-010100  # EVT 1.1
>>> +              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
>>> +              - google,pixel-id-070304-rev-010000  # DVT 1
>>> +              - google,pixel-id-070305-rev-010000  # PVT 1
>>> +              - google,pixel-id-070306-rev-010000  # MP 1
>>> +          - const: google,lga-frankel
>>> +          - const: google,lga
>>
>> So what is the lga?
> 
> "google,lga" is the name of the processor. I was under the impression
> that the last entry in the top-level compatible string was supposed to
> be the SoC compatible string. Certainly this was true in every board

google,soc-id-0005-rev-00 is the soc compatible string.

> I've worked with and I seem to even recall it being requested by DT
> folks. It also seems to match what I see in examples in the kernel
> docs [1].

Sorry but no. Writing bindings do not request having two compatibles for
the same soc in two different, independent (orthogonal) lists.

So it is rev-xyz + google,lga-frankel + soc-id + lga, if you need that
soc-id part.

> 
> At the moment, the fact that the SoC name is part of the top-level
> compatible is used in the Linux driver
> "drivers/cpufreq/cpufreq-dt-platdev.c" to implement its blocklist. The
> extensive list of compatible strings there shows how prevalent this
> concept is.
> 
> I seem to recall a previous discussion where Stephen Boyd proposed
> that a better place for the SoC compatible string was under the
> "soc@0" node. Ah yes, I found at least one [2]  post about it, though
> I think there was some earlier discussion too. Do you want me to try
> jumping that way?
> 
> 
>> What is lga-frankel?
> 
> This was an attempt to add a slightly more generic name for the board
> in case it was later found to be needed for some reason. I know that,
> occasionally, code finds it useful to test a top-level compatible
> string to apply a workaround to a specific class of boards. In this
> case, if someone needed to detect that they were on a "frankel" board
> but didn't care about the specific revision, they could test for this
> string.
> 
> Alternatively, I could add something like "google,pixel-id-0703xx", or
> "google,pixel-id-0703", or something similar which "means"
> google,lga-frankel. If you'd prefer this, I'm happy to change it.
> 
> I also have no specific need to add the "lga-frankel" compatible
> string here other than the fact that it shouldn't really hurt to have
> it here, it seems to match the example I pointed to earlier in the
> docs [1], and that it could be useful in the future. If you think I
> should simply remove it, I can do that. If we later find some need for
> it we can add some rules to deal with it then.
> 
> 
>>> +allOf:
>>>    # Bootloader requires empty ect node to be present
>>> -  ect:
>>> -    type: object
>>> -    additionalProperties: false
>>
>> Please keep it here
> 
> "it" being "additionalProperties", I think? I'm not sure I understand,
> but let's discuss below in the context of full examples and not diffs.

I meant ect node, existing hunk. Properties must be defined in top-level.


> 
> 
>>> +  - if:
>>> +      properties:
>>> +        compatible:
>>
>> not:
>>
>>> +          contains:
>>> +            const: google,gs101
>>
>>> +    then:
>>> +      properties:
>>> +        ect:
>>
>> ect: false, instead
> 
> Trying to understand the above is making my brain hurt. Perhaps I
> didn't get enough sleep last night. ...or maybe my brain isn't meant
> to directly parse diffs. It's probably easier to just look at
> full-blown examples.
> 
> Before, we had this:
> 
> --
> 
> properties:
>   ...
>   ...
>   # Bootloader requires empty ect node to be present
>   ect:
>     type: object
>     additionalProperties: false
> 
> required:
>   - ect
> 
> additionalProperties: true
> 
> --
> 
> In other words we were _required_ to have an "ect" node with no
> properties under it. However, additional properties are allowed in the
> root node.
> 
> After my patch:
> 
> --
> 
> properties:
>   ..
>   ..
> 
> allOf:
>   # Bootloader requires empty ect node to be present
>   - if:
>       properties:
>         compatible:
>           contains:
>             const: google,gs101
>     then:
>       properties:
>         ect:
>           type: object
>           additionalProperties: false
> 
>       required:
>         - ect
> 
> additionalProperties: true
> 
> --
> 
> In other words, on gs101 we're _required_ to have an "ect" node with
> no properties under it. However, additional properties are allowed in
> the root node. This seems correct.
> 
> The best my brain can parse your request, I think you're asking for this:
> 
> --
> 
> properties:
>   ...
>   ...
>   ect:
>     type: object
>     additionalProperties: false
> 
> allOf:
>   # Bootloader requires empty ect node to be present
>   - if:
>       properties:
>         compatible:
>           not:
>             contains:
>               const: google,gs101
>     then:
>       properties:
>         ect: false
>     else:
>       required:
>       - ect

Yes, actually now I see you could drop the "not:" and exchange the
"then:else:" branches.

Best regards,
Krzysztof

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

[Doug Anderson]

Hi,

On Wed, Nov 12, 2025 at 11:23 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> >>> +      # Google Tensor G5 AKA lga (laguna) SoC and boards
> >>> +      - description: Tensor G5 SoC (laguna)
> >>> +        items:
> >>> +          - enum:
> >>> +              - google,soc-id-0005-rev-00  # A0
> >>> +              - google,soc-id-0005-rev-10  # B0
> >>
> >> SoCs cannot be final compatibles.
> >
> > Right. I talked about this at length "after the cut" in my patch. See
> > above. I wish to relitigate this policy and wish to know more details
> > about where it is documented, the reasons for decision, and where the
> > boundary exactly lies between something that's allowed to be a final
> > compatible and something that's not. I made several arguments above
> > for why I think the SoC should be allowed as a final compatible, so it
>
> Because this represents a actual device users run. It is electronically,
> physically impossible to run the SoC alone.

I'm not convinced that this definition is as clear as you're making it
out to be. It's physically impossible to run many "boards" alone.

Want to boot up a Raspberry Pi? Provide it with power. Hook up a
display to it. Hook up a keyboard to it. Plug in an Ethernet cable.
Plug an SD card in it. Without those things it doesn't run.

Want to boot up a lga-B0 SoC? Hook up power to the power pins. Connect
a MIPI panel to the MIPI pins. Connect a UFS chip to the UFS pins.
Without those things it doesn't run.

Yes, the complexity of just "hooking up" the components on an SoC is
an order of magnitude harder than a Raspberry Pi, but it's still just
hooking it up to external components. In both cases, we are modeling
the core "brains" (the part that contains the processor) as the DTB
and everything else just "hooks up" to interfaces.

If I had to make a definition for what the base DTB should be it
should be the component with the boot CPU. _Why_ is that the wrong
definition?


> There are few - one or two - exceptions for the SoMs, but never for SoC.

OK, but the big question: _WHY???_

Where does it say that a DTB has to be something that can run "alone"
and (most importantly) what benefit do we get for making that
requirement (AKA _WHY_)? This is the question you're not answering.
From Rob's response, he doesn't seem to think that a DTB needs to be
for something that can boot alone and he seems OK with allowing a
fairly flexible split here. Rob's response was focused on making sure
we can do validation and I'd love to continue on with that discussion.


> > would be great if you could respond to them and tell me where I got it
> > wrong.
> >
> >
> >> Your commit msg does not explain what
> >> is 'soc-id' or 'soc_id' in this context.
> >
> > In the commit message I do say: "SoC: an A0 pre-production variant (ID
> > 0x000500) and a B0 variant (ID 0x000510) used in production. The ID is
> > canonicaly broken up into a 16-bit SoC product ID, a 4-bit major rev,
> > and a 4-bit minor rev."
>
> >
> > ...then, I further say "In this patch, put the SoC IDs straight into
>
> That's fine.
>
> > the compatible. Though the bootloader doesn't look at the compatible
> > at the moment, this should be easy to teach the bootloader about."
>
> But nothing explains why this SoC can be run alone without board.
> >
> > The idea here is for the bootloader, which can read the ID of the
> > current SoC, to be able to pick the right device tree from among
> > multiple. I am certainly not married to putting the SoC ID in the
>
> I am not discussing about style of the compatible. I said - you cannot
> have SoC compatible alone. None of above gives any argument for that.
>
> > compatible like this. As I mentioned above, in downstream device trees
> > the SoC is stored in a custom node and I thought upstream would hate
> > that. I also considered giving the `soc@0` node a custom compatible
> > string and adding properties about the SoC ID underneath that and
> > teaching the bootloader how to find this, and I can switch to this if
> > you prefer.
> >
> > If you have an alternate technique for which the bootloader could pick
> > a device tree based on the current SoC ID or you have specific wording
> > that you think I should add to the commit message to explain my
> > current scheme, I'm happy to adjust things.
> >
> >
> >>> +          - const: google,lga
> >>> +      - description: Google Pixel 10 Board (Frankel)
> >>> +        items:
> >>> +          - enum:
> >>> +              - google,pixel-id-070302-rev-000000  # Proto 0
> >>> +              - google,pixel-id-070302-rev-010000  # Proto 1
> >>> +              - google,pixel-id-070302-rev-010100  # Proto 1.1
> >>> +              - google,pixel-id-070303-rev-010000  # EVT 1
> >>> +              - google,pixel-id-070303-rev-010100  # EVT 1.1
> >>> +              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
> >>> +              - google,pixel-id-070304-rev-010000  # DVT 1
> >>> +              - google,pixel-id-070305-rev-010000  # PVT 1
> >>> +              - google,pixel-id-070306-rev-010000  # MP 1
> >>> +          - const: google,lga-frankel
> >>> +          - const: google,lga
> >>
> >> So what is the lga?
> >
> > "google,lga" is the name of the processor. I was under the impression
> > that the last entry in the top-level compatible string was supposed to
> > be the SoC compatible string. Certainly this was true in every board
>
> google,soc-id-0005-rev-00 is the soc compatible string.
>
> > I've worked with and I seem to even recall it being requested by DT
> > folks. It also seems to match what I see in examples in the kernel
> > docs [1].
>
> Sorry but no. Writing bindings do not request having two compatibles for
> the same soc in two different, independent (orthogonal) lists.
>
> So it is rev-xyz + google,lga-frankel + soc-id + lga, if you need that
> soc-id part.

Probably not worth continuing to discuss until we can agree that the
SoC can be in its own dtb. If we can agree upon that we can talk about
if we need the SoC part in the top-level compatible and how to
accomplish that. I had a few ideas / suggestions in my response to Rob
that roughly break down into:

* Don't model the SoC in the top-level compatible. Maybe put it in the
soc@0 node.

* Come up with a rule for "merging" top-level compatibles if a base
and overlay both define.

Whatever solution we come up with, I want to make sure it handles our
socketed dev boards where the SoC can be removed and replaced with a
different one.


> >>> +allOf:
> >>>    # Bootloader requires empty ect node to be present
> >>> -  ect:
> >>> -    type: object
> >>> -    additionalProperties: false
> >>
> >> Please keep it here
> >
> > "it" being "additionalProperties", I think? I'm not sure I understand,
> > but let's discuss below in the context of full examples and not diffs.
>
> I meant ect node, existing hunk. Properties must be defined in top-level.

OK, much clearer. Thanks!


> > The best my brain can parse your request, I think you're asking for this:
> >
> > --
> >
> > properties:
> >   ...
> >   ...
> >   ect:
> >     type: object
> >     additionalProperties: false
> >
> > allOf:
> >   # Bootloader requires empty ect node to be present
> >   - if:
> >       properties:
> >         compatible:
> >           not:
> >             contains:
> >               const: google,gs101
> >     then:
> >       properties:
> >         ect: false
> >     else:
> >       required:
> >       - ect
>
> Yes, actually now I see you could drop the "not:" and exchange the
> "then:else:" branches.

For the sake of clarity, I'll go with this:

properties:
  ...
  ...
  ect:
    type: object
    additionalProperties: false

allOf:
  # Bootloader requires empty ect node to be present
  - if:
      properties:
        compatible:
          contains:
            const: google,gs101
    then:
      required:
      - ect

additionalProperties: true

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

[Krzysztof Kozlowski]

On 13/11/2025 17:23, Doug Anderson wrote:
> Hi,
> 
> On Wed, Nov 12, 2025 at 11:23 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>>>>> +      # Google Tensor G5 AKA lga (laguna) SoC and boards
>>>>> +      - description: Tensor G5 SoC (laguna)
>>>>> +        items:
>>>>> +          - enum:
>>>>> +              - google,soc-id-0005-rev-00  # A0
>>>>> +              - google,soc-id-0005-rev-10  # B0
>>>>
>>>> SoCs cannot be final compatibles.
>>>
>>> Right. I talked about this at length "after the cut" in my patch. See
>>> above. I wish to relitigate this policy and wish to know more details
>>> about where it is documented, the reasons for decision, and where the
>>> boundary exactly lies between something that's allowed to be a final
>>> compatible and something that's not. I made several arguments above
>>> for why I think the SoC should be allowed as a final compatible, so it
>>
>> Because this represents a actual device users run. It is electronically,
>> physically impossible to run the SoC alone.
> 
> I'm not convinced that this definition is as clear as you're making it
> out to be. It's physically impossible to run many "boards" alone.
> 
> Want to boot up a Raspberry Pi? Provide it with power. Hook up a
> display to it. Hook up a keyboard to it. Plug in an Ethernet cable.
> Plug an SD card in it. Without those things it doesn't run.

But I can plug them...

> 
> Want to boot up a lga-B0 SoC? Hook up power to the power pins. Connect
> a MIPI panel to the MIPI pins. Connect a UFS chip to the UFS pins.
> Without those things it doesn't run.

These I cannot plug, it's impossible for me.

My clumsy fingers are too big for these pins.

And following your logic, we should have the compatible for the
transistors, because that's basically what SoC is made of.

> 
> Yes, the complexity of just "hooking up" the components on an SoC is
> an order of magnitude harder than a Raspberry Pi, but it's still just
> hooking it up to external components. In both cases, we are modeling
> the core "brains" (the part that contains the processor) as the DTB
> and everything else just "hooks up" to interfaces.

You mix the topics, so I don't follow. I speak here about bindings - you
cannot have the that compatible alone, because it is incomplete, just
like compatible for "transistor" is not correct in that context. You
speak what could or could be DTB, different topic.

> 
> If I had to make a definition for what the base DTB should be it
> should be the component with the boot CPU. _Why_ is that the wrong
> definition?
> 
> 
>> There are few - one or two - exceptions for the SoMs, but never for SoC.
> 
> OK, but the big question: _WHY???_
> 
> Where does it say that a DTB has to be something that can run "alone"

We don't discuss DTB here, but the top-level compatibles.

Why? Because DT spec says so.

"Specifies a list of platform architectures with which this platform is
compatible. "

And when you combine it with the standard definition of the
"compatible", it is not *a* "platform architecture" but *list* of
platform architectures describing this device as a whole.


Best regards,
Krzysztof

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

[Doug Anderson]

Hi,

On Thu, Nov 13, 2025 at 8:34 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 13/11/2025 17:23, Doug Anderson wrote:
> > Hi,
> >
> > On Wed, Nov 12, 2025 at 11:23 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >>>>> +      # Google Tensor G5 AKA lga (laguna) SoC and boards
> >>>>> +      - description: Tensor G5 SoC (laguna)
> >>>>> +        items:
> >>>>> +          - enum:
> >>>>> +              - google,soc-id-0005-rev-00  # A0
> >>>>> +              - google,soc-id-0005-rev-10  # B0
> >>>>
> >>>> SoCs cannot be final compatibles.
> >>>
> >>> Right. I talked about this at length "after the cut" in my patch. See
> >>> above. I wish to relitigate this policy and wish to know more details
> >>> about where it is documented, the reasons for decision, and where the
> >>> boundary exactly lies between something that's allowed to be a final
> >>> compatible and something that's not. I made several arguments above
> >>> for why I think the SoC should be allowed as a final compatible, so it
> >>
> >> Because this represents a actual device users run. It is electronically,
> >> physically impossible to run the SoC alone.
> >
> > I'm not convinced that this definition is as clear as you're making it
> > out to be. It's physically impossible to run many "boards" alone.
> >
> > Want to boot up a Raspberry Pi? Provide it with power. Hook up a
> > display to it. Hook up a keyboard to it. Plug in an Ethernet cable.
> > Plug an SD card in it. Without those things it doesn't run.
>
> But I can plug them...

I can plug my lga SoC into my dev board too. My dev board literally
has a place for me to drop in the SoC. I unscrew the socket connector,
carefully make sure that none of the balls of the SoC have dust
particles on them (and we have instructions for cleaning the SoC),
then drop the SoC into the socket (ideally using a vacuum pen tool). I
then screw the top back together which uses compression to attach the
balls on the SoC.

Yes, this is only true on dev boards and not phones, but we want to be
able to support dev boards too and it would be silly to have a
different split between DTB and overlays for dev boards and phones
that are based on the same architecture.


> > Want to boot up a lga-B0 SoC? Hook up power to the power pins. Connect
> > a MIPI panel to the MIPI pins. Connect a UFS chip to the UFS pins.
> > Without those things it doesn't run.
>
> These I cannot plug, it's impossible for me.
>
> My clumsy fingers are too big for these pins.

As per above, sockets do exist. They are pluggable. I have confidence
that even with clumsy fingers you could drop the SoC into the slot and
screw the connector down.

I'm still not totally convinced that it should require the existence
of a socket to justify this but, yes, they do exist.


> And following your logic, we should have the compatible for the
> transistors, because that's basically what SoC is made of.

My logic (stated later in my email) is that the minimum requirement
for a compatible should be something with a CPU able to execute
instructions. A single transistor can't do that. If you want to
combine a bunch of transistors together to make a CPU then absolutely
you should be able to have a DTB representing this CPU.


> > Yes, the complexity of just "hooking up" the components on an SoC is
> > an order of magnitude harder than a Raspberry Pi, but it's still just
> > hooking it up to external components. In both cases, we are modeling
> > the core "brains" (the part that contains the processor) as the DTB
> > and everything else just "hooks up" to interfaces.
>
> You mix the topics, so I don't follow. I speak here about bindings - you
> cannot have the that compatible alone, because it is incomplete, just
> like compatible for "transistor" is not correct in that context. You
> speak what could or could be DTB, different topic.

A "SoC" is "complete". It has a processor that can run instructions.


> > If I had to make a definition for what the base DTB should be it
> > should be the component with the boot CPU. _Why_ is that the wrong
> > definition?
> >
> >
> >> There are few - one or two - exceptions for the SoMs, but never for SoC.
> >
> > OK, but the big question: _WHY???_
> >
> > Where does it say that a DTB has to be something that can run "alone"
>
> We don't discuss DTB here, but the top-level compatibles.
>
> Why? Because DT spec says so.
>
> "Specifies a list of platform architectures with which this platform is
> compatible. "
>
> And when you combine it with the standard definition of the
> "compatible", it is not *a* "platform architecture" but *list* of
> platform architectures describing this device as a whole.

I still don't understand why a SoC doesn't qualify for your
definition. Even if it did, there is _no benefit_ from excluding a SoC
from this definition. I'm trying to figure out what the benefit is for
holding to this stance.

In any case, maybe we can approach this a different way that I alluded
to in one of my other posts. Can we just call the SoC thing something
different and make everyone happy?

1. Rename the SoC file to lga-b0.dtf (device tree fragment) and
_REMOVE_ the top-level compatible. Problem solved--we're not adding a
top-level compatible.

2. Add a special node at the top level of the "dtf" file describing it
(so someone could figure it's useful for). Like:

fragment-info {
  compatible = "google,soc-id";
  google,product-id = <0x5>;
  google,major-rev = <0x1>;
  google,minor-rev = <0x0>;
  google,package-mode = <0x0>;
};

3. We can compile the "dtf" file using existing tools into a "dtfb".
This looks just like a "dtb" but has no top-level compatible but
instead has "fragment-info".

Now we're not violating any spec because we're not adding any
top-level compatible.


-Doug

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

[Krzysztof Kozlowski]

On 13/11/2025 18:16, Doug Anderson wrote:
> Hi,
> 
> On Thu, Nov 13, 2025 at 8:34 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 13/11/2025 17:23, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Wed, Nov 12, 2025 at 11:23 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>
>>>>>>> +      # Google Tensor G5 AKA lga (laguna) SoC and boards
>>>>>>> +      - description: Tensor G5 SoC (laguna)
>>>>>>> +        items:
>>>>>>> +          - enum:
>>>>>>> +              - google,soc-id-0005-rev-00  # A0
>>>>>>> +              - google,soc-id-0005-rev-10  # B0
>>>>>>
>>>>>> SoCs cannot be final compatibles.
>>>>>
>>>>> Right. I talked about this at length "after the cut" in my patch. See
>>>>> above. I wish to relitigate this policy and wish to know more details
>>>>> about where it is documented, the reasons for decision, and where the
>>>>> boundary exactly lies between something that's allowed to be a final
>>>>> compatible and something that's not. I made several arguments above
>>>>> for why I think the SoC should be allowed as a final compatible, so it
>>>>
>>>> Because this represents a actual device users run. It is electronically,
>>>> physically impossible to run the SoC alone.
>>>
>>> I'm not convinced that this definition is as clear as you're making it
>>> out to be. It's physically impossible to run many "boards" alone.
>>>
>>> Want to boot up a Raspberry Pi? Provide it with power. Hook up a
>>> display to it. Hook up a keyboard to it. Plug in an Ethernet cable.
>>> Plug an SD card in it. Without those things it doesn't run.
>>
>> But I can plug them...
> 
> I can plug my lga SoC into my dev board too. My dev board literally

So this will be dev board... If you plug this into dev board, then I
claim that your compatible must be specific for this system thus
describe that product, which is SoC and devboard, not SoC alone.


> has a place for me to drop in the SoC. I unscrew the socket connector,
> carefully make sure that none of the balls of the SoC have dust
> particles on them (and we have instructions for cleaning the SoC),
> then drop the SoC into the socket (ideally using a vacuum pen tool). I
> then screw the top back together which uses compression to attach the
> balls on the SoC.
> 
> Yes, this is only true on dev boards and not phones, but we want to be
> able to support dev boards too and it would be silly to have a
> different split between DTB and overlays for dev boards and phones
> that are based on the same architecture
You still have dev board thus need dev board compatible.

> 
> 
>>> Want to boot up a lga-B0 SoC? Hook up power to the power pins. Connect
>>> a MIPI panel to the MIPI pins. Connect a UFS chip to the UFS pins.
>>> Without those things it doesn't run.
>>
>> These I cannot plug, it's impossible for me.
>>
>> My clumsy fingers are too big for these pins.
> 
> As per above, sockets do exist. They are pluggable. I have confidence
> that even with clumsy fingers you could drop the SoC into the slot and
> screw the connector down.
> 
> I'm still not totally convinced that it should require the existence
> of a socket to justify this but, yes, they do exist.
> 
> 
>> And following your logic, we should have the compatible for the
>> transistors, because that's basically what SoC is made of.
> 
> My logic (stated later in my email) is that the minimum requirement
> for a compatible should be something with a CPU able to execute
> instructions. A single transistor can't do that. If you want to
> combine a bunch of transistors together to make a CPU then absolutely
> you should be able to have a DTB representing this CPU.

Linux cannot execute instructions on this SoC alone. You need dev board.

My clumsy fingers were just example, but you simply cannot run any
software on this SoC without something else.

Virtual models and virtual platforms could be run without that
"something else" and they are allowed to have just the compatible. See
all the FVPs and QEMU platforms.


 >
>>> Yes, the complexity of just "hooking up" the components on an SoC is
>>> an order of magnitude harder than a Raspberry Pi, but it's still just
>>> hooking it up to external components. In both cases, we are modeling
>>> the core "brains" (the part that contains the processor) as the DTB
>>> and everything else just "hooks up" to interfaces.
>>
>> You mix the topics, so I don't follow. I speak here about bindings - you
>> cannot have the that compatible alone, because it is incomplete, just
>> like compatible for "transistor" is not correct in that context. You
>> speak what could or could be DTB, different topic.
> 
> A "SoC" is "complete". It has a processor that can run instructions.

Then show me executing any piece of software, which is the consumer of
the bindings, and runs on the SoC without the rest of the hardware system.

> 
> 
>>> If I had to make a definition for what the base DTB should be it
>>> should be the component with the boot CPU. _Why_ is that the wrong
>>> definition?
>>>
>>>
>>>> There are few - one or two - exceptions for the SoMs, but never for SoC.
>>>
>>> OK, but the big question: _WHY???_
>>>
>>> Where does it say that a DTB has to be something that can run "alone"
>>
>> We don't discuss DTB here, but the top-level compatibles.
>>
>> Why? Because DT spec says so.
>>
>> "Specifies a list of platform architectures with which this platform is
>> compatible. "
>>
>> And when you combine it with the standard definition of the
>> "compatible", it is not *a* "platform architecture" but *list* of
>> platform architectures describing this device as a whole.
> 
> I still don't understand why a SoC doesn't qualify for your
> definition. Even if it did, there is _no benefit_ from excluding a SoC
> from this definition. I'm trying to figure out what the benefit is for
> holding to this stance.

We write bindings for users. There is no user of SoC and such compatible
alone. There is no such real use case.

Your use case is broken bootloader which pretends there is no board, but
there is a board, someone just did not want to admit it.

We don't develop for such use cases.

> 
> In any case, maybe we can approach this a different way that I alluded
> to in one of my other posts. Can we just call the SoC thing something
> different and make everyone happy?
> 
> 1. Rename the SoC file to lga-b0.dtf (device tree fragment) and
> _REMOVE_ the top-level compatible. Problem solved--we're not adding a
> top-level compatible.
> 
> 2. Add a special node at the top level of the "dtf" file describing it
> (so someone could figure it's useful for). Like:
> 
> fragment-info {
>   compatible = "google,soc-id";
>   google,product-id = <0x5>;
>   google,major-rev = <0x1>;
>   google,minor-rev = <0x0>;
>   google,package-mode = <0x0>;
> };
> 
> 3. We can compile the "dtf" file using existing tools into a "dtfb".
> This looks just like a "dtb" but has no top-level compatible but
> instead has "fragment-info".
> 
> Now we're not violating any spec because we're not adding any
> top-level compatible.

Didn't you just describe an overlay or DTSI file?

Best regards,
Krzysztof

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

[Doug Anderson]

Hi,


On Thu, Nov 13, 2025 at 9:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> >>> Yes, the complexity of just "hooking up" the components on an SoC is
> >>> an order of magnitude harder than a Raspberry Pi, but it's still just
> >>> hooking it up to external components. In both cases, we are modeling
> >>> the core "brains" (the part that contains the processor) as the DTB
> >>> and everything else just "hooks up" to interfaces.
> >>
> >> You mix the topics, so I don't follow. I speak here about bindings - you
> >> cannot have the that compatible alone, because it is incomplete, just
> >> like compatible for "transistor" is not correct in that context. You
> >> speak what could or could be DTB, different topic.
> >
> > A "SoC" is "complete". It has a processor that can run instructions.
>
> Then show me executing any piece of software, which is the consumer of
> the bindings, and runs on the SoC without the rest of the hardware system.

Show me something that runs on a Raspberry Pi (the models that don't
have eMMC) that runs without hooking up power and plugging in an SD
card. :-P


> > In any case, maybe we can approach this a different way that I alluded
> > to in one of my other posts. Can we just call the SoC thing something
> > different and make everyone happy?
> >
> > 1. Rename the SoC file to lga-b0.dtf (device tree fragment) and
> > _REMOVE_ the top-level compatible. Problem solved--we're not adding a
> > top-level compatible.
> >
> > 2. Add a special node at the top level of the "dtf" file describing it
> > (so someone could figure it's useful for). Like:
> >
> > fragment-info {
> >   compatible = "google,soc-id";
> >   google,product-id = <0x5>;
> >   google,major-rev = <0x1>;
> >   google,minor-rev = <0x0>;
> >   google,package-mode = <0x0>;
> > };
> >
> > 3. We can compile the "dtf" file using existing tools into a "dtfb".
> > This looks just like a "dtb" but has no top-level compatible but
> > instead has "fragment-info".
> >
> > Now we're not violating any spec because we're not adding any
> > top-level compatible.
>
> Didn't you just describe an overlay or DTSI file?

Sure, you can look at it that way. ...and since you're happy with
"dtsi" files I assume you're happy with my "device tree fragment"
files, right?

The difference here is:

* A "dtf" file must be able to compile (with dtc) on its own. Contrast
with a "dtsi" file could rely on labels that are provided by the file
including it.

* A "dtf" file needs to have "/dts-v1/;" at the top, unlike a "dtsi" file.

* Kernel (or other OS) build rules will be happy compiling a "dtf"
file. This is in contrast with a "dtsi" file.

* A "dtf" file is _intended_ to be compiled and hooked up to an
overlay. This means it will always be compiled with "-@".

* We can document the requirement that a "dtf" file needs to live
together with the overlays that it will be combined with to make
complete device trees. This means that there is no need to set a new
ABI boundary here and we can be flexible with what labels are exported
by the "dtf" file.


If that all sounds reasonable, I'll get working on it right away.

-Doug

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

[Doug Anderson]

Hi,

On Thu, Nov 13, 2025 at 10:04 AM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
>
> On Thu, Nov 13, 2025 at 9:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > >>> Yes, the complexity of just "hooking up" the components on an SoC is
> > >>> an order of magnitude harder than a Raspberry Pi, but it's still just
> > >>> hooking it up to external components. In both cases, we are modeling
> > >>> the core "brains" (the part that contains the processor) as the DTB
> > >>> and everything else just "hooks up" to interfaces.
> > >>
> > >> You mix the topics, so I don't follow. I speak here about bindings - you
> > >> cannot have the that compatible alone, because it is incomplete, just
> > >> like compatible for "transistor" is not correct in that context. You
> > >> speak what could or could be DTB, different topic.
> > >
> > > A "SoC" is "complete". It has a processor that can run instructions.
> >
> > Then show me executing any piece of software, which is the consumer of
> > the bindings, and runs on the SoC without the rest of the hardware system.
>
> Show me something that runs on a Raspberry Pi (the models that don't
> have eMMC) that runs without hooking up power and plugging in an SD
> card. :-P
>
>
> > > In any case, maybe we can approach this a different way that I alluded
> > > to in one of my other posts. Can we just call the SoC thing something
> > > different and make everyone happy?
> > >
> > > 1. Rename the SoC file to lga-b0.dtf (device tree fragment) and
> > > _REMOVE_ the top-level compatible. Problem solved--we're not adding a
> > > top-level compatible.
> > >
> > > 2. Add a special node at the top level of the "dtf" file describing it
> > > (so someone could figure it's useful for). Like:
> > >
> > > fragment-info {
> > >   compatible = "google,soc-id";
> > >   google,product-id = <0x5>;
> > >   google,major-rev = <0x1>;
> > >   google,minor-rev = <0x0>;
> > >   google,package-mode = <0x0>;
> > > };
> > >
> > > 3. We can compile the "dtf" file using existing tools into a "dtfb".
> > > This looks just like a "dtb" but has no top-level compatible but
> > > instead has "fragment-info".
> > >
> > > Now we're not violating any spec because we're not adding any
> > > top-level compatible.
> >
> > Didn't you just describe an overlay or DTSI file?
>
> Sure, you can look at it that way. ...and since you're happy with
> "dtsi" files I assume you're happy with my "device tree fragment"
> files, right?
>
> The difference here is:
>
> * A "dtf" file must be able to compile (with dtc) on its own. Contrast
> with a "dtsi" file could rely on labels that are provided by the file
> including it.
>
> * A "dtf" file needs to have "/dts-v1/;" at the top, unlike a "dtsi" file.
>
> * Kernel (or other OS) build rules will be happy compiling a "dtf"
> file. This is in contrast with a "dtsi" file.
>
> * A "dtf" file is _intended_ to be compiled and hooked up to an
> overlay. This means it will always be compiled with "-@".
>
> * We can document the requirement that a "dtf" file needs to live
> together with the overlays that it will be combined with to make
> complete device trees. This means that there is no need to set a new
> ABI boundary here and we can be flexible with what labels are exported
> by the "dtf" file.
>
>
> If that all sounds reasonable, I'll get working on it right away.

FWIW, I wasn't terribly happy with the name "fragment" or the "dtf"
suffix but couldn't come up with anything better. ...but then I just
had a realization. Perhaps it would be better to think of this as a
"SoC Tree". Thus:

* .sts: SoC tree source
* .stb: SoC tree binary

...and a "SoC" tree it always intended to be the base for a device tree overlay.

This also matches with my assertion that really anything with a CPU on
it should be able to act as the base here.

-Doug

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

[Krzysztof Kozlowski]

On Thu, Nov 13, 2025 at 10:04:53AM -0800, Doug Anderson wrote:
> Hi,
> 
> 
> On Thu, Nov 13, 2025 at 9:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >
> > >>> Yes, the complexity of just "hooking up" the components on an SoC is
> > >>> an order of magnitude harder than a Raspberry Pi, but it's still just
> > >>> hooking it up to external components. In both cases, we are modeling
> > >>> the core "brains" (the part that contains the processor) as the DTB
> > >>> and everything else just "hooks up" to interfaces.
> > >>
> > >> You mix the topics, so I don't follow. I speak here about bindings - you
> > >> cannot have the that compatible alone, because it is incomplete, just
> > >> like compatible for "transistor" is not correct in that context. You
> > >> speak what could or could be DTB, different topic.
> > >
> > > A "SoC" is "complete". It has a processor that can run instructions.
> >
> > Then show me executing any piece of software, which is the consumer of
> > the bindings, and runs on the SoC without the rest of the hardware system.
> 
> Show me something that runs on a Raspberry Pi (the models that don't
> have eMMC) that runs without hooking up power and plugging in an SD
> card. :-P

It has MMC controller/slot described in the DTS and the SDcard itself is
DT-transparent, meaning you do not describe it in DTS, plus I can easily
insert such card, thus for sake of this discussion that RPi still works
fine with DTS.

This SoC cannot work without other pieces described in DT, that's why it
is incomplete and unusable on its own.

You are right that my previous arguments of hooking components are
incomplete, so let me rephrase it - the DTS file should be complete from
DT point of view and completly usable on its own. That's why DTS
represents board (with the exceptions of few SoMs as explaiend to me
long time ago).

SoC does not meet this criteria, therefore it is not suitable for DTS.

And if you claim that SoC could be fitting DTS, then I claim that
individual transistor or one IP block like DWC USB3 could be there as
well. With your arguments we could create DTS files for DWC USB3 nodes.
Fact that transistor or DWC USB3 cannot execute code on their own does
not matter, because it is nowhere said that DTS represents something
which can execute code. CPU executes code, so following this argument
DTS could contain only CPU device nodes..

If we allow subpieces, like SoC components or SoCs (both still unusable
on their own), as DTS files we open the pandora box of all possible
styles and formats. I don't see reasoon why would we want it, what
benefits this would bring to the ecosystem maintenance.

We did not document it that DTS represents usable board, but it is
implied all over the software projects, like GRUB devicetree [1] which
takes one DTB to load. Only one.

[1] https://www.gnu.org/software/grub/manual/grub/html_node/devicetree.html

Best regards,
Krzysztof

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

[Rob Herring]

On Fri, Nov 14, 2025 at 3:26 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Thu, Nov 13, 2025 at 10:04:53AM -0800, Doug Anderson wrote:
> > Hi,
> >
> >
> > On Thu, Nov 13, 2025 at 9:43 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > >
> > > >>> Yes, the complexity of just "hooking up" the components on an SoC is
> > > >>> an order of magnitude harder than a Raspberry Pi, but it's still just
> > > >>> hooking it up to external components. In both cases, we are modeling
> > > >>> the core "brains" (the part that contains the processor) as the DTB
> > > >>> and everything else just "hooks up" to interfaces.
> > > >>
> > > >> You mix the topics, so I don't follow. I speak here about bindings - you
> > > >> cannot have the that compatible alone, because it is incomplete, just
> > > >> like compatible for "transistor" is not correct in that context. You
> > > >> speak what could or could be DTB, different topic.
> > > >
> > > > A "SoC" is "complete". It has a processor that can run instructions.
> > >
> > > Then show me executing any piece of software, which is the consumer of
> > > the bindings, and runs on the SoC without the rest of the hardware system.
> >
> > Show me something that runs on a Raspberry Pi (the models that don't
> > have eMMC) that runs without hooking up power and plugging in an SD
> > card. :-P
>
> It has MMC controller/slot described in the DTS and the SDcard itself is
> DT-transparent, meaning you do not describe it in DTS, plus I can easily
> insert such card, thus for sake of this discussion that RPi still works
> fine with DTS.
>
> This SoC cannot work without other pieces described in DT, that's why it
> is incomplete and unusable on its own.
>
> You are right that my previous arguments of hooking components are
> incomplete, so let me rephrase it - the DTS file should be complete from
> DT point of view and completly usable on its own. That's why DTS
> represents board (with the exceptions of few SoMs as explaiend to me
> long time ago).
>
> SoC does not meet this criteria, therefore it is not suitable for DTS.
>
> And if you claim that SoC could be fitting DTS, then I claim that
> individual transistor or one IP block like DWC USB3 could be there as
> well. With your arguments we could create DTS files for DWC USB3 nodes.
> Fact that transistor or DWC USB3 cannot execute code on their own does
> not matter, because it is nowhere said that DTS represents something
> which can execute code. CPU executes code, so following this argument
> DTS could contain only CPU device nodes..
>
> If we allow subpieces, like SoC components or SoCs (both still unusable
> on their own), as DTS files we open the pandora box of all possible
> styles and formats. I don't see reasoon why would we want it, what
> benefits this would bring to the ecosystem maintenance.
>
> We did not document it that DTS represents usable board, but it is
> implied all over the software projects, like GRUB devicetree [1] which
> takes one DTB to load. Only one.

Obviously at the grub and kernel level we support only 1 DTB. No one
is debating that here. Can we back up and stop debating implementation
details.

The problem is in early boot before there's DT used where you
determine the SoC and/or board at runtime and need to load the DTB
from that information. Both are dynamic in Google's case, but it could
easily be only the SoC or only the board is determined at runtime.
There's another similar usecase of booting a SoM with a SoM DT and
then applying the baseboard DT overlay. You could want to do both in
the same system. Your options are either have every possible
combination as a full DT or have a way to combine them at runtime in
some way. I'm pretty certain the answer for the former will be there's
not enough storage. So that leaves the latter option.

The only real answers here are a) your usecase is not valid or b) how
to implement the usecase.

Rob

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

[Rob Herring]

On Tue, Nov 11, 2025 at 11:22:04AM -0800, Douglas Anderson wrote:
> Add top-level DT bindings useful for Pixel 10 (frankel), Pixel 10 Pro
> (blazer), and Pixel 10 Pro XL (mustang).
> 
> Since overlays are fairly well-supported these days and the downstream
> Pixel bootloader assumes that the SoC is the base overlay and specific
> board revisions are overlays, reflect the SoC / board split in the
> bindings.
> 
> The SoC in the Pixel 10 series has the marketing name of "Tensor
> G5". Despite the fact that it sounds very similar to the "Tensor G4",
> it's a very different chip. Tensor G4 was, for all intents and
> purposes, a Samsung Exynos offshoot whereas Tensor G5 is entirely its
> own SoC. This SoC is known internally as "laguna" and canonically
> referred to in code as "lga". There are two known revisions of the
> SoC: an A0 pre-production variant (ID 0x000500) and a B0 variant (ID
> 0x000510) used in production. The ID is canonicaly broken up into a
> 16-bit SoC product ID, a 4-bit major rev, and a 4-bit minor rev.
> 
> The dtb for all supported SoC revisions is appended to one of the boot
> partitions and the bootloader will look at the device trees and pick
> the correct one. The current bootloader uses a downstream
> `soc_compatible` node to help it pick the correct device tree. It
> looks like this:
>   soc_compatible {
>     B0 {
>       description = "LGA B0";
>       product_id = <0x5>;
>       major = <0x1>;
>       minor = <0x0>;
>       pkg_mode = <0x0>;
>     };
>   };
> Note that `pkg_mode` isn't currently part of the ID on the SoC and the
> bootloader always assumes 0 for it.
> 
> In this patch, put the SoC IDs straight into the compatible. Though
> the bootloader doesn't look at the compatible at the moment, this
> should be easy to teach the bootloader about.
> 
> Boards all know their own platform_id / product_id / stage / major /
> minor / variant. For instance, Google Pixel 10 Pro XL MP1 is:
> * platform_id (8-bits): 0x07 - frankel/blazer/mustang
> * product_id (8-bits):  0x05 - mustang
> * stage (4-bits):       0x06 - MP
> * major (8-bits):       0x01 - MP 1
> * minor (8-bits):       0x00 - MP 1.0
> * variant (8-bits):     0x00 - No special variant
> 
> When board overlays are packed into the "dtbo" partition, a tool
> (`mkdtimg`) extracts a board ID and board rev from the overlay and
> stores that as metadata with the overlay. Downstream, the dtso
> intended for the Pixel 10 Pro XL MP1 has the following properties at
> its top-level:
>   board_id = <0x70506>;
>   board_rev = <0x010000>;
> 
> The use of top-level IDs can probably be used for overlays upstream as
> well, but also add the IDs to the compatible string in case it's
> useful.
> 
> Compatible strings are added for all board revisions known to be
> produced based on downstream sources.
> 
> A few notes:
> * If you look at `/proc/device-tree/compatible` and
>   `/proc/device-tree/model` on a running device, that won't
>   necessarily be an exact description of the hardware you're running
>   on. If the bootloader can't find a device tree that's an exact match
>   then it will pick the best match (within reason--it will never pick
>   a device tree for a different product--just for different revs of
>   the same product).
> * There is no merging of the top-level compatible from the SoC and
>   board. The compatible string containing IDs for the SoC will not be
>   found in the device-tree passed to the OS.

I think this is a problem...

> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> In the past, attempts to have the SoC as a base device tree and boards
> supported as overlays has been NAKed. From a previous discussion [1]
> "Nope, boards are not overlays. Boards are DTB." I believe this needs
> to be relitigated.

I think it is worth having the discussion. There's been some discussions 
about an overlay split with SoMs and baseboards as well. I think that's 
what is driving this addition[1]. I don't think this case is much 
different.

As a different way to combine things compared to .dtsi files, I don't 
care too much how things are structured to the extent that's just 
internal structure and we're moving the combining of files from one 
point in time to another.

My concern here is largely around validation. Can the SoC DTB pass 
validation, and can we still validate the whole thing at build time? To 
start with, it's not great if we have to make the schema allow only an 
SoC compatible without a board compatible. Then suddenly omitting a 
board compatible is always valid. Solving that with an entirely 
different SoC compatible as you have doesn't seem great.

My other concern is whether this is an ABI between the SoC and board 
DTBs? And I don't mean just you, but for anyone wanting to do anything 
remotely similar. An ABI is a problem as we don't really have any way to 
validate each piece separately. (This is already a problem for existing 
overlays.)

> In the previous NAK, I didn't see any links to documentation
> explicitly stating that DTBs have to represent boards. It's also
> unclear, at least to me, _why_ a DTB would be limited to represent a
> "board" nor what the definition of a "board" is.
> 
> As at least one stab at why someone might not want an overlay scheme
> like this, one could point out that the top-level compatible can be a
> bit of a mess. Specifically in this scheme the board "compatible" from
> the overlay will fully replace/hide the SoC "compatible" from the base
> SoC. If this is truly the main concern, it wouldn't be terribly hard
> to add a new semantic (maybe selectable via a new additional
> property?) that caused the compatible strings to be merged in a
> reasonable way.
> 
> Aside from dealing with the compatible string, let's think about what
> a "board" is. I will make the argument here that the SoC qualifies as
> a "board" and that the main PCB of a phone can be looked at as a
> "cape" for this SoC "board". While this may sound like a stretch, I
> would invite a reader to propose a definition of "board" that excludes
> this. Specifically, it can be noted:
> * I have a development board at my desk that is "socketed". That is, I
>   can pull the SoC out and put a different one in. I can swap in a
>   "rev A0" or a "rev B0" SoC into this socket. Conceivably, I could
>   even put a "Tensor G6", G7, G8, or G999 in the socket if it was
>   compatible. In this sense, the "SoC" is a standalone thing that can
>   be attached to the devboard "cape". The SoC being a standalone thing
>   is in the name. It's a "system" on a chip.
> * In case the definition of a board somehow needs a PCB involved, I
>   can note that on my dev board the CPU socket is soldered onto to a
>   CPU daughtercard (a PCB!) that then has a board-to-board connector
>   to the main PCB.
> * Perhaps one could argue that a dev board like I have describe would
>   qualify for this SoC/board overlay scheme but that a normal cell
>   phone wouldn't because the SoC isn't removable. Perhaps removability
>   is a requirement here? If so, imagine if some company took a
>   Raspberry Pi, soldered some components directly onto the "expansion"
>   pins, and resold that to consumers. Does this mean they can't use
>   overlays?
> 
> To me, the above arguments justify why SoC DTBs + "board" overlays
> should be accepted. As far as I can tell, there is no downside and
> many people who would be made happy with this.
> 
> [1] https://lore.kernel.org/all/dbeb28be-1aac-400b-87c1-9764aca3a799@kernel.org/
> 
>  .../devicetree/bindings/arm/google.yaml       | 87 +++++++++++++++----
>  1 file changed, 68 insertions(+), 19 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> index 99961e5282e5..f9f9ea1c8050 100644
> --- a/Documentation/devicetree/bindings/arm/google.yaml
> +++ b/Documentation/devicetree/bindings/arm/google.yaml
> @@ -13,27 +13,18 @@ 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.
> +  These bindings for older Pixel devices don't use device tree overlays so
> +  no separate SoC entry is added. This may change in the future.
>  
> -  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.
> +  Newer Pixel devices are expected to have the SoC device tree as the base
> +  and specific board device trees as overlays.
>  
>  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,13 +32,71 @@ properties:
>                - google,gs101-raven
>            - const: google,gs101
>  
> +      # Google Tensor G5 AKA lga (laguna) SoC and boards
> +      - description: Tensor G5 SoC (laguna)
> +        items:
> +          - enum:
> +              - google,soc-id-0005-rev-00  # A0
> +              - google,soc-id-0005-rev-10  # B0
> +          - const: google,lga
> +      - description: Google Pixel 10 Board (Frankel)
> +        items:
> +          - enum:
> +              - google,pixel-id-070302-rev-000000  # Proto 0
> +              - google,pixel-id-070302-rev-010000  # Proto 1
> +              - google,pixel-id-070302-rev-010100  # Proto 1.1
> +              - google,pixel-id-070303-rev-010000  # EVT 1
> +              - google,pixel-id-070303-rev-010100  # EVT 1.1
> +              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
> +              - google,pixel-id-070304-rev-010000  # DVT 1
> +              - google,pixel-id-070305-rev-010000  # PVT 1
> +              - google,pixel-id-070306-rev-010000  # MP 1

Should upstream really care about anything other than MP1? I don't think 
so. Which ones are useful in 1 year, 2 years, 10 years?

> +          - const: google,lga-frankel
> +          - const: google,lga

It's not clear to me how you map boards to SoC revision? You boot up 
using the SoC DTB and then select the board DTBO based on? This all 
needs to be well defined and general enough any (existing) platform 
could use it. If [1] helps or doesn't work for you I'm interested in 
hearing that.

Rob

[1] https://lore.kernel.org/devicetree-spec/20250911151436.2467758-1-raymond.mao@linaro.org/

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

[Doug Anderson]

Hi,

On Wed, Nov 12, 2025 at 6:27 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Nov 11, 2025 at 11:22:04AM -0800, Douglas Anderson wrote:
> > Add top-level DT bindings useful for Pixel 10 (frankel), Pixel 10 Pro
> > (blazer), and Pixel 10 Pro XL (mustang).
> >
> > Since overlays are fairly well-supported these days and the downstream
> > Pixel bootloader assumes that the SoC is the base overlay and specific
> > board revisions are overlays, reflect the SoC / board split in the
> > bindings.
> >
> > The SoC in the Pixel 10 series has the marketing name of "Tensor
> > G5". Despite the fact that it sounds very similar to the "Tensor G4",
> > it's a very different chip. Tensor G4 was, for all intents and
> > purposes, a Samsung Exynos offshoot whereas Tensor G5 is entirely its
> > own SoC. This SoC is known internally as "laguna" and canonically
> > referred to in code as "lga". There are two known revisions of the
> > SoC: an A0 pre-production variant (ID 0x000500) and a B0 variant (ID
> > 0x000510) used in production. The ID is canonicaly broken up into a
> > 16-bit SoC product ID, a 4-bit major rev, and a 4-bit minor rev.
> >
> > The dtb for all supported SoC revisions is appended to one of the boot
> > partitions and the bootloader will look at the device trees and pick
> > the correct one. The current bootloader uses a downstream
> > `soc_compatible` node to help it pick the correct device tree. It
> > looks like this:
> >   soc_compatible {
> >     B0 {
> >       description = "LGA B0";
> >       product_id = <0x5>;
> >       major = <0x1>;
> >       minor = <0x0>;
> >       pkg_mode = <0x0>;
> >     };
> >   };
> > Note that `pkg_mode` isn't currently part of the ID on the SoC and the
> > bootloader always assumes 0 for it.
> >
> > In this patch, put the SoC IDs straight into the compatible. Though
> > the bootloader doesn't look at the compatible at the moment, this
> > should be easy to teach the bootloader about.
> >
> > Boards all know their own platform_id / product_id / stage / major /
> > minor / variant. For instance, Google Pixel 10 Pro XL MP1 is:
> > * platform_id (8-bits): 0x07 - frankel/blazer/mustang
> > * product_id (8-bits):  0x05 - mustang
> > * stage (4-bits):       0x06 - MP
> > * major (8-bits):       0x01 - MP 1
> > * minor (8-bits):       0x00 - MP 1.0
> > * variant (8-bits):     0x00 - No special variant
> >
> > When board overlays are packed into the "dtbo" partition, a tool
> > (`mkdtimg`) extracts a board ID and board rev from the overlay and
> > stores that as metadata with the overlay. Downstream, the dtso
> > intended for the Pixel 10 Pro XL MP1 has the following properties at
> > its top-level:
> >   board_id = <0x70506>;
> >   board_rev = <0x010000>;
> >
> > The use of top-level IDs can probably be used for overlays upstream as
> > well, but also add the IDs to the compatible string in case it's
> > useful.
> >
> > Compatible strings are added for all board revisions known to be
> > produced based on downstream sources.
> >
> > A few notes:
> > * If you look at `/proc/device-tree/compatible` and
> >   `/proc/device-tree/model` on a running device, that won't
> >   necessarily be an exact description of the hardware you're running
> >   on. If the bootloader can't find a device tree that's an exact match
> >   then it will pick the best match (within reason--it will never pick
> >   a device tree for a different product--just for different revs of
> >   the same product).
> > * There is no merging of the top-level compatible from the SoC and
> >   board. The compatible string containing IDs for the SoC will not be
> >   found in the device-tree passed to the OS.
>
> I think this is a problem...

Fair enough. Is the right answer to add a special rule when applying
overlays to base dtbs? If both the base DTB and the overlay contain a
top-level compatible, should we merge the two instead of having the
overlay replace the base property? Would that be right in all cases?

Specifically, if we were to look at how we handle our dev boards that
are socketed and can handle either SoC rev A0 or SoC rev B0, I guess
the top-level compatible string somehow needs to indicate this
somehow? If we "merged" the compatible strings of the board and the
SoC?

So if we had a deepspace (devboard) with a A0 rev SoC:

base (lga A0):
  google,soc-id-0005-rev-00, google,lga

overlay (deepspace devboard 1)
  google,pixel-id-070101-rev-010000

Final compatible:
  google,pixel-id-070101-rev-010000, google,soc-id-0005-rev-00, google,lga

If we had a deepspace with a B0 rev SoC:

base (lga A0):
  google,soc-id-0005-rev-10, google,lga

overlay (deepspace devboard 1)
  google,pixel-id-070101-rev-010000

Final compatible:
  google,pixel-id-070101-rev-010000, google,soc-id-0005-rev-10, google,lga


...is that what you're thinking? Of course, it still somehow feels
cleaner to me to put the SoC compatible under the "soc@0" node, though
I know that goes against "tradition"... If we did that then the base
SoC "dtb" doesn't need a compatible at all and the board would _just_
have its own compatible.


NOTE: I don't think this is a novel problem. There are already
existing overlays that mess with the top-level compatible...

grep '^\tcompatible' $(find arch/arm64/boot/dts -name '*.dtso')


> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> > In the past, attempts to have the SoC as a base device tree and boards
> > supported as overlays has been NAKed. From a previous discussion [1]
> > "Nope, boards are not overlays. Boards are DTB." I believe this needs
> > to be relitigated.
>
> I think it is worth having the discussion. There's been some discussions
> about an overlay split with SoMs and baseboards as well. I think that's
> what is driving this addition[1]. I don't think this case is much
> different.
>
> As a different way to combine things compared to .dtsi files, I don't
> care too much how things are structured to the extent that's just
> internal structure and we're moving the combining of files from one
> point in time to another.
>
> My concern here is largely around validation. Can the SoC DTB pass
> validation, and can we still validate the whole thing at build time? To
> start with, it's not great if we have to make the schema allow only an
> SoC compatible without a board compatible. Then suddenly omitting a
> board compatible is always valid. Solving that with an entirely
> different SoC compatible as you have doesn't seem great.

I guess, in theory, we could solve this by simply not trying to
validate the SoC "dts" file on its own. Is this as simple as giving it
its own filename suffix? Do we just call it "lga-b0.dtsb" or for
"device tree source base", or something like that? Then we add kernel
rules where we don't validate that on its own but only validate it
together with overlays?


> My other concern is whether this is an ABI between the SoC and board
> DTBs? And I don't mean just you, but for anyone wanting to do anything
> remotely similar. An ABI is a problem as we don't really have any way to
> validate each piece separately. (This is already a problem for existing
> overlays.)

To keep the problem smaller / easier to think about and not try to
solve all existing problems: the only case we're worried about at the
moment is when the base device tree and all overlays are generated at
the same time. That feels like it might be an easier case to handle?


> > In the previous NAK, I didn't see any links to documentation
> > explicitly stating that DTBs have to represent boards. It's also
> > unclear, at least to me, _why_ a DTB would be limited to represent a
> > "board" nor what the definition of a "board" is.
> >
> > As at least one stab at why someone might not want an overlay scheme
> > like this, one could point out that the top-level compatible can be a
> > bit of a mess. Specifically in this scheme the board "compatible" from
> > the overlay will fully replace/hide the SoC "compatible" from the base
> > SoC. If this is truly the main concern, it wouldn't be terribly hard
> > to add a new semantic (maybe selectable via a new additional
> > property?) that caused the compatible strings to be merged in a
> > reasonable way.
> >
> > Aside from dealing with the compatible string, let's think about what
> > a "board" is. I will make the argument here that the SoC qualifies as
> > a "board" and that the main PCB of a phone can be looked at as a
> > "cape" for this SoC "board". While this may sound like a stretch, I
> > would invite a reader to propose a definition of "board" that excludes
> > this. Specifically, it can be noted:
> > * I have a development board at my desk that is "socketed". That is, I
> >   can pull the SoC out and put a different one in. I can swap in a
> >   "rev A0" or a "rev B0" SoC into this socket. Conceivably, I could
> >   even put a "Tensor G6", G7, G8, or G999 in the socket if it was
> >   compatible. In this sense, the "SoC" is a standalone thing that can
> >   be attached to the devboard "cape". The SoC being a standalone thing
> >   is in the name. It's a "system" on a chip.
> > * In case the definition of a board somehow needs a PCB involved, I
> >   can note that on my dev board the CPU socket is soldered onto to a
> >   CPU daughtercard (a PCB!) that then has a board-to-board connector
> >   to the main PCB.
> > * Perhaps one could argue that a dev board like I have describe would
> >   qualify for this SoC/board overlay scheme but that a normal cell
> >   phone wouldn't because the SoC isn't removable. Perhaps removability
> >   is a requirement here? If so, imagine if some company took a
> >   Raspberry Pi, soldered some components directly onto the "expansion"
> >   pins, and resold that to consumers. Does this mean they can't use
> >   overlays?
> >
> > To me, the above arguments justify why SoC DTBs + "board" overlays
> > should be accepted. As far as I can tell, there is no downside and
> > many people who would be made happy with this.
> >
> > [1] https://lore.kernel.org/all/dbeb28be-1aac-400b-87c1-9764aca3a799@kernel.org/
> >
> >  .../devicetree/bindings/arm/google.yaml       | 87 +++++++++++++++----
> >  1 file changed, 68 insertions(+), 19 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> > index 99961e5282e5..f9f9ea1c8050 100644
> > --- a/Documentation/devicetree/bindings/arm/google.yaml
> > +++ b/Documentation/devicetree/bindings/arm/google.yaml
> > @@ -13,27 +13,18 @@ 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.
> > +  These bindings for older Pixel devices don't use device tree overlays so
> > +  no separate SoC entry is added. This may change in the future.
> >
> > -  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.
> > +  Newer Pixel devices are expected to have the SoC device tree as the base
> > +  and specific board device trees as overlays.
> >
> >  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,13 +32,71 @@ properties:
> >                - google,gs101-raven
> >            - const: google,gs101
> >
> > +      # Google Tensor G5 AKA lga (laguna) SoC and boards
> > +      - description: Tensor G5 SoC (laguna)
> > +        items:
> > +          - enum:
> > +              - google,soc-id-0005-rev-00  # A0
> > +              - google,soc-id-0005-rev-10  # B0
> > +          - const: google,lga
> > +      - description: Google Pixel 10 Board (Frankel)
> > +        items:
> > +          - enum:
> > +              - google,pixel-id-070302-rev-000000  # Proto 0
> > +              - google,pixel-id-070302-rev-010000  # Proto 1
> > +              - google,pixel-id-070302-rev-010100  # Proto 1.1
> > +              - google,pixel-id-070303-rev-010000  # EVT 1
> > +              - google,pixel-id-070303-rev-010100  # EVT 1.1
> > +              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
> > +              - google,pixel-id-070304-rev-010000  # DVT 1
> > +              - google,pixel-id-070305-rev-010000  # PVT 1
> > +              - google,pixel-id-070306-rev-010000  # MP 1
>
> Should upstream really care about anything other than MP1? I don't think
> so. Which ones are useful in 1 year, 2 years, 10 years?

I suspect that nearly all of them are useful, though _possibly_ some
of the early proto devices can be removed?

Specifically, engineers at Google will be supporting these devices for
many many years to come. Newer Pixel phones have something like an
8-year support life during which engineers will need to continue to
support them. From my experience on the Pixel team, unless you can
demonstrate a need for something newer it's common to get assigned EVT
1 or EVT 1.1 devices when you request hardware, even for older phones.

Even if end users are unlikely to need these, having them supported
will be essential for those at Google who need to support the product
as a whole.

We've had similar discussions in the past about Chromebooks and the
need to support old hardware, which is why Chromebooks have many
revisions supported. I can tell you that when we tried to drop old
revisions in the past I had angry people come and visit me.


> > +          - const: google,lga-frankel
> > +          - const: google,lga
>
> It's not clear to me how you map boards to SoC revision? You boot up
> using the SoC DTB and then select the board DTBO based on?

The key here is that combining happens in the bootloader. The
bootloader boots up and has its own (non-device tree ways) to handle
things. It then looks at the SoC ID register, looks at the IDs that
tell it what board it's running on, and picks a base DTB (representing
the SoC) and an overlay (representing the board). It combines these
two and passes a single unified device tree to Linux.

Maybe this is a key difference between what we're doing and what
you're thinking of? We're not trying to boot the main OS with just the
base.


> This all
> needs to be well defined and general enough any (existing) platform
> could use it. If [1] helps or doesn't work for you I'm interested in
> hearing that.

> [1] https://lore.kernel.org/devicetree-spec/20250911151436.2467758-1-raymond.mao@linaro.org/

Perhaps I don't understand the proposal, but it doesn't seem useful to
me (?) or at least it's not relevant to the problem we're trying to
solve here.

If I had to guess, I'd say the problem they're trying to solve there
is that they've got some external peripherals (like an i2c-connected
dohickey). They want to ship their dohickey to customers and tell
customers that they can attach the dohickey to any of a number of
devboards. If a customer attaches their dohickey to a Raspberry Pi it
should go on, let's say, i2c5. If it's on a Beagleboard they'll say it
belongs on i2c3. On an stm32 it belongs on i2c11. So they distribute a
bunch of "dtbo" files with their dohickey, one for each target
devboard. This mechanism allows a loader to figure out which devboard
is running and which overlay should be loaded. Is that right?


In our case, the problem is very different. We're really just trying
to pick together all the pieces that make up a full system.

-Doug

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

[Rob Herring]

On Wed, Nov 12, 2025 at 07:29:55PM -0800, Doug Anderson wrote:
> Hi,
> 
> On Wed, Nov 12, 2025 at 6:27 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Nov 11, 2025 at 11:22:04AM -0800, Douglas Anderson wrote:
> > > Add top-level DT bindings useful for Pixel 10 (frankel), Pixel 10 Pro
> > > (blazer), and Pixel 10 Pro XL (mustang).
> > >
> > > Since overlays are fairly well-supported these days and the downstream
> > > Pixel bootloader assumes that the SoC is the base overlay and specific
> > > board revisions are overlays, reflect the SoC / board split in the
> > > bindings.
> > >
> > > The SoC in the Pixel 10 series has the marketing name of "Tensor
> > > G5". Despite the fact that it sounds very similar to the "Tensor G4",
> > > it's a very different chip. Tensor G4 was, for all intents and
> > > purposes, a Samsung Exynos offshoot whereas Tensor G5 is entirely its
> > > own SoC. This SoC is known internally as "laguna" and canonically
> > > referred to in code as "lga". There are two known revisions of the
> > > SoC: an A0 pre-production variant (ID 0x000500) and a B0 variant (ID
> > > 0x000510) used in production. The ID is canonicaly broken up into a
> > > 16-bit SoC product ID, a 4-bit major rev, and a 4-bit minor rev.
> > >
> > > The dtb for all supported SoC revisions is appended to one of the boot
> > > partitions and the bootloader will look at the device trees and pick
> > > the correct one. The current bootloader uses a downstream
> > > `soc_compatible` node to help it pick the correct device tree. It
> > > looks like this:
> > >   soc_compatible {
> > >     B0 {
> > >       description = "LGA B0";
> > >       product_id = <0x5>;
> > >       major = <0x1>;
> > >       minor = <0x0>;
> > >       pkg_mode = <0x0>;
> > >     };
> > >   };
> > > Note that `pkg_mode` isn't currently part of the ID on the SoC and the
> > > bootloader always assumes 0 for it.
> > >
> > > In this patch, put the SoC IDs straight into the compatible. Though
> > > the bootloader doesn't look at the compatible at the moment, this
> > > should be easy to teach the bootloader about.
> > >
> > > Boards all know their own platform_id / product_id / stage / major /
> > > minor / variant. For instance, Google Pixel 10 Pro XL MP1 is:
> > > * platform_id (8-bits): 0x07 - frankel/blazer/mustang
> > > * product_id (8-bits):  0x05 - mustang
> > > * stage (4-bits):       0x06 - MP
> > > * major (8-bits):       0x01 - MP 1
> > > * minor (8-bits):       0x00 - MP 1.0
> > > * variant (8-bits):     0x00 - No special variant
> > >
> > > When board overlays are packed into the "dtbo" partition, a tool
> > > (`mkdtimg`) extracts a board ID and board rev from the overlay and
> > > stores that as metadata with the overlay. Downstream, the dtso
> > > intended for the Pixel 10 Pro XL MP1 has the following properties at
> > > its top-level:
> > >   board_id = <0x70506>;
> > >   board_rev = <0x010000>;
> > >
> > > The use of top-level IDs can probably be used for overlays upstream as
> > > well, but also add the IDs to the compatible string in case it's
> > > useful.
> > >
> > > Compatible strings are added for all board revisions known to be
> > > produced based on downstream sources.
> > >
> > > A few notes:
> > > * If you look at `/proc/device-tree/compatible` and
> > >   `/proc/device-tree/model` on a running device, that won't
> > >   necessarily be an exact description of the hardware you're running
> > >   on. If the bootloader can't find a device tree that's an exact match
> > >   then it will pick the best match (within reason--it will never pick
> > >   a device tree for a different product--just for different revs of
> > >   the same product).
> > > * There is no merging of the top-level compatible from the SoC and
> > >   board. The compatible string containing IDs for the SoC will not be
> > >   found in the device-tree passed to the OS.
> >
> > I think this is a problem...
> 
> Fair enough. Is the right answer to add a special rule when applying
> overlays to base dtbs? If both the base DTB and the overlay contain a
> top-level compatible, should we merge the two instead of having the
> overlay replace the base property? Would that be right in all cases?

That's what has to be figured out. Maybe there's a generic 
rule/transformation or maybe it's platform specifc or both?

> Specifically, if we were to look at how we handle our dev boards that
> are socketed and can handle either SoC rev A0 or SoC rev B0, I guess
> the top-level compatible string somehow needs to indicate this
> somehow? If we "merged" the compatible strings of the board and the
> SoC?

Yes.

> So if we had a deepspace (devboard) with a A0 rev SoC:
> 
> base (lga A0):
>   google,soc-id-0005-rev-00, google,lga
> 
> overlay (deepspace devboard 1)
>   google,pixel-id-070101-rev-010000
> 
> Final compatible:
>   google,pixel-id-070101-rev-010000, google,soc-id-0005-rev-00, google,lga
> 
> If we had a deepspace with a B0 rev SoC:
> 
> base (lga A0):
>   google,soc-id-0005-rev-10, google,lga
> 
> overlay (deepspace devboard 1)
>   google,pixel-id-070101-rev-010000
> 
> Final compatible:
>   google,pixel-id-070101-rev-010000, google,soc-id-0005-rev-10, google,lga
> 
> 
> ...is that what you're thinking? 

Yes, on the final value, but that leaves the base and overlay with 
invalid values.

Maybe we do something like '"", "soc"' and '"board", ""' so the entry is 
present even if the value is not. We still have to put something in the 
schema, but at least it makes it clear these are incomplete values.

> Of course, it still somehow feels
> cleaner to me to put the SoC compatible under the "soc@0" node, though
> I know that goes against "tradition"... If we did that then the base
> SoC "dtb" doesn't need a compatible at all and the board would _just_
> have its own compatible.

The soc@0 node doesn't cover everything in the SoC though. The biggest 
thing being the CPU nodes.


> NOTE: I don't think this is a novel problem. There are already
> existing overlays that mess with the top-level compatible...
> 
> grep '^\tcompatible' $(find arch/arm64/boot/dts -name '*.dtso')

That's empty for me...

But there are certainly .dtsi files which define a compatible that's 
invalid, but they are overwritten by the board .dts file.

> > > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > > ---
> > > In the past, attempts to have the SoC as a base device tree and boards
> > > supported as overlays has been NAKed. From a previous discussion [1]
> > > "Nope, boards are not overlays. Boards are DTB." I believe this needs
> > > to be relitigated.
> >
> > I think it is worth having the discussion. There's been some discussions
> > about an overlay split with SoMs and baseboards as well. I think that's
> > what is driving this addition[1]. I don't think this case is much
> > different.
> >
> > As a different way to combine things compared to .dtsi files, I don't
> > care too much how things are structured to the extent that's just
> > internal structure and we're moving the combining of files from one
> > point in time to another.
> >
> > My concern here is largely around validation. Can the SoC DTB pass
> > validation, and can we still validate the whole thing at build time? To
> > start with, it's not great if we have to make the schema allow only an
> > SoC compatible without a board compatible. Then suddenly omitting a
> > board compatible is always valid. Solving that with an entirely
> > different SoC compatible as you have doesn't seem great.
> 
> I guess, in theory, we could solve this by simply not trying to
> validate the SoC "dts" file on its own. Is this as simple as giving it
> its own filename suffix? Do we just call it "lga-b0.dtsb" or for
> "device tree source base", or something like that? Then we add kernel
> rules where we don't validate that on its own but only validate it
> together with overlays?

We already do that with overlays. They are are not validated on their 
own, and that's why we require them to be applied at build time to 
something. Though that's hard to enforce and I'm not happy with 
extending that to the base.

As an aside, part of what makes validation so slow is N boards 
for an SoC validates the SoC part of the DT N times. I'd like a way to 
have a quicker validate all the SoC DTs.

> > My other concern is whether this is an ABI between the SoC and board
> > DTBs? And I don't mean just you, but for anyone wanting to do anything
> > remotely similar. An ABI is a problem as we don't really have any way to
> > validate each piece separately. (This is already a problem for existing
> > overlays.)
> 
> To keep the problem smaller / easier to think about and not try to
> solve all existing problems: the only case we're worried about at the
> moment is when the base device tree and all overlays are generated at
> the same time. That feels like it might be an easier case to handle?

I know you don't care. I just don't want a mixture here. And if anyone 
wants this to be an ABI, then the pieces need to be validated. Maybe 
everyone is tired of us beating the ABI drum and will be happy if it is 
not.


> > > In the previous NAK, I didn't see any links to documentation
> > > explicitly stating that DTBs have to represent boards. It's also
> > > unclear, at least to me, _why_ a DTB would be limited to represent a
> > > "board" nor what the definition of a "board" is.
> > >
> > > As at least one stab at why someone might not want an overlay scheme
> > > like this, one could point out that the top-level compatible can be a
> > > bit of a mess. Specifically in this scheme the board "compatible" from
> > > the overlay will fully replace/hide the SoC "compatible" from the base
> > > SoC. If this is truly the main concern, it wouldn't be terribly hard
> > > to add a new semantic (maybe selectable via a new additional
> > > property?) that caused the compatible strings to be merged in a
> > > reasonable way.
> > >
> > > Aside from dealing with the compatible string, let's think about what
> > > a "board" is. I will make the argument here that the SoC qualifies as
> > > a "board" and that the main PCB of a phone can be looked at as a
> > > "cape" for this SoC "board". While this may sound like a stretch, I
> > > would invite a reader to propose a definition of "board" that excludes
> > > this. Specifically, it can be noted:
> > > * I have a development board at my desk that is "socketed". That is, I
> > >   can pull the SoC out and put a different one in. I can swap in a
> > >   "rev A0" or a "rev B0" SoC into this socket. Conceivably, I could
> > >   even put a "Tensor G6", G7, G8, or G999 in the socket if it was
> > >   compatible. In this sense, the "SoC" is a standalone thing that can
> > >   be attached to the devboard "cape". The SoC being a standalone thing
> > >   is in the name. It's a "system" on a chip.
> > > * In case the definition of a board somehow needs a PCB involved, I
> > >   can note that on my dev board the CPU socket is soldered onto to a
> > >   CPU daughtercard (a PCB!) that then has a board-to-board connector
> > >   to the main PCB.
> > > * Perhaps one could argue that a dev board like I have describe would
> > >   qualify for this SoC/board overlay scheme but that a normal cell
> > >   phone wouldn't because the SoC isn't removable. Perhaps removability
> > >   is a requirement here? If so, imagine if some company took a
> > >   Raspberry Pi, soldered some components directly onto the "expansion"
> > >   pins, and resold that to consumers. Does this mean they can't use
> > >   overlays?
> > >
> > > To me, the above arguments justify why SoC DTBs + "board" overlays
> > > should be accepted. As far as I can tell, there is no downside and
> > > many people who would be made happy with this.
> > >
> > > [1] https://lore.kernel.org/all/dbeb28be-1aac-400b-87c1-9764aca3a799@kernel.org/
> > >
> > >  .../devicetree/bindings/arm/google.yaml       | 87 +++++++++++++++----
> > >  1 file changed, 68 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/arm/google.yaml b/Documentation/devicetree/bindings/arm/google.yaml
> > > index 99961e5282e5..f9f9ea1c8050 100644
> > > --- a/Documentation/devicetree/bindings/arm/google.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/google.yaml
> > > @@ -13,27 +13,18 @@ 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.
> > > +  These bindings for older Pixel devices don't use device tree overlays so
> > > +  no separate SoC entry is added. This may change in the future.
> > >
> > > -  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.
> > > +  Newer Pixel devices are expected to have the SoC device tree as the base
> > > +  and specific board device trees as overlays.
> > >
> > >  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,13 +32,71 @@ properties:
> > >                - google,gs101-raven
> > >            - const: google,gs101
> > >
> > > +      # Google Tensor G5 AKA lga (laguna) SoC and boards
> > > +      - description: Tensor G5 SoC (laguna)
> > > +        items:
> > > +          - enum:
> > > +              - google,soc-id-0005-rev-00  # A0
> > > +              - google,soc-id-0005-rev-10  # B0
> > > +          - const: google,lga
> > > +      - description: Google Pixel 10 Board (Frankel)
> > > +        items:
> > > +          - enum:
> > > +              - google,pixel-id-070302-rev-000000  # Proto 0
> > > +              - google,pixel-id-070302-rev-010000  # Proto 1
> > > +              - google,pixel-id-070302-rev-010100  # Proto 1.1
> > > +              - google,pixel-id-070303-rev-010000  # EVT 1
> > > +              - google,pixel-id-070303-rev-010100  # EVT 1.1
> > > +              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
> > > +              - google,pixel-id-070304-rev-010000  # DVT 1
> > > +              - google,pixel-id-070305-rev-010000  # PVT 1
> > > +              - google,pixel-id-070306-rev-010000  # MP 1
> >
> > Should upstream really care about anything other than MP1? I don't think
> > so. Which ones are useful in 1 year, 2 years, 10 years?
> 
> I suspect that nearly all of them are useful, though _possibly_ some
> of the early proto devices can be removed?
> 
> Specifically, engineers at Google will be supporting these devices for
> many many years to come. Newer Pixel phones have something like an
> 8-year support life during which engineers will need to continue to
> support them. From my experience on the Pixel team, unless you can
> demonstrate a need for something newer it's common to get assigned EVT
> 1 or EVT 1.1 devices when you request hardware, even for older phones.

Okay, fair enough. I would drop anything you aren't certain you 
need. You can always add it later. It's also only really useful if you 
have DTs with the values *and* you run validation on them. If you do, 
great! If you don't, then upstream is just carrying dead code.

> > > +          - const: google,lga-frankel
> > > +          - const: google,lga
> >
> > It's not clear to me how you map boards to SoC revision? You boot up
> > using the SoC DTB and then select the board DTBO based on?
> 
> The key here is that combining happens in the bootloader. The
> bootloader boots up and has its own (non-device tree ways) to handle
> things. It then looks at the SoC ID register, looks at the IDs that
> tell it what board it's running on, and picks a base DTB (representing
> the SoC) and an overlay (representing the board). It combines these
> two and passes a single unified device tree to Linux.
> 
> Maybe this is a key difference between what we're doing and what
> you're thinking of? We're not trying to boot the main OS with just the
> base.

But others are and I need to worry about both. Conceivably, someone 
might want to do both. First combine the SoC and SoM DTs, and then 
combine that with the full board DT.

> > This all
> > needs to be well defined and general enough any (existing) platform
> > could use it. If [1] helps or doesn't work for you I'm interested in
> > hearing that.
> 
> > [1] https://lore.kernel.org/devicetree-spec/20250911151436.2467758-1-raymond.mao@linaro.org/
> 
> Perhaps I don't understand the proposal, but it doesn't seem useful to
> me (?) or at least it's not relevant to the problem we're trying to
> solve here.

> If I had to guess, I'd say the problem they're trying to solve there
> is that they've got some external peripherals (like an i2c-connected
> dohickey). They want to ship their dohickey to customers and tell
> customers that they can attach the dohickey to any of a number of
> devboards. If a customer attaches their dohickey to a Raspberry Pi it
> should go on, let's say, i2c5. If it's on a Beagleboard they'll say it
> belongs on i2c3. On an stm32 it belongs on i2c11. So they distribute a
> bunch of "dtbo" files with their dohickey, one for each target
> devboard. This mechanism allows a loader to figure out which devboard
> is running and which overlay should be loaded. Is that right?

That would be more the connector usecase.

It's more how do you know if a base DT is a valid target for an overlay 
DT. I guess that's an orthongonal issue. You only have one base in your 
series, but in general how do you know what base to apply the overlays 
to? You've encoded that into the Makefile. The overlay-compatible scheme 
moves that information into the overlay so any s/w can figure that out. 

I think it would help if you described what you want to do more 
generically rather than mixed in with "add a new SoC" and send that to 
devicetree-spec and perhaps boot-architecture lists. Present the 
problem, not just the solution.

Rob

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

[Doug Anderson]

Hi,

On Fri, Nov 14, 2025 at 7:20 AM Rob Herring <robh@kernel.org> wrote:
>
> > NOTE: I don't think this is a novel problem. There are already
> > existing overlays that mess with the top-level compatible...
> >
> > grep '^\tcompatible' $(find arch/arm64/boot/dts -name '*.dtso')
>
> That's empty for me...

Ah, sorry! I didn't know how to represent the tab character in a text
email. You have to replace the \t with a tab character (Ctrl-V Tab if
you're in bash). I should have stated that.


> > > My concern here is largely around validation. Can the SoC DTB pass
> > > validation, and can we still validate the whole thing at build time? To
> > > start with, it's not great if we have to make the schema allow only an
> > > SoC compatible without a board compatible. Then suddenly omitting a
> > > board compatible is always valid. Solving that with an entirely
> > > different SoC compatible as you have doesn't seem great.
> >
> > I guess, in theory, we could solve this by simply not trying to
> > validate the SoC "dts" file on its own. Is this as simple as giving it
> > its own filename suffix? Do we just call it "lga-b0.dtsb" or for
> > "device tree source base", or something like that? Then we add kernel
> > rules where we don't validate that on its own but only validate it
> > together with overlays?
>
> We already do that with overlays. They are are not validated on their
> own, and that's why we require them to be applied at build time to
> something. Though that's hard to enforce and I'm not happy with
> extending that to the base.

OK, fair enough. So the requirements for the SoC-level tree seem to be:

1. The base can be validated on its own.

2. It's obvious that the base isn't "complete" by itself.

3. We expect the top-level compatible string to continue to be
built-up until we consider something a "complete" device tree, so we
need a scheme for this.

Did I miss anything?

Those feel like solvable problems.


> As an aside, part of what makes validation so slow is N boards
> for an SoC validates the SoC part of the DT N times. I'd like a way to
> have a quicker validate all the SoC DTs.

Looking at what's downstream, we do appear to be doing M x N
validation where M = number of SoCs and N = known boards. I'd agree,
that doesn't scale super well. That being said:

1. It's not expected for the number of SoC to scale up very high. I
suspect it would be super rare that a given board could be made to
boot with more than a small handful of different SoCs. Here I'm not
even just thinking about the needs of the Pixel team or Google, but in
general it seems like it would be pretty hard to make a board that
could handle a very big variety of SoCs. I think even if we scale this
to larger things like SoMs, the answer still feels the same. NOTE:
here, I'm only considering the problem of combining things until we
get a "complete" board (one where we're no longer expecting to munge
the top-level compatible string). If a SoM has enough stuff to be
considered "complete" (we stop munging the top-level compatible) then
I think we're back in the pre-existing overlay problem.

2. Even downstream, I believe it's really only the dev boards that
could have various SoCs plugged in. While it's possible someone made
the choice to build half of our "proto 0" boards with A0 stepping and
half with B0 stepping, I can't imagine that happening for more than
one board revision. Thus if D is the number of boards that could have
more than one SoC, the validation would actually be (M x D) + (N - D).
It can be noted that this is the same number of device trees we'd need
to validate if we gave up on using overlays and simply included a full
device tree for every valid combination, like what we did with
Chromebooks.

As far as I can think of, the only way to decrease the amount of
validation would be if we declared some sort of "interface" for the
SoC tree. Then we validate that the SoC trees provide that interface
and we validate the overlays against that interface.

I can't imagine something like that being specified manually for
something as giant as the interface between a board and the SoC that
would let the board validate solely via the interface.

I also can't quite imagine a tool that could somehow analyze all of
the SoC trees and generate some sort of unified interface. The .yaml
files are allowed to have complex enough rules about properties
depending on other properties that it doesn't feel like you'd be able
to succeed.

That being said, I could imagine the idea of manually specifying an
interface for more constrained uses of overlays. For instance, it does
feel like you could maybe express an interface that a "cape" needed,
then validate the "cape" against that.

I'm going to _hope_ that solving this isn't a blocker at this point in time?


> > > My other concern is whether this is an ABI between the SoC and board
> > > DTBs? And I don't mean just you, but for anyone wanting to do anything
> > > remotely similar. An ABI is a problem as we don't really have any way to
> > > validate each piece separately. (This is already a problem for existing
> > > overlays.)
> >
> > To keep the problem smaller / easier to think about and not try to
> > solve all existing problems: the only case we're worried about at the
> > moment is when the base device tree and all overlays are generated at
> > the same time. That feels like it might be an easier case to handle?
>
> I know you don't care. I just don't want a mixture here. And if anyone
> wants this to be an ABI, then the pieces need to be validated.

Hmmm, any way I can convince you that the problem is different? It
sounds as if it fundamentally breaks down into overlays that need to
munge the top-level compatible string and ones that don't.

Overlays that need to munge the top-level compatible string are likely
doing very complex things that are very tightly intertwined with the
tree they're overlaying atop. Yes, someone could pretend that there's
an ABI here and someone could try to build an out-of-tree overlay
against it, but I would argue that it's an unstable ABI you should
expect things to break.

Overlays that _don't_ need to munge the top-level compatible string
are doing things that are much more constrained and it feels like we
_could_ define a tight ABI to validate against. IMO, that's a very
interesting problem to solve, but it's not the problem I'm trying to
solve here.


> Maybe
> everyone is tired of us beating the ABI drum and will be happy if it is
> not.

I certainly appreciate all the work DT folks have done towards
validation and also to making sure that DTs are clean and sensible.
:-) I know my thoughts on the sanctity of overall DT ABI don't always
match DT maintainers, though I certainly understand where you're
coming from and why it's a problem folks try to solve. In any case, I
don't believe that the rules I'm introducing here would interfere with
the sanctity of the overall DT ABI.


> > > > +              - google,pixel-id-070302-rev-000000  # Proto 0
> > > > +              - google,pixel-id-070302-rev-010000  # Proto 1
> > > > +              - google,pixel-id-070302-rev-010100  # Proto 1.1
> > > > +              - google,pixel-id-070303-rev-010000  # EVT 1
> > > > +              - google,pixel-id-070303-rev-010100  # EVT 1.1
> > > > +              - google,pixel-id-070303-rev-010101  # EVT 1.1 Wingboard
> > > > +              - google,pixel-id-070304-rev-010000  # DVT 1
> > > > +              - google,pixel-id-070305-rev-010000  # PVT 1
> > > > +              - google,pixel-id-070306-rev-010000  # MP 1
> > >
> > > Should upstream really care about anything other than MP1? I don't think
> > > so. Which ones are useful in 1 year, 2 years, 10 years?
> >
> > I suspect that nearly all of them are useful, though _possibly_ some
> > of the early proto devices can be removed?
> >
> > Specifically, engineers at Google will be supporting these devices for
> > many many years to come. Newer Pixel phones have something like an
> > 8-year support life during which engineers will need to continue to
> > support them. From my experience on the Pixel team, unless you can
> > demonstrate a need for something newer it's common to get assigned EVT
> > 1 or EVT 1.1 devices when you request hardware, even for older phones.
>
> Okay, fair enough. I would drop anything you aren't certain you
> need. You can always add it later. It's also only really useful if you
> have DTs with the values *and* you run validation on them. If you do,
> great! If you don't, then upstream is just carrying dead code.

FWIW, my plan was to document all the compatible strings, but not
necessarily add support for everything. In this series, I added
support for just "-mp", though I'm booting the result on an EVT 1.1
device. With the barebones device tree I've added so far there is no
difference between EVT and MP and the bootloader is OK picking the MP
one since it can't find the EVT one.


> > > > +          - const: google,lga-frankel
> > > > +          - const: google,lga
> > >
> > > It's not clear to me how you map boards to SoC revision? You boot up
> > > using the SoC DTB and then select the board DTBO based on?
> >
> > The key here is that combining happens in the bootloader. The
> > bootloader boots up and has its own (non-device tree ways) to handle
> > things. It then looks at the SoC ID register, looks at the IDs that
> > tell it what board it's running on, and picks a base DTB (representing
> > the SoC) and an overlay (representing the board). It combines these
> > two and passes a single unified device tree to Linux.
> >
> > Maybe this is a key difference between what we're doing and what
> > you're thinking of? We're not trying to boot the main OS with just the
> > base.
>
> But others are and I need to worry about both. Conceivably, someone
> might want to do both. First combine the SoC and SoM DTs, and then
> combine that with the full board DT.

Fair enough. It's something to keep in mind, but I _think_ this case
should be handled by my current ideas.

1. If the SoC, SoM, and board all need to add to the top-level
compatible then they use my scheme. All valid combinations need to be
enumerated in the kernel Makefile and no stable ABI is intended
between the SoC, SoM and board.

2. If the SoC and SoM together make a "complete" top-level compatible
and the board doesn't munge with it, then we just need all
combinations of the SoC / SoM to be enumerated in the kernel Makefile
and the board simply falls into the existing "it's an overlay"
scenario.


So anything that is an "incomplete" tree (doesn't have a full
compatible string) is marked as such. TBD exactly how. Incomplete
trees can still be validated on their own. All valid users of
incomplete trees must be stored together with them so they can be
validated, and all possible combinations must be enumerated. No ABI is
provided from an incomplete tree to an overlay that wasn't enumerated.


> > > This all
> > > needs to be well defined and general enough any (existing) platform
> > > could use it. If [1] helps or doesn't work for you I'm interested in
> > > hearing that.
> >
> > > [1] https://lore.kernel.org/devicetree-spec/20250911151436.2467758-1-raymond.mao@linaro.org/
> >
> > Perhaps I don't understand the proposal, but it doesn't seem useful to
> > me (?) or at least it's not relevant to the problem we're trying to
> > solve here.
>
> > If I had to guess, I'd say the problem they're trying to solve there
> > is that they've got some external peripherals (like an i2c-connected
> > dohickey). They want to ship their dohickey to customers and tell
> > customers that they can attach the dohickey to any of a number of
> > devboards. If a customer attaches their dohickey to a Raspberry Pi it
> > should go on, let's say, i2c5. If it's on a Beagleboard they'll say it
> > belongs on i2c3. On an stm32 it belongs on i2c11. So they distribute a
> > bunch of "dtbo" files with their dohickey, one for each target
> > devboard. This mechanism allows a loader to figure out which devboard
> > is running and which overlay should be loaded. Is that right?
>
> That would be more the connector usecase.

Right. It was the only usecase I could come up with where having the
base device tree compatible name was both necessary and sufficient for
knowing if an overlay should be applied. :-)


> It's more how do you know if a base DT is a valid target for an overlay
> DT. I guess that's an orthongonal issue. You only have one base in your
> series, but in general how do you know what base to apply the overlays
> to? You've encoded that into the Makefile. The overlay-compatible scheme
> moves that information into the overlay so any s/w can figure that out.

I talked about this a bit in the 4th patch in this series. In my mind,
every possible "loader" of the overlays will need different
information, so there shouldn't be just one scheme. I explored that
idea a bit [1] and I proposed something like this:

/ {
  loaders {
    mkdtimg {
      board-id = <0x1234>;
      board-rev = <0x5678>;
    };
    other-loader {
      something-else  <0xaaaa>;
    };
  };

Then under the "loaders" node we have node names that need to match
exactly for various loaders and then properties that they need. That's
just a quick proposal for the syntax, so happy for that to change. We
would definitely want to add some sort of bindings doc to let us
validate that.

Yes, clearly there could be lots of "loaders" out there, but I would
expect this number to be fairly constrained? If nothing else, if you
think someone's loader isn't worth supporting I guess you could deny
their bindings...

I have no idea what "loader" (other than "higher-level software or
firmware") is intended to consume the "overlay-compatible" of the
proposal you pointed at, but information that could go into the
bindings doc and would actually help me understand why the base device
tree compatible name was necessary and sufficient. :-) NOTE: if two
loaders can both use the same information, that's certainly OK too. We
could name the node after the loader that came first, right?


You correctly point out that I've encoded possible combinations in the
Makefile, but this is more in terms of enumerating possible
combinations so they can be validated. It does nothing to help the
loader pick the right one.


> I think it would help if you described what you want to do more
> generically rather than mixed in with "add a new SoC" and send that to
> devicetree-spec and perhaps boot-architecture lists. Present the
> problem, not just the solution.

Sure, though I think the problem has been discussed at length in a
number of situations before (mailing lists, conferences, etc). Each
time it seems like it ends up being too complicated and folks hit dead
ends and stop trying to upstream. Downstream just keeps doing their
own downstream things because there are tons of people all hitting the
same problem and there's no upstream solution.

IMO we need to start moving into the realm of solutions. I understand
that upstream doesn't want to accept some poorly-thought-out scheme
that will cause long-term grief, but at some point it feels like we
need to accept something that's "not too bad" so that we can at least
iterate from there.

After re-reading all the above, it feels like we're not that far from
a solution, though perhaps you'll read it all and say that you hate it
and that we're not as close as I thought. ;-)

[1] http://lore.kernel.org/r/CAD=FV=W3CTMkWPMN5GqGg_L_bUT2Q9vLpc43p5kWAf+j5HBEGA@mail.gmail.com


-Doug

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

[Doug Anderson]

Hi,

On Fri, Nov 14, 2025 at 10:53 AM Doug Anderson <dianders@chromium.org> wrote:
>
> > I think it would help if you described what you want to do more
> > generically rather than mixed in with "add a new SoC" and send that to
> > devicetree-spec and perhaps boot-architecture lists. Present the
> > problem, not just the solution.
>
> Sure, though I think the problem has been discussed at length in a
> number of situations before (mailing lists, conferences, etc). Each
> time it seems like it ends up being too complicated and folks hit dead
> ends and stop trying to upstream. Downstream just keeps doing their
> own downstream things because there are tons of people all hitting the
> same problem and there's no upstream solution.
>
> IMO we need to start moving into the realm of solutions. I understand
> that upstream doesn't want to accept some poorly-thought-out scheme
> that will cause long-term grief, but at some point it feels like we
> need to accept something that's "not too bad" so that we can at least
> iterate from there.
>
> After re-reading all the above, it feels like we're not that far from
> a solution, though perhaps you'll read it all and say that you hate it
> and that we're not as close as I thought. ;-)

I've taken your advice and posted to the devicetree-spec and
boot-architecture lists. To connect anyone that was following this
conversation, see:

https://lore.kernel.org/r/CAD=FV=Ux7nGFnYEyX0cUL-9__BKnTYc+kAJjkF458ZnFS7zoJA@mail.gmail.com

I've done my best to include all the concerns / points that were
brought up in this thread.

-Doug

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

[Douglas Anderson]

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

 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 cb9da6c97afc..df6a7558a9f2 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
@@ -53,6 +53,7 @@ properties:
           - enum:
               - brcm,bcm11351-dw-apb-uart
               - brcm,bcm21664-dw-apb-uart
+              - google,lga-uart
               - rockchip,px30-uart
               - rockchip,rk1808-uart
               - rockchip,rk3036-uart
-- 
2.51.2.1041.gc1ab5b90ca-goog

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

[Krzysztof Kozlowski]

On 11/11/2025 20:22, Douglas Anderson wrote:
> 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>

Best regards,
Krzysztof

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

[Douglas Anderson]

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.

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

 MAINTAINERS                         | 1 +
 arch/arm64/Kconfig.platforms        | 6 ++++++
 arch/arm64/boot/dts/Makefile        | 1 +
 arch/arm64/boot/dts/google/Makefile | 1 +
 4 files changed, 9 insertions(+)
 create mode 100644 arch/arm64/boot/dts/google/Makefile

diff --git a/MAINTAINERS b/MAINTAINERS
index ddecf1ef3bed..f73a247ec61c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10606,6 +10606,7 @@ C:	irc://irc.oftc.net/pixel6-kernel-dev
 F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
 F:	Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
 F:	arch/arm64/boot/dts/exynos/google/
+F:	arch/arm64/boot/dts/google/
 F:	drivers/clk/samsung/clk-gs101.c
 F:	drivers/phy/samsung/phy-gs101-ufs.c
 F:	include/dt-bindings/clock/google,gs101.h
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 13173795c43d..044af9a3b45f 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -138,6 +138,12 @@ 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 chips starting at the
+	  Google Tensor G5.
+
 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 b0844404eda1..b4b5023d61d2 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -17,6 +17,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.51.2.1041.gc1ab5b90ca-goog

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

[Krzysztof Kozlowski]

On 11/11/2025 20:22, Douglas Anderson wrote:
> 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.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  MAINTAINERS                         | 1 +
>  arch/arm64/Kconfig.platforms        | 6 ++++++
>  arch/arm64/boot/dts/Makefile        | 1 +
>  arch/arm64/boot/dts/google/Makefile | 1 +
>  4 files changed, 9 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/google/Makefile
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ddecf1ef3bed..f73a247ec61c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10606,6 +10606,7 @@ C:	irc://irc.oftc.net/pixel6-kernel-dev
>  F:	Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
>  F:	Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
>  F:	arch/arm64/boot/dts/exynos/google/
> +F:	arch/arm64/boot/dts/google/
>  F:	drivers/clk/samsung/clk-gs101.c
>  F:	drivers/phy/samsung/phy-gs101-ufs.c
>  F:	include/dt-bindings/clock/google,gs101.h


I am fine with this but also please consider having separate maintainers
entry, because, as you said, this is a completely different SoC.

In any case, up to you folks.


> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index 13173795c43d..044af9a3b45f 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -138,6 +138,12 @@ 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 chips starting at the
> +	  Google Tensor G5.
> +
>  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 b0844404eda1..b4b5023d61d2 100644
> --- a/arch/arm64/boot/dts/Makefile
> +++ b/arch/arm64/boot/dts/Makefile
> @@ -17,6 +17,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)
Drop the '+' in GPL license.


Best regards,
Krzysztof

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

[Peter Griffin]

Hi Krzysztof & Doug,

On Wed, 12 Nov 2025 at 08:10, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 11/11/2025 20:22, Douglas Anderson wrote:
> > 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.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> >  MAINTAINERS                         | 1 +
> >  arch/arm64/Kconfig.platforms        | 6 ++++++
> >  arch/arm64/boot/dts/Makefile        | 1 +
> >  arch/arm64/boot/dts/google/Makefile | 1 +
> >  4 files changed, 9 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/google/Makefile
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ddecf1ef3bed..f73a247ec61c 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10606,6 +10606,7 @@ C:    irc://irc.oftc.net/pixel6-kernel-dev
> >  F:   Documentation/devicetree/bindings/clock/google,gs101-clock.yaml
> >  F:   Documentation/devicetree/bindings/soc/google/google,gs101-pmu-intr-gen.yaml
> >  F:   arch/arm64/boot/dts/exynos/google/
> > +F:   arch/arm64/boot/dts/google/
> >  F:   drivers/clk/samsung/clk-gs101.c
> >  F:   drivers/phy/samsung/phy-gs101-ufs.c
> >  F:   include/dt-bindings/clock/google,gs101.h
>
>
> I am fine with this but also please consider having separate maintainers
> entry, because, as you said, this is a completely different SoC.
>
> In any case, up to you folks.

Doug did reach out to me prior to posting. We are OK having it here
(happy to help with Laguna). Most of the exynos specific SoC drivers
are under ARM/SAMSUNG entry anyway. There will be some Laguna SoC
drivers for pinctrl, clocks etc, but many of the IPs are designware so
likely to have existing entries (uart, i2c, spi, i3c, usb etc).

>
> > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> > index 13173795c43d..044af9a3b45f 100644
> > --- a/arch/arm64/Kconfig.platforms
> > +++ b/arch/arm64/Kconfig.platforms
> > @@ -138,6 +138,12 @@ 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 chips starting at the
> > +       Google Tensor G5.

It might be worth adding (Laguna) here

With that addressed:
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>

regards,

Peter

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

[Linus Walleij]

On Wed, Nov 12, 2025 at 1:26 PM Peter Griffin <peter.griffin@linaro.org> wrote:

> There will be some Laguna SoC
> drivers for pinctrl, clocks etc,

Oh new pin control, interesting!

Will you be doing the upstreaming of that?

Yours,
Linus Walleij

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

[Peter Griffin]

Hi Linus,

On Wed, 12 Nov 2025 at 12:36, Linus Walleij <linus.walleij@linaro.org> wrote:
>
> On Wed, Nov 12, 2025 at 1:26 PM Peter Griffin <peter.griffin@linaro.org> wrote:
>
> > There will be some Laguna SoC
> > drivers for pinctrl, clocks etc,
>
> Oh new pin control, interesting!
>
> Will you be doing the upstreaming of that?

It will most likely be Doug, not sure if he's started looking at that
yet though.

Peter

[PATCH 4/4] arm64: dts: google: Add initial dts for frankel, blazer, and mustang

[Douglas Anderson]

Add barebones 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.

Many things can be noted about these device trees:

1. They are organized as "dts" files for the main SoC and "dtso"
   overlays for the boards. There is discussion about this in the
   bindings patch ("dt-bindings: arm: google: Add bindings for
   frankel/blazer/mustang").
2. They won't boot with the currently shipping bootloader. The current
   bootloader hardcodes several paths to nodes that it wants to update
   and considers it a fatal error if it can't find these nodes.
   Interested parties will need to wait for fixes to land and a new
   bootloader to be rolled out before attempting to use these.
3. They only add one revision (MP1) of each of frankel, blazer, and
   mustang. With this simple barebones device tree, there doesn't
   appear to be any difference between the revisions. More revisions
   will be added as needed in the future. The heuristics in the
   bootloader will pick the MP1 device tree if there are not any
   better matches.
4. They only add the dts for the B0 SoC for now. The A0 SoC support
   can be added later if we find the need.
5. 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.
6. 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.
7. 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.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
To avoid fragmenting the discussion, IMO:
* Let's have the discussion about using the "dts" for SoC and the
  "dtso" for the boards in response to the bindings (patch #1).
* If we want to have a discussion about putting "board-id" and
  "model-id" at the root of the board overlays, we can have it
  here. I'll preemptively note that the "board-id" and "model-id"
  won't show up in the final combined device tree and they are just
  used by the tool (mkdtimg). We could change mkdtimg to parse the
  "compatible" strings of the overlays files (since I've put the IDs
  there too), but official the docs [1] seem to indicate that
  top-level properties like this are OK.

In order for these device trees to pass validation without warnings,
it's assumed you have my dtc patches:
* https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
* https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org

[1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main

 arch/arm64/boot/dts/google/Makefile           |   9 +
 arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
 .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
 .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
 .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
 .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
 6 files changed, 483 insertions(+)
 create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
 create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
 create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
 create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
 create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi

diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
index a6b187e2d631..276001e91632 100644
--- a/arch/arm64/boot/dts/google/Makefile
+++ b/arch/arm64/boot/dts/google/Makefile
@@ -1 +1,10 @@
 # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+
+dtb-$(CONFIG_ARCH_GOOGLE) += \
+	lga-blazer-mp1.dtb \
+	lga-frankel-mp1.dtb \
+	lga-mustang-mp1.dtb
+
+lga-blazer-mp1-dtbs		:= lga-b0.dtb lga-blazer-mp1.dtbo
+lga-frankel-mp1-dtbs		:= lga-b0.dtb lga-frankel-mp1.dtbo
+lga-mustang-mp1-dtbs		:= lga-b0.dtb lga-mustang-mp1.dtbo
diff --git a/arch/arm64/boot/dts/google/lga-b0.dts b/arch/arm64/boot/dts/google/lga-b0.dts
new file mode 100644
index 000000000000..83c2db4f20ef
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-b0.dts
@@ -0,0 +1,391 @@
+// 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>
+
+/ {
+	model = "Google Tensor G5 rev B0";
+	compatible = "google,soc-id-0005-rev-10", "google,lga";
+	#address-cells = <2>;
+	#size-cells = <2>;
+	interrupt-parent = <&gic>;
+
+	memory: memory@80000000 {
+		device_type = "memory";
+		/* We expect the bootloader to fill in the size */
+		reg = <0x00000000 0x80000000 0x00000000 0x00000000>;
+	};
+
+	reserved_memory: reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+	};
+
+	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>;
+			};
+		};
+	};
+
+	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>;
+		};
+	};
+
+	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 {
+	};
+
+	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 { /* TODO ask for CPU IPC CSR */
+			compatible = "arm,gic-v3";
+			reg = <0 0x05880000 0 0x00010000>,
+			      <0 0x05900000 0 0x00200000>;
+			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";
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/google/lga-blazer-mp1.dtso b/arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
new file mode 100644
index 000000000000..1c0248b931e8
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Google Pixel 10 Pro (blazer) MP 1
+ *
+ * Copyright 2024-2025 Google LLC.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include "lga-muzel-common.dtsi"
+
+/ {
+	board-id = <0x070406>;
+	board-rev = <0x010000>;
+};
+
+&{/} {
+	model = "BLAZER MP 1 based on LGA";
+	compatible = "google,pixel-id-070406-rev-010000",
+		     "google,lga-blazer", "google,lga";
+};
diff --git a/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
new file mode 100644
index 000000000000..133494de7a9b
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Google Pixel 10 (frankel) MP 1
+ *
+ * Copyright 2024-2025 Google LLC.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include "lga-muzel-common.dtsi"
+
+/ {
+	board-id = <0x070306>;
+	board-rev = <0x010000>;
+};
+
+&{/} {
+	model = "FRANKEL MP 1 based on LGA";
+	compatible = "google,pixel-id-070306-rev-010000",
+		     "google,lga-frankel", "google,lga";
+};
diff --git a/arch/arm64/boot/dts/google/lga-mustang-mp1.dtso b/arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
new file mode 100644
index 000000000000..1f79bbe48056
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Google Pixel 10 Pro XL (mustang) MP 1
+ *
+ * Copyright 2024-2025 Google LLC.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include "lga-muzel-common.dtsi"
+
+/ {
+	board-id = <0x070506>;
+	board-rev = <0x010000>;
+};
+
+&{/} {
+	model = "MUSTANG MP 1 based on LGA";
+	compatible = "google,pixel-id-070506-rev-010000",
+		     "google,lga-mustang", "google,lga";
+};
diff --git a/arch/arm64/boot/dts/google/lga-muzel-common.dtsi b/arch/arm64/boot/dts/google/lga-muzel-common.dtsi
new file mode 100644
index 000000000000..3505f02f5b36
--- /dev/null
+++ b/arch/arm64/boot/dts/google/lga-muzel-common.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Google Pixel 10 family (mustang + blazer + frankel = muzel) common dtsi.
+ *
+ * Copyright 2024-2025 Google LLC.
+ */
+
+&{/} {
+	chosen {
+		stdout-path = "serial0";
+	};
+
+	aliases {
+		serial0 = "/soc@0/serial@db62000";	/* &lsion_cli16_uart */
+		ufs0 = "/ufs-placeholder";		/* &ufs - TODO "/soc@0/ufs@3c400000" */
+	};
+};
-- 
2.51.2.1041.gc1ab5b90ca-goog

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

[Krzysztof Kozlowski]

On 11/11/2025 20:22, Douglas Anderson wrote:
> Add barebones 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.
> 
> Many things can be noted about these device trees:
> 
> 1. They are organized as "dts" files for the main SoC and "dtso"
>    overlays for the boards. There is discussion about this in the
>    bindings patch ("dt-bindings: arm: google: Add bindings for
>    frankel/blazer/mustang").
> 2. They won't boot with the currently shipping bootloader. The current
>    bootloader hardcodes several paths to nodes that it wants to update
>    and considers it a fatal error if it can't find these nodes.
>    Interested parties will need to wait for fixes to land and a new
>    bootloader to be rolled out before attempting to use these.
> 3. They only add one revision (MP1) of each of frankel, blazer, and
>    mustang. With this simple barebones device tree, there doesn't
>    appear to be any difference between the revisions. More revisions
>    will be added as needed in the future. The heuristics in the
>    bootloader will pick the MP1 device tree if there are not any
>    better matches.
> 4. They only add the dts for the B0 SoC for now. The A0 SoC support
>    can be added later if we find the need.
> 5. 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.
> 6. 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.
> 7. 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.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> To avoid fragmenting the discussion, IMO:
> * Let's have the discussion about using the "dts" for SoC and the
>   "dtso" for the boards in response to the bindings (patch #1).

That's discussion here, bindings are irrelevant to this.

> * If we want to have a discussion about putting "board-id" and
>   "model-id" at the root of the board overlays, we can have it
>   here. I'll preemptively note that the "board-id" and "model-id"
>   won't show up in the final combined device tree and they are just
>   used by the tool (mkdtimg). We could change mkdtimg to parse the
>   "compatible" strings of the overlays files (since I've put the IDs
>   there too), but official the docs [1] seem to indicate that
>   top-level properties like this are OK.
> 
> In order for these device trees to pass validation without warnings,
> it's assumed you have my dtc patches:
> * https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
> * https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org
> 
> [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main
> 
>  arch/arm64/boot/dts/google/Makefile           |   9 +
>  arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
>  .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
>  .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
>  .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
>  .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
>  6 files changed, 483 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
>  create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
>  create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>  create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
>  create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi
> 
> diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
> index a6b187e2d631..276001e91632 100644
> --- a/arch/arm64/boot/dts/google/Makefile
> +++ b/arch/arm64/boot/dts/google/Makefile
> @@ -1 +1,10 @@
>  # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> +
> +dtb-$(CONFIG_ARCH_GOOGLE) += \
> +	lga-blazer-mp1.dtb \
> +	lga-frankel-mp1.dtb \
> +	lga-mustang-mp1.dtb
> +
> +lga-blazer-mp1-dtbs		:= lga-b0.dtb lga-blazer-mp1.dtbo
> +lga-frankel-mp1-dtbs		:= lga-b0.dtb lga-frankel-mp1.dtbo
> +lga-mustang-mp1-dtbs		:= lga-b0.dtb lga-mustang-mp1.dtbo
> diff --git a/arch/arm64/boot/dts/google/lga-b0.dts b/arch/arm64/boot/dts/google/lga-b0.dts
> new file mode 100644
> index 000000000000..83c2db4f20ef
> --- /dev/null
> +++ b/arch/arm64/boot/dts/google/lga-b0.dts
> @@ -0,0 +1,391 @@
> +// 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>
> +
> +/ {
> +	model = "Google Tensor G5 rev B0";
> +	compatible = "google,soc-id-0005-rev-10", "google,lga";

So that's SoC, thus must not be a DTS file, but DTSI.

...


...


> diff --git a/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> new file mode 100644
> index 000000000000..133494de7a9b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso

And that's a board, so DTS.

> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> +/*
> + * Google Pixel 10 (frankel) MP 1
> + *
> + * Copyright 2024-2025 Google LLC.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +#include "lga-muzel-common.dtsi"
> +
> +/ {
> +	board-id = <0x070306>;
> +	board-rev = <0x010000>;

Undocumented ABI, which you cannot document because these properties are
not allowed. You cannot have them.

Best regards,
Krzysztof

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

[Chen-Yu Tsai]

On Wed, Nov 12, 2025 at 4:14 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 11/11/2025 20:22, Douglas Anderson wrote:
> > Add barebones 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.
> >
> > Many things can be noted about these device trees:
> >
> > 1. They are organized as "dts" files for the main SoC and "dtso"
> >    overlays for the boards. There is discussion about this in the
> >    bindings patch ("dt-bindings: arm: google: Add bindings for
> >    frankel/blazer/mustang").
> > 2. They won't boot with the currently shipping bootloader. The current
> >    bootloader hardcodes several paths to nodes that it wants to update
> >    and considers it a fatal error if it can't find these nodes.
> >    Interested parties will need to wait for fixes to land and a new
> >    bootloader to be rolled out before attempting to use these.
> > 3. They only add one revision (MP1) of each of frankel, blazer, and
> >    mustang. With this simple barebones device tree, there doesn't
> >    appear to be any difference between the revisions. More revisions
> >    will be added as needed in the future. The heuristics in the
> >    bootloader will pick the MP1 device tree if there are not any
> >    better matches.
> > 4. They only add the dts for the B0 SoC for now. The A0 SoC support
> >    can be added later if we find the need.
> > 5. 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.
> > 6. 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.
> > 7. 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.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> > To avoid fragmenting the discussion, IMO:
> > * Let's have the discussion about using the "dts" for SoC and the
> >   "dtso" for the boards in response to the bindings (patch #1).
>
> That's discussion here, bindings are irrelevant to this.
>
> > * If we want to have a discussion about putting "board-id" and
> >   "model-id" at the root of the board overlays, we can have it
> >   here. I'll preemptively note that the "board-id" and "model-id"
> >   won't show up in the final combined device tree and they are just
> >   used by the tool (mkdtimg). We could change mkdtimg to parse the
> >   "compatible" strings of the overlays files (since I've put the IDs
> >   there too), but official the docs [1] seem to indicate that
> >   top-level properties like this are OK.
> >
> > In order for these device trees to pass validation without warnings,
> > it's assumed you have my dtc patches:
> > * https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
> > * https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org
> >
> > [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main
> >
> >  arch/arm64/boot/dts/google/Makefile           |   9 +
> >  arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
> >  .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
> >  .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
> >  .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
> >  .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
> >  6 files changed, 483 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
> >  create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
> >  create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> >  create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
> >  create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi
> >
> > diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
> > index a6b187e2d631..276001e91632 100644
> > --- a/arch/arm64/boot/dts/google/Makefile
> > +++ b/arch/arm64/boot/dts/google/Makefile
> > @@ -1 +1,10 @@
> >  # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> > +
> > +dtb-$(CONFIG_ARCH_GOOGLE) += \
> > +     lga-blazer-mp1.dtb \
> > +     lga-frankel-mp1.dtb \
> > +     lga-mustang-mp1.dtb
> > +
> > +lga-blazer-mp1-dtbs          := lga-b0.dtb lga-blazer-mp1.dtbo
> > +lga-frankel-mp1-dtbs         := lga-b0.dtb lga-frankel-mp1.dtbo
> > +lga-mustang-mp1-dtbs         := lga-b0.dtb lga-mustang-mp1.dtbo
> > diff --git a/arch/arm64/boot/dts/google/lga-b0.dts b/arch/arm64/boot/dts/google/lga-b0.dts
> > new file mode 100644
> > index 000000000000..83c2db4f20ef
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/google/lga-b0.dts
> > @@ -0,0 +1,391 @@
> > +// 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>
> > +
> > +/ {
> > +     model = "Google Tensor G5 rev B0";
> > +     compatible = "google,soc-id-0005-rev-10", "google,lga";
>
> So that's SoC, thus must not be a DTS file, but DTSI.
>
> ...
>
>
> ...
>
>
> > diff --git a/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> > new file mode 100644
> > index 000000000000..133494de7a9b
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>
> And that's a board, so DTS.
>
> > @@ -0,0 +1,22 @@
> > +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> > +/*
> > + * Google Pixel 10 (frankel) MP 1
> > + *
> > + * Copyright 2024-2025 Google LLC.
> > + */
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +
> > +#include "lga-muzel-common.dtsi"
> > +
> > +/ {
> > +     board-id = <0x070306>;
> > +     board-rev = <0x010000>;
>
> Undocumented ABI, which you cannot document because these properties are
> not allowed. You cannot have them.

This is part of the discussion I want to have at Plumbers. But I suppose
we can start here.

The Android DTB partition format uses six 32-bit integers for matching,
as opposed to a compatible string used in FIT images. Two of the integers
are the "id" and "rev" numbers in the example above. The remaining four
are custom and left up to the (vendor) bootloader implementation.

The values for these fields need to be stored somewhere with the .dts.
The compiled DTB is useless if the user cannot build a proper image for
the bootloader to consume, and that involves putting in the right numbers
in these fields. The android "mkdtimg" tool can either take the values
from some known properties within the DTB, or have them fed to it
externally.

So if we don't want these numbers in the dts itself, then we should come
up with some format to store them beside the dts files.


On a similar note, we would have a similar problem with FIT images and
overlays. The FIT image format maps a (series of) compatible string(s)
to one DTB and any number of overlays. If overlays are involved, then
the compatible string cannot come from the DTB itself, and the mapping
must be stored somewhere.


ChenYu

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

[Krzysztof Kozlowski]

On 12/11/2025 10:35, Chen-Yu Tsai wrote:
> On Wed, Nov 12, 2025 at 4:14 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 11/11/2025 20:22, Douglas Anderson wrote:
>>> Add barebones 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.
>>>
>>> Many things can be noted about these device trees:
>>>
>>> 1. They are organized as "dts" files for the main SoC and "dtso"
>>>    overlays for the boards. There is discussion about this in the
>>>    bindings patch ("dt-bindings: arm: google: Add bindings for
>>>    frankel/blazer/mustang").
>>> 2. They won't boot with the currently shipping bootloader. The current
>>>    bootloader hardcodes several paths to nodes that it wants to update
>>>    and considers it a fatal error if it can't find these nodes.
>>>    Interested parties will need to wait for fixes to land and a new
>>>    bootloader to be rolled out before attempting to use these.
>>> 3. They only add one revision (MP1) of each of frankel, blazer, and
>>>    mustang. With this simple barebones device tree, there doesn't
>>>    appear to be any difference between the revisions. More revisions
>>>    will be added as needed in the future. The heuristics in the
>>>    bootloader will pick the MP1 device tree if there are not any
>>>    better matches.
>>> 4. They only add the dts for the B0 SoC for now. The A0 SoC support
>>>    can be added later if we find the need.
>>> 5. 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.
>>> 6. 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.
>>> 7. 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.
>>>
>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>> ---
>>> To avoid fragmenting the discussion, IMO:
>>> * Let's have the discussion about using the "dts" for SoC and the
>>>   "dtso" for the boards in response to the bindings (patch #1).
>>
>> That's discussion here, bindings are irrelevant to this.
>>
>>> * If we want to have a discussion about putting "board-id" and
>>>   "model-id" at the root of the board overlays, we can have it
>>>   here. I'll preemptively note that the "board-id" and "model-id"
>>>   won't show up in the final combined device tree and they are just
>>>   used by the tool (mkdtimg). We could change mkdtimg to parse the
>>>   "compatible" strings of the overlays files (since I've put the IDs
>>>   there too), but official the docs [1] seem to indicate that
>>>   top-level properties like this are OK.
>>>
>>> In order for these device trees to pass validation without warnings,
>>> it's assumed you have my dtc patches:
>>> * https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
>>> * https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org
>>>
>>> [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main
>>>
>>>  arch/arm64/boot/dts/google/Makefile           |   9 +
>>>  arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
>>>  .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
>>>  .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
>>>  .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
>>>  .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
>>>  6 files changed, 483 insertions(+)
>>>  create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
>>>  create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
>>>  create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>>>  create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
>>>  create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi
>>>
>>> diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
>>> index a6b187e2d631..276001e91632 100644
>>> --- a/arch/arm64/boot/dts/google/Makefile
>>> +++ b/arch/arm64/boot/dts/google/Makefile
>>> @@ -1 +1,10 @@
>>>  # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
>>> +
>>> +dtb-$(CONFIG_ARCH_GOOGLE) += \
>>> +     lga-blazer-mp1.dtb \
>>> +     lga-frankel-mp1.dtb \
>>> +     lga-mustang-mp1.dtb
>>> +
>>> +lga-blazer-mp1-dtbs          := lga-b0.dtb lga-blazer-mp1.dtbo
>>> +lga-frankel-mp1-dtbs         := lga-b0.dtb lga-frankel-mp1.dtbo
>>> +lga-mustang-mp1-dtbs         := lga-b0.dtb lga-mustang-mp1.dtbo
>>> diff --git a/arch/arm64/boot/dts/google/lga-b0.dts b/arch/arm64/boot/dts/google/lga-b0.dts
>>> new file mode 100644
>>> index 000000000000..83c2db4f20ef
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/google/lga-b0.dts
>>> @@ -0,0 +1,391 @@
>>> +// 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>
>>> +
>>> +/ {
>>> +     model = "Google Tensor G5 rev B0";
>>> +     compatible = "google,soc-id-0005-rev-10", "google,lga";
>>
>> So that's SoC, thus must not be a DTS file, but DTSI.
>>
>> ...
>>
>>
>> ...
>>
>>
>>> diff --git a/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>>> new file mode 100644
>>> index 000000000000..133494de7a9b
>>> --- /dev/null
>>> +++ b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>>
>> And that's a board, so DTS.
>>
>>> @@ -0,0 +1,22 @@
>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>>> +/*
>>> + * Google Pixel 10 (frankel) MP 1
>>> + *
>>> + * Copyright 2024-2025 Google LLC.
>>> + */
>>> +
>>> +/dts-v1/;
>>> +/plugin/;
>>> +
>>> +#include "lga-muzel-common.dtsi"
>>> +
>>> +/ {
>>> +     board-id = <0x070306>;
>>> +     board-rev = <0x010000>;
>>
>> Undocumented ABI, which you cannot document because these properties are
>> not allowed. You cannot have them.
> 
> This is part of the discussion I want to have at Plumbers. But I suppose
> we can start here.

Then the patch should be called RFC as not yet ready for merging. :)

> 
> The Android DTB partition format uses six 32-bit integers for matching,
> as opposed to a compatible string used in FIT images. Two of the integers
> are the "id" and "rev" numbers in the example above. The remaining four
> are custom and left up to the (vendor) bootloader implementation.
> 
> The values for these fields need to be stored somewhere with the .dts.
> The compiled DTB is useless if the user cannot build a proper image for
> the bootloader to consume, and that involves putting in the right numbers
> in these fields. The android "mkdtimg" tool can either take the values
> from some known properties within the DTB, or have them fed to it
> externally.
> 
> So if we don't want these numbers in the dts itself, then we should come
> up with some format to store them beside the dts files.

Re-iterating comment from Rob long time ago: adding such new properties
is fine, but they must come for more than one user and be universal
across these users.

And of course the ABI needs to be documented which did not happen here.

I indeed said incorrectly that "properties are not allowed". The
properties could be allowed if we document them according to above Rob's
comment, but that did not happen.

Adding these properties per one SoC vendor is not really allowed, like
qcom,board-id and qcom,msm-id, but maybe you intend to make it generic.

> 
> 
> On a similar note, we would have a similar problem with FIT images and
> overlays. The FIT image format maps a (series of) compatible string(s)
> to one DTB and any number of overlays. If overlays are involved, then
> the compatible string cannot come from the DTB itself, and the mapping
> must be stored somewhere.

I recall, although cannot find now references to, a email talk on the
list saying that such overlays should have their own compatible, thus
solving this mapping problem.


Best regards,
Krzysztof

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

[Doug Anderson]

Hi,

On Wed, Nov 12, 2025 at 1:49 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> >>> To avoid fragmenting the discussion, IMO:
> >>> * Let's have the discussion about using the "dts" for SoC and the
> >>>   "dtso" for the boards in response to the bindings (patch #1).
> >>
> >> That's discussion here, bindings are irrelevant to this.

Ummm, OK. In any case, I'm going to wait until our discussion in the
bindings patch about whether SoCs can be final compatibles, then if I
still think extra discussion is needed I'll respond more on this
thread.


> >>> * If we want to have a discussion about putting "board-id" and
> >>>   "model-id" at the root of the board overlays, we can have it
> >>>   here. I'll preemptively note that the "board-id" and "model-id"
> >>>   won't show up in the final combined device tree and they are just
> >>>   used by the tool (mkdtimg). We could change mkdtimg to parse the
> >>>   "compatible" strings of the overlays files (since I've put the IDs
> >>>   there too), but official the docs [1] seem to indicate that
> >>>   top-level properties like this are OK.
> >>>
> >>> In order for these device trees to pass validation without warnings,
> >>> it's assumed you have my dtc patches:
> >>> * https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
> >>> * https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org
> >>>
> >>> [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main

> >>> +     board-id = <0x070306>;
> >>> +     board-rev = <0x010000>;
> >>
> >> Undocumented ABI, which you cannot document because these properties are
> >> not allowed. You cannot have them.
> >
> > This is part of the discussion I want to have at Plumbers. But I suppose
> > we can start here.
>
> Then the patch should be called RFC as not yet ready for merging. :)
>
> >
> > The Android DTB partition format uses six 32-bit integers for matching,
> > as opposed to a compatible string used in FIT images. Two of the integers
> > are the "id" and "rev" numbers in the example above. The remaining four
> > are custom and left up to the (vendor) bootloader implementation.
> >
> > The values for these fields need to be stored somewhere with the .dts.
> > The compiled DTB is useless if the user cannot build a proper image for
> > the bootloader to consume, and that involves putting in the right numbers
> > in these fields. The android "mkdtimg" tool can either take the values
> > from some known properties within the DTB, or have them fed to it
> > externally.
> >
> > So if we don't want these numbers in the dts itself, then we should come
> > up with some format to store them beside the dts files.
>
> Re-iterating comment from Rob long time ago: adding such new properties
> is fine, but they must come for more than one user and be universal
> across these users.
>
> And of course the ABI needs to be documented which did not happen here.
>
> I indeed said incorrectly that "properties are not allowed". The
> properties could be allowed if we document them according to above Rob's
> comment, but that did not happen.
>
> Adding these properties per one SoC vendor is not really allowed, like
> qcom,board-id and qcom,msm-id, but maybe you intend to make it generic.

Perhaps you have a link to Rob's comment from a long time ago?

As per my comment "after the cut" in the original patch (see above),
for my use case, I'm OK with removing the "board-id" and "board-rev"
here. It wouldn't be terribly hard to teach my tool to parse the
top-level compatible. That being said, it would be nice to allow them
at a top-level like this. As Chen-Yu says, there are other interested
parties.

The official documentation that I referred to in my comment "after the
cut" says this about properties directly in the overlays:

```
/dts-v1/;
/plugin/; /* allow undefined references and record them */
/ {
    .... /* various properties for loader use; i.e. part id etc. */
    fragment@0 {
```

So properties are clearly documented to be allowed here. When I read
the above, I interpret it as the properties are "whatever the expected
loader of this overlay would find convenient".

I am more than happy to document which properties my "loader"
(mkdtimg) needs if you have some proposed place or way for me to
document them. I'm happy to do it in freeform text (or markup) for now
if that's what people would accept. Maybe that lets us get started yet
still document things while we figure out what the needs are?


> > On a similar note, we would have a similar problem with FIT images and
> > overlays. The FIT image format maps a (series of) compatible string(s)
> > to one DTB and any number of overlays. If overlays are involved, then
> > the compatible string cannot come from the DTB itself, and the mapping
> > must be stored somewhere.
>
> I recall, although cannot find now references to, a email talk on the
> list saying that such overlays should have their own compatible, thus
> solving this mapping problem.

If you have more details or if Rob wants to re-iterate his thoughts,
I'm happy to discuss.

In my mind, I'd rather this not be a "compatible" but I'm also not
dead set on that. IMO, though it can be made to work, having a
"compatible" here is sorta backwards from what we want. We faced this
issue in ChromeOS when we used the top-level "compatible" to pick the
device tree. Specifically, the normal usage of "compatible" is to
start with the device tree which has a list of compatible strings.
From there, we pick a driver that matches. AKA: we start with some
"compatible" strings and find a matching "thing" (a driver). When
using a "compatible" to pick an overlay / device tree, we start with a
"thing" (a known board) and then pick a list of "compatible" strings
that matches it. Hopefully it's clear how that's a bit different.

As I said, the problems are mostly subtle, but this is how we ended up
with the weirdness on Chromebooks where we had a pile of all equal
"compatible" strings at the top level and that made all the DT folks
grumpy. See, for instance, the sc7180-trogdor-lazor-r1.dts file where
"google,lazor-rev1" and "google,lazor-rev2" are both there. We'll pick
this same DTS for both revisions.

It can be made to work, but IMO it's not a perfect fit.

I'd rather us just pick some standard property that documents the
information that the expected loader should need. Maybe you could even
handle more than one loader type?

/ {
  loaders {
    mkdtimg {
      board-id = <0x1234>;
      board-rev = <0x5678>;
    };
    other-loader {
      something-else  <0xaaaa>;
    };
  };

Then under the "loaders" node we have node names that need to match
exactly for various loaders and then properties that they need.

I haven't tested this, but I believe that since the "loaders" isn't
under any "fragment" that it will just be ignored when the overlay is
applied, so it will just be for the consumption of the loader.


-Doug

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

[Chen-Yu Tsai]

On Wed, Nov 12, 2025 at 5:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 12/11/2025 10:35, Chen-Yu Tsai wrote:
> > On Wed, Nov 12, 2025 at 4:14 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On 11/11/2025 20:22, Douglas Anderson wrote:
> >>> Add barebones 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.
> >>>
> >>> Many things can be noted about these device trees:
> >>>
> >>> 1. They are organized as "dts" files for the main SoC and "dtso"
> >>>    overlays for the boards. There is discussion about this in the
> >>>    bindings patch ("dt-bindings: arm: google: Add bindings for
> >>>    frankel/blazer/mustang").
> >>> 2. They won't boot with the currently shipping bootloader. The current
> >>>    bootloader hardcodes several paths to nodes that it wants to update
> >>>    and considers it a fatal error if it can't find these nodes.
> >>>    Interested parties will need to wait for fixes to land and a new
> >>>    bootloader to be rolled out before attempting to use these.
> >>> 3. They only add one revision (MP1) of each of frankel, blazer, and
> >>>    mustang. With this simple barebones device tree, there doesn't
> >>>    appear to be any difference between the revisions. More revisions
> >>>    will be added as needed in the future. The heuristics in the
> >>>    bootloader will pick the MP1 device tree if there are not any
> >>>    better matches.
> >>> 4. They only add the dts for the B0 SoC for now. The A0 SoC support
> >>>    can be added later if we find the need.
> >>> 5. 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.
> >>> 6. 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.
> >>> 7. 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.
> >>>
> >>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> >>> ---
> >>> To avoid fragmenting the discussion, IMO:
> >>> * Let's have the discussion about using the "dts" for SoC and the
> >>>   "dtso" for the boards in response to the bindings (patch #1).
> >>
> >> That's discussion here, bindings are irrelevant to this.
> >>
> >>> * If we want to have a discussion about putting "board-id" and
> >>>   "model-id" at the root of the board overlays, we can have it
> >>>   here. I'll preemptively note that the "board-id" and "model-id"
> >>>   won't show up in the final combined device tree and they are just
> >>>   used by the tool (mkdtimg). We could change mkdtimg to parse the
> >>>   "compatible" strings of the overlays files (since I've put the IDs
> >>>   there too), but official the docs [1] seem to indicate that
> >>>   top-level properties like this are OK.
> >>>
> >>> In order for these device trees to pass validation without warnings,
> >>> it's assumed you have my dtc patches:
> >>> * https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
> >>> * https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org
> >>>
> >>> [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main
> >>>
> >>>  arch/arm64/boot/dts/google/Makefile           |   9 +
> >>>  arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
> >>>  .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
> >>>  .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
> >>>  .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
> >>>  .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
> >>>  6 files changed, 483 insertions(+)
> >>>  create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
> >>>  create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
> >>>  create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> >>>  create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
> >>>  create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi
> >>>
> >>> diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
> >>> index a6b187e2d631..276001e91632 100644
> >>> --- a/arch/arm64/boot/dts/google/Makefile
> >>> +++ b/arch/arm64/boot/dts/google/Makefile
> >>> @@ -1 +1,10 @@
> >>>  # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> >>> +
> >>> +dtb-$(CONFIG_ARCH_GOOGLE) += \
> >>> +     lga-blazer-mp1.dtb \
> >>> +     lga-frankel-mp1.dtb \
> >>> +     lga-mustang-mp1.dtb
> >>> +
> >>> +lga-blazer-mp1-dtbs          := lga-b0.dtb lga-blazer-mp1.dtbo
> >>> +lga-frankel-mp1-dtbs         := lga-b0.dtb lga-frankel-mp1.dtbo
> >>> +lga-mustang-mp1-dtbs         := lga-b0.dtb lga-mustang-mp1.dtbo
> >>> diff --git a/arch/arm64/boot/dts/google/lga-b0.dts b/arch/arm64/boot/dts/google/lga-b0.dts
> >>> new file mode 100644
> >>> index 000000000000..83c2db4f20ef
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/google/lga-b0.dts
> >>> @@ -0,0 +1,391 @@
> >>> +// 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>
> >>> +
> >>> +/ {
> >>> +     model = "Google Tensor G5 rev B0";
> >>> +     compatible = "google,soc-id-0005-rev-10", "google,lga";
> >>
> >> So that's SoC, thus must not be a DTS file, but DTSI.
> >>
> >> ...
> >>
> >>
> >> ...
> >>
> >>
> >>> diff --git a/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> >>> new file mode 100644
> >>> index 000000000000..133494de7a9b
> >>> --- /dev/null
> >>> +++ b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> >>
> >> And that's a board, so DTS.
> >>
> >>> @@ -0,0 +1,22 @@
> >>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> >>> +/*
> >>> + * Google Pixel 10 (frankel) MP 1
> >>> + *
> >>> + * Copyright 2024-2025 Google LLC.
> >>> + */
> >>> +
> >>> +/dts-v1/;
> >>> +/plugin/;
> >>> +
> >>> +#include "lga-muzel-common.dtsi"
> >>> +
> >>> +/ {
> >>> +     board-id = <0x070306>;
> >>> +     board-rev = <0x010000>;
> >>
> >> Undocumented ABI, which you cannot document because these properties are
> >> not allowed. You cannot have them.
> >
> > This is part of the discussion I want to have at Plumbers. But I suppose
> > we can start here.
>
> Then the patch should be called RFC as not yet ready for merging. :)
>
> >
> > The Android DTB partition format uses six 32-bit integers for matching,
> > as opposed to a compatible string used in FIT images. Two of the integers
> > are the "id" and "rev" numbers in the example above. The remaining four
> > are custom and left up to the (vendor) bootloader implementation.
> >
> > The values for these fields need to be stored somewhere with the .dts.
> > The compiled DTB is useless if the user cannot build a proper image for
> > the bootloader to consume, and that involves putting in the right numbers
> > in these fields. The android "mkdtimg" tool can either take the values
> > from some known properties within the DTB, or have them fed to it
> > externally.
> >
> > So if we don't want these numbers in the dts itself, then we should come
> > up with some format to store them beside the dts files.
>
> Re-iterating comment from Rob long time ago: adding such new properties
> is fine, but they must come for more than one user and be universal
> across these users.

Is Android universal enough? As mentioned above, Android defines some
fields that it wants in its DTBO partition header. I am doubtful we
could generalize further, since each bootloader scheme wants different
things.

> And of course the ABI needs to be documented which did not happen here.
>
> I indeed said incorrectly that "properties are not allowed". The
> properties could be allowed if we document them according to above Rob's
> comment, but that did not happen.
>
> Adding these properties per one SoC vendor is not really allowed, like
> qcom,board-id and qcom,msm-id, but maybe you intend to make it generic.

That is indeed not great. I believe this part predates the DTBO partition
format, and is also related to how vendors split their base DTB and
overlays, such as the scheme Doug presented.

Maybe the new Android Generic Boot Loader (GBL) work will provide
unification. I will reach out to them to see what's happening in that space.

> > On a similar note, we would have a similar problem with FIT images and
> > overlays. The FIT image format maps a (series of) compatible string(s)
> > to one DTB and any number of overlays. If overlays are involved, then
> > the compatible string cannot come from the DTB itself, and the mapping
> > must be stored somewhere.
>
> I recall, although cannot find now references to, a email talk on the
> list saying that such overlays should have their own compatible, thus
> solving this mapping problem.

Rob provided it in the other thread. The per-overlay compatible allows
identifying the overlay instead of using the filename, which I think
is much appreciated. But we still need a mapping of what a final device
compatible breaks down to.

For example, say we have the the following:

- product common base "google,yoda" (DTB)
- codec option one "google,yoda-codec-rt5682i" (DTBO)
- codec option two "google,yoda-codec-rt5682s" (DTBO)
- WWAN module and SAR sensor option "google,yoda,wwan" (DTBO)

We then have different SKUs that are a combination of the above:

- product SKU "google,yoda-sku0"
  combine "google,yoda", "google,yoda-codec-rt5682s", and "google,yoda,wwan"

- product SKU "google,yoda-sku4"
  combine "google,yoda", "google,yoda-codec-rt5682i", and "google,yoda,wwan"

- product SKU "google,yoda-sku16"
  combine "google,yoda" and "google,yoda-codec-rt5682s"

This is the mapping we have to put _somewhere_. The bootloader only
knows about "google,yoda-skuXYZ" and "google,yoda", as described in
the Chromebook boot flow document [1].

Now I suppose we could have per-SKU DTBOs that just update the base
compatible string, and have Makefile rules put them all together.
But we have something like 32 SKUs just for this product alone, and
I don't think we want to add that many dtso files. The whole reason
for us to switch to overlays was to avoid the explosion of SKU-based
DTB files.


Thanks
ChenYu

[1] Documentation/arch/arm/google/chromebook-boot-flow.rst

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

[Krzysztof Kozlowski]

On 17/11/2025 07:43, Chen-Yu Tsai wrote:
> On Wed, Nov 12, 2025 at 5:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 12/11/2025 10:35, Chen-Yu Tsai wrote:
>>> On Wed, Nov 12, 2025 at 4:14 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>>
>>>> On 11/11/2025 20:22, Douglas Anderson wrote:
>>>>> Add barebones 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.
>>>>>
>>>>> Many things can be noted about these device trees:
>>>>>
>>>>> 1. They are organized as "dts" files for the main SoC and "dtso"
>>>>>    overlays for the boards. There is discussion about this in the
>>>>>    bindings patch ("dt-bindings: arm: google: Add bindings for
>>>>>    frankel/blazer/mustang").
>>>>> 2. They won't boot with the currently shipping bootloader. The current
>>>>>    bootloader hardcodes several paths to nodes that it wants to update
>>>>>    and considers it a fatal error if it can't find these nodes.
>>>>>    Interested parties will need to wait for fixes to land and a new
>>>>>    bootloader to be rolled out before attempting to use these.
>>>>> 3. They only add one revision (MP1) of each of frankel, blazer, and
>>>>>    mustang. With this simple barebones device tree, there doesn't
>>>>>    appear to be any difference between the revisions. More revisions
>>>>>    will be added as needed in the future. The heuristics in the
>>>>>    bootloader will pick the MP1 device tree if there are not any
>>>>>    better matches.
>>>>> 4. They only add the dts for the B0 SoC for now. The A0 SoC support
>>>>>    can be added later if we find the need.
>>>>> 5. 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.
>>>>> 6. 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.
>>>>> 7. 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.
>>>>>
>>>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>>>> ---
>>>>> To avoid fragmenting the discussion, IMO:
>>>>> * Let's have the discussion about using the "dts" for SoC and the
>>>>>   "dtso" for the boards in response to the bindings (patch #1).
>>>>
>>>> That's discussion here, bindings are irrelevant to this.
>>>>
>>>>> * If we want to have a discussion about putting "board-id" and
>>>>>   "model-id" at the root of the board overlays, we can have it
>>>>>   here. I'll preemptively note that the "board-id" and "model-id"
>>>>>   won't show up in the final combined device tree and they are just
>>>>>   used by the tool (mkdtimg). We could change mkdtimg to parse the
>>>>>   "compatible" strings of the overlays files (since I've put the IDs
>>>>>   there too), but official the docs [1] seem to indicate that
>>>>>   top-level properties like this are OK.
>>>>>
>>>>> In order for these device trees to pass validation without warnings,
>>>>> it's assumed you have my dtc patches:
>>>>> * https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
>>>>> * https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org
>>>>>
>>>>> [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main
>>>>>
>>>>>  arch/arm64/boot/dts/google/Makefile           |   9 +
>>>>>  arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
>>>>>  .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
>>>>>  .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
>>>>>  .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
>>>>>  .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
>>>>>  6 files changed, 483 insertions(+)
>>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
>>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
>>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
>>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
>>>>> index a6b187e2d631..276001e91632 100644
>>>>> --- a/arch/arm64/boot/dts/google/Makefile
>>>>> +++ b/arch/arm64/boot/dts/google/Makefile
>>>>> @@ -1 +1,10 @@
>>>>>  # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
>>>>> +
>>>>> +dtb-$(CONFIG_ARCH_GOOGLE) += \
>>>>> +     lga-blazer-mp1.dtb \
>>>>> +     lga-frankel-mp1.dtb \
>>>>> +     lga-mustang-mp1.dtb
>>>>> +
>>>>> +lga-blazer-mp1-dtbs          := lga-b0.dtb lga-blazer-mp1.dtbo
>>>>> +lga-frankel-mp1-dtbs         := lga-b0.dtb lga-frankel-mp1.dtbo
>>>>> +lga-mustang-mp1-dtbs         := lga-b0.dtb lga-mustang-mp1.dtbo
>>>>> diff --git a/arch/arm64/boot/dts/google/lga-b0.dts b/arch/arm64/boot/dts/google/lga-b0.dts
>>>>> new file mode 100644
>>>>> index 000000000000..83c2db4f20ef
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/google/lga-b0.dts
>>>>> @@ -0,0 +1,391 @@
>>>>> +// 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>
>>>>> +
>>>>> +/ {
>>>>> +     model = "Google Tensor G5 rev B0";
>>>>> +     compatible = "google,soc-id-0005-rev-10", "google,lga";
>>>>
>>>> So that's SoC, thus must not be a DTS file, but DTSI.
>>>>
>>>> ...
>>>>
>>>>
>>>> ...
>>>>
>>>>
>>>>> diff --git a/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>>>>> new file mode 100644
>>>>> index 000000000000..133494de7a9b
>>>>> --- /dev/null
>>>>> +++ b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
>>>>
>>>> And that's a board, so DTS.
>>>>
>>>>> @@ -0,0 +1,22 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
>>>>> +/*
>>>>> + * Google Pixel 10 (frankel) MP 1
>>>>> + *
>>>>> + * Copyright 2024-2025 Google LLC.
>>>>> + */
>>>>> +
>>>>> +/dts-v1/;
>>>>> +/plugin/;
>>>>> +
>>>>> +#include "lga-muzel-common.dtsi"
>>>>> +
>>>>> +/ {
>>>>> +     board-id = <0x070306>;
>>>>> +     board-rev = <0x010000>;
>>>>
>>>> Undocumented ABI, which you cannot document because these properties are
>>>> not allowed. You cannot have them.
>>>
>>> This is part of the discussion I want to have at Plumbers. But I suppose
>>> we can start here.
>>
>> Then the patch should be called RFC as not yet ready for merging. :)
>>
>>>
>>> The Android DTB partition format uses six 32-bit integers for matching,
>>> as opposed to a compatible string used in FIT images. Two of the integers
>>> are the "id" and "rev" numbers in the example above. The remaining four
>>> are custom and left up to the (vendor) bootloader implementation.
>>>
>>> The values for these fields need to be stored somewhere with the .dts.
>>> The compiled DTB is useless if the user cannot build a proper image for
>>> the bootloader to consume, and that involves putting in the right numbers
>>> in these fields. The android "mkdtimg" tool can either take the values
>>> from some known properties within the DTB, or have them fed to it
>>> externally.
>>>
>>> So if we don't want these numbers in the dts itself, then we should come
>>> up with some format to store them beside the dts files.
>>
>> Re-iterating comment from Rob long time ago: adding such new properties
>> is fine, but they must come for more than one user and be universal
>> across these users.
> 
> Is Android universal enough? As mentioned above, Android defines some
> fields that it wants in its DTBO partition header. I am doubtful we
> could generalize further, since each bootloader scheme wants different
> things.

There is no such user of these bindings as "Android".

> 
>> And of course the ABI needs to be documented which did not happen here.
>>
>> I indeed said incorrectly that "properties are not allowed". The
>> properties could be allowed if we document them according to above Rob's
>> comment, but that did not happen.
>>
>> Adding these properties per one SoC vendor is not really allowed, like
>> qcom,board-id and qcom,msm-id, but maybe you intend to make it generic.
> 
> That is indeed not great. I believe this part predates the DTBO partition
> format, and is also related to how vendors split their base DTB and
> overlays, such as the scheme Doug presented.
> 
> Maybe the new Android Generic Boot Loader (GBL) work will provide
> unification. I will reach out to them to see what's happening in that space.
> 
>>> On a similar note, we would have a similar problem with FIT images and
>>> overlays. The FIT image format maps a (series of) compatible string(s)
>>> to one DTB and any number of overlays. If overlays are involved, then
>>> the compatible string cannot come from the DTB itself, and the mapping
>>> must be stored somewhere.
>>
>> I recall, although cannot find now references to, a email talk on the
>> list saying that such overlays should have their own compatible, thus
>> solving this mapping problem.
> 
> Rob provided it in the other thread. The per-overlay compatible allows
> identifying the overlay instead of using the filename, which I think
> is much appreciated. But we still need a mapping of what a final device
> compatible breaks down to.

Who is "we"? Linux does not care about that mapping. For user-space
"google,yoda-sku0" should be good enough.


> 
> For example, say we have the the following:
> 
> - product common base "google,yoda" (DTB)
> - codec option one "google,yoda-codec-rt5682i" (DTBO)
> - codec option two "google,yoda-codec-rt5682s" (DTBO)
> - WWAN module and SAR sensor option "google,yoda,wwan" (DTBO)
> 
> We then have different SKUs that are a combination of the above:
> 
> - product SKU "google,yoda-sku0"
>   combine "google,yoda", "google,yoda-codec-rt5682s", and "google,yoda,wwan"
> 
> - product SKU "google,yoda-sku4"
>   combine "google,yoda", "google,yoda-codec-rt5682i", and "google,yoda,wwan"
> 
> - product SKU "google,yoda-sku16"
>   combine "google,yoda" and "google,yoda-codec-rt5682s"
> 
> This is the mapping we have to put _somewhere_. The bootloader only
> knows about "google,yoda-skuXYZ" and "google,yoda", as described in
> the Chromebook boot flow document [1].
> 

The entire pathset is about Google Pixel so I really do not get how
Chromebook boot flow got here.

Best regards,
Krzysztof

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

[Chen-Yu Tsai]

On Mon, Nov 17, 2025 at 2:55 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 17/11/2025 07:43, Chen-Yu Tsai wrote:
> > On Wed, Nov 12, 2025 at 5:49 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>
> >> On 12/11/2025 10:35, Chen-Yu Tsai wrote:
> >>> On Wed, Nov 12, 2025 at 4:14 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >>>>
> >>>> On 11/11/2025 20:22, Douglas Anderson wrote:
> >>>>> Add barebones 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.
> >>>>>
> >>>>> Many things can be noted about these device trees:
> >>>>>
> >>>>> 1. They are organized as "dts" files for the main SoC and "dtso"
> >>>>>    overlays for the boards. There is discussion about this in the
> >>>>>    bindings patch ("dt-bindings: arm: google: Add bindings for
> >>>>>    frankel/blazer/mustang").
> >>>>> 2. They won't boot with the currently shipping bootloader. The current
> >>>>>    bootloader hardcodes several paths to nodes that it wants to update
> >>>>>    and considers it a fatal error if it can't find these nodes.
> >>>>>    Interested parties will need to wait for fixes to land and a new
> >>>>>    bootloader to be rolled out before attempting to use these.
> >>>>> 3. They only add one revision (MP1) of each of frankel, blazer, and
> >>>>>    mustang. With this simple barebones device tree, there doesn't
> >>>>>    appear to be any difference between the revisions. More revisions
> >>>>>    will be added as needed in the future. The heuristics in the
> >>>>>    bootloader will pick the MP1 device tree if there are not any
> >>>>>    better matches.
> >>>>> 4. They only add the dts for the B0 SoC for now. The A0 SoC support
> >>>>>    can be added later if we find the need.
> >>>>> 5. 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.
> >>>>> 6. 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.
> >>>>> 7. 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.
> >>>>>
> >>>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> >>>>> ---
> >>>>> To avoid fragmenting the discussion, IMO:
> >>>>> * Let's have the discussion about using the "dts" for SoC and the
> >>>>>   "dtso" for the boards in response to the bindings (patch #1).
> >>>>
> >>>> That's discussion here, bindings are irrelevant to this.
> >>>>
> >>>>> * If we want to have a discussion about putting "board-id" and
> >>>>>   "model-id" at the root of the board overlays, we can have it
> >>>>>   here. I'll preemptively note that the "board-id" and "model-id"
> >>>>>   won't show up in the final combined device tree and they are just
> >>>>>   used by the tool (mkdtimg). We could change mkdtimg to parse the
> >>>>>   "compatible" strings of the overlays files (since I've put the IDs
> >>>>>   there too), but official the docs [1] seem to indicate that
> >>>>>   top-level properties like this are OK.
> >>>>>
> >>>>> In order for these device trees to pass validation without warnings,
> >>>>> it's assumed you have my dtc patches:
> >>>>> * https://lore.kernel.org/r/20251110204529.2838248-1-dianders@chromium.org
> >>>>> * https://lore.kernel.org/r/20251110204529.2838248-2-dianders@chromium.org
> >>>>>
> >>>>> [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git/tree/Documentation/dt-object-internal.txt?h=main
> >>>>>
> >>>>>  arch/arm64/boot/dts/google/Makefile           |   9 +
> >>>>>  arch/arm64/boot/dts/google/lga-b0.dts         | 391 ++++++++++++++++++
> >>>>>  .../arm64/boot/dts/google/lga-blazer-mp1.dtso |  22 +
> >>>>>  .../boot/dts/google/lga-frankel-mp1.dtso      |  22 +
> >>>>>  .../boot/dts/google/lga-mustang-mp1.dtso      |  22 +
> >>>>>  .../boot/dts/google/lga-muzel-common.dtsi     |  17 +
> >>>>>  6 files changed, 483 insertions(+)
> >>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-b0.dts
> >>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-blazer-mp1.dtso
> >>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> >>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-mustang-mp1.dtso
> >>>>>  create mode 100644 arch/arm64/boot/dts/google/lga-muzel-common.dtsi
> >>>>>
> >>>>> diff --git a/arch/arm64/boot/dts/google/Makefile b/arch/arm64/boot/dts/google/Makefile
> >>>>> index a6b187e2d631..276001e91632 100644
> >>>>> --- a/arch/arm64/boot/dts/google/Makefile
> >>>>> +++ b/arch/arm64/boot/dts/google/Makefile
> >>>>> @@ -1 +1,10 @@
> >>>>>  # SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> >>>>> +
> >>>>> +dtb-$(CONFIG_ARCH_GOOGLE) += \
> >>>>> +     lga-blazer-mp1.dtb \
> >>>>> +     lga-frankel-mp1.dtb \
> >>>>> +     lga-mustang-mp1.dtb
> >>>>> +
> >>>>> +lga-blazer-mp1-dtbs          := lga-b0.dtb lga-blazer-mp1.dtbo
> >>>>> +lga-frankel-mp1-dtbs         := lga-b0.dtb lga-frankel-mp1.dtbo
> >>>>> +lga-mustang-mp1-dtbs         := lga-b0.dtb lga-mustang-mp1.dtbo
> >>>>> diff --git a/arch/arm64/boot/dts/google/lga-b0.dts b/arch/arm64/boot/dts/google/lga-b0.dts
> >>>>> new file mode 100644
> >>>>> index 000000000000..83c2db4f20ef
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/google/lga-b0.dts
> >>>>> @@ -0,0 +1,391 @@
> >>>>> +// 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>
> >>>>> +
> >>>>> +/ {
> >>>>> +     model = "Google Tensor G5 rev B0";
> >>>>> +     compatible = "google,soc-id-0005-rev-10", "google,lga";
> >>>>
> >>>> So that's SoC, thus must not be a DTS file, but DTSI.
> >>>>
> >>>> ...
> >>>>
> >>>>
> >>>> ...
> >>>>
> >>>>
> >>>>> diff --git a/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> >>>>> new file mode 100644
> >>>>> index 000000000000..133494de7a9b
> >>>>> --- /dev/null
> >>>>> +++ b/arch/arm64/boot/dts/google/lga-frankel-mp1.dtso
> >>>>
> >>>> And that's a board, so DTS.
> >>>>
> >>>>> @@ -0,0 +1,22 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
> >>>>> +/*
> >>>>> + * Google Pixel 10 (frankel) MP 1
> >>>>> + *
> >>>>> + * Copyright 2024-2025 Google LLC.
> >>>>> + */
> >>>>> +
> >>>>> +/dts-v1/;
> >>>>> +/plugin/;
> >>>>> +
> >>>>> +#include "lga-muzel-common.dtsi"
> >>>>> +
> >>>>> +/ {
> >>>>> +     board-id = <0x070306>;
> >>>>> +     board-rev = <0x010000>;
> >>>>
> >>>> Undocumented ABI, which you cannot document because these properties are
> >>>> not allowed. You cannot have them.
> >>>
> >>> This is part of the discussion I want to have at Plumbers. But I suppose
> >>> we can start here.
> >>
> >> Then the patch should be called RFC as not yet ready for merging. :)
> >>
> >>>
> >>> The Android DTB partition format uses six 32-bit integers for matching,
> >>> as opposed to a compatible string used in FIT images. Two of the integers
> >>> are the "id" and "rev" numbers in the example above. The remaining four
> >>> are custom and left up to the (vendor) bootloader implementation.
> >>>
> >>> The values for these fields need to be stored somewhere with the .dts.
> >>> The compiled DTB is useless if the user cannot build a proper image for
> >>> the bootloader to consume, and that involves putting in the right numbers
> >>> in these fields. The android "mkdtimg" tool can either take the values
> >>> from some known properties within the DTB, or have them fed to it
> >>> externally.
> >>>
> >>> So if we don't want these numbers in the dts itself, then we should come
> >>> up with some format to store them beside the dts files.
> >>
> >> Re-iterating comment from Rob long time ago: adding such new properties
> >> is fine, but they must come for more than one user and be universal
> >> across these users.
> >
> > Is Android universal enough? As mentioned above, Android defines some
> > fields that it wants in its DTBO partition header. I am doubtful we
> > could generalize further, since each bootloader scheme wants different
> > things.
>
> There is no such user of these bindings as "Android".

Sure, since many vendors for Android-based devices don't bother to
upstream their device trees.

> >
> >> And of course the ABI needs to be documented which did not happen here.
> >>
> >> I indeed said incorrectly that "properties are not allowed". The
> >> properties could be allowed if we document them according to above Rob's
> >> comment, but that did not happen.
> >>
> >> Adding these properties per one SoC vendor is not really allowed, like
> >> qcom,board-id and qcom,msm-id, but maybe you intend to make it generic.
> >
> > That is indeed not great. I believe this part predates the DTBO partition
> > format, and is also related to how vendors split their base DTB and
> > overlays, such as the scheme Doug presented.
> >
> > Maybe the new Android Generic Boot Loader (GBL) work will provide
> > unification. I will reach out to them to see what's happening in that space.
> >
> >>> On a similar note, we would have a similar problem with FIT images and
> >>> overlays. The FIT image format maps a (series of) compatible string(s)
> >>> to one DTB and any number of overlays. If overlays are involved, then
> >>> the compatible string cannot come from the DTB itself, and the mapping
> >>> must be stored somewhere.
> >>
> >> I recall, although cannot find now references to, a email talk on the
> >> list saying that such overlays should have their own compatible, thus
> >> solving this mapping problem.
> >
> > Rob provided it in the other thread. The per-overlay compatible allows
> > identifying the overlay instead of using the filename, which I think
> > is much appreciated. But we still need a mapping of what a final device
> > compatible breaks down to.
>
> Who is "we"? Linux does not care about that mapping. For user-space
> "google,yoda-sku0" should be good enough.

"We" as in the Chromebook team, but more broadly, any user or developer
that wants to build a generic kernel image based off of base DTBs and
overlays.

> >
> > For example, say we have the the following:
> >
> > - product common base "google,yoda" (DTB)
> > - codec option one "google,yoda-codec-rt5682i" (DTBO)
> > - codec option two "google,yoda-codec-rt5682s" (DTBO)
> > - WWAN module and SAR sensor option "google,yoda,wwan" (DTBO)
> >
> > We then have different SKUs that are a combination of the above:
> >
> > - product SKU "google,yoda-sku0"
> >   combine "google,yoda", "google,yoda-codec-rt5682s", and "google,yoda,wwan"
> >
> > - product SKU "google,yoda-sku4"
> >   combine "google,yoda", "google,yoda-codec-rt5682i", and "google,yoda,wwan"
> >
> > - product SKU "google,yoda-sku16"
> >   combine "google,yoda" and "google,yoda-codec-rt5682s"
> >
> > This is the mapping we have to put _somewhere_. The bootloader only
> > knows about "google,yoda-skuXYZ" and "google,yoda", as described in
> > the Chromebook boot flow document [1].
> >
>
> The entire pathset is about Google Pixel so I really do not get how
> Chromebook boot flow got here.

My apologies, I should have forked the thread to make it clear my stuff
was about Chromebooks, but the discussion on overlays seemed relevant.

I'll try to work out an example and RFC patchset based on existing
ChromeOS device trees to further discuss things.


ChenYu