[1/4] dt-bindings: leds: document property for LED triggers

From: Rafał Miłecki <rafal@milecki.pl>

There was a long discussion on describing LED trigger sources in DT.
Few solutions were posted but neither was clear & flexible enough. It's
really hard to design DT bindings for a LED node that will allow
describing any kinds of triggers.

Finally Jacek suggested a different design. It involved using separated
DT node for each trigger.

This documentation follows that idea. It really simplifies DT bindings
and allows clear support for different trigger types. With this solution
every type can have its own specific properties.

Please note an example will be added later with the first supported
trigger bindings. The point is to have nodes like:
foo-trigger {
	trigger-type = "foo";
	...
};

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
 Documentation/devicetree/bindings/leds/common.txt   |  3 +++
 Documentation/devicetree/bindings/leds/triggers.txt | 13 +++++++++++++
 2 files changed, 16 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/triggers.txt

Hi Rafał,

Thanks for continuing this effort.

I think that it would be simpler if we could initially see
a complete sample dts implementation containing all required DT
nodes. The example could contain timer trigger as well as usb-port
trigger specific bindings.

I suppose that we should see DT nodes containing #list-cells
properties that define the quantity of phandle arguments.

It seems that this approach allows for defining a list of elements
with variable number of arguments, i.e. what you were initially
asking for.


Best regards,
Jacek Anaszewski

On 02/28/2017 01:04 PM, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> There was a long discussion on describing LED trigger sources in DT.
> Few solutions were posted but neither was clear & flexible enough. It's
> really hard to design DT bindings for a LED node that will allow
> describing any kinds of triggers.
> 
> Finally Jacek suggested a different design. It involved using separated
> DT node for each trigger.
> 
> This documentation follows that idea. It really simplifies DT bindings
> and allows clear support for different trigger types. With this solution
> every type can have its own specific properties.
> 
> Please note an example will be added later with the first supported
> trigger bindings. The point is to have nodes like:
> foo-trigger {
> 	trigger-type = "foo";
> 	...
> };
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
>  Documentation/devicetree/bindings/leds/common.txt   |  3 +++
>  Documentation/devicetree/bindings/leds/triggers.txt | 13 +++++++++++++
>  2 files changed, 16 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/triggers.txt
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
> index 696be5792625..0bc91556a47a 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -49,6 +49,9 @@ Optional properties for child nodes:
>  - panic-indicator : This property specifies that the LED should be used,
>  		    if at all possible, as a panic indicator.
>  
> +- triggers : List of nodes of triggers that should control this LED state. For
> +	     more details see triggers.txt.
> +
>  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
> diff --git a/Documentation/devicetree/bindings/leds/triggers.txt b/Documentation/devicetree/bindings/leds/triggers.txt
> new file mode 100644
> index 000000000000..a1fbf3a75d67
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/triggers.txt
> @@ -0,0 +1,13 @@
> +Common trigger properties.
> +
> +Triggers describe the way LEDs should be controlled, e.g. under what conditions
> +they should be turned on or off. Depending on a trigger type various events can
> +be used to determine a LED state. Some triggers can be hardware independent
> +(e.g. time based), some can react to a specific hardware events.
> +
> +Common properties:
> +- trigger-type : Type of a trigger. Choosing a trigger determines what kind of
> +		 events will be used to control LED. See specific trigger
> +		 documentation for more details.
> +
> +More properties can be available depending on the chosen trigger type.
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html