[PATCH v2 1/2] dt-bindings: leds: Convert common LED binding to schema

[PATCH v2 1/2] dt-bindings: leds: Convert common LED binding to schema

[Rob Herring]

Convert the common LEDs properties bindings to a schema. As trigger source
providers are different nodes, we need to split trigger source properties
to a separate file.

Bindings for LED controllers can reference the common schema for the LED
child nodes:

patternProperties:
  "^led@[0-4]":
    type: object
    allOf:
      - $ref: common.yaml#

Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: linux-leds@vger.kernel.org
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
Jacek, Please take this via led tree

v2:
- Fix typo in function

 .../devicetree/bindings/leds/common.txt       | 174 +------------
 .../devicetree/bindings/leds/common.yaml      | 228 ++++++++++++++++++
 .../bindings/leds/trigger-source.yaml         |  24 ++
 3 files changed, 253 insertions(+), 173 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/leds/common.yaml
 create mode 100644 Documentation/devicetree/bindings/leds/trigger-source.yaml

diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
index 9fa6f9795d50..26d770ef3601 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -1,173 +1 @@
-* Common leds properties.
-
-LED and flash LED devices provide the same basic functionality as current
-regulators, but extended with LED and flash LED specific features like
-blinking patterns, flash timeout, flash faults and external flash strobe mode.
-
-Many LED devices expose more than one current output that can be connected
-to one or more discrete LED component. Since the arrangement of connections
-can influence the way of the LED device initialization, the LED components
-have to be tightly coupled with the LED device binding. They are represented
-by child nodes of the parent LED device binding.
-
-
-Optional properties for child nodes:
-- led-sources : List of device current outputs the LED is connected to. The
-		outputs are identified by the numbers that must be defined
-		in the LED device binding documentation.
-
-- function: LED functon. Use one of the LED_FUNCTION_* prefixed definitions
-	    from the header include/dt-bindings/leds/common.h.
-	    If there is no matching LED_FUNCTION available, add a new one.
-
-- color : Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions
-	  from the header include/dt-bindings/leds/common.h.
-	  If there is no matching LED_COLOR_ID available, add a new one.
-
-- function-enumerator: Integer to be used when more than one instance
-                       of the same function is needed, differing only with
-		       an ordinal number.
-
-- label : The label for this LED. If omitted, the label is taken from the node
-	  name (excluding the unit address). It has to uniquely identify
-	  a device, i.e. no other LED class device can be assigned the same
-	  label. This property is deprecated - use 'function' and 'color'
-	  properties instead. function-enumerator has no effect when this
-	  property is present.
-
-- default-state : The initial state of the LED. Valid values are "on", "off",
-  and "keep". If the LED is already on or off and the default-state property is
-  set the to same value, then no glitch should be produced where the LED
-  momentarily turns off (or on). The "keep" setting will keep the LED at
-  whatever its current state is, without producing a glitch.  The default is
-  off if this property is not present.
-
-- linux,default-trigger :  This parameter, if present, is a
-    string defining the trigger assigned to the LED.  Current triggers are:
-     "backlight" - LED will act as a back-light, controlled by the framebuffer
-		   system
-     "default-on" - LED will turn on (but for leds-gpio see "default-state"
-		    property in Documentation/devicetree/bindings/leds/leds-gpio.txt)
-     "heartbeat" - LED "double" flashes at a load average based rate
-     "disk-activity" - LED indicates disk activity
-     "ide-disk" - LED indicates IDE disk activity (deprecated),
-                  in new implementations use "disk-activity"
-     "timer" - LED flashes at a fixed, configurable rate
-     "pattern" - LED alters the brightness for the specified duration with one
-                 software timer (requires "led-pattern" property)
-
-- led-pattern : Array of integers with default pattern for certain triggers.
-                Each trigger may parse this property differently:
-                - one-shot : two numbers specifying delay on and delay off (in ms),
-                - timer : two numbers specifying delay on and delay off (in ms),
-                - pattern : the pattern is given by a series of tuples, of
-                  brightness and duration (in ms).  The exact format is
-                  described in:
-                  Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
-
-
-- led-max-microamp : Maximum LED supply current in microamperes. This property
-                     can be made mandatory for the board configurations
-                     introducing a risk of hardware damage in case an excessive
-                     current is set.
-                     For flash LED controllers with configurable current this
-                     property is mandatory for the LEDs in the non-flash modes
-                     (e.g. torch or indicator).
-
-- panic-indicator : This property specifies that the LED should be used,
-		    if at all possible, as a panic indicator.
-
-- trigger-sources : List of devices which should be used as a source triggering
-		    this LED activity. Some LEDs can be related to a specific
-		    device and should somehow indicate its state. E.g. USB 2.0
-		    LED may react to device(s) in a USB 2.0 port(s).
-		    Another common example is switch or router with multiple
-		    Ethernet ports each of them having its own LED assigned
-		    (assuming they are not hardwired). In such cases this
-		    property should contain phandle(s) of related source
-		    device(s).
-		    In many cases LED can be related to more than one device
-		    (e.g. one USB LED vs. multiple USB ports). Each source
-		    should be represented by a node in the device tree and be
-		    referenced by a phandle and a set of phandle arguments. A
-		    length of arguments should be specified by the
-		    #trigger-source-cells property in the source node.
-
-Required properties for flash LED child nodes:
-- flash-max-microamp : Maximum flash LED supply current in microamperes.
-- flash-max-timeout-us : Maximum timeout in microseconds after which the flash
-                         LED is turned off.
-
-For controllers that have no configurable current the flash-max-microamp
-property can be omitted.
-For controllers that have no configurable timeout the flash-max-timeout-us
-property can be omitted.
-
-* Trigger source providers
-
-Each trigger source should be represented by a device tree node. It may be e.g.
-a USB port or an Ethernet device.
-
-Required properties for trigger source:
-- #trigger-source-cells : Number of cells in a source trigger. Typically 0 for
-			  nodes of simple trigger sources (e.g. a specific USB
-			  port).
-
-* Examples
-
-#include <dt-bindings/leds/common.h>
-
-led-controller@0 {
-	compatible = "gpio-leds";
-
-	led0 {
-		function = LED_FUNCTION_STATUS;
-		linux,default-trigger = "heartbeat";
-		gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
-	};
-
-	led1 {
-		function = LED_FUNCTION_USB;
-		gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
-		trigger-sources = <&ohci_port1>, <&ehci_port1>;
-	};
-};
-
-led-controller@0 {
-	compatible = "maxim,max77693-led";
-
-	led {
-		function = LED_FUNCTION_FLASH;
-		color = <LED_COLOR_ID_WHITE>;
-		led-sources = <0>, <1>;
-		led-max-microamp = <50000>;
-		flash-max-microamp = <320000>;
-		flash-max-timeout-us = <500000>;
-	};
-};
-
-led-controller@30 {
-        compatible = "panasonic,an30259a";
-        reg = <0x30>;
-        #address-cells = <1>;
-        #size-cells = <0>;
-
-        led@1 {
-		reg = <1>;
-		linux,default-trigger = "heartbeat";
-		function = LED_FUNCTION_INDICATOR;
-		function-enumerator = <1>;
-        };
-
-        led@2 {
-		reg = <2>;
-		function = LED_FUNCTION_INDICATOR;
-		function-enumerator = <2>;
-        };
-
-        led@3 {
-		reg = <3>;
-		function = LED_FUNCTION_INDICATOR;
-		function-enumerator = <3>;
-        };
-};
+This file has moved to ./common.yaml.
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
new file mode 100644
index 000000000000..d97d099b87e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -0,0 +1,228 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/common.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common leds properties
+
+maintainers:
+  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
+  - Pavel Machek <pavel@ucw.cz>
+
+description:
+  LED and flash LED devices provide the same basic functionality as current
+  regulators, but extended with LED and flash LED specific features like
+  blinking patterns, flash timeout, flash faults and external flash strobe mode.
+
+  Many LED devices expose more than one current output that can be connected
+  to one or more discrete LED component. Since the arrangement of connections
+  can influence the way of the LED device initialization, the LED components
+  have to be tightly coupled with the LED device binding. They are represented
+  by child nodes of the parent LED device binding.
+
+properties:
+  led-sources:
+    description:
+      List of device current outputs the LED is connected to. The outputs are
+      identified by the numbers that must be defined in the LED device binding
+      documentation.
+    $ref: /schemas/types.yaml#definitions/uint32-array
+
+  function:
+    description:
+      LED function. Use one of the LED_FUNCTION_* prefixed definitions
+      from the header include/dt-bindings/leds/common.h. If there is no
+      matching LED_FUNCTION available, add a new one.
+    $ref: /schemas/types.yaml#definitions/string
+
+  color:
+    description:
+      Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions from
+      the header include/dt-bindings/leds/common.h. If there is no matching
+      LED_COLOR_ID available, add a new one.
+    allOf:
+      - $ref: /schemas/types.yaml#definitions/uint32
+    minimum: 0
+    maximum: 8
+
+  function-enumerator:
+    description:
+      Integer to be used when more than one instance of the same function is
+      needed, differing only with an ordinal number.
+    $ref: /schemas/types.yaml#definitions/uint32
+
+  label:
+    description:
+      The label for this LED. If omitted, the label is taken from the node name
+      (excluding the unit address). It has to uniquely identify a device, i.e.
+      no other LED class device can be assigned the same label. This property is
+      deprecated - use 'function' and 'color' properties instead.
+      function-enumerator has no effect when this property is present.
+
+  default-state:
+    description:
+      The initial state of the LED. If the LED is already on or off and the
+      default-state property is set the to same value, then no glitch should be
+      produced where the LED momentarily turns off (or on). The "keep" setting
+      will keep the LED at whatever its current state is, without producing a
+      glitch.
+    allOf:
+      - $ref: /schemas/types.yaml#definitions/string
+    enum:
+      - on
+      - off
+      - keep
+    default: off
+
+  linux,default-trigger:
+    description:
+      This parameter, if present, is a string defining the trigger assigned to
+      the LED.
+    allOf:
+      - $ref: /schemas/types.yaml#definitions/string
+    enum:
+        # LED will act as a back-light, controlled by the framebuffer system
+      - backlight
+        # LED will turn on (but for leds-gpio see "default-state" property in
+        # Documentation/devicetree/bindings/leds/leds-gpio.txt)
+      - default-on
+        # LED "double" flashes at a load average based rate
+      - heartbeat
+        # LED indicates disk activity
+      - disk-activity
+        # LED indicates IDE disk activity (deprecated), in new implementations
+        # use "disk-activity"
+      - ide-disk
+        # LED flashes at a fixed, configurable rate
+      - timer
+        # LED alters the brightness for the specified duration with one software
+        # timer (requires "led-pattern" property)
+      - pattern
+
+  led-pattern:
+    description: |
+      Array of integers with default pattern for certain triggers.
+
+      Each trigger may parse this property differently:
+        - one-shot : two numbers specifying delay on and delay off (in ms),
+        - timer : two numbers specifying delay on and delay off (in ms),
+        - pattern : the pattern is given by a series of tuples, of
+          brightness and duration (in ms).  The exact format is
+          described in:
+          Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
+    allOf:
+      - $ref: /schemas/types.yaml#definitions/uint32-matrix
+    items:
+      minItems: 2
+      maxItems: 2
+
+  led-max-microamp:
+    description:
+      Maximum LED supply current in microamperes. This property can be made
+      mandatory for the board configurations introducing a risk of hardware
+      damage in case an excessive current is set.
+      For flash LED controllers with configurable current this property is
+      mandatory for the LEDs in the non-flash modes (e.g. torch or indicator).
+
+  panic-indicator:
+    description:
+      This property specifies that the LED should be used, if at all possible,
+      as a panic indicator.
+    type: boolean
+
+  trigger-sources:
+    description: |
+      List of devices which should be used as a source triggering this LED
+      activity. Some LEDs can be related to a specific device and should somehow
+      indicate its state. E.g. USB 2.0 LED may react to device(s) in a USB 2.0
+      port(s).
+      Another common example is switch or router with multiple Ethernet ports
+      each of them having its own LED assigned (assuming they are not
+      hardwired). In such cases this property should contain phandle(s) of
+      related source device(s).
+      In many cases LED can be related to more than one device (e.g. one USB LED
+      vs. multiple USB ports). Each source should be represented by a node in
+      the device tree and be referenced by a phandle and a set of phandle
+      arguments. A length of arguments should be specified by the
+      #trigger-source-cells property in the source node.
+    $ref: /schemas/types.yaml#definitions/phandle-array
+
+  # Required properties for flash LED child nodes:
+  flash-max-microamp:
+    description:
+      Maximum flash LED supply current in microamperes. Required for flash LED
+      nodes with configurable current.
+
+  flash-max-timeout-us:
+    description:
+      Maximum timeout in microseconds after which the flash LED is turned off.
+      Required for flash LED nodes with configurable timeout.
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/leds/common.h>
+
+    led-controller {
+        compatible = "gpio-leds";
+
+        led0 {
+            function = LED_FUNCTION_STATUS;
+            linux,default-trigger = "heartbeat";
+            gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+        };
+
+        led1 {
+            function = LED_FUNCTION_USB;
+            gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+            trigger-sources = <&ohci_port1>, <&ehci_port1>;
+        };
+    };
+
+    led-controller@0 {
+        compatible = "maxim,max77693-led";
+        reg = <0 0x100>;
+
+        led {
+            function = LED_FUNCTION_FLASH;
+            color = <LED_COLOR_ID_WHITE>;
+            led-sources = <0>, <1>;
+            led-max-microamp = <50000>;
+            flash-max-microamp = <320000>;
+            flash-max-timeout-us = <500000>;
+        };
+    };
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        led-controller@30 {
+            compatible = "panasonic,an30259a";
+            reg = <0x30>;
+            #address-cells = <1>;
+            #size-cells = <0>;
+
+            led@1 {
+                reg = <1>;
+                linux,default-trigger = "heartbeat";
+                function = LED_FUNCTION_INDICATOR;
+                function-enumerator = <1>;
+            };
+
+            led@2 {
+                reg = <2>;
+                function = LED_FUNCTION_INDICATOR;
+                function-enumerator = <2>;
+            };
+
+            led@3 {
+                reg = <3>;
+                function = LED_FUNCTION_INDICATOR;
+                function-enumerator = <3>;
+            };
+        };
+    };
+
+...
diff --git a/Documentation/devicetree/bindings/leds/trigger-source.yaml b/Documentation/devicetree/bindings/leds/trigger-source.yaml
new file mode 100644
index 000000000000..0618003e40bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/trigger-source.yaml
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/trigger-source.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Trigger source providers
+
+maintainers:
+  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
+  - Pavel Machek <pavel@ucw.cz>
+
+description:
+  Each trigger source provider should be represented by a device tree node. It
+  may be e.g. a USB port or an Ethernet device.
+
+properties:
+  '#trigger-source-cells':
+    description:
+      Number of cells in a source trigger. Typically 0 for nodes of simple
+      trigger sources (e.g. a specific USB port).
+    enum: [ 0, 1 ]
+
+...
-- 
2.20.1

[PATCH v2 2/2] dt-bindings: leds: Convert gpio-leds to DT schema

[Rob Herring]

Convert the gpio-leds binding to DT schema format.

Drop the last example as the node name collides when built, and it doesn't
add much value.

Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
Jacek, Please take this via led tree

v2:
- no change

 .../devicetree/bindings/leds/leds-gpio.txt    | 75 ----------------
 .../devicetree/bindings/leds/leds-gpio.yaml   | 86 +++++++++++++++++++
 2 files changed, 86 insertions(+), 75 deletions(-)
 delete mode 100644 Documentation/devicetree/bindings/leds/leds-gpio.txt
 create mode 100644 Documentation/devicetree/bindings/leds/leds-gpio.yaml

diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt
deleted file mode 100644
index d21281b63d38..000000000000
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-LEDs connected to GPIO lines
-
-Required properties:
-- compatible : should be "gpio-leds".
-
-Each LED is represented as a sub-node of the gpio-leds device.  Each
-node's name represents the name of the corresponding LED.
-
-LED sub-node properties:
-- gpios :  Should specify the LED's GPIO, see "gpios property" in
-  Documentation/devicetree/bindings/gpio/gpio.txt.  Active low LEDs should be
-  indicated using flags in the GPIO specifier.
-- function :  (optional)
-  see Documentation/devicetree/bindings/leds/common.txt
-- color :  (optional)
-  see Documentation/devicetree/bindings/leds/common.txt
-- label :  (optional)
-  see Documentation/devicetree/bindings/leds/common.txt (deprecated)
-- linux,default-trigger :  (optional)
-  see Documentation/devicetree/bindings/leds/common.txt
-- default-state:  (optional) The initial state of the LED.
-  see Documentation/devicetree/bindings/leds/common.txt
-- retain-state-suspended: (optional) The suspend state can be retained.Such
-  as charge-led gpio.
-- retain-state-shutdown: (optional) Retain the state of the LED on shutdown.
-  Useful in BMC systems, for example when the BMC is rebooted while the host
-  remains up.
-- panic-indicator : (optional)
-  see Documentation/devicetree/bindings/leds/common.txt
-
-Examples:
-
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
-
-leds {
-	compatible = "gpio-leds";
-	led0 {
-		gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
-		linux,default-trigger = "disk-activity";
-		function = LED_FUNCTION_DISK;
-	};
-
-	led1 {
-		gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
-		/* Keep LED on if BIOS detected hardware fault */
-		default-state = "keep";
-		function = LED_FUNCTION_FAULT;
-	};
-};
-
-run-control {
-	compatible = "gpio-leds";
-	led0 {
-		gpios = <&mpc8572 6 GPIO_ACTIVE_HIGH>;
-		color = <LED_COLOR_ID_RED>;
-		default-state = "off";
-	};
-	led1 {
-		gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
-		color = <LED_COLOR_ID_GREEN>;
-		default-state = "on";
-	};
-};
-
-leds {
-	compatible = "gpio-leds";
-
-	led0 {
-		gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
-		linux,default-trigger = "max8903-charger-charging";
-		retain-state-suspended;
-		function = LED_FUNCTION_CHARGE;
-	};
-};
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.yaml b/Documentation/devicetree/bindings/leds/leds-gpio.yaml
new file mode 100644
index 000000000000..0e75b185dd19
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LEDs connected to GPIO lines
+
+maintainers:
+  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
+  - Pavel Machek <pavel@ucw.cz>
+
+description:
+  Each LED is represented as a sub-node of the gpio-leds device.  Each
+  node's name represents the name of the corresponding LED.
+
+properties:
+  compatible:
+    const: gpio-leds
+
+patternProperties:
+  # The first form is preferred, but fall back to just 'led' anywhere in the
+  # node name to at least catch some child nodes.
+  "(^led-[0-9a-f]$|led)":
+    type: object
+
+    allOf:
+      - $ref: common.yaml#
+
+    properties:
+      gpios:
+        maxItems: 1
+
+      retain-state-suspended:
+        description:
+          The suspend state can be retained.Such as charge-led gpio.
+        type: boolean
+
+      retain-state-shutdown:
+        description:
+          Retain the state of the LED on shutdown. Useful in BMC systems, for
+          example when the BMC is rebooted while the host remains up.
+        type: boolean
+
+    required:
+      - gpios
+
+additionalProperties: false
+
+examples:
+  - |
+
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/leds/common.h>
+
+    leds {
+        compatible = "gpio-leds";
+        led-0 {
+            gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
+            linux,default-trigger = "disk-activity";
+            function = LED_FUNCTION_DISK;
+        };
+
+        led-1 {
+            gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
+            /* Keep LED on if BIOS detected hardware fault */
+            default-state = "keep";
+            function = LED_FUNCTION_FAULT;
+        };
+    };
+
+    run-control {
+        compatible = "gpio-leds";
+        led-0 {
+            gpios = <&mpc8572 6 GPIO_ACTIVE_HIGH>;
+            color = <LED_COLOR_ID_RED>;
+            default-state = "off";
+        };
+        led-1 {
+            gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
+            color = <LED_COLOR_ID_GREEN>;
+            default-state = "on";
+        };
+    };
+
+...
-- 
2.20.1

Re: [PATCH v2 2/2] dt-bindings: leds: Convert gpio-leds to DT schema

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

On Tue 2020-01-07 18:17:38, Rob Herring wrote:
> Convert the gpio-leds binding to DT schema format.
> 
> Drop the last example as the node name collides when built, and it doesn't
> add much value.
> 
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Dan Murphy <dmurphy@ti.com>
> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> Signed-off-by: Rob Herring <robh@kernel.org>

It seems it is already in tree, as of Linux 5.6-rc2...?

So, sorry for delay but nothing for me to do here?

Best regards,
								Pavel
								
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [PATCH v2 2/2] dt-bindings: leds: Convert gpio-leds to DT schema

[Philippe Schenker]

On Tue, 2020-01-07 at 18:17 -0600, Rob Herring wrote:
> Convert the gpio-leds binding to DT schema format.
> 
> Drop the last example as the node name collides when built, and it
> doesn't
> add much value.
> 
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Dan Murphy <dmurphy@ti.com>
> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Jacek, Please take this via led tree
> 
> v2:
> - no change
> 
>  .../devicetree/bindings/leds/leds-gpio.txt    | 75 ----------------
>  .../devicetree/bindings/leds/leds-gpio.yaml   | 86
> +++++++++++++++++++
>  2 files changed, 86 insertions(+), 75 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/leds/leds-
> gpio.txt
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-
> gpio.yaml
> 
> diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt
> b/Documentation/devicetree/bindings/leds/leds-gpio.txt
> deleted file mode 100644
> index d21281b63d38..000000000000
> --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
> +++ /dev/null
> @@ -1,75 +0,0 @@
> -LEDs connected to GPIO lines
> -
> -Required properties:
> -- compatible : should be "gpio-leds".
> -
> -Each LED is represented as a sub-node of the gpio-leds device.  Each
> -node's name represents the name of the corresponding LED.
> -
> -LED sub-node properties:
> -- gpios :  Should specify the LED's GPIO, see "gpios property" in
> -  Documentation/devicetree/bindings/gpio/gpio.txt.  Active low LEDs
> should be
> -  indicated using flags in the GPIO specifier.
> -- function :  (optional)
> -  see Documentation/devicetree/bindings/leds/common.txt
> -- color :  (optional)
> -  see Documentation/devicetree/bindings/leds/common.txt
> -- label :  (optional)
> -  see Documentation/devicetree/bindings/leds/common.txt (deprecated)
> -- linux,default-trigger :  (optional)
> -  see Documentation/devicetree/bindings/leds/common.txt
> -- default-state:  (optional) The initial state of the LED.
> -  see Documentation/devicetree/bindings/leds/common.txt
> -- retain-state-suspended: (optional) The suspend state can be
> retained.Such
> -  as charge-led gpio.
> -- retain-state-shutdown: (optional) Retain the state of the LED on
> shutdown.
> -  Useful in BMC systems, for example when the BMC is rebooted while
> the host
> -  remains up.
> -- panic-indicator : (optional)
> -  see Documentation/devicetree/bindings/leds/common.txt
> -
> -Examples:
> -
> -#include <dt-bindings/gpio/gpio.h>
> -#include <dt-bindings/leds/common.h>
> -
> -leds {
> -       compatible = "gpio-leds";
> -       led0 {
> -               gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
> -               linux,default-trigger = "disk-activity";
> -               function = LED_FUNCTION_DISK;
> -       };
> -
> -       led1 {
> -               gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
> -               /* Keep LED on if BIOS detected hardware fault */
> -               default-state = "keep";
> -               function = LED_FUNCTION_FAULT;
> -       };
> -};
> -
> -run-control {
> -       compatible = "gpio-leds";
> -       led0 {
> -               gpios = <&mpc8572 6 GPIO_ACTIVE_HIGH>;
> -               color = <LED_COLOR_ID_RED>;
> -               default-state = "off";
> -       };
> -       led1 {
> -               gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
> -               color = <LED_COLOR_ID_GREEN>;
> -               default-state = "on";
> -       };
> -};
> -
> -leds {
> -       compatible = "gpio-leds";
> -
> -       led0 {
> -               gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> -               linux,default-trigger = "max8903-charger-charging";
> -               retain-state-suspended;
> -               function = LED_FUNCTION_CHARGE;
> -       };
> -};
> diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.yaml
> b/Documentation/devicetree/bindings/leds/leds-gpio.yaml
> new file mode 100644
> index 000000000000..0e75b185dd19
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-gpio.yaml
> @@ -0,0 +1,86 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/leds-gpio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: LEDs connected to GPIO lines
> +
> +maintainers:
> +  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
> +  - Pavel Machek <pavel@ucw.cz>
> +
> +description:
> +  Each LED is represented as a sub-node of the gpio-leds device. 
> Each
> +  node's name represents the name of the corresponding LED.
> +
> +properties:
> +  compatible:
> +    const: gpio-leds
> +
> +patternProperties:
> +  # The first form is preferred, but fall back to just 'led' anywhere
> in the
> +  # node name to at least catch some child nodes.
> +  "(^led-[0-9a-f]$|led)":

Hi Rob, just stumbled on this regexp which I do not understand what you
meant with it.
It is limiting the amount of LEDs to 16 in the part "^led-[0-9a-f]$" but
then after the or "|" it is allowed to put any name containing "led"?

Is this really wanted?
Am I now needed to number my leds like "led-1, led-2, ..., led-f"?

Thanks in advance for the explanation.

Philippe

> +    type: object
> +
> +    allOf:
> +      - $ref: common.yaml#
> +
> +    properties:
> +      gpios:
> +        maxItems: 1
> +
> +      retain-state-suspended:
> +        description:
> +          The suspend state can be retained.Such as charge-led gpio.
> +        type: boolean
> +
> +      retain-state-shutdown:
> +        description:
> +          Retain the state of the LED on shutdown. Useful in BMC
> systems, for
> +          example when the BMC is rebooted while the host remains up.
> +        type: boolean
> +
> +    required:
> +      - gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +
> +    #include <dt-bindings/gpio/gpio.h>
> +    #include <dt-bindings/leds/common.h>
> +
> +    leds {
> +        compatible = "gpio-leds";
> +        led-0 {
> +            gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
> +            linux,default-trigger = "disk-activity";
> +            function = LED_FUNCTION_DISK;
> +        };
> +
> +        led-1 {
> +            gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
> +            /* Keep LED on if BIOS detected hardware fault */
> +            default-state = "keep";
> +            function = LED_FUNCTION_FAULT;
> +        };
> +    };
> +
> +    run-control {
> +        compatible = "gpio-leds";
> +        led-0 {
> +            gpios = <&mpc8572 6 GPIO_ACTIVE_HIGH>;
> +            color = <LED_COLOR_ID_RED>;
> +            default-state = "off";
> +        };
> +        led-1 {
> +            gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
> +            color = <LED_COLOR_ID_GREEN>;
> +            default-state = "on";
> +        };
> +    };
> +
> +...

Re: [PATCH v2 1/2] dt-bindings: leds: Convert common LED binding to schema

[Jacek Anaszewski]

On 1/8/20 1:17 AM, Rob Herring wrote:
> Convert the common LEDs properties bindings to a schema. As trigger source
> providers are different nodes, we need to split trigger source properties
> to a separate file.
> 
> Bindings for LED controllers can reference the common schema for the LED
> child nodes:
> 
> patternProperties:
>   "^led@[0-4]":
>     type: object
>     allOf:
>       - $ref: common.yaml#
> 
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Dan Murphy <dmurphy@ti.com>
> Cc: linux-leds@vger.kernel.org
> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> Jacek, Please take this via led tree

Currently Pavel maintains LED tree. Pavel?

> v2:
> - Fix typo in function
> 
>  .../devicetree/bindings/leds/common.txt       | 174 +------------
>  .../devicetree/bindings/leds/common.yaml      | 228 ++++++++++++++++++
>  .../bindings/leds/trigger-source.yaml         |  24 ++
>  3 files changed, 253 insertions(+), 173 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/leds/common.yaml
>  create mode 100644 Documentation/devicetree/bindings/leds/trigger-source.yaml
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 9fa6f9795d50..26d770ef3601 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -1,173 +1 @@
> -* Common leds properties.
> -
> -LED and flash LED devices provide the same basic functionality as current
> -regulators, but extended with LED and flash LED specific features like
> -blinking patterns, flash timeout, flash faults and external flash strobe mode.
> -
> -Many LED devices expose more than one current output that can be connected
> -to one or more discrete LED component. Since the arrangement of connections
> -can influence the way of the LED device initialization, the LED components
> -have to be tightly coupled with the LED device binding. They are represented
> -by child nodes of the parent LED device binding.
> -
> -
> -Optional properties for child nodes:
> -- led-sources : List of device current outputs the LED is connected to. The
> -		outputs are identified by the numbers that must be defined
> -		in the LED device binding documentation.
> -
> -- function: LED functon. Use one of the LED_FUNCTION_* prefixed definitions
> -	    from the header include/dt-bindings/leds/common.h.
> -	    If there is no matching LED_FUNCTION available, add a new one.
> -
> -- color : Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions
> -	  from the header include/dt-bindings/leds/common.h.
> -	  If there is no matching LED_COLOR_ID available, add a new one.
> -
> -- function-enumerator: Integer to be used when more than one instance
> -                       of the same function is needed, differing only with
> -		       an ordinal number.
> -
> -- label : The label for this LED. If omitted, the label is taken from the node
> -	  name (excluding the unit address). It has to uniquely identify
> -	  a device, i.e. no other LED class device can be assigned the same
> -	  label. This property is deprecated - use 'function' and 'color'
> -	  properties instead. function-enumerator has no effect when this
> -	  property is present.
> -
> -- default-state : The initial state of the LED. Valid values are "on", "off",
> -  and "keep". If the LED is already on or off and the default-state property is
> -  set the to same value, then no glitch should be produced where the LED
> -  momentarily turns off (or on). The "keep" setting will keep the LED at
> -  whatever its current state is, without producing a glitch.  The default is
> -  off if this property is not present.
> -
> -- linux,default-trigger :  This parameter, if present, is a
> -    string defining the trigger assigned to the LED.  Current triggers are:
> -     "backlight" - LED will act as a back-light, controlled by the framebuffer
> -		   system
> -     "default-on" - LED will turn on (but for leds-gpio see "default-state"
> -		    property in Documentation/devicetree/bindings/leds/leds-gpio.txt)
> -     "heartbeat" - LED "double" flashes at a load average based rate
> -     "disk-activity" - LED indicates disk activity
> -     "ide-disk" - LED indicates IDE disk activity (deprecated),
> -                  in new implementations use "disk-activity"
> -     "timer" - LED flashes at a fixed, configurable rate
> -     "pattern" - LED alters the brightness for the specified duration with one
> -                 software timer (requires "led-pattern" property)
> -
> -- led-pattern : Array of integers with default pattern for certain triggers.
> -                Each trigger may parse this property differently:
> -                - one-shot : two numbers specifying delay on and delay off (in ms),
> -                - timer : two numbers specifying delay on and delay off (in ms),
> -                - pattern : the pattern is given by a series of tuples, of
> -                  brightness and duration (in ms).  The exact format is
> -                  described in:
> -                  Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
> -
> -
> -- led-max-microamp : Maximum LED supply current in microamperes. This property
> -                     can be made mandatory for the board configurations
> -                     introducing a risk of hardware damage in case an excessive
> -                     current is set.
> -                     For flash LED controllers with configurable current this
> -                     property is mandatory for the LEDs in the non-flash modes
> -                     (e.g. torch or indicator).
> -
> -- panic-indicator : This property specifies that the LED should be used,
> -		    if at all possible, as a panic indicator.
> -
> -- trigger-sources : List of devices which should be used as a source triggering
> -		    this LED activity. Some LEDs can be related to a specific
> -		    device and should somehow indicate its state. E.g. USB 2.0
> -		    LED may react to device(s) in a USB 2.0 port(s).
> -		    Another common example is switch or router with multiple
> -		    Ethernet ports each of them having its own LED assigned
> -		    (assuming they are not hardwired). In such cases this
> -		    property should contain phandle(s) of related source
> -		    device(s).
> -		    In many cases LED can be related to more than one device
> -		    (e.g. one USB LED vs. multiple USB ports). Each source
> -		    should be represented by a node in the device tree and be
> -		    referenced by a phandle and a set of phandle arguments. A
> -		    length of arguments should be specified by the
> -		    #trigger-source-cells property in the source node.
> -
> -Required properties for flash LED child nodes:
> -- flash-max-microamp : Maximum flash LED supply current in microamperes.
> -- flash-max-timeout-us : Maximum timeout in microseconds after which the flash
> -                         LED is turned off.
> -
> -For controllers that have no configurable current the flash-max-microamp
> -property can be omitted.
> -For controllers that have no configurable timeout the flash-max-timeout-us
> -property can be omitted.
> -
> -* Trigger source providers
> -
> -Each trigger source should be represented by a device tree node. It may be e.g.
> -a USB port or an Ethernet device.
> -
> -Required properties for trigger source:
> -- #trigger-source-cells : Number of cells in a source trigger. Typically 0 for
> -			  nodes of simple trigger sources (e.g. a specific USB
> -			  port).
> -
> -* Examples
> -
> -#include <dt-bindings/leds/common.h>
> -
> -led-controller@0 {
> -	compatible = "gpio-leds";
> -
> -	led0 {
> -		function = LED_FUNCTION_STATUS;
> -		linux,default-trigger = "heartbeat";
> -		gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> -	};
> -
> -	led1 {
> -		function = LED_FUNCTION_USB;
> -		gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> -		trigger-sources = <&ohci_port1>, <&ehci_port1>;
> -	};
> -};
> -
> -led-controller@0 {
> -	compatible = "maxim,max77693-led";
> -
> -	led {
> -		function = LED_FUNCTION_FLASH;
> -		color = <LED_COLOR_ID_WHITE>;
> -		led-sources = <0>, <1>;
> -		led-max-microamp = <50000>;
> -		flash-max-microamp = <320000>;
> -		flash-max-timeout-us = <500000>;
> -	};
> -};
> -
> -led-controller@30 {
> -        compatible = "panasonic,an30259a";
> -        reg = <0x30>;
> -        #address-cells = <1>;
> -        #size-cells = <0>;
> -
> -        led@1 {
> -		reg = <1>;
> -		linux,default-trigger = "heartbeat";
> -		function = LED_FUNCTION_INDICATOR;
> -		function-enumerator = <1>;
> -        };
> -
> -        led@2 {
> -		reg = <2>;
> -		function = LED_FUNCTION_INDICATOR;
> -		function-enumerator = <2>;
> -        };
> -
> -        led@3 {
> -		reg = <3>;
> -		function = LED_FUNCTION_INDICATOR;
> -		function-enumerator = <3>;
> -        };
> -};
> +This file has moved to ./common.yaml.
> diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
> new file mode 100644
> index 000000000000..d97d099b87e5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/common.yaml
> @@ -0,0 +1,228 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/common.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common leds properties
> +
> +maintainers:
> +  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
> +  - Pavel Machek <pavel@ucw.cz>
> +
> +description:
> +  LED and flash LED devices provide the same basic functionality as current
> +  regulators, but extended with LED and flash LED specific features like
> +  blinking patterns, flash timeout, flash faults and external flash strobe mode.
> +
> +  Many LED devices expose more than one current output that can be connected
> +  to one or more discrete LED component. Since the arrangement of connections
> +  can influence the way of the LED device initialization, the LED components
> +  have to be tightly coupled with the LED device binding. They are represented
> +  by child nodes of the parent LED device binding.
> +
> +properties:
> +  led-sources:
> +    description:
> +      List of device current outputs the LED is connected to. The outputs are
> +      identified by the numbers that must be defined in the LED device binding
> +      documentation.
> +    $ref: /schemas/types.yaml#definitions/uint32-array
> +
> +  function:
> +    description:
> +      LED function. Use one of the LED_FUNCTION_* prefixed definitions
> +      from the header include/dt-bindings/leds/common.h. If there is no
> +      matching LED_FUNCTION available, add a new one.
> +    $ref: /schemas/types.yaml#definitions/string
> +
> +  color:
> +    description:
> +      Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions from
> +      the header include/dt-bindings/leds/common.h. If there is no matching
> +      LED_COLOR_ID available, add a new one.
> +    allOf:
> +      - $ref: /schemas/types.yaml#definitions/uint32
> +    minimum: 0
> +    maximum: 8
> +
> +  function-enumerator:
> +    description:
> +      Integer to be used when more than one instance of the same function is
> +      needed, differing only with an ordinal number.
> +    $ref: /schemas/types.yaml#definitions/uint32
> +
> +  label:
> +    description:
> +      The label for this LED. If omitted, the label is taken from the node name
> +      (excluding the unit address). It has to uniquely identify a device, i.e.
> +      no other LED class device can be assigned the same label. This property is
> +      deprecated - use 'function' and 'color' properties instead.
> +      function-enumerator has no effect when this property is present.
> +
> +  default-state:
> +    description:
> +      The initial state of the LED. If the LED is already on or off and the
> +      default-state property is set the to same value, then no glitch should be
> +      produced where the LED momentarily turns off (or on). The "keep" setting
> +      will keep the LED at whatever its current state is, without producing a
> +      glitch.
> +    allOf:
> +      - $ref: /schemas/types.yaml#definitions/string
> +    enum:
> +      - on
> +      - off
> +      - keep
> +    default: off
> +
> +  linux,default-trigger:
> +    description:
> +      This parameter, if present, is a string defining the trigger assigned to
> +      the LED.
> +    allOf:
> +      - $ref: /schemas/types.yaml#definitions/string
> +    enum:
> +        # LED will act as a back-light, controlled by the framebuffer system
> +      - backlight
> +        # LED will turn on (but for leds-gpio see "default-state" property in
> +        # Documentation/devicetree/bindings/leds/leds-gpio.txt)
> +      - default-on
> +        # LED "double" flashes at a load average based rate
> +      - heartbeat
> +        # LED indicates disk activity
> +      - disk-activity
> +        # LED indicates IDE disk activity (deprecated), in new implementations
> +        # use "disk-activity"
> +      - ide-disk
> +        # LED flashes at a fixed, configurable rate
> +      - timer
> +        # LED alters the brightness for the specified duration with one software
> +        # timer (requires "led-pattern" property)
> +      - pattern
> +
> +  led-pattern:
> +    description: |
> +      Array of integers with default pattern for certain triggers.
> +
> +      Each trigger may parse this property differently:
> +        - one-shot : two numbers specifying delay on and delay off (in ms),
> +        - timer : two numbers specifying delay on and delay off (in ms),
> +        - pattern : the pattern is given by a series of tuples, of
> +          brightness and duration (in ms).  The exact format is
> +          described in:
> +          Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
> +    allOf:
> +      - $ref: /schemas/types.yaml#definitions/uint32-matrix
> +    items:
> +      minItems: 2
> +      maxItems: 2
> +
> +  led-max-microamp:
> +    description:
> +      Maximum LED supply current in microamperes. This property can be made
> +      mandatory for the board configurations introducing a risk of hardware
> +      damage in case an excessive current is set.
> +      For flash LED controllers with configurable current this property is
> +      mandatory for the LEDs in the non-flash modes (e.g. torch or indicator).
> +
> +  panic-indicator:
> +    description:
> +      This property specifies that the LED should be used, if at all possible,
> +      as a panic indicator.
> +    type: boolean
> +
> +  trigger-sources:
> +    description: |
> +      List of devices which should be used as a source triggering this LED
> +      activity. Some LEDs can be related to a specific device and should somehow
> +      indicate its state. E.g. USB 2.0 LED may react to device(s) in a USB 2.0
> +      port(s).
> +      Another common example is switch or router with multiple Ethernet ports
> +      each of them having its own LED assigned (assuming they are not
> +      hardwired). In such cases this property should contain phandle(s) of
> +      related source device(s).
> +      In many cases LED can be related to more than one device (e.g. one USB LED
> +      vs. multiple USB ports). Each source should be represented by a node in
> +      the device tree and be referenced by a phandle and a set of phandle
> +      arguments. A length of arguments should be specified by the
> +      #trigger-source-cells property in the source node.
> +    $ref: /schemas/types.yaml#definitions/phandle-array
> +
> +  # Required properties for flash LED child nodes:
> +  flash-max-microamp:
> +    description:
> +      Maximum flash LED supply current in microamperes. Required for flash LED
> +      nodes with configurable current.
> +
> +  flash-max-timeout-us:
> +    description:
> +      Maximum timeout in microseconds after which the flash LED is turned off.
> +      Required for flash LED nodes with configurable timeout.
> +
> +examples:
> +  - |
> +    #include <dt-bindings/gpio/gpio.h>
> +    #include <dt-bindings/leds/common.h>
> +
> +    led-controller {
> +        compatible = "gpio-leds";
> +
> +        led0 {
> +            function = LED_FUNCTION_STATUS;
> +            linux,default-trigger = "heartbeat";
> +            gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> +        };
> +
> +        led1 {
> +            function = LED_FUNCTION_USB;
> +            gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> +            trigger-sources = <&ohci_port1>, <&ehci_port1>;
> +        };
> +    };
> +
> +    led-controller@0 {
> +        compatible = "maxim,max77693-led";
> +        reg = <0 0x100>;
> +
> +        led {
> +            function = LED_FUNCTION_FLASH;
> +            color = <LED_COLOR_ID_WHITE>;
> +            led-sources = <0>, <1>;
> +            led-max-microamp = <50000>;
> +            flash-max-microamp = <320000>;
> +            flash-max-timeout-us = <500000>;
> +        };
> +    };
> +
> +    i2c {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        led-controller@30 {
> +            compatible = "panasonic,an30259a";
> +            reg = <0x30>;
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            led@1 {
> +                reg = <1>;
> +                linux,default-trigger = "heartbeat";
> +                function = LED_FUNCTION_INDICATOR;
> +                function-enumerator = <1>;
> +            };
> +
> +            led@2 {
> +                reg = <2>;
> +                function = LED_FUNCTION_INDICATOR;
> +                function-enumerator = <2>;
> +            };
> +
> +            led@3 {
> +                reg = <3>;
> +                function = LED_FUNCTION_INDICATOR;
> +                function-enumerator = <3>;
> +            };
> +        };
> +    };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/leds/trigger-source.yaml b/Documentation/devicetree/bindings/leds/trigger-source.yaml
> new file mode 100644
> index 000000000000..0618003e40bd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/trigger-source.yaml
> @@ -0,0 +1,24 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/trigger-source.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Trigger source providers
> +
> +maintainers:
> +  - Jacek Anaszewski <jacek.anaszewski@gmail.com>
> +  - Pavel Machek <pavel@ucw.cz>
> +
> +description:
> +  Each trigger source provider should be represented by a device tree node. It
> +  may be e.g. a USB port or an Ethernet device.
> +
> +properties:
> +  '#trigger-source-cells':
> +    description:
> +      Number of cells in a source trigger. Typically 0 for nodes of simple
> +      trigger sources (e.g. a specific USB port).
> +    enum: [ 0, 1 ]
> +
> +...
> 

-- 
Best regards,
Jacek Anaszewski

Re: [PATCH v2 1/2] dt-bindings: leds: Convert common LED binding to schema

[Rob Herring]

On Wed, Jan 8, 2020 at 1:02 PM Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
>
> On 1/8/20 1:17 AM, Rob Herring wrote:
> > Convert the common LEDs properties bindings to a schema. As trigger source
> > providers are different nodes, we need to split trigger source properties
> > to a separate file.
> >
> > Bindings for LED controllers can reference the common schema for the LED
> > child nodes:
> >
> > patternProperties:
> >   "^led@[0-4]":
> >     type: object
> >     allOf:
> >       - $ref: common.yaml#
> >
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Dan Murphy <dmurphy@ti.com>
> > Cc: linux-leds@vger.kernel.org
> > Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> > Signed-off-by: Rob Herring <robh@kernel.org>
> > ---
> > Jacek, Please take this via led tree
>
> Currently Pavel maintains LED tree. Pavel?

As it doesn't look like there's any conflicts, I've applied this
series to the DT tree.

Rob

Re: [PATCH v2 1/2] dt-bindings: leds: Convert common LED binding to schema

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

Hi!

> > > Bindings for LED controllers can reference the common schema for the LED
> > > child nodes:
> > >
> > > patternProperties:
> > >   "^led@[0-4]":
> > >     type: object
> > >     allOf:
> > >       - $ref: common.yaml#
> > >
> > > Cc: Pavel Machek <pavel@ucw.cz>
> > > Cc: Dan Murphy <dmurphy@ti.com>
> > > Cc: linux-leds@vger.kernel.org
> > > Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> > > Signed-off-by: Rob Herring <robh@kernel.org>
> > > ---
> > > Jacek, Please take this via led tree
> >
> > Currently Pavel maintains LED tree. Pavel?
> 
> As it doesn't look like there's any conflicts, I've applied this
> series to the DT tree.

Thank you!
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]