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.
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
