Re: [PATCH v8 1/2] dt-bindings: leds: Add LTC3220 18 channel LED Driver

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2856 bytes --]

On Tue, May 19, 2026 at 01:23:06AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Low] `#address-cells` and `#size-cells` are omitted from the top-level `required` list.
> - [Low] The schema fails to programmatically enforce the constraint that `reg` must be 1 when `led-sources` is used.
> --
> 
> commit 7595dbcc690fee63863037049c154e7a47df9973
> Author: Edelweise Escala <edelweise.escala@analog.com>
> 
> dt-bindings: leds: Add LTC3220 18 channel LED Driver
> 
> This commit introduces the device tree binding for the Analog Devices LTC3220,
> a multi-display LED driver with an I2C interface. It defines properties for
> both individual and aggregated LED control.
> 
> > diff --git a/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml b/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
> > new file mode 100644
> > index 0000000000000..9e545442f3d9d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
> [ ... ]
> > patternProperties:
> >   '^led@([1-9a-f]|1[0-2])$':
> >     type: object
> >     $ref: /schemas/leds/common.yaml#
> >     unevaluatedProperties: false
> >     properties:
> >       reg:
> >         description:
> >           Output channel for the LED (1-18 maps to LED outputs D1-D18).
> >           Unit-address must be in hexadecimal (1-12 hex = 1-18 decimal).
> >           For aggregated LED control, define only one LED node with reg = <1>
> >           and use led-sources to list all controlled outputs. Only reg 1 should
> >           be present when using led-sources.
> >         minimum: 1
> >         maximum: 18
> > 
> >     required:
> >       - reg
> 
> The description notes that only reg = <1> should be present when using
> led-sources, but the schema doesn't appear to programmatically enforce this.
> 
> Would it make sense to add an if/then block or dependencies rule to enforce
> that reg must be 1 when led-sources is present, so that invalid configurations
> do not silently pass schema validation?

I actually dunno what the syntax is for restricting this from the parent
node, but it could be done in the led node I guess, using something like
if:
  required:
    - led-sources
then:
  properties:
    reg:
      maximum: 1

Probably.

> 
> [ ... ]
> > required:
> >   - compatible
> >   - reg
> 
> Since the schema defines child nodes with reg properties, does the top-level
> node need to include #address-cells and #size-cells in this required list?
> 
> While dtc might issue warnings for missing cell properties, omitting them
> from the schema's required list might leave the DT schema validation
> incomplete for the container node.

I think this second one is something you should implement.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]