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 <[email protected]> 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/[email protected]?part=1
