All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Krzysztof Kozlowski" <krzysztof.kozlowski@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/4] dt-bindings: arm: qcom-soc: Include Eliza, Kaanapali and others in SoC names
Date: Tue, 07 Jul 2026 13:48:30 +0000	[thread overview]
Message-ID: <20260707134830.F28FE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260707-dt-bindings-qcom-soc-naming-v2-1-1b7d695be2e1@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Schema validation regression for legacy SoC component node names
--

--- Patch [1]: [PATCH v2 1/4] dt-bindings: arm: qcom-soc: Include Eliza, Kaanapali and others in SoC names ---
commit 345707be3cd74ebefeb7a14bc7aebf31883f9f6b
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 devicetree schema to allow proper compatible naming
styles with explicitly listed new Qualcomm SoC codenames (Eliza, Kaanapali,
Hawi, Mahua, Maili, Nord, and Shikra).

> 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: Medium]
Will this cause a schema validation regression for legacy SoC component
node names?

Since the select.properties.compatible.oneOf block matches any compatible
containing the new codenames, legacy-style nodes like "qcom,scm-eliza" or
"qcom,apss-wdt-shikra" will be pulled into this schema for validation.

Because these new codenames were not also added to the explicitly allowed
legacy naming patterns in properties.compatible.oneOf (such as the
"qcom,scm-" or "qcom,[ak]pss-wdt-" patterns), dtbs_check will reject these
otherwise valid nodes. Should the legacy naming patterns be updated to
include the new codenames as well?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707-dt-bindings-qcom-soc-naming-v2-0-1b7d695be2e1@oss.qualcomm.com?part=1

  reply	other threads:[~2026-07-07 13:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07 13:35 [PATCH v2 0/4] dt-bindings: arm: qcom-soc: Improve validation of expected SoC naming Krzysztof Kozlowski
2026-07-07 13:35 ` [PATCH v2 1/4] dt-bindings: arm: qcom-soc: Include Eliza, Kaanapali and others in SoC names Krzysztof Kozlowski
2026-07-07 13:48   ` sashiko-bot [this message]
2026-07-07 13:51     ` Krzysztof Kozlowski
2026-07-07 13:36 ` [PATCH v2 2/4] dt-bindings: arm: qcom-soc: Document more of existing legacy style compatibles Krzysztof Kozlowski
2026-07-07 13:36 ` [PATCH v2 3/4] dt-bindings: arm: qcom-soc: Validate nodes with fallbacks Krzysztof Kozlowski
2026-07-07 13:36 ` [PATCH v2 4/4] dt-bindings: arm: qcom-soc: Allow WSA88xx speaker compatible Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260707134830.F28FE1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.