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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux