Re: [PATCH v24 05/12] dt-bindings: arm: Document reboot mode magic

Thank you for your contribution! Sashiko AI review found 1 potential issue(=
s) to consider:
- [Medium] Incorrect tuple validation of a 2D `uint32-array`, applying oute=
r array constraints and invalid property-level type `$ref`s to inner elemen=
ts, breaking validation and dropping the `minimum` constraint.
--

--- Patch [5]: [PATCH v24 05/12] dt-bindings: arm: Document reboot mode mag=
ic ---
commit 27b283c27fa751f1b79c98734e61c56bbcfb0f0f
Author: Shivendra Pratap <[email protected]>

dt-bindings: arm: Document reboot mode magic

This commit adds bindings to describe vendor-specific reboot modes in the P=
SCI
SYSTEM_RESET2 call. The values defined here correspond to valid parameters
for vendor-specific reset types.

> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentat=
ion/devicetree/bindings/arm/psci.yaml
> index 6e2e0c5518411..7d6a86690a2e5 100644
> --- a/Documentation/devicetree/bindings/arm/psci.yaml
> +++ b/Documentation/devicetree/bindings/arm/psci.yaml
> @@ -98,6 +98,41 @@ properties:
[ ... ]
> +    patternProperties:
> +      "^mode-.*$":
> +        minItems: 1
> +        maxItems: 3
> +        items:
> +          - description: arg1 (vendor-specific SYSTEM_RESET2 reset_type)
> +            allOf:
> +              - $ref: /schemas/types.yaml#/definitions/uint32
> +              - minimum: 0x80000000
> +          - description: arg2 (cookie_lo in 2-cell form, cookie_hi in 3-=
cell form)
> +            $ref: /schemas/types.yaml#/definitions/uint32
> +          - description: arg3 (cookie_lo in 3-cell form)
> +            $ref: /schemas/types.yaml#/definitions/uint32

[Severity: Medium]
Will this schema correctly validate the property values?

Since dt-schema parses device tree arrays as 2D arrays, applying JSON Schema
items list validation to the outer array evaluates the entire inner tuple a=
s a
single element against the schema for arg1.

This regression can cause dt_binding_check to reject valid device trees bec=
ause
it ends up validating a 1xN array against uint32, which expects a 1x1 matri=
x.

Because JSON Schema ignores minimum constraints when applied to an array, i=
s it
possible this silently bypasses the minimum constraint of 0x80000000?

Should this pattern property reference /schemas/types.yaml#/definitions/uin=
t32-array
with the element constraints applied natively under it?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260803-arm-psci-s=
[email protected]?part=3D5