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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 04/10/2026 16:04, Uday Kiran wrote:
> On Wed, Sep 16, 2026 at 11:39 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> On 14/09/2026 19:58, Uday Kiran wrote:
>>> On Sat, Sep 12, 2026 at 1:20 PM Krzysztof Kozlowski <krzk@kernel.org> 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?

> 
> If we enforce ^led-[a-z0-9]+$ in the schema, the existing DTS file would fail
> validation, and renaming the nodes would change the userspace-visible
> LED names.


Best regards,
Krzysztof