Re: [PATCH] dt-bindings: leds: lacie,ns2-leds: Convert to DT schema
| Newsgroups | org.kernel.vger.linux-leds,org.kernel.vger.linux-devicetree |
|---|---|
| Message-ID | <[email protected]> |
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Low] The schema conversion incorrectly restricts LED child node names to `^led(-[0-9a-z]+)?$`, which breaks `dtbs_check` validation for all existing upstream device trees using this binding. -- commit 6c59295f22b17d02a2b26847db54458f820fa4f3 Author: Ninad Naik <[email protected]> dt-bindings: leds: lacie,ns2-leds: Convert to DT schema Convert lacie,ns2-leds to 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..679a618906d80 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/lacie,ns2-leds.yaml > @@ -0,0 +1,87 @@ [ ... ] > +properties: > + compatible: > + const: lacie,ns2-leds > + > +patternProperties: > + "^led(-[0-9a-z]+)?$": [Severity: Low] Will this restrictive regex cause existing device trees to fail dtbs_check? The old text binding example used a child node named blue-sata, which does not match this pattern. Since additionalProperties is set to false below, nodes in existing device trees that don't start with led will be rejected during validation. Should this regex be relaxed to allow existing node names, or should those device tree files be updated alongside this conversion? > + type: object > + $ref: common.yaml# > + unevaluatedProperties: false -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1