On 01/25/2017 10:08 AM, Rafał Miłecki wrote:
> 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.
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
