[PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Douglas Anderson]

This copy-pastes compatibles from sc7180-based boards from the device
trees to the yaml file so that `make dtbs_check` will be happy.

NOTES:
- I make no attempt to try to share an "item" for all sc7180 based
  Chromebooks. Because of the revision matching scheme used by the
  Chromebook bootloader, at times we need a different number of
  revisions listed.
- Some of the odd entries in here (like google,homestar-rev23 or the
  fact that "Google Lazor Limozeen without Touchscreen" changed from
  sku5 to sku6) are not typos but simply reflect reality.
- Many revisions of boards here never actually went to consumers, but
  they are still in use within various companies that were involved in
  Chromebook development. Since Chromebooks are developed with an
  "upstream first" methodology, having these revisions supported with
  upstream Linux is important. Making it easy for Chromebooks to be
  developed with an "upstream first" methodology is valuable to the
  upstream community because it improves the quality of upstream and
  gets Chromebooks supported with vanilla upstream faster.

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

 .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
 1 file changed, 180 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 5c06d1bfc046..399be67eb5d2 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -214,11 +214,191 @@ properties:
               - qcom,ipq8074-hk10-c2
           - const: qcom,ipq8074
 
+      # Qualcomm Technologies, Inc. SC7180 IDP
       - items:
           - enum:
               - qcom,sc7180-idp
           - const: qcom,sc7180
 
+      # Google CoachZ (rev1 - 2)
+      - items:
+          - const: google,coachz-rev1
+          - const: google,coachz-rev2
+          - const: qcom,sc7180
+
+      # Google CoachZ (newest rev)
+      - items:
+          - const: google,coachz
+          - const: qcom,sc7180
+
+      # Google CoachZ with LTE (rev1 - 2)
+      - items:
+          - const: google,coachz-rev1-sku0
+          - const: google,coachz-rev2-sku0
+          - const: qcom,sc7180
+
+      # Google CoachZ with LTE (newest rev)
+      - items:
+          - const: google,coachz-sku0
+          - const: qcom,sc7180
+
+      # Google Homestar (rev2)
+      - items:
+          - const: google,homestar-rev2
+          - const: google,homestar-rev23
+          - const: qcom,sc7180
+
+      # Google Homestar (rev3)
+      - items:
+          - const: google,homestar-rev3
+          - const: qcom,sc7180
+
+      # Google Homestar (newest rev)
+      - items:
+          - const: google,homestar
+          - const: qcom,sc7180
+
+      # Google Lazor (rev0)
+      - items:
+          - const: google,lazor-rev0
+          - const: qcom,sc7180
+
+      # Google Lazor (rev1 - 2)
+      - items:
+          - const: google,lazor-rev1
+          - const: google,lazor-rev2
+          - const: qcom,sc7180
+
+      # Google Lazor (rev3 - 8)
+      - items:
+          - const: google,lazor-rev3
+          - const: google,lazor-rev4
+          - const: google,lazor-rev5
+          - const: google,lazor-rev6
+          - const: google,lazor-rev7
+          - const: google,lazor-rev8
+          - const: qcom,sc7180
+
+      # Google Lazor (newest rev)
+      - items:
+          - const: google,lazor
+          - const: qcom,sc7180
+
+      # Google Lazor with KB Backlight (rev1 - 2)
+      - items:
+          - const: google,lazor-rev1-sku2
+          - const: google,lazor-rev2-sku2
+          - const: qcom,sc7180
+
+      # Google Lazor with KB Backlight (rev3 - 8)
+      - items:
+          - const: google,lazor-rev3-sku2
+          - const: google,lazor-rev4-sku2
+          - const: google,lazor-rev5-sku2
+          - const: google,lazor-rev6-sku2
+          - const: google,lazor-rev7-sku2
+          - const: google,lazor-rev8-sku2
+          - const: qcom,sc7180
+
+      # Google Lazor with KB Backlight (newest rev)
+      - items:
+          - const: google,lazor-sku2
+          - const: qcom,sc7180
+
+      # Google Lazor with LTE (rev1 - 2)
+      - items:
+          - const: google,lazor-rev1-sku0
+          - const: google,lazor-rev2-sku0
+          - const: qcom,sc7180
+
+      # Google Lazor with LTE (rev3 - 8)
+      - items:
+          - const: google,lazor-rev3-sku0
+          - const: google,lazor-rev4-sku0
+          - const: google,lazor-rev5-sku0
+          - const: google,lazor-rev6-sku0
+          - const: google,lazor-rev7-sku0
+          - const: google,lazor-rev8-sku0
+          - const: qcom,sc7180
+
+      # Google Lazor with LTE (newest rev)
+      - items:
+          - const: google,lazor-sku0
+          - const: qcom,sc7180
+
+      # Google Lazor Limozeen (rev4 - rev8)
+      - items:
+          - const: google,lazor-rev4-sku4
+          - const: google,lazor-rev5-sku4
+          - const: google,lazor-rev6-sku4
+          - const: google,lazor-rev7-sku4
+          - const: google,lazor-rev8-sku4
+          - const: qcom,sc7180
+
+      # Google Lazor Limozeen (newest rev)
+      - items:
+          - const: google,lazor-sku4
+          - const: qcom,sc7180
+
+      # Google Lazor Limozeen without Touchscreen (rev4)
+      - items:
+          - const: google,lazor-rev4-sku5
+          - const: qcom,sc7180
+
+      # Google Lazor Limozeen without Touchscreen (rev5 - rev8)
+      - items:
+          - const: google,lazor-rev5-sku5
+          - const: google,lazor-rev5-sku6
+          - const: google,lazor-rev6-sku6
+          - const: google,lazor-rev7-sku6
+          - const: google,lazor-rev8-sku6
+          - const: qcom,sc7180
+
+      # Google Lazor Limozeen without Touchscreen (newest rev)
+      - items:
+          - const: google,lazor-sku6
+          - const: qcom,sc7180
+
+      # Google Pompom (rev1)
+      - items:
+          - const: google,pompom-rev1
+          - const: qcom,sc7180
+
+      # Google Pompom (rev2)
+      - items:
+          - const: google,pompom-rev2
+          - const: qcom,sc7180
+
+      # Google Pompom (newest rev)
+      - items:
+          - const: google,pompom
+          - const: qcom,sc7180
+
+      # Google Pompom with LTE (rev1)
+      - items:
+          - const: google,pompom-rev1-sku0
+          - const: qcom,sc7180
+
+      # Google Pompom with LTE (rev2)
+      - items:
+          - const: google,pompom-rev2-sku0
+          - const: qcom,sc7180
+
+      # Google Pompom with LTE (newest rev)
+      - items:
+          - const: google,pompom-sku0
+          - const: qcom,sc7180
+
+      # Google Trogdor (newest rev)
+      - items:
+          - const: google,trogdor
+          - const: qcom,sc7180
+
+      # Google Trogdor (newest rev) with LTE
+      - items:
+          - const: google,trogdor-sku0
+          - const: qcom,sc7180
+
       - items:
           - enum:
               - qcom,sc7280-crd
-- 
2.36.0.550.gb090851708-goog

[PATCH 2/3] dt-bindings: arm: qcom: Add / fix sc7280 board bindings

[Douglas Anderson]

This copy-pastes compatibles from sc7280-based boards from the device
trees to the yaml file. It also fixes the CRD/IDP bindings which had
gotten stale.

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

 .../devicetree/bindings/arm/qcom.yaml         | 40 +++++++++++++++----
 1 file changed, 33 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 399be67eb5d2..c7ab028d54a0 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -399,14 +399,40 @@ properties:
           - const: google,trogdor-sku0
           - const: qcom,sc7180
 
+      # Qualcomm Technologies, Inc. sc7280 CRD platform (rev3 - 4)
       - items:
-          - enum:
-              - qcom,sc7280-crd
-              - qcom,sc7280-idp
-              - qcom,sc7280-idp2
-              - google,hoglin
-              - google,piglin
-              - google,senor
+          - const: qcom,sc7280-crd
+          - const: google,hoglin-rev3
+          - const: google,hoglin-rev4
+          - const: google,piglin-rev3
+          - const: google,piglin-rev4
+          - const: qcom,sc7280
+
+      # Qualcomm Technologies, Inc. sc7280 CRD platform (newest rev)
+      - items:
+          - const: google,hoglin
+          - const: qcom,sc7280
+
+      # Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform
+      - items:
+          - const: qcom,sc7280-idp
+          - const: google,senor
+          - const: qcom,sc7280
+
+      # Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform
+      - items:
+          - const: qcom,sc7280-idp2
+          - const: google,piglin
+          - const: qcom,sc7280
+
+      # Google Herobrine (newest rev)
+      - items:
+          - const: google,herobrine
+          - const: qcom,sc7280
+
+      # Google Villager (newest rev)
+      - items:
+          - const: google,villager
           - const: qcom,sc7280
 
       - items:
-- 
2.36.0.550.gb090851708-goog

[PATCH 3/3] dt-bindings: arm: qcom: Add more sc7180 Chromebook board bindings

[Douglas Anderson]

This adds board bindings for boards that are downstream but not quite
upstream yet.

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

 .../devicetree/bindings/arm/qcom.yaml         | 92 +++++++++++++++++++
 1 file changed, 92 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index c7ab028d54a0..98ff98e9d0bb 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -258,6 +258,16 @@ properties:
           - const: google,homestar
           - const: qcom,sc7180
 
+      # Google Kingoftown (rev0)
+      - items:
+          - const: google,kingoftown-rev0
+          - const: qcom,sc7180
+
+      # Google Kingoftown (newest rev)
+      - items:
+          - const: google,kingoftown
+          - const: qcom,sc7180
+
       # Google Lazor (rev0)
       - items:
           - const: google,lazor-rev0
@@ -359,6 +369,48 @@ properties:
           - const: google,lazor-sku6
           - const: qcom,sc7180
 
+      # Google Mrbland with AUO panel (rev0)
+      - items:
+          - const: google,mrbland-rev0-sku0
+          - const: qcom,sc7180
+
+      # Google Mrbland with AUO panel (newest rev)
+      - items:
+          - const: google,mrbland-sku1536
+          - const: qcom,sc7180
+
+      # Google Mrbland with BOE panel (rev0)
+      - items:
+          - const: google,mrbland-rev0-sku16
+          - const: qcom,sc7180
+
+      # Google Mrbland with BOE panel (newest rev)
+      - items:
+          - const: google,mrbland-sku1024
+          - const: google,mrbland-sku768
+          - const: qcom,sc7180
+
+      # Google Pazquel with Parade (newest rev)
+      - items:
+          - const: google,pazquel-sku5
+          - const: qcom,sc7180
+
+      # Google Pazquel with TI (newest rev)
+      - items:
+          - const: google,pazquel-sku1
+          - const: qcom,sc7180
+
+      # Google Pazquel with LTE and Parade (newest rev)
+      - items:
+          - const: google,pazquel-sku4
+          - const: qcom,sc7180
+
+      # Google Pazquel with LTE and TI (newest rev)
+      - items:
+          - const: google,pazquel-sku0
+          - const: google,pazquel-sku2
+          - const: qcom,sc7180
+
       # Google Pompom (rev1)
       - items:
           - const: google,pompom-rev1
@@ -389,6 +441,16 @@ properties:
           - const: google,pompom-sku0
           - const: qcom,sc7180
 
+      # Google Quackingstick (newest rev)
+      - items:
+          - const: google,quackingstick-sku1537
+          - const: qcom,sc7180
+
+      # Google Quackingstick with LTE (newest rev)
+      - items:
+          - const: google,quackingstick-sku1536
+          - const: qcom,sc7180
+
       # Google Trogdor (newest rev)
       - items:
           - const: google,trogdor
@@ -399,6 +461,36 @@ properties:
           - const: google,trogdor-sku0
           - const: qcom,sc7180
 
+      # Google Wormdingler with BOE panel (rev0)
+      - items:
+          - const: google,wormdingler-rev0-sku16
+          - const: qcom,sc7180
+
+      # Google Wormdingler with BOE panel (newest rev)
+      - items:
+          - const: google,wormdingler-sku1024
+          - const: qcom,sc7180
+
+      # Google Wormdingler with BOE panel and rt5682s (newest rev)
+      - items:
+          - const: google,wormdingler-sku1025
+          - const: qcom,sc7180
+
+      # Google Wormdingler with INX panel (rev0)
+      - items:
+          - const: google,wormdingler-rev0-sku0
+          - const: qcom,sc7180
+
+      # Google Wormdingler with INX panel (newest rev)
+      - items:
+          - const: google,wormdingler-sku0
+          - const: qcom,sc7180
+
+      # Google Wormdingler with INX panel and rt5682s (newest rev)
+      - items:
+          - const: google,wormdingler-sku1
+          - const: qcom,sc7180
+
       # Qualcomm Technologies, Inc. sc7280 CRD platform (rev3 - 4)
       - items:
           - const: qcom,sc7280-crd
-- 
2.36.0.550.gb090851708-goog

Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Stephen Boyd]

Quoting Douglas Anderson (2022-05-12 09:04:45)
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 5c06d1bfc046..399be67eb5d2 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -214,11 +214,191 @@ properties:
>                - qcom,ipq8074-hk10-c2
>            - const: qcom,ipq8074
>

Side note: The top of this file describes a scheme that is basically not
used by any compatibles in this file. I came up with that scheme many
years ago so that we could upstream DTS files but still be able to
generate the magic numbers that the bootloader picked DTBs by. I hope
nobody assumes that description applies to "google," prefixed
compatibles.

Can the description can be amended to indicate the "google," scheme with
rev and sku details? Or a bindings/arm/chrome.yaml file could be made
and all google prefix chromeos board compatibles could be put in there
regardless of SoC used.

> +      # Qualcomm Technologies, Inc. SC7180 IDP
>        - items:
>            - enum:
>                - qcom,sc7180-idp
>            - const: qcom,sc7180
>
> +      # Google CoachZ (rev1 - 2)

Can we follow the design of rockchip.yaml and also include the marketing
name (if published)? That helps folks match things up quicker.

Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Krzysztof Kozlowski]

On 12/05/2022 18:04, Douglas Anderson wrote:
> This copy-pastes compatibles from sc7180-based boards from the device
> trees to the yaml file so that `make dtbs_check` will be happy.
> 
> NOTES:
> - I make no attempt to try to share an "item" for all sc7180 based
>   Chromebooks. Because of the revision matching scheme used by the
>   Chromebook bootloader, at times we need a different number of
>   revisions listed.
> - Some of the odd entries in here (like google,homestar-rev23 or the
>   fact that "Google Lazor Limozeen without Touchscreen" changed from
>   sku5 to sku6) are not typos but simply reflect reality.
> - Many revisions of boards here never actually went to consumers, but
>   they are still in use within various companies that were involved in
>   Chromebook development. Since Chromebooks are developed with an
>   "upstream first" methodology, having these revisions supported with
>   upstream Linux is important. Making it easy for Chromebooks to be
>   developed with an "upstream first" methodology is valuable to the
>   upstream community because it improves the quality of upstream and
>   gets Chromebooks supported with vanilla upstream faster.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
>  1 file changed, 180 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index 5c06d1bfc046..399be67eb5d2 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -214,11 +214,191 @@ properties:
>                - qcom,ipq8074-hk10-c2
>            - const: qcom,ipq8074
>  
> +      # Qualcomm Technologies, Inc. SC7180 IDP
>        - items:
>            - enum:
>                - qcom,sc7180-idp
>            - const: qcom,sc7180
>  
> +      # Google CoachZ (rev1 - 2)
> +      - items:
> +          - const: google,coachz-rev1
> +          - const: google,coachz-rev2

The inverted pattern of old revision being compatible with the new one,
is done on purpose? You claim here every rev1 is always compatible with
rev2 ...

I don't think we discussed such patterns in previous talk. I quickly
went through it and there were only skuX moving around, not rev1 being
newer then rev2.

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Krzysztof Kozlowski]

On 13/05/2022 09:57, Krzysztof Kozlowski wrote:
> On 12/05/2022 18:04, Douglas Anderson wrote:
>> This copy-pastes compatibles from sc7180-based boards from the device
>> trees to the yaml file so that `make dtbs_check` will be happy.
>>
>> NOTES:
>> - I make no attempt to try to share an "item" for all sc7180 based
>>   Chromebooks. Because of the revision matching scheme used by the
>>   Chromebook bootloader, at times we need a different number of
>>   revisions listed.
>> - Some of the odd entries in here (like google,homestar-rev23 or the
>>   fact that "Google Lazor Limozeen without Touchscreen" changed from
>>   sku5 to sku6) are not typos but simply reflect reality.
>> - Many revisions of boards here never actually went to consumers, but
>>   they are still in use within various companies that were involved in
>>   Chromebook development. Since Chromebooks are developed with an
>>   "upstream first" methodology, having these revisions supported with
>>   upstream Linux is important. Making it easy for Chromebooks to be
>>   developed with an "upstream first" methodology is valuable to the
>>   upstream community because it improves the quality of upstream and
>>   gets Chromebooks supported with vanilla upstream faster.
>>
>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>> ---
>>
>>  .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
>>  1 file changed, 180 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>> index 5c06d1bfc046..399be67eb5d2 100644
>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>> @@ -214,11 +214,191 @@ properties:
>>                - qcom,ipq8074-hk10-c2
>>            - const: qcom,ipq8074
>>  
>> +      # Qualcomm Technologies, Inc. SC7180 IDP
>>        - items:
>>            - enum:
>>                - qcom,sc7180-idp
>>            - const: qcom,sc7180
>>  
>> +      # Google CoachZ (rev1 - 2)
>> +      - items:
>> +          - const: google,coachz-rev1
>> +          - const: google,coachz-rev2
> 
> The inverted pattern of old revision being compatible with the new one,
> is done on purpose? You claim here every rev1 is always compatible with
> rev2 ...
> 
> I don't think we discussed such patterns in previous talk. I quickly
> went through it and there were only skuX moving around, not rev1 being
> newer then rev2.

BTW, your other Chromebooks use logical order:

https://lore.kernel.org/all/20220512205602.158273-2-nfraprado@collabora.com/




Best regards,
Krzysztof

Re: [PATCH 2/3] dt-bindings: arm: qcom: Add / fix sc7280 board bindings

[Rob Herring]

On Thu, 12 May 2022 09:04:46 -0700, Douglas Anderson wrote:
> This copy-pastes compatibles from sc7280-based boards from the device
> trees to the yaml file. It also fixes the CRD/IDP bindings which had
> gotten stale.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
> 
>  .../devicetree/bindings/arm/qcom.yaml         | 40 +++++++++++++++----
>  1 file changed, 33 insertions(+), 7 deletions(-)
> 

Running 'make dtbs_check' with the schema in this patch gives the
following warnings. Consider if they are expected or the schema is
incorrect. These may not be new warnings.

Note that it is not yet a requirement to have 0 warnings for dtbs_check.
This will change in the future.

Full log is available here: https://patchwork.ozlabs.org/patch/


/: compatible: 'oneOf' conditional failed, one must be fixed:
	arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dtb
	arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dtb
	arch/arm64/boot/dts/qcom/msm8916-huawei-g7.dtb
	arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dtb
	arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dtb
	arch/arm64/boot/dts/qcom/msm8916-mtp.dtb
	arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dtb
	arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dtb
	arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dtb
	arch/arm64/boot/dts/qcom/msm8994-huawei-angler-rev-101.dtb
	arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dtb
	arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-ivy.dtb
	arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-karin.dtb
	arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-satsuki.dtb
	arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-sumire.dtb
	arch/arm64/boot/dts/qcom/msm8994-sony-xperia-kitakami-suzuran.dtb
	arch/arm64/boot/dts/qcom/sc7280-crd.dtb
	arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dtb
	arch/arm64/boot/dts/qcom/sm8150-hdk.dtb
	arch/arm64/boot/dts/qcom/sm8150-microsoft-surface-duo.dtb
	arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano-bahamut.dtb
	arch/arm64/boot/dts/qcom/sm8150-sony-xperia-kumano-griffin.dtb
	arch/arm64/boot/dts/qcom/sm8250-hdk.dtb
	arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo-pdx203.dtb
	arch/arm64/boot/dts/qcom/sm8250-sony-xperia-edo-pdx206.dtb
	arch/arm64/boot/dts/qcom/sm8350-microsoft-surface-duo2.dtb
	arch/arm64/boot/dts/qcom/sm8350-sony-xperia-sagami-pdx214.dtb
	arch/arm64/boot/dts/qcom/sm8350-sony-xperia-sagami-pdx215.dtb
	arch/arm/boot/dts/qcom-msm8916-samsung-serranove.dtb

Re: [PATCH 2/3] dt-bindings: arm: qcom: Add / fix sc7280 board bindings

[Doug Anderson]

Hi,

On Fri, May 13, 2022 at 5:33 AM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, 12 May 2022 09:04:46 -0700, Douglas Anderson wrote:
> > This copy-pastes compatibles from sc7280-based boards from the device
> > trees to the yaml file. It also fixes the CRD/IDP bindings which had
> > gotten stale.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> >  .../devicetree/bindings/arm/qcom.yaml         | 40 +++++++++++++++----
> >  1 file changed, 33 insertions(+), 7 deletions(-)
> >
>
> Running 'make dtbs_check' with the schema in this patch gives the
> following warnings. Consider if they are expected or the schema is
> incorrect. These may not be new warnings.
>
> Note that it is not yet a requirement to have 0 warnings for dtbs_check.
> This will change in the future.
>
> Full log is available here: https://patchwork.ozlabs.org/patch/
>
>
> /: compatible: 'oneOf' conditional failed, one must be fixed:
[...]
>         arch/arm64/boot/dts/qcom/sc7280-crd.dtb
>         arch/arm64/boot/dts/qcom/sc7280-herobrine-herobrine-r0.dtb

Looking explicitly at these, since sc7280 boards were supposed to have
been fixed.

Ah, I see. herobrine-r0 was removed recently, and the crd compatibles
were rejiggered. ...so this makes sense. I'll expect that it will be
resolved when the current Qualcomm tree makes it to mainline.

-Doug

Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Doug Anderson]

Hi,

On Fri, May 13, 2022 at 2:01 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 13/05/2022 09:57, Krzysztof Kozlowski wrote:
> > On 12/05/2022 18:04, Douglas Anderson wrote:
> >> This copy-pastes compatibles from sc7180-based boards from the device
> >> trees to the yaml file so that `make dtbs_check` will be happy.
> >>
> >> NOTES:
> >> - I make no attempt to try to share an "item" for all sc7180 based
> >>   Chromebooks. Because of the revision matching scheme used by the
> >>   Chromebook bootloader, at times we need a different number of
> >>   revisions listed.
> >> - Some of the odd entries in here (like google,homestar-rev23 or the
> >>   fact that "Google Lazor Limozeen without Touchscreen" changed from
> >>   sku5 to sku6) are not typos but simply reflect reality.
> >> - Many revisions of boards here never actually went to consumers, but
> >>   they are still in use within various companies that were involved in
> >>   Chromebook development. Since Chromebooks are developed with an
> >>   "upstream first" methodology, having these revisions supported with
> >>   upstream Linux is important. Making it easy for Chromebooks to be
> >>   developed with an "upstream first" methodology is valuable to the
> >>   upstream community because it improves the quality of upstream and
> >>   gets Chromebooks supported with vanilla upstream faster.
> >>
> >> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> >> ---
> >>
> >>  .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
> >>  1 file changed, 180 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> >> index 5c06d1bfc046..399be67eb5d2 100644
> >> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> >> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> >> @@ -214,11 +214,191 @@ properties:
> >>                - qcom,ipq8074-hk10-c2
> >>            - const: qcom,ipq8074
> >>
> >> +      # Qualcomm Technologies, Inc. SC7180 IDP
> >>        - items:
> >>            - enum:
> >>                - qcom,sc7180-idp
> >>            - const: qcom,sc7180
> >>
> >> +      # Google CoachZ (rev1 - 2)
> >> +      - items:
> >> +          - const: google,coachz-rev1
> >> +          - const: google,coachz-rev2
> >
> > The inverted pattern of old revision being compatible with the new one,
> > is done on purpose? You claim here every rev1 is always compatible with
> > rev2 ...
> >
> > I don't think we discussed such patterns in previous talk. I quickly
> > went through it and there were only skuX moving around, not rev1 being
> > newer then rev2.

Isn't this what we just had a whole discussion about?

Oh, I see. You're objecting to the fact that the order here lists
"rev1" first and "rev2" second.

I think the issue here is that for the purposes of booting Chromebooks
the order here doesn't matter. Certainly we can pick a fixed order and
we can validate that the order in the yaml matches the order in the
device tree, but for all intents and purposes it doesn't matter to
anything. The same device tree is compatible with _both_ rev1 and rev2
coachz devices. Neither of those two devices is inherently better
supported by this device tree than the other.

We can reorder them if it's important for some reason, but it doesn't
change the facts of the matter. You can't tell whether you've booted a
"-rev1" Chromebook or a "-rev2" Chromebook based on the most specific
compatible string.

As per the other discussion, we could "solve" this by making two
device trees that were exactly the same but one of them had the
compatible "-rev1" the other "-rev2". This would result in a big
explosion in the number of device trees in our FIT Image for very
little gain. It also fails to solve the "newest rev" problem.


OK, so I've written up a description of the whole system. Maybe it
will be clearer with that and we can continue the discussion in my v2
if needed.

https://lore.kernel.org/r/20220513095722.v2.1.I71e42c6174f1cec17da3024c9f73ba373263b9b6@changeid

-Doug

Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Krzysztof Kozlowski]

On 13/05/2022 19:00, Doug Anderson wrote:
> Hi,
> 
> On Fri, May 13, 2022 at 2:01 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 13/05/2022 09:57, Krzysztof Kozlowski wrote:
>>> On 12/05/2022 18:04, Douglas Anderson wrote:
>>>> This copy-pastes compatibles from sc7180-based boards from the device
>>>> trees to the yaml file so that `make dtbs_check` will be happy.
>>>>
>>>> NOTES:
>>>> - I make no attempt to try to share an "item" for all sc7180 based
>>>>   Chromebooks. Because of the revision matching scheme used by the
>>>>   Chromebook bootloader, at times we need a different number of
>>>>   revisions listed.
>>>> - Some of the odd entries in here (like google,homestar-rev23 or the
>>>>   fact that "Google Lazor Limozeen without Touchscreen" changed from
>>>>   sku5 to sku6) are not typos but simply reflect reality.
>>>> - Many revisions of boards here never actually went to consumers, but
>>>>   they are still in use within various companies that were involved in
>>>>   Chromebook development. Since Chromebooks are developed with an
>>>>   "upstream first" methodology, having these revisions supported with
>>>>   upstream Linux is important. Making it easy for Chromebooks to be
>>>>   developed with an "upstream first" methodology is valuable to the
>>>>   upstream community because it improves the quality of upstream and
>>>>   gets Chromebooks supported with vanilla upstream faster.
>>>>
>>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>>> ---
>>>>
>>>>  .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
>>>>  1 file changed, 180 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> index 5c06d1bfc046..399be67eb5d2 100644
>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>> @@ -214,11 +214,191 @@ properties:
>>>>                - qcom,ipq8074-hk10-c2
>>>>            - const: qcom,ipq8074
>>>>
>>>> +      # Qualcomm Technologies, Inc. SC7180 IDP
>>>>        - items:
>>>>            - enum:
>>>>                - qcom,sc7180-idp
>>>>            - const: qcom,sc7180
>>>>
>>>> +      # Google CoachZ (rev1 - 2)
>>>> +      - items:
>>>> +          - const: google,coachz-rev1
>>>> +          - const: google,coachz-rev2
>>>
>>> The inverted pattern of old revision being compatible with the new one,
>>> is done on purpose? You claim here every rev1 is always compatible with
>>> rev2 ...
>>>
>>> I don't think we discussed such patterns in previous talk. I quickly
>>> went through it and there were only skuX moving around, not rev1 being
>>> newer then rev2.
> 
> Isn't this what we just had a whole discussion about?
> 
> Oh, I see. You're objecting to the fact that the order here lists
> "rev1" first and "rev2" second.
> 
> I think the issue here is that for the purposes of booting Chromebooks
> the order here doesn't matter. Certainly we can pick a fixed order and
> we can validate that the order in the yaml matches the order in the
> device tree, but for all intents and purposes it doesn't matter to
> anything. The same device tree is compatible with _both_ rev1 and rev2
> coachz devices. Neither of those two devices is inherently better
> supported by this device tree than the other.

OK, thanks for explanation. Since these were not documented maybe fixing
existing DTS to more expected order (rev2 being the newest, rev1
following) would make sense. But certainly please use such new order
compatibles for new DTSes.

> 
> We can reorder them if it's important for some reason, but it doesn't
> change the facts of the matter. You can't tell whether you've booted a
> "-rev1" Chromebook or a "-rev2" Chromebook based on the most specific
> compatible string.

Of course you cannot, because DT is not for such case (when you can use
different DT for booting on different hardware...)

> 
> As per the other discussion, we could "solve" this by making two
> device trees that were exactly the same but one of them had the
> compatible "-rev1" the other "-rev2". This would result in a big
> explosion in the number of device trees in our FIT Image for very
> little gain. It also fails to solve the "newest rev" problem.
> 
> 
> OK, so I've written up a description of the whole system. Maybe it
> will be clearer with that and we can continue the discussion in my v2
> if needed.
> 
> https://lore.kernel.org/r/20220513095722.v2.1.I71e42c6174f1cec17da3024c9f73ba373263b9b6@changeid
> 
> -Doug


Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Doug Anderson]

Hi,

On Sun, May 15, 2022 at 11:40 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 13/05/2022 19:00, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, May 13, 2022 at 2:01 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 13/05/2022 09:57, Krzysztof Kozlowski wrote:
> >>> On 12/05/2022 18:04, Douglas Anderson wrote:
> >>>> This copy-pastes compatibles from sc7180-based boards from the device
> >>>> trees to the yaml file so that `make dtbs_check` will be happy.
> >>>>
> >>>> NOTES:
> >>>> - I make no attempt to try to share an "item" for all sc7180 based
> >>>>   Chromebooks. Because of the revision matching scheme used by the
> >>>>   Chromebook bootloader, at times we need a different number of
> >>>>   revisions listed.
> >>>> - Some of the odd entries in here (like google,homestar-rev23 or the
> >>>>   fact that "Google Lazor Limozeen without Touchscreen" changed from
> >>>>   sku5 to sku6) are not typos but simply reflect reality.
> >>>> - Many revisions of boards here never actually went to consumers, but
> >>>>   they are still in use within various companies that were involved in
> >>>>   Chromebook development. Since Chromebooks are developed with an
> >>>>   "upstream first" methodology, having these revisions supported with
> >>>>   upstream Linux is important. Making it easy for Chromebooks to be
> >>>>   developed with an "upstream first" methodology is valuable to the
> >>>>   upstream community because it improves the quality of upstream and
> >>>>   gets Chromebooks supported with vanilla upstream faster.
> >>>>
> >>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> >>>> ---
> >>>>
> >>>>  .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
> >>>>  1 file changed, 180 insertions(+)
> >>>>
> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> index 5c06d1bfc046..399be67eb5d2 100644
> >>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>> @@ -214,11 +214,191 @@ properties:
> >>>>                - qcom,ipq8074-hk10-c2
> >>>>            - const: qcom,ipq8074
> >>>>
> >>>> +      # Qualcomm Technologies, Inc. SC7180 IDP
> >>>>        - items:
> >>>>            - enum:
> >>>>                - qcom,sc7180-idp
> >>>>            - const: qcom,sc7180
> >>>>
> >>>> +      # Google CoachZ (rev1 - 2)
> >>>> +      - items:
> >>>> +          - const: google,coachz-rev1
> >>>> +          - const: google,coachz-rev2
> >>>
> >>> The inverted pattern of old revision being compatible with the new one,
> >>> is done on purpose? You claim here every rev1 is always compatible with
> >>> rev2 ...
> >>>
> >>> I don't think we discussed such patterns in previous talk. I quickly
> >>> went through it and there were only skuX moving around, not rev1 being
> >>> newer then rev2.
> >
> > Isn't this what we just had a whole discussion about?
> >
> > Oh, I see. You're objecting to the fact that the order here lists
> > "rev1" first and "rev2" second.
> >
> > I think the issue here is that for the purposes of booting Chromebooks
> > the order here doesn't matter. Certainly we can pick a fixed order and
> > we can validate that the order in the yaml matches the order in the
> > device tree, but for all intents and purposes it doesn't matter to
> > anything. The same device tree is compatible with _both_ rev1 and rev2
> > coachz devices. Neither of those two devices is inherently better
> > supported by this device tree than the other.
>
> OK, thanks for explanation. Since these were not documented maybe fixing
> existing DTS to more expected order (rev2 being the newest, rev1
> following) would make sense. But certainly please use such new order
> compatibles for new DTSes.

I'm still not sure I understand: if the list of revisions is
effectively unordered, why does it matter which order they are listed
in? Certainly we can change the order, but I'm not sure how I justify
the extra churn in my patch description.

-Doug

Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Krzysztof Kozlowski]

On 16/05/2022 17:11, Doug Anderson wrote:
> Hi,
> 
> On Sun, May 15, 2022 at 11:40 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 13/05/2022 19:00, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Fri, May 13, 2022 at 2:01 AM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 13/05/2022 09:57, Krzysztof Kozlowski wrote:
>>>>> On 12/05/2022 18:04, Douglas Anderson wrote:
>>>>>> This copy-pastes compatibles from sc7180-based boards from the device
>>>>>> trees to the yaml file so that `make dtbs_check` will be happy.
>>>>>>
>>>>>> NOTES:
>>>>>> - I make no attempt to try to share an "item" for all sc7180 based
>>>>>>   Chromebooks. Because of the revision matching scheme used by the
>>>>>>   Chromebook bootloader, at times we need a different number of
>>>>>>   revisions listed.
>>>>>> - Some of the odd entries in here (like google,homestar-rev23 or the
>>>>>>   fact that "Google Lazor Limozeen without Touchscreen" changed from
>>>>>>   sku5 to sku6) are not typos but simply reflect reality.
>>>>>> - Many revisions of boards here never actually went to consumers, but
>>>>>>   they are still in use within various companies that were involved in
>>>>>>   Chromebook development. Since Chromebooks are developed with an
>>>>>>   "upstream first" methodology, having these revisions supported with
>>>>>>   upstream Linux is important. Making it easy for Chromebooks to be
>>>>>>   developed with an "upstream first" methodology is valuable to the
>>>>>>   upstream community because it improves the quality of upstream and
>>>>>>   gets Chromebooks supported with vanilla upstream faster.
>>>>>>
>>>>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
>>>>>> ---
>>>>>>
>>>>>>  .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
>>>>>>  1 file changed, 180 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> index 5c06d1bfc046..399be67eb5d2 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> @@ -214,11 +214,191 @@ properties:
>>>>>>                - qcom,ipq8074-hk10-c2
>>>>>>            - const: qcom,ipq8074
>>>>>>
>>>>>> +      # Qualcomm Technologies, Inc. SC7180 IDP
>>>>>>        - items:
>>>>>>            - enum:
>>>>>>                - qcom,sc7180-idp
>>>>>>            - const: qcom,sc7180
>>>>>>
>>>>>> +      # Google CoachZ (rev1 - 2)
>>>>>> +      - items:
>>>>>> +          - const: google,coachz-rev1
>>>>>> +          - const: google,coachz-rev2
>>>>>
>>>>> The inverted pattern of old revision being compatible with the new one,
>>>>> is done on purpose? You claim here every rev1 is always compatible with
>>>>> rev2 ...
>>>>>
>>>>> I don't think we discussed such patterns in previous talk. I quickly
>>>>> went through it and there were only skuX moving around, not rev1 being
>>>>> newer then rev2.
>>>
>>> Isn't this what we just had a whole discussion about?
>>>
>>> Oh, I see. You're objecting to the fact that the order here lists
>>> "rev1" first and "rev2" second.
>>>
>>> I think the issue here is that for the purposes of booting Chromebooks
>>> the order here doesn't matter. Certainly we can pick a fixed order and
>>> we can validate that the order in the yaml matches the order in the
>>> device tree, but for all intents and purposes it doesn't matter to
>>> anything. The same device tree is compatible with _both_ rev1 and rev2
>>> coachz devices. Neither of those two devices is inherently better
>>> supported by this device tree than the other.
>>
>> OK, thanks for explanation. Since these were not documented maybe fixing
>> existing DTS to more expected order (rev2 being the newest, rev1
>> following) would make sense. But certainly please use such new order
>> compatibles for new DTSes.
> 
> I'm still not sure I understand: if the list of revisions is
> effectively unordered, why does it matter which order they are listed
> in? Certainly we can change the order, but I'm not sure how I justify
> the extra churn in my patch description.

The list for the bindings (YAML), the toolset and for the Devicetree
spec is ordered. Even if it is not ordered for your bootloader
implementation. Your current order is a bit confusing:

compatible = "google,coachz-rev1", "google,coachz-rev2", "qcom,sc7180";

Changing the order in existing DTS, might not be worth. I propose then
to introduce the logical order in the future, so for new DTS:

compatible = "google,XXX-rev2", "google,XXX-rev1", "qcom,sc7180";

I understood that for your bootloader it does not matter.

Best regards,
Krzysztof

Re: [PATCH 1/3] dt-bindings: arm: qcom: Add sc7180 Chromebook board bindings

[Doug Anderson]

Hi,

On Mon, May 16, 2022 at 8:15 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 16/05/2022 17:11, Doug Anderson wrote:
> > Hi,
> >
> > On Sun, May 15, 2022 at 11:40 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 13/05/2022 19:00, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Fri, May 13, 2022 at 2:01 AM Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>
> >>>> On 13/05/2022 09:57, Krzysztof Kozlowski wrote:
> >>>>> On 12/05/2022 18:04, Douglas Anderson wrote:
> >>>>>> This copy-pastes compatibles from sc7180-based boards from the device
> >>>>>> trees to the yaml file so that `make dtbs_check` will be happy.
> >>>>>>
> >>>>>> NOTES:
> >>>>>> - I make no attempt to try to share an "item" for all sc7180 based
> >>>>>>   Chromebooks. Because of the revision matching scheme used by the
> >>>>>>   Chromebook bootloader, at times we need a different number of
> >>>>>>   revisions listed.
> >>>>>> - Some of the odd entries in here (like google,homestar-rev23 or the
> >>>>>>   fact that "Google Lazor Limozeen without Touchscreen" changed from
> >>>>>>   sku5 to sku6) are not typos but simply reflect reality.
> >>>>>> - Many revisions of boards here never actually went to consumers, but
> >>>>>>   they are still in use within various companies that were involved in
> >>>>>>   Chromebook development. Since Chromebooks are developed with an
> >>>>>>   "upstream first" methodology, having these revisions supported with
> >>>>>>   upstream Linux is important. Making it easy for Chromebooks to be
> >>>>>>   developed with an "upstream first" methodology is valuable to the
> >>>>>>   upstream community because it improves the quality of upstream and
> >>>>>>   gets Chromebooks supported with vanilla upstream faster.
> >>>>>>
> >>>>>> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> >>>>>> ---
> >>>>>>
> >>>>>>  .../devicetree/bindings/arm/qcom.yaml         | 180 ++++++++++++++++++
> >>>>>>  1 file changed, 180 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>>>> index 5c06d1bfc046..399be67eb5d2 100644
> >>>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> >>>>>> @@ -214,11 +214,191 @@ properties:
> >>>>>>                - qcom,ipq8074-hk10-c2
> >>>>>>            - const: qcom,ipq8074
> >>>>>>
> >>>>>> +      # Qualcomm Technologies, Inc. SC7180 IDP
> >>>>>>        - items:
> >>>>>>            - enum:
> >>>>>>                - qcom,sc7180-idp
> >>>>>>            - const: qcom,sc7180
> >>>>>>
> >>>>>> +      # Google CoachZ (rev1 - 2)
> >>>>>> +      - items:
> >>>>>> +          - const: google,coachz-rev1
> >>>>>> +          - const: google,coachz-rev2
> >>>>>
> >>>>> The inverted pattern of old revision being compatible with the new one,
> >>>>> is done on purpose? You claim here every rev1 is always compatible with
> >>>>> rev2 ...
> >>>>>
> >>>>> I don't think we discussed such patterns in previous talk. I quickly
> >>>>> went through it and there were only skuX moving around, not rev1 being
> >>>>> newer then rev2.
> >>>
> >>> Isn't this what we just had a whole discussion about?
> >>>
> >>> Oh, I see. You're objecting to the fact that the order here lists
> >>> "rev1" first and "rev2" second.
> >>>
> >>> I think the issue here is that for the purposes of booting Chromebooks
> >>> the order here doesn't matter. Certainly we can pick a fixed order and
> >>> we can validate that the order in the yaml matches the order in the
> >>> device tree, but for all intents and purposes it doesn't matter to
> >>> anything. The same device tree is compatible with _both_ rev1 and rev2
> >>> coachz devices. Neither of those two devices is inherently better
> >>> supported by this device tree than the other.
> >>
> >> OK, thanks for explanation. Since these were not documented maybe fixing
> >> existing DTS to more expected order (rev2 being the newest, rev1
> >> following) would make sense. But certainly please use such new order
> >> compatibles for new DTSes.
> >
> > I'm still not sure I understand: if the list of revisions is
> > effectively unordered, why does it matter which order they are listed
> > in? Certainly we can change the order, but I'm not sure how I justify
> > the extra churn in my patch description.
>
> The list for the bindings (YAML), the toolset and for the Devicetree
> spec is ordered. Even if it is not ordered for your bootloader
> implementation.

Understood. This is just like clocks where technically they are
unordered (because you have "clock-names" to look them up) but it is
expected that the order be documented and consistent, if nothing else
to make it easier to validate.


> Your current order is a bit confusing:
>
> compatible = "google,coachz-rev1", "google,coachz-rev2", "qcom,sc7180";
>
> Changing the order in existing DTS, might not be worth.

OK, I'll leave the existing DTS alone.


> I propose then
> to introduce the logical order in the future, so for new DTS:
>
> compatible = "google,XXX-rev2", "google,XXX-rev1", "qcom,sc7180";
>
> I understood that for your bootloader it does not matter.

Sure. I'm not sure why it's any less confusing to list higher
revisions first, but if you find it less confusing we can do it in the
future.

-Doug