Re: [PATCH v5 01/14] dt-bindings: leds: Document TI LM3533 LED controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] DT Schema Validation Failure due to strict property restrictions.
- [Low] Ineffective Schema Constraints on `reg` property array.
--

commit 69694c121b5fef16f95b87bbf30e28ee4fb13044
Author: Svyatoslav Ryhel <clamor95@gmail.com>

dt-bindings: leds: Document TI LM3533 LED controller

Document the LM3533 - a complete power source for backlight, keypad and
indicator LEDs in smartphone handsets.

> diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml
> new file mode 100644
> index 0000000000000..a25846e9b3752
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml
[ ... ]
> +properties:
> +  compatible:
> +    const: ti,lm3533-backlight
> +
> +  reg:
> +    description: Control bank selection (0 = bank A, 1 = bank B).
> +    maximum: 1

[Severity: Low]
Are these constraints effective? In Device Tree JSON representations, reg is
decoded as an array of arrays of integers (cells).

Numeric validation keywords like maximum are silently ignored when applied
directly to arrays instead of being nested under items.

[ ... ]
> diff --git a/Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml b/Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml
> new file mode 100644
> index 0000000000000..d8dbefef3323e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml
[ ... ]
> +properties:
> +  compatible:
> +    const: ti,lm3533-leds
> +
> +  reg:
> +    description:
> +      Control bank selection (2 = bank C, 3 = bank D, 4 = bank E, 5 = bank F).
> +    minimum: 2
> +    maximum: 5

[Severity: Low]
Similar to the reg property in the backlight binding, should these numeric
constraints be nested under items? As written, they apply to the array itself
and will be ignored during schema validation.

[ ... ]
> diff --git a/Documentation/devicetree/bindings/leds/ti,lm3533.yaml b/Documentation/devicetree/bindings/leds/ti,lm3533.yaml
> new file mode 100644
> index 0000000000000..bdc05a9f3d663
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/ti,lm3533.yaml
[ ... ]
> +  light-sensor:
> +    type: object
> +    additionalProperties: false
> +
> +    properties:
> +      compatible:
> +        const: ti,lm3533-als
[ ... ]
> +examples:
> +  - |
[ ... ]
> +            light-sensor {
> +                compatible = "ti,lm3533-als";
> +
> +                interrupt-parent = <&gpio>;
> +                interrupts = <80 IRQ_TYPE_LEVEL_LOW>;

[Severity: Low]
Will this fail make dt_binding_check? The light-sensor definition uses
additionalProperties: false but doesn't explicitly list interrupt-parent
in its properties block.

Since the example uses interrupt-parent, it seems this will cause a schema
validation failure. Should the schema include interrupt-parent: true, or
perhaps drop additionalProperties: false?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260617080031.99156-1-clamor95@gmail.com?part=1