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

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Using `additionalProperties` at the root level to define child nodes incorrectly restricts standard properties on the parent node, breaking device tree validation.
- [Low] The schema omits the `num-modes` property, causing `dtbs_check` failures for existing in-tree device trees.
--

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

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

Convert the lacie,ns2-leds binding text document to a DT schema.

> 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..1976669d2218c
> --- /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: Low]
Does setting additionalProperties to type: object at the root level break
standard parent device tree properties like status = "okay" or pinctrl-names?

By enforcing that any unlisted top-level property must be an object, standard
properties (which are strings or arrays) will fail validation with type
mismatch errors during make dtbs_check.

Is it better to use patternProperties: "^led(-[0-9a-f]+)?$": for the child
nodes and set additionalProperties: false at the root instead?

> +
> +  description: Each child node represents a single LED
> +
> +  properties:
> +    cmd-gpio:
> +      maxItems: 1
> +      description: GPIO connected to the command LED output

[Severity: Low]
Will this schema omission cause dtbs_check failures for existing in-tree
device trees?

The new schema strictly allows only documented properties via
unevaluatedProperties: false on the child nodes. However, existing in-tree
device trees contain an undocumented num-modes property:

arch/arm/boot/dts/armada-370-seagate-nas-4bay.dts:white-sata2 {
        ...
        slow-gpio = <&pca9554 2 GPIO_ACTIVE_HIGH>;
        num-modes = <4>;
        modes-map = <NS_V2_LED_SATA 0 0
        ...
}

Since num-modes is omitted from this new schema, validation will fail when
checking those boards. Should num-modes be added to the schema (perhaps with
deprecated: true), or removed from the DTS files as part of this patch series?

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