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

[Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

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-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> > 
> > 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-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
> > ---
> > 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.

> There is linux,default-trigger property which allows to define one
> trigger that will be initially assigned.
> 
> 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 not going to accept something specific to USB. So the choice is make 
the existing property work for USB or design something more flexible and 
generic.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html