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

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The dt-schema incorrectly uses an object schema for `additionalProperties` to define child LED nodes instead of `patternProperties`.
--

--- Patch [1]: [PATCH] dt-bindings: leds: lacie,netxbig-leds: Convert to DT schema ---
commit aac938a074c3b72885d598a72f89b254f35a5d88
Author: Udaya Kiran Challa <[email protected]>

dt-bindings: leds: lacie,netxbig-leds: Convert to DT schema
    
This commit converts the lacie,netxbig-leds devicetree binding from the
legacy text format to DT schema.

> diff --git a/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml b/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
> new file mode 100644
> index 0000000000000..ffdd47458d248
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml

[ ... ]

> +required:
> +  - compatible
> +  - gpio-ext
> +
> +additionalProperties:
> +  description: Each child node represents a single LED
> +  type: object
> +  $ref: common.yaml#
> +  unevaluatedProperties: false

[Severity: Medium]
Will this strict additionalProperties definition cause standard device tree
properties to fail validation?

Because additionalProperties is defined as an object schema here, any
top-level property added to the netxbig-leds node that isn't explicitly
defined (like status = "okay" or pinctrl-0) will be forced to evaluate
as an object, triggering schema validation errors for strings or arrays.

Should child LED nodes be defined using patternProperties instead, so that
standard node properties are not caught by this block?

> +
> +  properties:
> +    mode-addr:
> +      description: Mode register address on gpio-ext bus.

[ ... ]

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