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

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

[Udaya Kiran Challa]

Convert lacie,netxbig-leds devicetree binding from legacy
text format to DT schema.

Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v2:
- Add reference to led common.yaml
- Drop type for all common properties

Link to v2:https://lore.kernel.org/all/20260821123723.198286-1-challauday369@gmail.com/

Changes since v1:
- Use pattenProperties for LED child nodes instead of additionalProperties
- Explicitly list the two optional properties supported by the binding
- Place the top-level required block after child-node definition

Link to v1:https://lore.kernel.org/all/20260820150223.108374-1-challauday369@gmail.com/
---
 .../bindings/leds/lacie,netxbig-leds.yaml     | 139 ++++++++++++++++++
 .../devicetree/bindings/leds/leds-netxbig.txt |  92 ------------
 2 files changed, 139 insertions(+), 92 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
 delete mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt

diff --git a/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml b/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
new file mode 100644
index 000000000000..5cb2eaf74d1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
@@ -0,0 +1,139 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/lacie,netxbig-leds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LaCie/Seagate netxbig CPLD LEDs
+
+maintainers:
+  - Simon Guinot <simon.guinot@sequanux.org>
+
+description: |
+  Binding for the CPLD LEDs (GPIO extension bus) found on some LaCie/Seagate
+  boards (Example: 2Big/5Big Network v2, 2Big NAS).
+
+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]+)+$":
+    type: object
+    $ref: common.yaml#
+    unevaluatedProperties: false
+
+    properties:
+      label: true
+      linux,default-trigger: true
+
+      mode-addr:
+        description: Mode register address on gpio-ext bus.
+        $ref: /schemas/types.yaml#/definitions/uint32
+
+      mode-val:
+        description: |
+          Mode to value mapping. Each entry is represented by two integers:
+          a mode and the corresponding value on the gpio-ext bus.
+        $ref: /schemas/types.yaml#/definitions/uint32-array
+
+      bright-addr:
+        description: Brightness register address on gpio-ext bus.
+        $ref: /schemas/types.yaml#/definitions/uint32
+
+      max-brightness:
+        description: Maximum brightness value.
+        $ref: /schemas/types.yaml#/definitions/uint32
+
+    required:
+      - mode-addr
+      - mode-val
+      - bright-addr
+      - max-brightness
+
+required:
+  - compatible
+  - gpio-ext
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/leds/leds-netxbig.h>
+
+    netxbig-leds {
+        compatible = "lacie,netxbig-leds";
+
+        gpio-ext = <&netxbig_gpio_ext>;
+
+        timers = <NETXBIG_LED_TIMER1 500 500
+                  NETXBIG_LED_TIMER2 500 1000>;
+
+        blue-power {
+            label = "netxbig:blue:power";
+            mode-addr = <0>;
+            mode-val = <NETXBIG_LED_OFF 0
+                        NETXBIG_LED_ON 1
+                        NETXBIG_LED_TIMER1 3
+                        NETXBIG_LED_TIMER2 7>;
+            bright-addr = <1>;
+            max-brightness = <7>;
+        };
+        red-power {
+            label = "netxbig:red:power";
+            mode-addr = <0>;
+            mode-val = <NETXBIG_LED_OFF 0
+                        NETXBIG_LED_ON 2
+                        NETXBIG_LED_TIMER1 4>;
+            bright-addr = <1>;
+            max-brightness = <7>;
+        };
+        blue-sata0 {
+            label = "netxbig:blue:sata0";
+            mode-addr = <3>;
+            mode-val = <NETXBIG_LED_OFF 0
+                        NETXBIG_LED_ON 7
+                        NETXBIG_LED_SATA 1
+                        NETXBIG_LED_TIMER1 3>;
+            bright-addr = <2>;
+            max-brightness = <7>;
+        };
+        red-sata0 {
+            label = "netxbig:red:sata0";
+            mode-addr = <3>;
+            mode-val = <NETXBIG_LED_OFF 0
+                        NETXBIG_LED_ON 2
+                        NETXBIG_LED_TIMER1 4>;
+            bright-addr = <2>;
+            max-brightness = <7>;
+        };
+        blue-sata1 {
+            label = "netxbig:blue:sata1";
+            mode-addr = <4>;
+            mode-val = <NETXBIG_LED_OFF 0
+                        NETXBIG_LED_ON 7
+                        NETXBIG_LED_SATA 1
+                        NETXBIG_LED_TIMER1 3>;
+            bright-addr = <2>;
+            max-brightness = <7>;
+        };
+        red-sata1 {
+            label = "netxbig:red:sata1";
+            mode-addr = <4>;
+            mode-val = <NETXBIG_LED_OFF 0
+                        NETXBIG_LED_ON 2
+                        NETXBIG_LED_TIMER1 4>;
+            bright-addr = <2>;
+            max-brightness = <7>;
+        };
+    };
diff --git a/Documentation/devicetree/bindings/leds/leds-netxbig.txt b/Documentation/devicetree/bindings/leds/leds-netxbig.txt
deleted file mode 100644
index 5ef92a26d768..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-netxbig.txt
+++ /dev/null
@@ -1,92 +0,0 @@
-Binding for the CPLD LEDs (GPIO extension bus) found on some LaCie/Seagate
-boards (Example: 2Big/5Big Network v2, 2Big NAS).
-
-Required properties:
-- compatible: "lacie,netxbig-leds".
-- gpio-ext: Phandle for the gpio-ext bus.
-
-Optional properties:
-- timers: Timer array. Each timer entry is represented by three integers:
-  Mode (gpio-ext bus), delay_on and delay_off.
-
-Each LED is represented as a sub-node of the netxbig-leds device.
-
-Required sub-node properties:
-- mode-addr: Mode register address on gpio-ext bus.
-- mode-val: Mode to value mapping. Each entry is represented by two integers:
-  A mode and the corresponding value on the gpio-ext bus.
-- bright-addr: Brightness register address on gpio-ext bus.
-- max-brightness: Maximum brightness value.
-
-Optional sub-node properties:
-- label: Name for this LED. If omitted, the label is taken from the node name.
-- linux,default-trigger: Trigger assigned to the LED.
-
-Example:
-
-netxbig-leds {
-	compatible = "lacie,netxbig-leds";
-
-	gpio-ext = &gpio_ext;
-
-	timers = <NETXBIG_LED_TIMER1 500 500
-		  NETXBIG_LED_TIMER2 500 1000>;
-
-	blue-power {
-		label = "netxbig:blue:power";
-		mode-addr = <0>;
-		mode-val = <NETXBIG_LED_OFF 0
-			    NETXBIG_LED_ON 1
-			    NETXBIG_LED_TIMER1 3
-			    NETXBIG_LED_TIMER2 7>;
-		bright-addr = <1>;
-		max-brightness = <7>;
-	};
-	red-power {
-		label = "netxbig:red:power";
-		mode-addr = <0>;
-		mode-val = <NETXBIG_LED_OFF 0
-			    NETXBIG_LED_ON 2
-			    NETXBIG_LED_TIMER1 4>;
-		bright-addr = <1>;
-		max-brightness = <7>;
-	};
-	blue-sata0 {
-		label = "netxbig:blue:sata0";
-		mode-addr = <3>;
-		mode-val = <NETXBIG_LED_OFF 0
-			    NETXBIG_LED_ON 7
-			    NETXBIG_LED_SATA 1
-			    NETXBIG_LED_TIMER1 3>;
-		bright-addr = <2>;
-		max-brightness = <7>;
-	};
-	red-sata0 {
-		label = "netxbig:red:sata0";
-		mode-addr = <3>;
-		mode-val = <NETXBIG_LED_OFF 0
-			    NETXBIG_LED_ON 2
-			    NETXBIG_LED_TIMER1 4>;
-		bright-addr = <2>;
-		max-brightness = <7>;
-	};
-	blue-sata1 {
-		label = "netxbig:blue:sata1";
-		mode-addr = <4>;
-		mode-val = <NETXBIG_LED_OFF 0
-			    NETXBIG_LED_ON 7
-			    NETXBIG_LED_SATA 1
-			    NETXBIG_LED_TIMER1 3>;
-		bright-addr = <2>;
-		max-brightness = <7>;
-	};
-	red-sata1 {
-		label = "netxbig:red:sata1";
-		mode-addr = <4>;
-		mode-val = <NETXBIG_LED_OFF 0
-			    NETXBIG_LED_ON 2
-			    NETXBIG_LED_TIMER1 4>;
-		bright-addr = <2>;
-		max-brightness = <7>;
-	};
-};
-- 
2.34.1

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

[Krzysztof Kozlowski]

On Tue, Sep 01, 2026 at 10:33:58PM +0530, Udaya Kiran Challa wrote:
> Convert lacie,netxbig-leds devicetree binding from legacy
> text format to DT schema.
> 
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> ---
> Changelog:
> Changes since v2:
> - Add reference to led common.yaml
> - Drop type for all common properties
> 
> Link to v2:https://lore.kernel.org/all/20260821123723.198286-1-challauday369@gmail.com/
> 
> Changes since v1:
> - Use pattenProperties for LED child nodes instead of additionalProperties
> - Explicitly list the two optional properties supported by the binding
> - Place the top-level required block after child-node definition
> 
> Link to v1:https://lore.kernel.org/all/20260820150223.108374-1-challauday369@gmail.com/
> ---
>  .../bindings/leds/lacie,netxbig-leds.yaml     | 139 ++++++++++++++++++
>  .../devicetree/bindings/leds/leds-netxbig.txt |  92 ------------
>  2 files changed, 139 insertions(+), 92 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
>  delete mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml b/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
> new file mode 100644
> index 000000000000..5cb2eaf74d1a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/lacie,netxbig-leds.yaml
> @@ -0,0 +1,139 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/lacie,netxbig-leds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LaCie/Seagate netxbig CPLD LEDs
> +
> +maintainers:
> +  - Simon Guinot <simon.guinot@sequanux.org>
> +
> +description: |
> +  Binding for the CPLD LEDs (GPIO extension bus) found on some LaCie/Seagate
> +  boards (Example: 2Big/5Big Network v2, 2Big NAS).
> +
> +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?




> +    type: object
> +    $ref: common.yaml#
> +    unevaluatedProperties: false
> +
> +    properties:
> +      label: true
> +      linux,default-trigger: true

Drop both, common.yaml provides these.

> +
> +      mode-addr:
> +        description: Mode register address on gpio-ext bus.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +
> +      mode-val:
> +        description: |

Do not need '|' unless you need to preserve formatting.

> +          Mode to value mapping. Each entry is represented by two integers:
> +          a mode and the corresponding value on the gpio-ext bus.
> +        $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +      bright-addr:
> +        description: Brightness register address on gpio-ext bus.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +
> +      max-brightness:
> +        description: Maximum brightness value.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +
> +    required:
> +      - mode-addr
> +      - mode-val
> +      - bright-addr
> +      - max-brightness
> +
> +required:
> +  - compatible
> +  - gpio-ext
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/leds/leds-netxbig.h>
> +
> +    netxbig-leds {

Just "leds"

> +        compatible = "lacie,netxbig-leds";

Best regards,
Krzysztof

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

[Uday Kiran]

> > +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

>
>
>
>
> > +    type: object
> > +    $ref: common.yaml#
> > +    unevaluatedProperties: false
> > +
> > +    properties:
> > +      label: true
> > +      linux,default-trigger: true
>
> Drop both, common.yaml provides these.

Taken care in the next revision.

>
> > +
> > +      mode-addr:
> > +        description: Mode register address on gpio-ext bus.
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +      mode-val:
> > +        description: |
>
> Do not need '|' unless you need to preserve formatting.

Taken care in the next revision.

>
> > +          Mode to value mapping. Each entry is represented by two integers:
> > +          a mode and the corresponding value on the gpio-ext bus.
> > +        $ref: /schemas/types.yaml#/definitions/uint32-array
> > +
> > +      bright-addr:
> > +        description: Brightness register address on gpio-ext bus.
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +      max-brightness:
> > +        description: Maximum brightness value.
> > +        $ref: /schemas/types.yaml#/definitions/uint32
> > +
> > +    required:
> > +      - mode-addr
> > +      - mode-val
> > +      - bright-addr
> > +      - max-brightness
> > +
> > +required:
> > +  - compatible
> > +  - gpio-ext
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/leds/leds-netxbig.h>
> > +
> > +    netxbig-leds {
>
> Just "leds"

Taken care in the next revision.

>
> > +        compatible = "lacie,netxbig-leds";
>

Regards,
Udaya Kiran Challa

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

[Krzysztof Kozlowski]

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]+$"

Best regards,
Krzysztof

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

[Uday Kiran]

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]+)$"

Regards,
Udaya Kiran Challa

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

[Krzysztof Kozlowski]

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.

Best regards,
Krzysztof

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

[Uday Kiran]

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.

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.

Regards,
Udaya Kiran Challa

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

[Krzysztof Kozlowski]

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

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@kernel.org> wrote:
>
> 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?

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