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

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

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

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

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

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