On 01/23/2017 05:45 PM, Rob Herring wrote:
On Fri, Jan 20, 2017 at 11:35:20PM +0100, Jacek Anaszewski wrote:
Hi Rafał,
On 01/20/2017 10:56 PM, Rafał Miłecki wrote:
From: Rafał Miłecki <rafal@xxxxxxxxxx>
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 <rafal@xxxxxxxxxx>
---
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.
Saying that thanks Rob for rejecting my initial "usb-ports" property try :P
