On 20 January 2017 at 23:35, Jacek Anaszewski
<jacek.anaszewski@xxxxxxxxx> wrote:
> 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.
> There is linux,default-trigger property which allows to define one
> trigger that will be initially assigned.
I think we owe some extra explanation to people not closely familiar
with the triggers.
Linux has multiple trigger drivers each supporting some *type* of
events. Linux supports assigning only one trigger driver to LED at a
time.
This means you can use e.g.:
1) "usbport" trigger driver that supports USB events
XOR
2) "timer" trigger driver that uses timer to control LED
XOR
3) "cpu" trigger driver that supports CPU events
at once.
With proposed "led-triggers" property one could assign different
trigger *sources* to a LED. You could e.g. assign 2 USB ports, network
device & CPU to a single LED. For reason explained above Linux
couldn't support all of them at once.
> I am aware that this is renamed usb-ports property from v1,
> that attempts to address Rob's comment, but we can't do that this way.
> Maybe usb-ports property could be documented in led-trigger-usbport's
> specific bindings and a reference to it could be added next to the
> related entry on the list of the available LED triggers (which is
> actually missing) in Documentation/devicetree/bindings/leds/common.txt.
I'm wondering if we need to care about this Linux limitation and if it
should stop us from adding this flexible DT property. Maybe we could
live with Linux having limitation of supporting one trigger type at a
time? So e.g. if one assigns 2 USB ports + network device + CPU and
decides to use "usport" trigger driver he'll get LED indicating status
of USB ports only.
I think we could live with such limitation in Linux support for this
generic "led-triggers" property. I think it's also not very common to
have LED with different types of devices assigned. Personally I've
never seen devices with LED label "USB & CPU" or whatever.
What do you think about this? Maybe we could also document this
limitation in trigger docs.
