[PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Dmitry Baryshkov]

Describing each compatible board in DT schema seems wrong to me. It
means that each new board is incompatible by default, until added to the DT
schema. Adding support for more and more devices would grow this file
indefinitely. Drop most of individual device-specific compatibility
strings leaving just list of platforms in place. All entries which
differ from two-item string array are left inplace.

To ease review first patch provides just a scripted conversion, with all
platform entries being unmodified, while second patch actually merges
them into a single enum.

Dmitry Baryshkov (3):
  dt-bindings: arm: qcom: stop describing individual boards
  dt-bindings: arm: qcom: merge simple platform definitions
  dt-bindings: arm: qcom: drop individual descriptions of Google devices

 .../devicetree/bindings/arm/qcom.yaml         | 515 ++----------------
 1 file changed, 43 insertions(+), 472 deletions(-)

-- 
2.35.1

[PATCH 1/3] dt-bindings: arm: qcom: stop describing individual boards

[Dmitry Baryshkov]

Describing each compatible board in DT schema seems wrong to me. It
means that each new board is incompatible by default, until added to the
DT schema. If any of the vendors for whatever reasons tries to validate
their new device's DT, they will be stuck with it being incompatible
with arm/qcom.yaml until the file is expanded to include such devices.

Rework simple cases by dropping individual board compatible strings and
replacing them with the empty schema.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 .../devicetree/bindings/arm/qcom.yaml         | 203 ++++--------------
 1 file changed, 39 insertions(+), 164 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index fb1d00bcc847..d4d945a43178 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -107,60 +107,39 @@ properties:
   compatible:
     oneOf:
       - items:
-          - enum:
-              - qcom,apq8016-sbc
+          - {}
           - const: qcom,apq8016
 
       - items:
-          - enum:
-              - asus,sparrow
-              - lg,lenok
+          - {}
           - const: qcom,apq8026
 
       - items:
-          - enum:
-              - asus,nexus7-flo
-              - lg,nexus4-mako
-              - sony,xperia-yuga
-              - qcom,apq8064-cm-qs600
-              - qcom,apq8064-ifc6410
+          - {}
           - const: qcom,apq8064
 
       - items:
-          - enum:
-              - qcom,apq8074-dragonboard
+          - {}
           - const: qcom,apq8074
 
       - items:
-          - enum:
-              - qcom,apq8060-dragonboard
-              - qcom,msm8660-surf
+          - {}
           - const: qcom,msm8660
 
       - items:
-          - enum:
-              - qcom,apq8084-mtp
-              - qcom,apq8084-sbc
+          - {}
           - const: qcom,apq8084
 
       - items:
-          - enum:
-              - samsung,s3ve3g
+          - {}
           - const: qcom,msm8226
 
       - items:
-          - enum:
-              - qcom,msm8960-cdp
+          - {}
           - const: qcom,msm8960
 
       - items:
-          - enum:
-              - fairphone,fp2
-              - lge,hammerhead
-              - samsung,klte
-              - sony,xperia-amami
-              - sony,xperia-castor
-              - sony,xperia-honami
+          - {}
           - const: qcom,msm8974
 
       - items:
@@ -169,16 +148,7 @@ properties:
           - const: qcom,msm8916
 
       - items:
-          - enum:
-              - alcatel,idol347
-              - asus,z00l
-              - huawei,g7
-              - longcheer,l8910
-              - samsung,a3u-eur
-              - samsung,a5u-eur
-              - samsung,j5
-              - samsung,serranove
-              - wingtech,wt88047
+          - {}
           - const: qcom,msm8916
 
       - items:
@@ -187,26 +157,15 @@ properties:
           - const: qcom,msm8916
 
       - items:
-          - enum:
-              - lg,bullhead
-              - microsoft,talkman
-              - xiaomi,libra
+          - {}
           - const: qcom,msm8992
 
       - items:
-          - enum:
-              - sony,karin_windy
+          - {}
           - const: qcom,apq8094
 
       - items:
-          - enum:
-              - huawei,angler
-              - microsoft,cityman
-              - sony,ivy-row
-              - sony,karin-row
-              - sony,satsuki-row
-              - sony,sumire-row
-              - sony,suzuran-row
+          - {}
           - const: qcom,msm8994
 
       - items:
@@ -217,49 +176,23 @@ properties:
           - const: qcom,apq8096
 
       - items:
-          - enum:
-              - qcom,msm8996-mtp
-              - sony,dora-row
-              - sony,kagura-row
-              - sony,keyaki-row
-              - xiaomi,gemini
-              - xiaomi,natrium
-              - xiaomi,scorpio
+          - {}
           - const: qcom,msm8996
 
       - items:
-          - enum:
-              - asus,novago-tp370ql
-              - fxtec,pro1
-              - hp,envy-x2
-              - lenovo,miix-630
-              - oneplus,cheeseburger
-              - oneplus,dumpling
-              - qcom,msm8998-mtp
-              - sony,xperia-lilac
-              - sony,xperia-maple
-              - sony,xperia-poplar
+          - {}
           - const: qcom,msm8998
 
       - items:
-          - enum:
-              - qcom,ipq4019-ap-dk01.1-c1
-              - qcom,ipq4019-ap-dk04.1-c3
-              - qcom,ipq4019-ap-dk07.1-c1
-              - qcom,ipq4019-ap-dk07.1-c2
-              - qcom,ipq4019-dk04.1-c1
+          - {}
           - const: qcom,ipq4019
 
       - items:
-          - enum:
-              - qcom,ipq8064-ap148
+          - {}
           - const: qcom,ipq8064
 
       - items:
-          - enum:
-              - qcom,ipq8074-hk01
-              - qcom,ipq8074-hk10-c1
-              - qcom,ipq8074-hk10-c2
+          - {}
           - const: qcom,ipq8074
 
       - description: Qualcomm Technologies, Inc. SC7180 IDP
@@ -576,146 +509,88 @@ properties:
           - const: qcom,sc7280
 
       - items:
-          - enum:
-              - lenovo,flex-5g
-              - microsoft,surface-prox
-              - qcom,sc8180x-primus
+          - {}
           - const: qcom,sc8180x
 
       - items:
-          - enum:
-              - lenovo,thinkpad-x13s
-              - qcom,sc8280xp-crd
-              - qcom,sc8280xp-qrd
+          - {}
           - const: qcom,sc8280xp
 
       - items:
-          - enum:
-              - sony,discovery-row
-              - sony,kirin-row
-              - sony,pioneer-row
-              - sony,voyager-row
+          - {}
           - const: qcom,sdm630
 
       - items:
-          - enum:
-              - inforce,ifc6560
+          - {}
           - const: qcom,sda660
 
       - items:
-          - enum:
-              - fairphone,fp3
+          - {}
           - const: qcom,sdm632
 
       - items:
-          - enum:
-              - sony,mermaid-row
+          - {}
           - const: qcom,sdm636
 
       - items:
-          - enum:
-              - xiaomi,lavender
+          - {}
           - const: qcom,sdm660
 
       - items:
-          - enum:
-              - qcom,sdx55-mtp
-              - qcom,sdx55-telit-fn980-tlb
-              - qcom,sdx55-t55
+          - {}
           - const: qcom,sdx55
 
       - items:
-          - enum:
-              - qcom,sdx65-mtp
+          - {}
           - const: qcom,sdx65
 
       - items:
-          - enum:
-              - qcom,ipq6018-cp01
-              - qcom,ipq6018-cp01-c1
+          - {}
           - const: qcom,ipq6018
 
       - items:
-          - enum:
-              - qcom,qcs404-evb-1000
-              - qcom,qcs404-evb-4000
+          - {}
           - const: qcom,qcs404-evb
           - const: qcom,qcs404
 
       - items:
-          - enum:
-              - qcom,sa8155p-adp
+          - {}
           - const: qcom,sa8155p
 
       - items:
-          - enum:
-              - qcom,sa8295p-adp
+          - {}
           - const: qcom,sa8540p
 
       - items:
-          - enum:
-              - lenovo,yoga-c630
-              - lg,judyln
-              - lg,judyp
-              - oneplus,enchilada
-              - oneplus,fajita
-              - qcom,sdm845-mtp
-              - shift,axolotl
-              - samsung,w737
-              - sony,akari-row
-              - sony,akatsuki-row
-              - sony,apollo-row
-              - thundercomm,db845c
-              - xiaomi,beryllium
-              - xiaomi,polaris
+          - {}
           - const: qcom,sdm845
 
       - items:
-          - enum:
-              - sony,pdx201
+          - {}
           - const: qcom,sm6125
 
       - items:
-          - enum:
-              - sony,pdx213
+          - {}
           - const: qcom,sm6350
 
       - items:
-          - enum:
-              - fairphone,fp4
+          - {}
           - const: qcom,sm7225
 
       - items:
-          - enum:
-              - microsoft,surface-duo
-              - qcom,sm8150-hdk
-              - qcom,sm8150-mtp
-              - sony,bahamut-generic
-              - sony,griffin-generic
+          - {}
           - const: qcom,sm8150
 
       - items:
-          - enum:
-              - qcom,qrb5165-rb5
-              - qcom,sm8250-hdk
-              - qcom,sm8250-mtp
-              - sony,pdx203-generic
-              - sony,pdx206-generic
+          - {}
           - const: qcom,sm8250
 
       - items:
-          - enum:
-              - microsoft,surface-duo2
-              - qcom,sm8350-hdk
-              - qcom,sm8350-mtp
-              - sony,pdx214-generic
-              - sony,pdx215-generic
+          - {}
           - const: qcom,sm8350
 
       - items:
-          - enum:
-              - qcom,sm8450-hdk
-              - qcom,sm8450-qrd
+          - {}
           - const: qcom,sm8450
 
 additionalProperties: true
-- 
2.35.1

Re: [PATCH 1/3] dt-bindings: arm: qcom: stop describing individual boards

[Krzysztof Kozlowski]

On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> Describing each compatible board in DT schema seems wrong to me. It
> means that each new board is incompatible by default, until added to the
> DT schema. If any of the vendors for whatever reasons tries to validate
> their new device's DT, they will be stuck with it being incompatible
> with arm/qcom.yaml until the file is expanded to include such devices.
> 
> Rework simple cases by dropping individual board compatible strings and
> replacing them with the empty schema.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
>  .../devicetree/bindings/arm/qcom.yaml         | 203 ++++--------------
>  1 file changed, 39 insertions(+), 164 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
> index fb1d00bcc847..d4d945a43178 100644
> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
> @@ -107,60 +107,39 @@ properties:
>    compatible:
>      oneOf:
>        - items:
> -          - enum:
> -              - qcom,apq8016-sbc
> +          - {}
>            - const: qcom,apq8016
>  

No, this removes documentation of compatibles thus removes part
documenting the ABI.


Best regards,
Krzysztof

[PATCH 2/3] dt-bindings: arm: qcom: merge simple platform definitions

[Dmitry Baryshkov]

Merge most existing Qualcomm platform definitions, which consist of
empty schema plus single SoC string.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 .../devicetree/bindings/arm/qcom.yaml         | 188 ++++--------------
 1 file changed, 39 insertions(+), 149 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d4d945a43178..809d3de18194 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -108,66 +108,56 @@ properties:
     oneOf:
       - items:
           - {}
-          - const: qcom,apq8016
-
-      - items:
-          - {}
-          - const: qcom,apq8026
-
-      - items:
-          - {}
-          - const: qcom,apq8064
-
-      - items:
-          - {}
-          - const: qcom,apq8074
-
-      - items:
-          - {}
-          - const: qcom,msm8660
-
-      - items:
-          - {}
-          - const: qcom,apq8084
-
-      - items:
-          - {}
-          - const: qcom,msm8226
-
-      - items:
-          - {}
-          - const: qcom,msm8960
-
-      - items:
-          - {}
-          - const: qcom,msm8974
+          - enum:
+              - qcom,apq8016
+              - qcom,apq8026
+              - qcom,apq8064
+              - qcom,apq8074
+              - qcom,apq8084
+              - qcom,apq8094
+              - qcom,ipq4019
+              - qcom,ipq6018
+              - qcom,ipq8064
+              - qcom,ipq8074
+              - qcom,msm8226
+              - qcom,msm8660
+              - qcom,msm8916
+              - qcom,msm8960
+              - qcom,msm8974
+              - qcom,msm8992
+              - qcom,msm8994
+              - qcom,msm8996
+              - qcom,msm8998
+              - qcom,sa8155p
+              - qcom,sa8540p
+              - qcom,sc8180x
+              - qcom,sc8280xp
+              - qcom,sda660
+              - qcom,sdm630
+              - qcom,sdm632
+              - qcom,sdm636
+              - qcom,sdm660
+              - qcom,sdm845
+              - qcom,sdx55
+              - qcom,sdx65
+              - qcom,sm6125
+              - qcom,sm6350
+              - qcom,sm7225
+              - qcom,sm8150
+              - qcom,sm8250
+              - qcom,sm8350
+              - qcom,sm8450
 
       - items:
           - const: qcom,msm8916-mtp
           - const: qcom,msm8916-mtp/1
           - const: qcom,msm8916
 
-      - items:
-          - {}
-          - const: qcom,msm8916
-
       - items:
           - const: longcheer,l8150
           - const: qcom,msm8916-v1-qrd/9-v1
           - const: qcom,msm8916
 
-      - items:
-          - {}
-          - const: qcom,msm8992
-
-      - items:
-          - {}
-          - const: qcom,apq8094
-
-      - items:
-          - {}
-          - const: qcom,msm8994
-
       - items:
           - enum:
               - arrow,apq8096-db820c
@@ -175,26 +165,6 @@ properties:
           - const: qcom,apq8096-sbc
           - const: qcom,apq8096
 
-      - items:
-          - {}
-          - const: qcom,msm8996
-
-      - items:
-          - {}
-          - const: qcom,msm8998
-
-      - items:
-          - {}
-          - const: qcom,ipq4019
-
-      - items:
-          - {}
-          - const: qcom,ipq8064
-
-      - items:
-          - {}
-          - const: qcom,ipq8074
-
       - description: Qualcomm Technologies, Inc. SC7180 IDP
         items:
           - enum:
@@ -508,91 +478,11 @@ properties:
           - const: google,villager
           - const: qcom,sc7280
 
-      - items:
-          - {}
-          - const: qcom,sc8180x
-
-      - items:
-          - {}
-          - const: qcom,sc8280xp
-
-      - items:
-          - {}
-          - const: qcom,sdm630
-
-      - items:
-          - {}
-          - const: qcom,sda660
-
-      - items:
-          - {}
-          - const: qcom,sdm632
-
-      - items:
-          - {}
-          - const: qcom,sdm636
-
-      - items:
-          - {}
-          - const: qcom,sdm660
-
-      - items:
-          - {}
-          - const: qcom,sdx55
-
-      - items:
-          - {}
-          - const: qcom,sdx65
-
-      - items:
-          - {}
-          - const: qcom,ipq6018
-
       - items:
           - {}
           - const: qcom,qcs404-evb
           - const: qcom,qcs404
 
-      - items:
-          - {}
-          - const: qcom,sa8155p
-
-      - items:
-          - {}
-          - const: qcom,sa8540p
-
-      - items:
-          - {}
-          - const: qcom,sdm845
-
-      - items:
-          - {}
-          - const: qcom,sm6125
-
-      - items:
-          - {}
-          - const: qcom,sm6350
-
-      - items:
-          - {}
-          - const: qcom,sm7225
-
-      - items:
-          - {}
-          - const: qcom,sm8150
-
-      - items:
-          - {}
-          - const: qcom,sm8250
-
-      - items:
-          - {}
-          - const: qcom,sm8350
-
-      - items:
-          - {}
-          - const: qcom,sm8450
-
 additionalProperties: true
 
 ...
-- 
2.35.1

Re: [PATCH 2/3] dt-bindings: arm: qcom: merge simple platform definitions

[Krzysztof Kozlowski]

On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> Merge most existing Qualcomm platform definitions, which consist of
> empty schema plus single SoC string.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

Just oneOf:
 - items:
     - {}
     - {}
 - items:
     - {}
     - {}
     - {}
 - items:
     - {}
     - {}
     - {}
     - {}
 - items:
     - {}
     - {}
     - {}
     - {}
     - {}

and all boards and all SoCs are handled.

So unfortunately that's a no.


Best regards,
Krzysztof

[PATCH 3/3] dt-bindings: arm: qcom: drop individual descriptions of Google devices

[Dmitry Baryshkov]

Follow the pattern and drop simple sc7180/sc7280 device declarations.
The goal to leave in place only non-standard cases, rather than
documenting every possible device.

Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
 .../devicetree/bindings/arm/qcom.yaml         | 198 +-----------------
 1 file changed, 2 insertions(+), 196 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 809d3de18194..f2d3209a25fa 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -130,6 +130,8 @@ properties:
               - qcom,msm8998
               - qcom,sa8155p
               - qcom,sa8540p
+              - qcom,sc7180
+              - qcom,sc7280
               - qcom,sc8180x
               - qcom,sc8280xp
               - qcom,sda660
@@ -165,65 +167,24 @@ properties:
           - const: qcom,apq8096-sbc
           - const: qcom,apq8096
 
-      - description: Qualcomm Technologies, Inc. SC7180 IDP
-        items:
-          - enum:
-              - qcom,sc7180-idp
-          - const: qcom,sc7180
-
       - description: HP Chromebook x2 11c (rev1 - 2)
         items:
           - const: google,coachz-rev1
           - const: google,coachz-rev2
           - const: qcom,sc7180
 
-      - description: HP Chromebook x2 11c (newest rev)
-        items:
-          - const: google,coachz
-          - const: qcom,sc7180
-
       - description: HP Chromebook x2 11c with LTE (rev1 - 2)
         items:
           - const: google,coachz-rev1-sku0
           - const: google,coachz-rev2-sku0
           - const: qcom,sc7180
 
-      - description: HP Chromebook x2 11c with LTE (newest rev)
-        items:
-          - const: google,coachz-sku0
-          - const: qcom,sc7180
-
       - description: Lenovo Chromebook Duet 5 13 (rev2)
         items:
           - const: google,homestar-rev2
           - const: google,homestar-rev23
           - const: qcom,sc7180
 
-      - description: Lenovo Chromebook Duet 5 13 (rev3)
-        items:
-          - const: google,homestar-rev3
-          - const: qcom,sc7180
-
-      - description: Lenovo Chromebook Duet 5 13 (newest rev)
-        items:
-          - const: google,homestar
-          - const: qcom,sc7180
-
-      - description: Google Kingoftown (rev0)
-        items:
-          - const: google,kingoftown-rev0
-          - const: qcom,sc7180
-
-      - description: Google Kingoftown (newest rev)
-        items:
-          - const: google,kingoftown
-          - const: qcom,sc7180
-
-      - description: Acer Chromebook Spin 513 (rev0)
-        items:
-          - const: google,lazor-rev0
-          - const: qcom,sc7180
-
       - description: Acer Chromebook Spin 513 (rev1 - 2)
         items:
           - const: google,lazor-rev1
@@ -240,11 +201,6 @@ properties:
           - const: google,lazor-rev8
           - const: qcom,sc7180
 
-      - description: Acer Chromebook Spin 513 (newest rev)
-        items:
-          - const: google,lazor
-          - const: qcom,sc7180
-
       - description: Acer Chromebook Spin 513 with KB Backlight (rev1 - 2)
         items:
           - const: google,lazor-rev1-sku2
@@ -261,11 +217,6 @@ properties:
           - const: google,lazor-rev8-sku2
           - const: qcom,sc7180
 
-      - description: Acer Chromebook Spin 513 with KB Backlight (newest rev)
-        items:
-          - const: google,lazor-sku2
-          - const: qcom,sc7180
-
       - description: Acer Chromebook Spin 513 with LTE (rev1 - 2)
         items:
           - const: google,lazor-rev1-sku0
@@ -282,11 +233,6 @@ properties:
           - const: google,lazor-rev8-sku0
           - const: qcom,sc7180
 
-      - description: Acer Chromebook Spin 513 with LTE (newest rev)
-        items:
-          - const: google,lazor-sku0
-          - const: qcom,sc7180
-
       - description: Acer Chromebook 511 (rev4 - rev8)
         items:
           - const: google,lazor-rev4-sku4
@@ -296,16 +242,6 @@ properties:
           - const: google,lazor-rev8-sku4
           - const: qcom,sc7180
 
-      - description: Acer Chromebook 511 (newest rev)
-        items:
-          - const: google,lazor-sku4
-          - const: qcom,sc7180
-
-      - description: Acer Chromebook 511 without Touchscreen (rev4)
-        items:
-          - const: google,lazor-rev4-sku5
-          - const: qcom,sc7180
-
       - description: Acer Chromebook 511 without Touchscreen (rev5 - rev8)
         items:
           - const: google,lazor-rev5-sku5
@@ -315,133 +251,18 @@ properties:
           - const: google,lazor-rev8-sku6
           - const: qcom,sc7180
 
-      - description: Acer Chromebook 511 without Touchscreen (newest rev)
-        items:
-          - const: google,lazor-sku6
-          - const: qcom,sc7180
-
-      - description: Google Mrbland with AUO panel (rev0)
-        items:
-          - const: google,mrbland-rev0-sku0
-          - const: qcom,sc7180
-
-      - description: Google Mrbland with AUO panel (newest rev)
-        items:
-          - const: google,mrbland-sku1536
-          - const: qcom,sc7180
-
-      - description: Google Mrbland with BOE panel (rev0)
-        items:
-          - const: google,mrbland-rev0-sku16
-          - const: qcom,sc7180
-
       - description: Google Mrbland with BOE panel (newest rev)
         items:
           - const: google,mrbland-sku1024
           - const: google,mrbland-sku768
           - const: qcom,sc7180
 
-      - description: Google Pazquel with Parade (newest rev)
-        items:
-          - const: google,pazquel-sku5
-          - const: qcom,sc7180
-
-      - description: Google Pazquel with TI (newest rev)
-        items:
-          - const: google,pazquel-sku1
-          - const: qcom,sc7180
-
-      - description: Google Pazquel with LTE and Parade (newest rev)
-        items:
-          - const: google,pazquel-sku4
-          - const: qcom,sc7180
-
       - description: Google Pazquel with LTE and TI (newest rev)
         items:
           - const: google,pazquel-sku0
           - const: google,pazquel-sku2
           - const: qcom,sc7180
 
-      - description: Sharp Dynabook Chromebook C1 (rev1)
-        items:
-          - const: google,pompom-rev1
-          - const: qcom,sc7180
-
-      - description: Sharp Dynabook Chromebook C1 (rev2)
-        items:
-          - const: google,pompom-rev2
-          - const: qcom,sc7180
-
-      - description: Sharp Dynabook Chromebook C1 (newest rev)
-        items:
-          - const: google,pompom
-          - const: qcom,sc7180
-
-      - description: Sharp Dynabook Chromebook C1 with LTE (rev1)
-        items:
-          - const: google,pompom-rev1-sku0
-          - const: qcom,sc7180
-
-      - description: Sharp Dynabook Chromebook C1 with LTE (rev2)
-        items:
-          - const: google,pompom-rev2-sku0
-          - const: qcom,sc7180
-
-      - description: Sharp Dynabook Chromebook C1 with LTE (newest rev)
-        items:
-          - const: google,pompom-sku0
-          - const: qcom,sc7180
-
-      - description: Google Quackingstick (newest rev)
-        items:
-          - const: google,quackingstick-sku1537
-          - const: qcom,sc7180
-
-      - description: Google Quackingstick with LTE (newest rev)
-        items:
-          - const: google,quackingstick-sku1536
-          - const: qcom,sc7180
-
-      - description: Google Trogdor (newest rev)
-        items:
-          - const: google,trogdor
-          - const: qcom,sc7180
-
-      - description: Google Trogdor with LTE (newest rev)
-        items:
-          - const: google,trogdor-sku0
-          - const: qcom,sc7180
-
-      - description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel (rev0)
-        items:
-          - const: google,wormdingler-rev0-sku16
-          - const: qcom,sc7180
-
-      - description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel (newest rev)
-        items:
-          - const: google,wormdingler-sku1024
-          - const: qcom,sc7180
-
-      - description: Lenovo IdeaPad Chromebook Duet 3 with BOE panel and rt5682s (newest rev)
-        items:
-          - const: google,wormdingler-sku1025
-          - const: qcom,sc7180
-
-      - description: Lenovo IdeaPad Chromebook Duet 3 with INX panel (rev0)
-        items:
-          - const: google,wormdingler-rev0-sku0
-          - const: qcom,sc7180
-
-      - description: Lenovo IdeaPad Chromebook Duet 3 with INX panel (newest rev)
-        items:
-          - const: google,wormdingler-sku0
-          - const: qcom,sc7180
-
-      - description: Lenovo IdeaPad Chromebook Duet 3 with INX panel and rt5682s (newest rev)
-        items:
-          - const: google,wormdingler-sku1
-          - const: qcom,sc7180
-
       - description: Qualcomm Technologies, Inc. sc7280 CRD platform (rev3 - 4)
         items:
           - const: qcom,sc7280-crd
@@ -451,11 +272,6 @@ properties:
           - const: google,piglin-rev4
           - const: qcom,sc7280
 
-      - description: Qualcomm Technologies, Inc. sc7280 CRD platform (newest rev)
-        items:
-          - const: google,hoglin
-          - const: qcom,sc7280
-
       - description: Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform
         items:
           - const: qcom,sc7280-idp
@@ -468,16 +284,6 @@ properties:
           - const: google,piglin
           - const: qcom,sc7280
 
-      - description: Google Herobrine (newest rev)
-        items:
-          - const: google,herobrine
-          - const: qcom,sc7280
-
-      - description: Google Villager (newest rev)
-        items:
-          - const: google,villager
-          - const: qcom,sc7280
-
       - items:
           - {}
           - const: qcom,qcs404-evb
-- 
2.35.1

Re: [PATCH 3/3] dt-bindings: arm: qcom: drop individual descriptions of Google devices

[Krzysztof Kozlowski]

On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> Follow the pattern and drop simple sc7180/sc7280 device declarations.
> The goal to leave in place only non-standard cases, rather than
> documenting every possible device.
> 
> Cc: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>

As well no.


Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Krzysztof Kozlowski]

On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> Describing each compatible board in DT schema seems wrong to me. It
> means that each new board is incompatible by default, until added to the DT
> schema. 

The bindings do not document something because it is or it is no
compatible. They document the compatible. Your patch essentially removes
the documentation, so there is no point in having compatibles in board
at all...

>Adding support for more and more devices would grow this file
> indefinitely. Drop most of individual device-specific compatibility
> strings leaving just list of platforms in place. All entries which
> differ from two-item string array are left inplace.


Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Dmitry Baryshkov]

On Sat, 23 Jul 2022 at 20:48, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> > Describing each compatible board in DT schema seems wrong to me. It
> > means that each new board is incompatible by default, until added to the DT
> > schema.

s/incompatible/non-valid/

>
> The bindings do not document something because it is or it is no
> compatible. They document the compatible. Your patch essentially removes
> the documentation, so there is no point in having compatibles in board
> at all...

I do not quite agree here. Please correct me if I'm wrong.
Schema defines which DT files are correct and which are not. Which
properties are required, which values are valid, etc. So far so good.
For the device nodes it declares (or is willing to declare) all
possible compatibility strings. There is a sensible number of on-chip
IP blocks, external chips, etc. Each and every new chip (or new IP
block) we are going to have a yaml file describing its usage. Perfect.
For the machine compatibility lists the arm,qcom schema declares which
machine compat strings are valid. And this looks like a problem. Now
for the DT to be fully valid against DT schema, we have to define its
machine compat string.
For each and every phone/sbc/evb we have to name it in schema. I think
this is an overkill. It feels like we are putting DT information
(mapping form machine compat to SoC) into the DT schema.
For qcs404 we already have a schema which uses three items: {},
qcom,qcs404-evb, qcom,qcs404. This sounds like a perfect idea to me.
We allow any board, created by Qualcomm, Google or any other random
vendor, named Foo, Bar or Baz, as long as it declares that it is
compatible with qcom,qcs404-evb.

To go even further. We now have the qrb5165-rb5.dts, declaring
compatible = "qcom,qrb5165-rb5", "qcom,sm8250".
If at some point I add a navigation/communication/whatever mezz on top
of it. It would make sense to use compatible =
"qcom,qrb5165-rb5-navi-comm", "qcom,qrb5165-rb5", "qcom,sm8250".
Adding this to the growing list inside arm,qcom.yaml sounds like a
nightmare. I can only hope that at some point JSON schema gains
postfixItems support (as proposed) to be able to change e.g.
arm,qcom.yaml to list just our qcom,something platforms as possible
postfixItems for the schema.

Regarding having compatibles in board files at all. I think that they
are somehow misused nowadays. Instead of declaring that the
Dragonboard 845c is compatible with "thundercomm,db845c",
"qcom,sdm845-sbc", "96boards,ce-board", "96boards,iot-board",
"qcom,sdm845", the DT file declares nearly useless
"thundercomm,db845c", "qcom,sdm845".

Thus, if we (mostly) use machine compatible array to just define
Vendor+device name and the underlying Qualcomm SoC, I propose to leave
just a sensible part (SoC) in DT schema, while allowing any string in
the first part.

> >Adding support for more and more devices would grow this file
> > indefinitely. Drop most of individual device-specific compatibility
> > strings leaving just list of platforms in place. All entries which
> > differ from two-item string array are left inplace.

-- 
With best wishes
Dmitry

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Krzysztof Kozlowski]

On 24/07/2022 00:50, Dmitry Baryshkov wrote:
> On Sat, 23 Jul 2022 at 20:48, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 23/07/2022 11:09, Dmitry Baryshkov wrote:
>>> Describing each compatible board in DT schema seems wrong to me. It
>>> means that each new board is incompatible by default, until added to the DT
>>> schema.
> 
> s/incompatible/non-valid/
> 
>>
>> The bindings do not document something because it is or it is no
>> compatible. They document the compatible. Your patch essentially removes
>> the documentation, so there is no point in having compatibles in board
>> at all...
> 
> I do not quite agree here. Please correct me if I'm wrong.
> Schema defines which DT files are correct and which are not. Which
> properties are required, which values are valid, etc. So far so good.

Schema is a tool, we create here bindings. The bindings document what
you wrote above, plus compatibles and any other pieces mentioned in DT spec.

> For the device nodes it declares (or is willing to declare) all
> possible compatibility strings. There is a sensible number of on-chip
> IP blocks, external chips, etc. Each and every new chip (or new IP
> block) we are going to have a yaml file describing its usage. Perfect.
> For the machine compatibility lists the arm,qcom schema declares which
> machine compat strings are valid. And this looks like a problem. Now
> for the DT to be fully valid against DT schema, we have to define its
> machine compat string.

Although one of goals is to have schema compliance, that is not the
reason why we document compatibles. Compatibles were documented long
time ago before DT schema came, because the bindings require it.

Bindings define the interface between the DTS and software which uses
it. SW is kernel, bootloaders, user-space and some more.

> For each and every phone/sbc/evb we have to name it in schema. I think
> this is an overkill. 

Qualcomm is rather moderate, nothing big here so definitely it is not an
overkill. We almost do not have there SoMs. Just take a pick at
Freescale - this is much more complex than Qualcomm, so any changes
should start with that. Qualcomm's "complexity" is not a reason to do
anything...

> It feels like we are putting DT information
> (mapping form machine compat to SoC) into the DT schema.

No, we are documenting the compatible in bindings. Just like we always
did and we always had to.

> For qcs404 we already have a schema which uses three items: {},
> qcom,qcs404-evb, qcom,qcs404. This sounds like a perfect idea to me.
> We allow any board, created by Qualcomm, Google or any other random
> vendor, named Foo, Bar or Baz, as long as it declares that it is
> compatible with qcom,qcs404-evb.
> 
> To go even further. We now have the qrb5165-rb5.dts, declaring
> compatible = "qcom,qrb5165-rb5", "qcom,sm8250".
> If at some point I add a navigation/communication/whatever mezz on top
> of it. It would make sense to use compatible =
> "qcom,qrb5165-rb5-navi-comm", "qcom,qrb5165-rb5", "qcom,sm8250".
> Adding this to the growing list inside arm,qcom.yaml sounds like a
> nightmare. I can only hope that at some point JSON schema gains
> postfixItems support (as proposed) to be able to change e.g.
> arm,qcom.yaml to list just our qcom,something platforms as possible
> postfixItems for the schema.

Again, Qualcomm complexity is nothing compared to Freescale. :)

> 
> Regarding having compatibles in board files at all. I think that they
> are somehow misused nowadays. Instead of declaring that the
> Dragonboard 845c is compatible with "thundercomm,db845c",
> "qcom,sdm845-sbc", "96boards,ce-board", "96boards,iot-board",
> "qcom,sdm845", the DT file declares nearly useless
> "thundercomm,db845c", "qcom,sdm845".
> 
> Thus, if we (mostly) use machine compatible array to just define
> Vendor+device name and the underlying Qualcomm SoC, I propose to leave
> just a sensible part (SoC) in DT schema, while allowing any string in
> the first part.


No, because you miss then the purpose of bindings - to document the
compatible which is the important piece of interface between
DTS/bootloader/kernel/other OS/user-space.

To summarize, you propose to not document board compatibles. This is not
what we want, because then the next step is - let's don't document SoCs.
If you do not document it, means anyone can uniliteraly change it, e.g.
in kernel DTS, which will break all other users (e.g. user-space or
bootloaders) parsing the compatibles. And before you say - no one parses
the board compatibles - let me just say that several user-space
(embedded/closed) parse them, bootloaders parse them (U-Boot, Google's
Chromebooks and others)

Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Dmitry Baryshkov]

On Mon, 25 Jul 2022 at 19:18, Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 24/07/2022 00:50, Dmitry Baryshkov wrote:
> > On Sat, 23 Jul 2022 at 20:48, Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> >>> Describing each compatible board in DT schema seems wrong to me. It
> >>> means that each new board is incompatible by default, until added to the DT
> >>> schema.
> >
> > s/incompatible/non-valid/
> >
> >>
> >> The bindings do not document something because it is or it is no
> >> compatible. They document the compatible. Your patch essentially removes
> >> the documentation, so there is no point in having compatibles in board
> >> at all...
> >
> > I do not quite agree here. Please correct me if I'm wrong.
> > Schema defines which DT files are correct and which are not. Which
> > properties are required, which values are valid, etc. So far so good.
>
> Schema is a tool, we create here bindings. The bindings document what
> you wrote above, plus compatibles and any other pieces mentioned in DT spec.
>
> > For the device nodes it declares (or is willing to declare) all
> > possible compatibility strings. There is a sensible number of on-chip
> > IP blocks, external chips, etc. Each and every new chip (or new IP
> > block) we are going to have a yaml file describing its usage. Perfect.
> > For the machine compatibility lists the arm,qcom schema declares which
> > machine compat strings are valid. And this looks like a problem. Now
> > for the DT to be fully valid against DT schema, we have to define its
> > machine compat string.
>
> Although one of goals is to have schema compliance, that is not the
> reason why we document compatibles. Compatibles were documented long
> time ago before DT schema came, because the bindings require it.
>
> Bindings define the interface between the DTS and software which uses
> it. SW is kernel, bootloaders, user-space and some more.

I completely agree here.

From the point of HW/SW interfaces maybe the following compat lists
would make more sense:
- "xiaomi,msm8996-phone", "qcom,msm8996"
- "qcom,qrb5165-iot-platform", "qcom,sm8250"
- "qcom,sda845-iot-platform", "qcom,sdm845"
- "inforce,sda660-sbc", "qcom,sda660"

etc. IOW, describing the kind of the device, not the exact name/model of it.

>
> > For each and every phone/sbc/evb we have to name it in schema. I think
> > this is an overkill.
>
> Qualcomm is rather moderate, nothing big here so definitely it is not an
> overkill. We almost do not have there SoMs. Just take a pick at
> Freescale - this is much more complex than Qualcomm, so any changes
> should start with that. Qualcomm's "complexity" is not a reason to do
> anything...

Yeah, been there. As I wrote earlier, this looks like a postfixItems use case.

>
> > It feels like we are putting DT information
> > (mapping form machine compat to SoC) into the DT schema.
>
> No, we are documenting the compatible in bindings. Just like we always
> did and we always had to.
>
> > For qcs404 we already have a schema which uses three items: {},
> > qcom,qcs404-evb, qcom,qcs404. This sounds like a perfect idea to me.
> > We allow any board, created by Qualcomm, Google or any other random
> > vendor, named Foo, Bar or Baz, as long as it declares that it is
> > compatible with qcom,qcs404-evb.
> >
> > To go even further. We now have the qrb5165-rb5.dts, declaring
> > compatible = "qcom,qrb5165-rb5", "qcom,sm8250".
> > If at some point I add a navigation/communication/whatever mezz on top
> > of it. It would make sense to use compatible =
> > "qcom,qrb5165-rb5-navi-comm", "qcom,qrb5165-rb5", "qcom,sm8250".
> > Adding this to the growing list inside arm,qcom.yaml sounds like a
> > nightmare. I can only hope that at some point JSON schema gains
> > postfixItems support (as proposed) to be able to change e.g.
> > arm,qcom.yaml to list just our qcom,something platforms as possible
> > postfixItems for the schema.
>
> Again, Qualcomm complexity is nothing compared to Freescale. :)

Fortunately :-)
I was trying to propose a way to have a useful schema, while keeping
it small enough.

> > Regarding having compatibles in board files at all. I think that they
> > are somehow misused nowadays. Instead of declaring that the
> > Dragonboard 845c is compatible with "thundercomm,db845c",
> > "qcom,sdm845-sbc", "96boards,ce-board", "96boards,iot-board",
> > "qcom,sdm845", the DT file declares nearly useless
> > "thundercomm,db845c", "qcom,sdm845".
> >
> > Thus, if we (mostly) use machine compatible array to just define
> > Vendor+device name and the underlying Qualcomm SoC, I propose to leave
> > just a sensible part (SoC) in DT schema, while allowing any string in
> > the first part.
>
>
> No, because you miss then the purpose of bindings - to document the
> compatible which is the important piece of interface between
> DTS/bootloader/kernel/other OS/user-space.
>
> To summarize, you propose to not document board compatibles. This is not
> what we want, because then the next step is - let's don't document SoCs.
> If you do not document it, means anyone can uniliteraly change it, e.g.
> in kernel DTS, which will break all other users (e.g. user-space or
> bootloaders) parsing the compatibles. And before you say - no one parses
> the board compatibles - let me just say that several user-space
> (embedded/closed) parse them, bootloaders parse them (U-Boot, Google's
> Chromebooks and others)

Yes, I know. And in the case of e.g. Google ChromeOS bootloader it
might make sense to declare compatibles using patterns rather than
enumeration.

Anyway, thank you for your comments, let's continue with documenting
all the devices until something changes.

-- 
With best wishes
Dmitry

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Krzysztof Kozlowski]

On 25/07/2022 19:13, Dmitry Baryshkov wrote:
> On Mon, 25 Jul 2022 at 19:18, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 24/07/2022 00:50, Dmitry Baryshkov wrote:
>>> On Sat, 23 Jul 2022 at 20:48, Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 23/07/2022 11:09, Dmitry Baryshkov wrote:
>>>>> Describing each compatible board in DT schema seems wrong to me. It
>>>>> means that each new board is incompatible by default, until added to the DT
>>>>> schema.
>>>
>>> s/incompatible/non-valid/
>>>
>>>>
>>>> The bindings do not document something because it is or it is no
>>>> compatible. They document the compatible. Your patch essentially removes
>>>> the documentation, so there is no point in having compatibles in board
>>>> at all...
>>>
>>> I do not quite agree here. Please correct me if I'm wrong.
>>> Schema defines which DT files are correct and which are not. Which
>>> properties are required, which values are valid, etc. So far so good.
>>
>> Schema is a tool, we create here bindings. The bindings document what
>> you wrote above, plus compatibles and any other pieces mentioned in DT spec.
>>
>>> For the device nodes it declares (or is willing to declare) all
>>> possible compatibility strings. There is a sensible number of on-chip
>>> IP blocks, external chips, etc. Each and every new chip (or new IP
>>> block) we are going to have a yaml file describing its usage. Perfect.
>>> For the machine compatibility lists the arm,qcom schema declares which
>>> machine compat strings are valid. And this looks like a problem. Now
>>> for the DT to be fully valid against DT schema, we have to define its
>>> machine compat string.
>>
>> Although one of goals is to have schema compliance, that is not the
>> reason why we document compatibles. Compatibles were documented long
>> time ago before DT schema came, because the bindings require it.
>>
>> Bindings define the interface between the DTS and software which uses
>> it. SW is kernel, bootloaders, user-space and some more.
> 
> I completely agree here.
> 
> From the point of HW/SW interfaces maybe the following compat lists
> would make more sense:
> - "xiaomi,msm8996-phone", "qcom,msm8996"
> - "qcom,qrb5165-iot-platform", "qcom,sm8250"
> - "qcom,sda845-iot-platform", "qcom,sdm845"
> - "inforce,sda660-sbc", "qcom,sda660"
> 
> etc. IOW, describing the kind of the device, not the exact name/model of it.

With a specific compatible (covered by pattern), this could work,
although not sure what would be the benefit. Other components, like some
user-space or bootloader might still need the specific compatible.

And if anyone needs a specific compatible, it means it should be documented.

>> To summarize, you propose to not document board compatibles. This is not
>> what we want, because then the next step is - let's don't document SoCs.
>> If you do not document it, means anyone can uniliteraly change it, e.g.
>> in kernel DTS, which will break all other users (e.g. user-space or
>> bootloaders) parsing the compatibles. And before you say - no one parses
>> the board compatibles - let me just say that several user-space
>> (embedded/closed) parse them, bootloaders parse them (U-Boot, Google's
>> Chromebooks and others)
> 
> Yes, I know. And in the case of e.g. Google ChromeOS bootloader it
> might make sense to declare compatibles using patterns rather than
> enumeration.

Patterns would simplify here a lot but also would allow (thus not
validate) incorrect combinations. Consider Ssytem-on-Modules:

oneOf:
 - items:
   - {}
   - foo,som-msm8996
   - qcom,msm8996
 - items:
   - {}
   - qcom,msm8996

what stops anyone to have a DTS:
"xiaomi,msm8996-phone", "foo,som-msm8996", "qcom,msm8996"
? even though it does not contain that SoM from company Foo?

For DT schema it would be a perfectly valid combination, even though it
would not make any sense. We document valid machines/compatibles as
documentation of the interface but the schema also allows us - with that
documentation - to actually check if DTS is correct.

One more use case are the the qcom,board-id and msm-id properties. They
might once be restricted to specific board compatibles, because maybe
only the closed-bootloader platforms need them. We don't want these
properties in general, thus we might decide to prohibit to use them in
open platforms (e.g. using open bootloader). Without board compatibles
we won't be able to do it.


> Anyway, thank you for your comments, let's continue with documenting
> all the devices until something changes.
> 


Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Doug Anderson]

Hi,

On Sat, Jul 23, 2022 at 3:51 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Sat, 23 Jul 2022 at 20:48, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> > > Describing each compatible board in DT schema seems wrong to me. It
> > > means that each new board is incompatible by default, until added to the DT
> > > schema.
>
> s/incompatible/non-valid/
>
> >
> > The bindings do not document something because it is or it is no
> > compatible. They document the compatible. Your patch essentially removes
> > the documentation, so there is no point in having compatibles in board
> > at all...
>
> I do not quite agree here. Please correct me if I'm wrong.
> Schema defines which DT files are correct and which are not. Which
> properties are required, which values are valid, etc. So far so good.
> For the device nodes it declares (or is willing to declare) all
> possible compatibility strings. There is a sensible number of on-chip
> IP blocks, external chips, etc. Each and every new chip (or new IP
> block) we are going to have a yaml file describing its usage. Perfect.
> For the machine compatibility lists the arm,qcom schema declares which
> machine compat strings are valid. And this looks like a problem. Now
> for the DT to be fully valid against DT schema, we have to define its
> machine compat string.
> For each and every phone/sbc/evb we have to name it in schema. I think
> this is an overkill. It feels like we are putting DT information
> (mapping form machine compat to SoC) into the DT schema.
> For qcs404 we already have a schema which uses three items: {},
> qcom,qcs404-evb, qcom,qcs404. This sounds like a perfect idea to me.
> We allow any board, created by Qualcomm, Google or any other random
> vendor, named Foo, Bar or Baz, as long as it declares that it is
> compatible with qcom,qcs404-evb.

I assume the above was supposed to be "as long as it declares that it
is compatible with qcom-qcs404" since everywhere else you're declaring
that only the SoC compatible is important.

In any case, I would tend to agree that the most useful thing that the
schema here is doing is validating that we didn't have a typo in the
SoC field. I already tried to argue that adding every board into this
yaml file seemed like extra overhead without a lot of benefit but I
finally ceded to do the busy work instead of continuing to argue.

As a side note, at one point Stephen Boyd was on a quest to get the
"SoC" removed from the top-level compatible and moved to the "SoC"
node. I dunno if that's still something he's pursuing.


> To go even further. We now have the qrb5165-rb5.dts, declaring
> compatible = "qcom,qrb5165-rb5", "qcom,sm8250".
> If at some point I add a navigation/communication/whatever mezz on top
> of it. It would make sense to use compatible =
> "qcom,qrb5165-rb5-navi-comm", "qcom,qrb5165-rb5", "qcom,sm8250".
> Adding this to the growing list inside arm,qcom.yaml sounds like a
> nightmare. I can only hope that at some point JSON schema gains
> postfixItems support (as proposed) to be able to change e.g.
> arm,qcom.yaml to list just our qcom,something platforms as possible
> postfixItems for the schema.
>
> Regarding having compatibles in board files at all. I think that they
> are somehow misused nowadays. Instead of declaring that the
> Dragonboard 845c is compatible with "thundercomm,db845c",
> "qcom,sdm845-sbc", "96boards,ce-board", "96boards,iot-board",
> "qcom,sdm845", the DT file declares nearly useless
> "thundercomm,db845c", "qcom,sdm845".

Again a little bit of an aside, but one point I've tried
(unsuccessfully) to make in the past is that, at least for the
ChromeOS bootloader (and presumably anyone else using a FIT image),
the top-level compatible works almost completely opposite of all the
rest of the compatibles.

For most compatible strings, you start with a known device tree file
which declares the compatibles for a peripheral. You then search for a
driver that can handle that peripheral. You start with the first
string and try to find a driver for that. If you can't, you go onto
the second string which is supposed to work, just not as well. Great.

The top level compatible string, at least in the case of ChromeOS, is
used by the bootloader to pick among all the device tree files it has.
That's a critical difference.

Let me try to be concrete. Let's say you have two boards that are
exactly identical but one has LTE components stuffed and one doesn't
(it's WiFi only). It's fine to treat the LTE board as a WiFi-only
board but not OK to treat the WiFi-only board as an LTE board (it'll
crash). The bootloader knows (through its own means) whether you're on
LTE or WiFi-only and is given a pile of device trees.

Let's look specifically at the device tree file for the LTE board. One
way to look at it is that the dts for the LTE board should have
compatibles:
  compatible = "lte", "wifi-only"

The above matches the normal device tree mentality. It says: "hey, if
you've got a lte driver for this board then use it; otherwise use the
wifi-only driver".

However, the above is actually broken for the bootloader use case. The
bootloader is trying to pick a device tree and, to the bootloader, the
above says "you can use this dts for either an lte board or a
wifi-only board". That's bad. If the bootloader picks this device tree
for a wifi-only board then the OS will try to initialize lte and
things will crash. To go further, if you think about it things
actually work fine if the wifi-only device tree says it's compatible
with the LTE board. This is why I say it's opposite... ;-)


> Thus, if we (mostly) use machine compatible array to just define
> Vendor+device name and the underlying Qualcomm SoC, I propose to leave
> just a sensible part (SoC) in DT schema, while allowing any string in
> the first part.
>
> > >Adding support for more and more devices would grow this file
> > > indefinitely. Drop most of individual device-specific compatibility
> > > strings leaving just list of platforms in place. All entries which
> > > differ from two-item string array are left inplace.
>
> --
> With best wishes
> Dmitry

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Krzysztof Kozlowski]

On 25/07/2022 18:25, Doug Anderson wrote:
> Let's look specifically at the device tree file for the LTE board. One
> way to look at it is that the dts for the LTE board should have
> compatibles:
>   compatible = "lte", "wifi-only"
> 
> The above matches the normal device tree mentality. It says: "hey, if
> you've got a lte driver for this board then use it; otherwise use the
> wifi-only driver".
> 
> However, the above is actually broken for the bootloader use case. The
> bootloader is trying to pick a device tree and, to the bootloader, the
> above says "you can use this dts for either an lte board or a
> wifi-only board". That's bad. If the bootloader picks this device tree
> for a wifi-only board then the OS will try to initialize lte and
> things will crash. To go further, if you think about it things
> actually work fine if the wifi-only device tree says it's compatible
> with the LTE board. This is why I say it's opposite... ;-)

This is not specific to "bootloaders" but your specific implementation
of entire chain. How you described it, you have dependent pieces -
user-space must use the same DTB as bootloader chosen, but bootloader
makes different choices than user-space. It's perfectly fine to make
these choices different, but then user-space should not depend on
something which was/was not initialized in bootloader.

IOW, if bootloader picked up generic WiFi compatible and user-space will
crash if picking up specific comaptible, you have a dependency and
user-space should probably bind to modified DTB, where LTE comaptible is
removed.

Other systems - I would say most of them - are independent, IOW, we try
to make kernel and user-space independent of what bootloader did,
because we are never sure what bootloader actually did and what DTS it
received.

Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Doug Anderson]

Hi,

On Mon, Jul 25, 2022 at 9:41 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/07/2022 18:25, Doug Anderson wrote:
> > Let's look specifically at the device tree file for the LTE board. One
> > way to look at it is that the dts for the LTE board should have
> > compatibles:
> >   compatible = "lte", "wifi-only"
> >
> > The above matches the normal device tree mentality. It says: "hey, if
> > you've got a lte driver for this board then use it; otherwise use the
> > wifi-only driver".
> >
> > However, the above is actually broken for the bootloader use case. The
> > bootloader is trying to pick a device tree and, to the bootloader, the
> > above says "you can use this dts for either an lte board or a
> > wifi-only board". That's bad. If the bootloader picks this device tree
> > for a wifi-only board then the OS will try to initialize lte and
> > things will crash. To go further, if you think about it things
> > actually work fine if the wifi-only device tree says it's compatible
> > with the LTE board. This is why I say it's opposite... ;-)
>
> This is not specific to "bootloaders" but your specific implementation
> of entire chain. How you described it, you have dependent pieces -
> user-space must use the same DTB as bootloader chosen, but bootloader
> makes different choices than user-space. It's perfectly fine to make
> these choices different, but then user-space should not depend on
> something which was/was not initialized in bootloader.

I think there's a misunderstanding here.

Currently the ChromeOS bootloader doesn't use the device tree to
control its flow at all. ...but the ChromeOS bootloader is in charge
of picking the device tree to give to the kernel.

Specifically I'm not aware of any mechanism in the kernel where you
can give it a pile of device tree files and have it pick the right
one. I believe that the official ABI says that it's up to the
bootloader to provide the device tree to the kernel. This is right out
of `Documentation/arm64/booting.rst`

A FIT image is, as far as I'm aware, a standard way to bundle a kernel
together with many device trees. The idea here is that the bootloader
should grab the kernel out and whichever device tree it decides is the
right one. It should then boot the kernel and give it the correct
device tree.

-Doug

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Krzysztof Kozlowski]

On 25/07/2022 18:54, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jul 25, 2022 at 9:41 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 25/07/2022 18:25, Doug Anderson wrote:
>>> Let's look specifically at the device tree file for the LTE board. One
>>> way to look at it is that the dts for the LTE board should have
>>> compatibles:
>>>   compatible = "lte", "wifi-only"
>>>
>>> The above matches the normal device tree mentality. It says: "hey, if
>>> you've got a lte driver for this board then use it; otherwise use the
>>> wifi-only driver".
>>>
>>> However, the above is actually broken for the bootloader use case. The
>>> bootloader is trying to pick a device tree and, to the bootloader, the
>>> above says "you can use this dts for either an lte board or a
>>> wifi-only board". That's bad. If the bootloader picks this device tree
>>> for a wifi-only board then the OS will try to initialize lte and
>>> things will crash. To go further, if you think about it things
>>> actually work fine if the wifi-only device tree says it's compatible
>>> with the LTE board. This is why I say it's opposite... ;-)
>>
>> This is not specific to "bootloaders" but your specific implementation
>> of entire chain. How you described it, you have dependent pieces -
>> user-space must use the same DTB as bootloader chosen, but bootloader
>> makes different choices than user-space. It's perfectly fine to make
>> these choices different, but then user-space should not depend on
>> something which was/was not initialized in bootloader.
> 
> I think there's a misunderstanding here.
> 
> Currently the ChromeOS bootloader doesn't use the device tree to
> control its flow at all. ...but the ChromeOS bootloader is in charge
> of picking the device tree to give to the kernel.
> 
> Specifically I'm not aware of any mechanism in the kernel where you
> can give it a pile of device tree files and have it pick the right
> one. I believe that the official ABI says that it's up to the
> bootloader to provide the device tree to the kernel. This is right out
> of `Documentation/arm64/booting.rst`
> 
> A FIT image is, as far as I'm aware, a standard way to bundle a kernel
> together with many device trees. The idea here is that the bootloader
> should grab the kernel out and whichever device tree it decides is the
> right one. It should then boot the kernel and give it the correct
> device tree.

So that's the same case if you had a device called "Foo" (google,foo)
with a Qualcomm sdm845 processor (qcom,sdm845) and have a DTS like:
"other-company,bar", "qcom,sdm845"

Bootloader on Foo sees "bar", ignores it. Then it sees "qcom,sdm845"
compatible and is all happy! It loads the DTS and passes to the kernel...

You cannot do that...

Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Doug Anderson]

Hi,

On Mon, Jul 25, 2022 at 10:08 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/07/2022 18:54, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Jul 25, 2022 at 9:41 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 25/07/2022 18:25, Doug Anderson wrote:
> >>> Let's look specifically at the device tree file for the LTE board. One
> >>> way to look at it is that the dts for the LTE board should have
> >>> compatibles:
> >>>   compatible = "lte", "wifi-only"
> >>>
> >>> The above matches the normal device tree mentality. It says: "hey, if
> >>> you've got a lte driver for this board then use it; otherwise use the
> >>> wifi-only driver".
> >>>
> >>> However, the above is actually broken for the bootloader use case. The
> >>> bootloader is trying to pick a device tree and, to the bootloader, the
> >>> above says "you can use this dts for either an lte board or a
> >>> wifi-only board". That's bad. If the bootloader picks this device tree
> >>> for a wifi-only board then the OS will try to initialize lte and
> >>> things will crash. To go further, if you think about it things
> >>> actually work fine if the wifi-only device tree says it's compatible
> >>> with the LTE board. This is why I say it's opposite... ;-)
> >>
> >> This is not specific to "bootloaders" but your specific implementation
> >> of entire chain. How you described it, you have dependent pieces -
> >> user-space must use the same DTB as bootloader chosen, but bootloader
> >> makes different choices than user-space. It's perfectly fine to make
> >> these choices different, but then user-space should not depend on
> >> something which was/was not initialized in bootloader.
> >
> > I think there's a misunderstanding here.
> >
> > Currently the ChromeOS bootloader doesn't use the device tree to
> > control its flow at all. ...but the ChromeOS bootloader is in charge
> > of picking the device tree to give to the kernel.
> >
> > Specifically I'm not aware of any mechanism in the kernel where you
> > can give it a pile of device tree files and have it pick the right
> > one. I believe that the official ABI says that it's up to the
> > bootloader to provide the device tree to the kernel. This is right out
> > of `Documentation/arm64/booting.rst`
> >
> > A FIT image is, as far as I'm aware, a standard way to bundle a kernel
> > together with many device trees. The idea here is that the bootloader
> > should grab the kernel out and whichever device tree it decides is the
> > right one. It should then boot the kernel and give it the correct
> > device tree.
>
> So that's the same case if you had a device called "Foo" (google,foo)
> with a Qualcomm sdm845 processor (qcom,sdm845) and have a DTS like:
> "other-company,bar", "qcom,sdm845"
>
> Bootloader on Foo sees "bar", ignores it. Then it sees "qcom,sdm845"
> compatible and is all happy! It loads the DTS and passes to the kernel...
>
> You cannot do that...

The bootloader never falls back to just the SoC name.

-Doug

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Krzysztof Kozlowski]

On 25/07/2022 19:09, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jul 25, 2022 at 10:08 AM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 25/07/2022 18:54, Doug Anderson wrote:
>>> Hi,
>>>
>>> On Mon, Jul 25, 2022 at 9:41 AM Krzysztof Kozlowski
>>> <krzysztof.kozlowski@linaro.org> wrote:
>>>>
>>>> On 25/07/2022 18:25, Doug Anderson wrote:
>>>>> Let's look specifically at the device tree file for the LTE board. One
>>>>> way to look at it is that the dts for the LTE board should have
>>>>> compatibles:
>>>>>   compatible = "lte", "wifi-only"
>>>>>
>>>>> The above matches the normal device tree mentality. It says: "hey, if
>>>>> you've got a lte driver for this board then use it; otherwise use the
>>>>> wifi-only driver".
>>>>>
>>>>> However, the above is actually broken for the bootloader use case. The
>>>>> bootloader is trying to pick a device tree and, to the bootloader, the
>>>>> above says "you can use this dts for either an lte board or a
>>>>> wifi-only board". That's bad. If the bootloader picks this device tree
>>>>> for a wifi-only board then the OS will try to initialize lte and
>>>>> things will crash. To go further, if you think about it things
>>>>> actually work fine if the wifi-only device tree says it's compatible
>>>>> with the LTE board. This is why I say it's opposite... ;-)
>>>>
>>>> This is not specific to "bootloaders" but your specific implementation
>>>> of entire chain. How you described it, you have dependent pieces -
>>>> user-space must use the same DTB as bootloader chosen, but bootloader
>>>> makes different choices than user-space. It's perfectly fine to make
>>>> these choices different, but then user-space should not depend on
>>>> something which was/was not initialized in bootloader.
>>>
>>> I think there's a misunderstanding here.
>>>
>>> Currently the ChromeOS bootloader doesn't use the device tree to
>>> control its flow at all. ...but the ChromeOS bootloader is in charge
>>> of picking the device tree to give to the kernel.
>>>
>>> Specifically I'm not aware of any mechanism in the kernel where you
>>> can give it a pile of device tree files and have it pick the right
>>> one. I believe that the official ABI says that it's up to the
>>> bootloader to provide the device tree to the kernel. This is right out
>>> of `Documentation/arm64/booting.rst`
>>>
>>> A FIT image is, as far as I'm aware, a standard way to bundle a kernel
>>> together with many device trees. The idea here is that the bootloader
>>> should grab the kernel out and whichever device tree it decides is the
>>> right one. It should then boot the kernel and give it the correct
>>> device tree.
>>
>> So that's the same case if you had a device called "Foo" (google,foo)
>> with a Qualcomm sdm845 processor (qcom,sdm845) and have a DTS like:
>> "other-company,bar", "qcom,sdm845"
>>
>> Bootloader on Foo sees "bar", ignores it. Then it sees "qcom,sdm845"
>> compatible and is all happy! It loads the DTS and passes to the kernel...
>>
>> You cannot do that...
> 
> The bootloader never falls back to just the SoC name.

There is no "SoC" part of compatible list. Only by convenience we put it
that way, but DT spec does not define first compatible to be for
platform because they all are[1], therefore following your earlier
description - bootloader should load BAR DTS on FOO device just because
qcom,sdm845 matches.

[1]
https://devicetree-specification.readthedocs.io/en/latest/chapter3-devicenodes.html#root-node

Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Doug Anderson]

Hi,

On Mon, Jul 25, 2022 at 10:14 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/07/2022 19:09, Doug Anderson wrote:
> > Hi,
> >
> > On Mon, Jul 25, 2022 at 10:08 AM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 25/07/2022 18:54, Doug Anderson wrote:
> >>> Hi,
> >>>
> >>> On Mon, Jul 25, 2022 at 9:41 AM Krzysztof Kozlowski
> >>> <krzysztof.kozlowski@linaro.org> wrote:
> >>>>
> >>>> On 25/07/2022 18:25, Doug Anderson wrote:
> >>>>> Let's look specifically at the device tree file for the LTE board. One
> >>>>> way to look at it is that the dts for the LTE board should have
> >>>>> compatibles:
> >>>>>   compatible = "lte", "wifi-only"
> >>>>>
> >>>>> The above matches the normal device tree mentality. It says: "hey, if
> >>>>> you've got a lte driver for this board then use it; otherwise use the
> >>>>> wifi-only driver".
> >>>>>
> >>>>> However, the above is actually broken for the bootloader use case. The
> >>>>> bootloader is trying to pick a device tree and, to the bootloader, the
> >>>>> above says "you can use this dts for either an lte board or a
> >>>>> wifi-only board". That's bad. If the bootloader picks this device tree
> >>>>> for a wifi-only board then the OS will try to initialize lte and
> >>>>> things will crash. To go further, if you think about it things
> >>>>> actually work fine if the wifi-only device tree says it's compatible
> >>>>> with the LTE board. This is why I say it's opposite... ;-)
> >>>>
> >>>> This is not specific to "bootloaders" but your specific implementation
> >>>> of entire chain. How you described it, you have dependent pieces -
> >>>> user-space must use the same DTB as bootloader chosen, but bootloader
> >>>> makes different choices than user-space. It's perfectly fine to make
> >>>> these choices different, but then user-space should not depend on
> >>>> something which was/was not initialized in bootloader.
> >>>
> >>> I think there's a misunderstanding here.
> >>>
> >>> Currently the ChromeOS bootloader doesn't use the device tree to
> >>> control its flow at all. ...but the ChromeOS bootloader is in charge
> >>> of picking the device tree to give to the kernel.
> >>>
> >>> Specifically I'm not aware of any mechanism in the kernel where you
> >>> can give it a pile of device tree files and have it pick the right
> >>> one. I believe that the official ABI says that it's up to the
> >>> bootloader to provide the device tree to the kernel. This is right out
> >>> of `Documentation/arm64/booting.rst`
> >>>
> >>> A FIT image is, as far as I'm aware, a standard way to bundle a kernel
> >>> together with many device trees. The idea here is that the bootloader
> >>> should grab the kernel out and whichever device tree it decides is the
> >>> right one. It should then boot the kernel and give it the correct
> >>> device tree.
> >>
> >> So that's the same case if you had a device called "Foo" (google,foo)
> >> with a Qualcomm sdm845 processor (qcom,sdm845) and have a DTS like:
> >> "other-company,bar", "qcom,sdm845"
> >>
> >> Bootloader on Foo sees "bar", ignores it. Then it sees "qcom,sdm845"
> >> compatible and is all happy! It loads the DTS and passes to the kernel...
> >>
> >> You cannot do that...
> >
> > The bootloader never falls back to just the SoC name.
>
> There is no "SoC" part of compatible list. Only by convenience we put it
> that way, but DT spec does not define first compatible to be for
> platform because they all are[1], therefore following your earlier
> description - bootloader should load BAR DTS on FOO device just because
> qcom,sdm845 matches.

As documented in "Documentation/arm/google/chromebook-boot-flow.rst",
the bootloader creates a match list to pick a device tree file. It
never creates a match list that has just the SoC. It always picks
based on the board name and never falls back to just the SoC name.


-Doug

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Krzysztof Kozlowski]

On 25/07/2022 19:22, Doug Anderson wrote:
>>>> You cannot do that...
>>>
>>> The bootloader never falls back to just the SoC name.
>>
>> There is no "SoC" part of compatible list. Only by convenience we put it
>> that way, but DT spec does not define first compatible to be for
>> platform because they all are[1], therefore following your earlier
>> description - bootloader should load BAR DTS on FOO device just because
>> qcom,sdm845 matches.
> 
> As documented in "Documentation/arm/google/chromebook-boot-flow.rst",
> the bootloader creates a match list to pick a device tree file. It
> never creates a match list that has just the SoC. It always picks
> based on the board name and never falls back to just the SoC name.

So this means you embedded some custom-interpretation of board
compatibles in bootloader. What stops you to customize it even more,
that the bootloader must always pick the most specific compatible? IOW,
it cannot load DTB from more generic compatible (just like it should not
load qcom,sdm845 DTS)?

I understand the limitation of board compatibles for your case, but I
still believe it is wrong usage of it.
If the usage - by principle - was correct, then you would not need to
add the restriction you mentioned above ("never creates a match list
that has just the SoC").

Because when Linux drivers match, they do not have such restriction...

Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Doug Anderson]

Hi,

On Mon, Jul 25, 2022 at 10:29 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/07/2022 19:22, Doug Anderson wrote:
> >>>> You cannot do that...
> >>>
> >>> The bootloader never falls back to just the SoC name.
> >>
> >> There is no "SoC" part of compatible list. Only by convenience we put it
> >> that way, but DT spec does not define first compatible to be for
> >> platform because they all are[1], therefore following your earlier
> >> description - bootloader should load BAR DTS on FOO device just because
> >> qcom,sdm845 matches.
> >
> > As documented in "Documentation/arm/google/chromebook-boot-flow.rst",
> > the bootloader creates a match list to pick a device tree file. It
> > never creates a match list that has just the SoC. It always picks
> > based on the board name and never falls back to just the SoC name.
>
> So this means you embedded some custom-interpretation of board
> compatibles in bootloader. What stops you to customize it even more,
> that the bootloader must always pick the most specific compatible? IOW,
> it cannot load DTB from more generic compatible (just like it should not
> load qcom,sdm845 DTS)?
>
> I understand the limitation of board compatibles for your case, but I
> still believe it is wrong usage of it.
> If the usage - by principle - was correct, then you would not need to
> add the restriction you mentioned above ("never creates a match list
> that has just the SoC").
>
> Because when Linux drivers match, they do not have such restriction...

I think we're essentially re-hashing a previous discussion that led me
writing the documentation of how depthcharge boots. It's probably not
worth rehashing. Depthcharge isn't going to change unless we find a
compelling way to solve all the use cases we described last time we
talked about this. I honestly think the "backwardness" stems from the
fact that in the normal case we start with a dts and pick a driver and
in the FIT image / bootloader case we are picking a dts. Those are
fundamentally different needs.

-Doug

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Krzysztof Kozlowski]

On 25/07/2022 18:41, Krzysztof Kozlowski wrote:
> On 25/07/2022 18:25, Doug Anderson wrote:
>> Let's look specifically at the device tree file for the LTE board. One
>> way to look at it is that the dts for the LTE board should have
>> compatibles:
>>   compatible = "lte", "wifi-only"
>>
>> The above matches the normal device tree mentality. It says: "hey, if
>> you've got a lte driver for this board then use it; otherwise use the
>> wifi-only driver".
>>
>> However, the above is actually broken for the bootloader use case. The
>> bootloader is trying to pick a device tree and, to the bootloader, the
>> above says "you can use this dts for either an lte board or a
>> wifi-only board". That's bad. If the bootloader picks this device tree
>> for a wifi-only board then the OS will try to initialize lte and
>> things will crash. To go further, if you think about it things
>> actually work fine if the wifi-only device tree says it's compatible
>> with the LTE board. This is why I say it's opposite... ;-)
> 
> This is not specific to "bootloaders" but your specific implementation
> of entire chain. How you described it, you have dependent pieces -
> user-space must use the same DTB as bootloader chosen, but bootloader
> makes different choices than user-space. It's perfectly fine to make
> these choices different, but then user-space should not depend on
> something which was/was not initialized in bootloader.
> 
> IOW, if bootloader picked up generic WiFi compatible and user-space will
> crash if picking up specific comaptible, you have a dependency and
> user-space should probably bind to modified DTB, where LTE comaptible is
> removed.
> 
> Other systems - I would say most of them - are independent, IOW, we try
> to make kernel and user-space independent of what bootloader did,
> because we are never sure what bootloader actually did and what DTS it
> received.

You can BTW compare it nicely to Linux device driver binding. If a
driver binds to more generic (WiFi) compatible, it is not allowed to use
any features/code related to more specific compatible (LTE).

Your case breaks this rule. Bootloader bound to generic (WiFi)
compatible, but it passed entire DTB/FDT to kernel/user-space which can
then run code for more specific compatible.

Although I understand the point the board compatibles by themself
provide little help for such use case.

Best regards,
Krzysztof

Re: [PATCH 0/3] dt-bindings: arm: qcom: define schema, not devices

[Rob Herring]

On Sat, Jul 23, 2022 at 4:51 PM Dmitry Baryshkov
<dmitry.baryshkov@linaro.org> wrote:
>
> On Sat, 23 Jul 2022 at 20:48, Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
> >
> > On 23/07/2022 11:09, Dmitry Baryshkov wrote:
> > > Describing each compatible board in DT schema seems wrong to me. It
> > > means that each new board is incompatible by default, until added to the DT
> > > schema.
>
> s/incompatible/non-valid/
>
> >
> > The bindings do not document something because it is or it is no
> > compatible. They document the compatible. Your patch essentially removes
> > the documentation, so there is no point in having compatibles in board
> > at all...
>
> I do not quite agree here. Please correct me if I'm wrong.
> Schema defines which DT files are correct and which are not. Which
> properties are required, which values are valid, etc. So far so good.
> For the device nodes it declares (or is willing to declare) all
> possible compatibility strings. There is a sensible number of on-chip
> IP blocks, external chips, etc. Each and every new chip (or new IP
> block) we are going to have a yaml file describing its usage. Perfect.
> For the machine compatibility lists the arm,qcom schema declares which
> machine compat strings are valid. And this looks like a problem. Now
> for the DT to be fully valid against DT schema, we have to define its
> machine compat string.

If we don't document all the compatible strings, how do we know if
there are name collisions (same compatible string used for 2 different
boards)?

I'm not in favor of not documenting some compatibles. I'd be more
inclined to allow invalid combinations if it reduced duplicating
compatible strings than that.

> For each and every phone/sbc/evb we have to name it in schema. I think
> this is an overkill. It feels like we are putting DT information
> (mapping form machine compat to SoC) into the DT schema.
> For qcs404 we already have a schema which uses three items: {},
> qcom,qcs404-evb, qcom,qcs404. This sounds like a perfect idea to me.
> We allow any board, created by Qualcomm, Google or any other random
> vendor, named Foo, Bar or Baz, as long as it declares that it is
> compatible with qcom,qcs404-evb.
>
> To go even further. We now have the qrb5165-rb5.dts, declaring
> compatible = "qcom,qrb5165-rb5", "qcom,sm8250".
> If at some point I add a navigation/communication/whatever mezz on top
> of it. It would make sense to use compatible =
> "qcom,qrb5165-rb5-navi-comm", "qcom,qrb5165-rb5", "qcom,sm8250".
> Adding this to the growing list inside arm,qcom.yaml sounds like a
> nightmare.

The combination of SoMs and/or add-on boards is not a QCom specific
issue. So if there's going to be any change for how we do things, it
needs to be for everyone.


> I can only hope that at some point JSON schema gains
> postfixItems support (as proposed) to be able to change e.g.
> arm,qcom.yaml to list just our qcom,something platforms as possible
> postfixItems for the schema.

I'm not really sure we'd want to support that. I'm not thrilled that
'items' has changed to 'prefixItems' in newer versions. The name is
confusing for how we use 'items'. So my current thought is we'll stick
with 'items' even if we replace it with 'prefixItems' in the processed
schema.

Rob