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

On Sat, Jul 18, 2026 at 3:15 AM Ninad Naik <[email protected]> wrote:
>
>
> On 16/07/26 11:09 pm, Rob Herring wrote:
> > On Wed, Jul 01, 2026 at 06:05:52PM +0000,[email protected] wrote:
> >> 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?
> > While yes we prefer what you did, it's perhaps not worth changing these
> > old .dts files to match the preference.
> >
> > Rob
>
> I understand this. Should I relax the regex to allow any pattern so that
> the existing as well
>
> as new DTS files could be properly validated?

I doubt there will be new DTS files here, so you could just list the
node names in use. Or to just allow anything, you can do:

additionalProperties:
  type: object
  ...