Re: [PATCH v3 1/4] dt-bindings: arm: qcom-soc: Include Eliza, Kaanapali and others in SoC names

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Schema validation regression for existing legacy compatibles using new SoC codenames
--

--- Patch [1]: [PATCH v3 1/4] dt-bindings: arm: qcom-soc: Include Eliza, Kaanapali and others in SoC names ---
commit 3874df0576bde7993596a9073b5a401dc452d1e8
Author: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

dt-bindings: arm: qcom-soc: Include Eliza, Kaanapali and others in SoC names

This commit updates the schema checking for proper SoC compatible naming style
to include several new Qualcomm SoC codenames. It expands both the schema
select block and the properties constraints to support these new names.

> diff --git a/Documentation/devicetree/bindings/arm/qcom-soc.yaml b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> index 27261039d56f6..fecf9dc05b67e 100644
> --- a/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> +++ b/Documentation/devicetree/bindings/arm/qcom-soc.yaml
> @@ -25,7 +25,7 @@ select:
>      compatible:
>        oneOf:
>          - pattern: "^qcom,.*(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sar|sc|sd[amx]|sm|x1[ep])[0-9]+.*$"
> -        - pattern: "^qcom,.*(glymur|milos).*$"
> +        - pattern: "^qcom,.*(eliza|kaanapali|glymur|hawi|mahua|maili|milos|nord|shikra).*$"
>    required:
>      - compatible
>  
> @@ -36,7 +36,7 @@ properties:
>        - pattern: "^qcom,(apq|ipq|mdm|msm|qcm|qcs|q[dr]u|sa|sc|sd[amx]|sm|x1[ep])[0-9]+(pro)?-.*$"
>        - pattern: "^qcom,sar[0-9]+[a-z]?-.*$"
>        - pattern: "^qcom,(sa|sc)8[0-9]+[a-z][a-z]?-.*$"
> -      - pattern: "^qcom,(glymur|milos)-.*$"
> +      - pattern: "^qcom,(eliza|kaanapali|glymur|hawi|mahua|maili|milos|nord|shikra)-.*$"
>  
>        # Legacy namings - variations of existing patterns/compatibles are OK,
>        # but do not add completely new entries to these:

[Severity: Low]
Will this cause dtbs_check validation to fail for existing upstream device
trees?

Adding these new SoC codenames to the select regex above causes the schema to
suddenly evaluate nodes using the legacy vendor,IP-SoC format, such as
qcom,scm-eliza or qcom,apss-wdt-kaanapali.

Since these strings start with an IP block identifier, they will not match
the new "^qcom,(eliza|kaanapali...)-.*$" pattern. Because they are not
included in the legacy regex whitelist below it, valid existing nodes will
fail validation against all allowed patterns.

Is there a way to validate these existing legacy compatibles without allowing
new ones?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-dt-bindings-qcom-soc-naming-v3-0-8f275c9d3412@oss.qualcomm.com?part=1