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

[Uday Kiran]

On Sun, Oct 4, 2026 at 8:00 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 04/10/2026 16:04, Uday Kiran wrote:
> > On Wed, Sep 16, 2026 at 11:39 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >>
> >> On 14/09/2026 19:58, Uday Kiran wrote:
> >>> On Sat, Sep 12, 2026 at 1:20 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >>>>
> >>>> On 11/09/2026 16:29, Uday Kiran wrote:
> >>>>>>> +properties:
> >>>>>>> +  compatible:
> >>>>>>> +    const: lacie,netxbig-leds
> >>>>>>> +
> >>>>>>> +  gpio-ext:
> >>>>>>> +    description: Phandle for the gpio-ext bus.
> >>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>>>>>> +
> >>>>>>> +  timers:
> >>>>>>> +    description: |
> >>>>>>> +      Timer array. Each timer entry is represented by three integers:
> >>>>>>> +      Mode (gpio-ext bus), delay_on and delay_off.
> >>>>>>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> >>>>>>> +
> >>>>>>> +patternProperties:
> >>>>>>> +  "^(?!gpio-ext$|pinctrl-[0-9]+$)[a-z][a-z0-9]*(-[a-z0-9]+)+$":
> >>>>>>
> >>>>>> This is an odd pattern. Why is pinctrl an LED? or gpio-ext?
> >>>>>>
> >>>>>> Actually entire pattern is very odd - it has $ in the middle, but then
> >>>>>> followed with other REQUIRED stuff. I am surprised it works, but
> >>>>>> regardless it is absolutely not readable. Looks like a begative pattern,
> >>>>>> but why would you have negative pattern for known properties?
> >>>>>
> >>>>> Thanks for the review Krzysztof.
> >>>>>
> >>>>> The negative lookahead was added because patternProperties matches all top-
> >>>>> level property names that fit the pattern, so excluded known top-level
> >>>>> properties like gpio-ext and pinctrl-*;
> >>>>>
> >>>>> In patch v1, I've used additionalProperties which removes the regex entirely
> >>>>> and allows arbitrary child-node names. But removed and used patternProperties
> >>>>> as per the review feedback.
> >>>>>
> >>>>> Could you please suggest to me which way to proceed? with additionalProperties
> >>>>> or patternProperties
> >>>>
> >>>>
> >>>> The children are leds, so they should use generic node name pattern like
> >>>> "^led-[a-z0-9]+$"
> >>>
> >>> Yes, Krzysztof but the original binding uses blue-power, red-power,
> >>> blue-sata0, etc.
> >>> as LED child node names. Would you like me to rename these nodes to
> >>> led-blue-power, led-red-power, etc. to use the suggested
> >>> ^led-[a-z0-9]+$ pattern,
> >>> or should I retain the existing node names and use a more specific
> >>> pattern for them
> >>> like "^(blue|red)-(power|sata[0-9]+)$"
> >>
> >> I did not see original binding mentioning any names. Neither in the driver.
> >
> > Sorry for the delayed response, Krzysztof.
> >
> > You are right that the binding text and the driver do not mandate node names.
> > However, the existing device tree source use names like blue-power,
> > red-sata0, etc.:
> >
> > arch/arm/boot/dts/marvell/kirkwood-netxbig.dtsi
> >
> > Also, the driver uses the node name as a fallback LED label when the label
> > property is absent.
> >
> > drivers/leds/leds-netxbig.c, lines 585-588.
>
> So what is the problem exactly? You rename the nodes and use label. Does
> anything break?

You are right. It will not break anything. will update the binding and DTS files
accordingly and send the next revision

Regards,
Udaya Kiran Challa