Re: [PATCH 1/2] dt-bindings: remoteproc: qcom,milos-pas: Move Eliza ADSP to SM8550 schema

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Moving the compatible string to an 'items' array constraint requiring a fallback breaks device tree validation for existing `qcom,eliza-adsp-pas` device nodes.
- [Medium] Moving `qcom,eliza-adsp-pas` to `qcom,sm8550-pas.yaml` inadvertently makes its 6th interrupt optional, whereas it was strictly required in its previous schema.
- [Low] Explicitly listing `qcom,eliza-adsp-pas` in the `contains` check for the `power-domains` block is redundant.
--

--- Patch [1]: [PATCH 1/2] dt-bindings: remoteproc: qcom,milos-pas: Move Eliza ADSP to SM8550 schema ---
commit a654472ebd2ea108ab10c5ccd22057e8aa31a94f
Author: Abel Vesa <abel.vesa@oss.qualcomm.com>

dt-bindings: remoteproc: qcom,milos-pas: Move Eliza ADSP to SM8550 schema

The ADSP PAS found on Eliza SoC looks fully compatible with SM8750, which
can fallback to SM8550 except for the extra interrupt ("shutdown-ack").
So document its bindings in the SM8550 schema instead.

> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> index 2a4c527552e69..019db91be7fd2 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml
> @@ -29,6 +29,7 @@ properties:
>            - qcom,x1e80100-cdsp-pas
>        - items:
>            - enum:
> +              - qcom,eliza-adsp-pas
>                - qcom,glymur-adsp-pas
>                - qcom,hawi-adsp-pas
>                - qcom,kaanapali-adsp-pas

[Severity: Medium]
Does this regression break validation for existing device trees?

By moving this into an items array that requires a fallback, a standalone
compatible string like the one used in arch/arm64/boot/dts/qcom/eliza.dtsi:

	compatible = "qcom,eliza-adsp-pas";

will fail validation since it doesn't specify the fallback.

[ ... ]

> @@ -134,6 +135,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - qcom,eliza-adsp-pas
>                - qcom,glymur-adsp-pas
>                - qcom,glymur-cdsp-pas
>                - qcom,hawi-adsp-pas

[Severity: Medium]
Can this inadvertently make the 6th interrupt optional for Eliza?

In the base schema, interrupts have a global minItems of 5. By adding
the compatible string to this block without an explicit minItems: 6 override,
the maxItems becomes 6, but the minItems remains 5, allowing device trees
with a missing "shutdown-ack" interrupt to silently pass validation.

[ ... ]

> @@ -232,6 +234,7 @@ allOf:
>          compatible:
>            contains:
>              enum:
> +              - qcom,eliza-adsp-pas
>                - qcom,sm8550-adsp-pas
>                - qcom,sm8650-adsp-pas
>                - qcom,x1e80100-adsp-pas

[Severity: Low]
Is it necessary to include the specific string here?

Since the newly updated schema enforces qcom,sm8550-adsp-pas as a fallback
for this device, a node for Eliza will already contain the fallback string
and naturally match this condition without the extra entry.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721-dts-qcom-eliza-fix-adsp-binding-v1-0-3a0b03af2ec7@oss.qualcomm.com?part=1