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

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

[Ninad Naik]

Convert lacie,ns2-leds to DT schema.

Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
---
Changes in v2: 
- Change maintainers from the subsystem maintainers to Simon Guinot. 
- Drop "|" from the description field and update the description. 
- Remove patternProperties field and instead use additionalProperties.

 .../bindings/leds/lacie,ns2-leds.yaml         | 80 +++++++++++++++++++
 .../devicetree/bindings/leds/leds-ns2.txt     | 35 --------
 2 files changed, 80 insertions(+), 35 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/leds/lacie,ns2-leds.yaml
 delete mode 100644 Documentation/devicetree/bindings/leds/leds-ns2.txt

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 000000000000..1976669d2218
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/lacie,ns2-leds.yaml
@@ -0,0 +1,80 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/lacie,ns2-leds.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Dual-GPIO LEDs found on Network Space v2 (and parents)
+
+maintainers:
+  - Simon Guinot <simon.guinot@sequanux.org>
+
+description:
+  The Network Space v2 dual-GPIO LED is wired to a CPLD. Three different LED
+  modes are available, off, on and SATA activity blinking. The LED modes are
+  controlled through two GPIOs (command and slow), each combination of values
+  for the command/slow GPIOs corresponds to a LED mode.
+
+properties:
+  compatible:
+    const: lacie,ns2-leds
+
+additionalProperties:
+  type: object
+  $ref: common.yaml#
+  unevaluatedProperties: false
+
+  description: Each child node represents a single LED
+
+  properties:
+    cmd-gpio:
+      maxItems: 1
+      description: GPIO connected to the command LED output
+
+    slow-gpio:
+      maxItems: 1
+      description: GPIO connected to the slow LED output
+
+    modes-map:
+      $ref: /schemas/types.yaml#/definitions/uint32-matrix
+      description:
+        A mapping between LED modes (off, on or SATA activity blinking) and
+        the corresponding cmd-gpio/slow-gpio values. All the GPIO values
+        combinations should be given in order to avoid having an unknown
+        mode at driver probe time.
+
+      items:
+        items:
+          - description: LED mode
+            enum: [0, 1, 2]
+          - description: Command GPIO level
+            enum: [0, 1]
+          - description: Slow GPIO level
+            enum: [0, 1]
+
+  required:
+    - cmd-gpio
+    - slow-gpio
+    - modes-map
+
+required:
+  - compatible
+
+examples:
+  - |
+    #include <dt-bindings/leds/leds-ns2.h>
+
+    led-controller {
+        compatible = "lacie,ns2-leds";
+
+        led-0 {
+            label = "ns2:blue:sata";
+            slow-gpio = <&gpio0 29 0>;
+            cmd-gpio = <&gpio0 30 0>;
+            modes-map = <NS_V2_LED_OFF  0 1
+                         NS_V2_LED_ON   1 0
+                         NS_V2_LED_ON   0 0
+                         NS_V2_LED_SATA 1 1>;
+        };
+    };
+...
diff --git a/Documentation/devicetree/bindings/leds/leds-ns2.txt b/Documentation/devicetree/bindings/leds/leds-ns2.txt
deleted file mode 100644
index 9f81258a5b6e..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-ns2.txt
+++ /dev/null
@@ -1,35 +0,0 @@
-Binding for dual-GPIO LED found on Network Space v2 (and parents).
-
-Required properties:
-- compatible: "lacie,ns2-leds".
-
-Each LED is represented as a sub-node of the ns2-leds device.
-
-Required sub-node properties:
-- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
-- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
-- modes-map: A mapping between LED modes (off, on or SATA activity blinking) and
-  the corresponding cmd-gpio/slow-gpio values. All the GPIO values combinations
-  should be given in order to avoid having an unknown mode at driver probe time.
-
-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:
-
-#include <dt-bindings/leds/leds-ns2.h>
-
-ns2-leds {
-	compatible = "lacie,ns2-leds";
-
-	blue-sata {
-		label = "ns2:blue:sata";
-		slow-gpio = <&gpio0 29 0>;
-		cmd-gpio = <&gpio0 30 0>;
-		modes-map = <NS_V2_LED_OFF  0 1
-			     NS_V2_LED_ON   1 0
-			     NS_V2_LED_ON   0 0
-			     NS_V2_LED_SATA 1 1>;
-	};
-};
-- 
2.55.0

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] Using `additionalProperties` at the root level to define child nodes incorrectly restricts standard properties on the parent node, breaking device tree validation.
- [Low] The schema omits the `num-modes` property, causing `dtbs_check` failures for existing in-tree device trees.
--

--- Patch [1]: [PATCH v2] dt-bindings: leds: lacie,ns2-leds: Convert to DT schema ---
commit d6e2084ac319cdcc30d00614f66ec071bc9c5c1a
Author: Ninad Naik <ninadnaik07@gmail.com>

dt-bindings: leds: lacie,ns2-leds: Convert to DT schema

Convert the lacie,ns2-leds binding text document to a 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..1976669d2218c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/lacie,ns2-leds.yaml

[ ... ]

> +properties:
> +  compatible:
> +    const: lacie,ns2-leds
> +
> +additionalProperties:
> +  type: object
> +  $ref: common.yaml#
> +  unevaluatedProperties: false

[Severity: Low]
Does setting additionalProperties to type: object at the root level break
standard parent device tree properties like status = "okay" or pinctrl-names?

By enforcing that any unlisted top-level property must be an object, standard
properties (which are strings or arrays) will fail validation with type
mismatch errors during make dtbs_check.

Is it better to use patternProperties: "^led(-[0-9a-f]+)?$": for the child
nodes and set additionalProperties: false at the root instead?

> +
> +  description: Each child node represents a single LED
> +
> +  properties:
> +    cmd-gpio:
> +      maxItems: 1
> +      description: GPIO connected to the command LED output

[Severity: Low]
Will this schema omission cause dtbs_check failures for existing in-tree
device trees?

The new schema strictly allows only documented properties via
unevaluatedProperties: false on the child nodes. However, existing in-tree
device trees contain an undocumented num-modes property:

arch/arm/boot/dts/armada-370-seagate-nas-4bay.dts:white-sata2 {
        ...
        slow-gpio = <&pca9554 2 GPIO_ACTIVE_HIGH>;
        num-modes = <4>;
        modes-map = <NS_V2_LED_SATA 0 0
        ...
}

Since num-modes is omitted from this new schema, validation will fail when
checking those boards. Should num-modes be added to the schema (perhaps with
deprecated: true), or removed from the DTS files as part of this patch series?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721192754.46344-1-ninadnaik07@gmail.com?part=1

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

[Rob Herring]

On Tue, Jul 21, 2026 at 07:38:49PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [Low] Using `additionalProperties` at the root level to define child nodes incorrectly restricts standard properties on the parent node, breaking device tree validation.
> - [Low] The schema omits the `num-modes` property, causing `dtbs_check` failures for existing in-tree device trees.
> --
> 
> --- Patch [1]: [PATCH v2] dt-bindings: leds: lacie,ns2-leds: Convert to DT schema ---
> commit d6e2084ac319cdcc30d00614f66ec071bc9c5c1a
> Author: Ninad Naik <ninadnaik07@gmail.com>
> 
> dt-bindings: leds: lacie,ns2-leds: Convert to DT schema
> 
> Convert the lacie,ns2-leds binding text document to a 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..1976669d2218c
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/leds/lacie,ns2-leds.yaml
> 
> [ ... ]
> 
> > +properties:
> > +  compatible:
> > +    const: lacie,ns2-leds
> > +
> > +additionalProperties:
> > +  type: object
> > +  $ref: common.yaml#
> > +  unevaluatedProperties: false
> 
> [Severity: Low]
> Does setting additionalProperties to type: object at the root level break
> standard parent device tree properties like status = "okay" or pinctrl-names?
> 
> By enforcing that any unlisted top-level property must be an object, standard
> properties (which are strings or arrays) will fail validation with type
> mismatch errors during make dtbs_check.
> 
> Is it better to use patternProperties: "^led(-[0-9a-f]+)?$": for the child
> nodes and set additionalProperties: false at the root instead?

No.

> 
> > +
> > +  description: Each child node represents a single LED
> > +
> > +  properties:
> > +    cmd-gpio:
> > +      maxItems: 1
> > +      description: GPIO connected to the command LED output
> 
> [Severity: Low]
> Will this schema omission cause dtbs_check failures for existing in-tree
> device trees?
> 
> The new schema strictly allows only documented properties via
> unevaluatedProperties: false on the child nodes. However, existing in-tree
> device trees contain an undocumented num-modes property:
> 
> arch/arm/boot/dts/armada-370-seagate-nas-4bay.dts:white-sata2 {
>         ...
>         slow-gpio = <&pca9554 2 GPIO_ACTIVE_HIGH>;
>         num-modes = <4>;
>         modes-map = <NS_V2_LED_SATA 0 0
>         ...
> }
> 
> Since num-modes is omitted from this new schema, validation will fail when
> checking those boards. Should num-modes be added to the schema (perhaps with
> deprecated: true), or removed from the DTS files as part of this patch series?

This should be fixed.

Rob