Re: [PATCH v3] dt-bindings: leds: lacie,ns2-leds: Convert to DT schema

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The top-level `additionalProperties` is incorrectly defined as a child-node schema, causing it to incorrectly reject standard device tree properties.
--

--- Patch [1]: [PATCH v3] dt-bindings: leds: lacie,ns2-leds: Convert to DT schema ---
commit 2e02c3a2b329288ad4aeeb155d96aec6b772c421
Author: Ninad Naik <[email protected]>

dt-bindings: leds: lacie,ns2-leds: Convert to DT schema

Convert lacie,ns2-leds to DT schema.

Closes: https://lore.kernel.org/r/[email protected]/

> diff --git a/Documentation/devicetree/bindings/leds/lacie,ns2-leds.yaml b/Documentation/devicetree/bindings/leds/lacie,ns2-leds.yaml
> new file mode 100644
> index 0000000000000..2138c75c04133
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/lacie,ns2-leds.yaml
[ ... ]
> +properties:
> +  compatible:
> +    const: lacie,ns2-leds
> +
> +additionalProperties:
> +  type: object
> +  $ref: common.yaml#
> +  unevaluatedProperties: false

[Severity: Medium]
Does this incorrectly apply an object constraint to all unspecified top-level
properties? 

It appears this schema logic will cause valid device trees containing standard
non-object properties (like status or pinctrl-0) to fail validation during
make dtbs_check. 

Should child nodes instead be matched using patternProperties, with
additionalProperties: false or unevaluatedProperties: false used at the top
level to allow standard DT properties?

> +
> +  description: Each child node represents a single LED
> +
> +  properties:
> +    cmd-gpio:
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1