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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html