Re: [PATCH V4 1/2] dt-bindings: leds: document new trigger-sources property

[Rob Herring]

On Tue, May 30, 2017 at 11:27:04AM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Some LEDs can be related to a specific device(s) described in the DT.
> This property allows specifying such relations. E.g. USB LED should
> usually be used to indicate some USB port(s) state.
> 
> Please note this binding is designed to be generic and not influenced by
> any operating system design. Linux developers may find "trigger" part a
> bit confusing since in Linux triggers are separated drivers. It
> shouldn't define the binding though (we shouldn't add an extra level of
> indirection).
> 
> Signed-off-by: Rafał Miłecki 
> ---
> V2: Replace "usb-ports" with "led-triggers" property which is more generic and
> allows specifying other devices as well.
> V3: Use "trigger-sources" which is even more accurate as devices aren't
> precisely triggers.
> V4: Update example to use the correct property
> ---
>  Documentation/devicetree/bindings/leds/common.txt | 18 ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/leds/common.txt 
> b/Documentation/devicetree/bindings/leds/common.txt
> index 24b656014089..7efaa2cff624 100644
> --- a/Documentation/devicetree/bindings/leds/common.txt
> +++ b/Documentation/devicetree/bindings/leds/common.txt
> @@ -49,6 +49,19 @@ Optional properties for child nodes:
>  - 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) so a list of
> + sources can be specified.
> +

Where's #source-cells documented?

I really prefer if we have consistency in naming with "s" and 
"#-cells". #source-cells is also not very clear what it is for. 

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

[PATCH V4 1/2] dt-bindings: leds: document new trigger-sources property

[Rafał Miłecki]

From: Rafał Miłecki 

Some LEDs can be related to a specific device(s) described in the DT.
This property allows specifying such relations. E.g. USB LED should
usually be used to indicate some USB port(s) state.

Please note this binding is designed to be generic and not influenced by
any operating system design. Linux developers may find "trigger" part a
bit confusing since in Linux triggers are separated drivers. It
shouldn't define the binding though (we shouldn't add an extra level of
indirection).

Signed-off-by: Rafał Miłecki 
---
V2: Replace "usb-ports" with "led-triggers" property which is more generic and
allows specifying other devices as well.
V3: Use "trigger-sources" which is even more accurate as devices aren't
precisely triggers.
V4: Update example to use the correct property
---
 Documentation/devicetree/bindings/leds/common.txt | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt 
b/Documentation/devicetree/bindings/leds/common.txt
index 24b656014089..7efaa2cff624 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -49,6 +49,19 @@ Optional properties for child nodes:
 - 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) so a list of
+   sources can be specified.
+
 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
@@ -69,6 +82,11 @@ gpio-leds {
linux,default-trigger = "heartbeat";
gpios = < 0 GPIO_ACTIVE_HIGH>;
};
+
+   usb {
+   gpios = < 1 GPIO_ACTIVE_HIGH>;
+   trigger-sources = <_port1>, <_port1>;
+   };
 };
 
 max77693-led {
-- 
2.11.0

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