Re: [PATCH v26 05/10] dt-bindings: arm: Document reboot mode magic

[Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>]

On 9/28/2026 11:56 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Low] dt-bindings: ineffective unevaluatedProperties allows undocumented properties
> - [Low] dt-bindings: missing maxItems constraint on mode-* arrays
> --
> 
> commit b385b6956b70c623850aefcc8ceb50fda4b87cc0
> Author: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> 
> dt-bindings: arm: Document reboot mode magic
> 
> Add bindings to describe vendor-specific reboot modes. Values here
> correspond to valid parameters to vendor-specific reset types in PSCI
> SYSTEM_RESET2 call.
> 
>> diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml
>> index 0d04389c81faa..82ae25e7a3386 100644
>> --- a/Documentation/devicetree/bindings/arm/psci.yaml
>> +++ b/Documentation/devicetree/bindings/arm/psci.yaml
> [ ... ]
>> @@ -98,6 +98,39 @@ properties:
>>         [1] Kernel documentation - ARM idle states bindings
>>           Documentation/devicetree/bindings/cpu/idle-states.yaml
>>   
>> +  reboot-mode:
>> +    type: object
>> +    $ref: /schemas/power/reset/reboot-mode.yaml#
>> +    unevaluatedProperties: false
> 
> [Severity: Low]
> Does unevaluatedProperties here effectively restrict undocumented properties?
> 
> The referenced schema /schemas/power/reset/reboot-mode.yaml# has an open
> additionalProperties: true. Under JSON Schema evaluation rules, this causes
> all properties to be annotated as successfully evaluated.
> 
> Consequently, unevaluatedProperties: false in the referencing schema becomes
> a no-op, allowing any arbitrary property to pass validation silently.
> 
>> +    properties:
>> +      # "mode-normal" is just SYSTEM_RESET
>> +      mode-normal: false
>> +    patternProperties:
>> +      "^mode-.*$":
>> +        $ref: /schemas/types.yaml#/definitions/uint32-array
>> +        minItems: 2
> 
> [Severity: Low]
> Should this also include a maxItems constraint?
> 
> Providing a list of schemas to items constrains the initial array elements
> but does not intrinsically limit the array's maximum length.
> 
> Without maxItems: 3, a device tree defining 4 or more cells for a reboot
> mode will silently pass schema validation, violating the binding's up to
> three 32-bit cells requirement.
> 
>> +        items:
>> +          - description: arg1 (vendor-specific SYSTEM_RESET2 reset_type)
>> +            minimum: 0x80000000
>> +          - description: arg2 (cookie_lo in 2-cell form, cookie_hi in 3-cell form)
>> +          - description: arg3 (cookie_lo in 3-cell form)

I would wait for Rob's review on both comments.

thanks,
Shivendra