Re: [PATCH V2 1/2] dt-bindings: leds: document new led-triggers property

On 01/25/2017 10:08 AM, Rafał Miłecki wrote:

On 01/23/2017 05:45 PM, Rob Herring wrote:

quoted

On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:

quoted

Hi Rafał,

On 01/20/2017 10:56 PM, Rafał Miłecki wrote:

quoted

From: Rafał Miłecki <redacted>

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

Signed-off-by: Rafał Miłecki <redacted>
---
V2: Replace "usb-ports" with "led-triggers" property which is more
generic and
    allows specifying other devices as well.

When bindings patch is related to some followup implementation, they
usually go
through the same tree.

Greg: this patch is based on top of e64b8cc72bf9 ("DT: leds: Improve
examples by
adding some context") from kernel/git/j.anaszewski/linux-leds.git .
Is there any
way to solve this dependency issue? Or should this patch wait until
3.11 is
released?
---
 Documentation/devicetree/bindings/leds/common.txt | 16
++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/common.txt

b/Documentation/devicetree/bindings/leds/common.txt
index 24b656014089..17632a041196 100644

--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt

@@ -49,6 +49,17 @@ Optional properties for child nodes:
 - panic-indicator : This property specifies that the LED should be

used,
             if at all possible, as a panic indicator.

+- led-triggers : List of devices that should trigger 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 (assuminled-trigger-usbportg they are not
hardwired).
+         In such cases this property should contain phandle(s) of
+         related 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 entries can be specified.
+

This implies that it is possible to define multiple triggers for
a LED class device but it is not supported by LED Trigger core.

Not really relevant for designing (and future proofing) a binding.

This is what I really like in this "led-triggers" property: it's future
proof. I
will be able to reuse it in other trigger drivers and I won't be trying
to sneak
properties like
* usb-port-triggers
* net-interface-triggers
* cpu-triggers
etc.

Very well, but led-triggers in this approach are not LED trigger drivers
but sources of events. Therefore I proposed trigger-sources.

Saying that thanks Rob for rejecting my initial "usb-ports" property try :P
.

-- 
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html