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

On Tue, Jul 21, 2026 at 07:38:49PM +0000, [email protected] wrote:
> 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?

No.

> 
> > +
> > +  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?

This should be fixed.

Rob