Re: [PATCH 05/25] dt-bindings: leds: Add function and color properties

[Jacek Anaszewski]

On 3/11/19 6:24 PM, Jacek Anaszewski wrote:
> Dan,
>
> On 3/11/19 1:26 PM, Dan Murphy wrote:
> > On 3/10/19 1:28 PM, Jacek Anaszewski wrote:
> > > Introduce dedicated properties for conveying information about
> > > LED function and color. Mark old "label" property as deprecated.
> > >
> > > Signed-off-by: Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>
> > > Cc: Baolin Wang <baolin.wang@xxxxxxxxxx>
> > > Cc: Daniel Mack <daniel@xxxxxxxxxx>
> > > Cc: Dan Murphy <dmurphy@xxxxxx>
> > > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx>
> > > Cc: Oleh Kravchenko <oleg@xxxxxxxxxx>
> > > Cc: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
> > > Cc: Simon Shields <simon@xxxxxxxxxxxxx>
> > > ---
> > > Â Documentation/devicetree/bindings/leds/common.txt | 55 
> > > +++++++++++++++++++----
> > > Â 1 file changed, 47 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/leds/common.txt 
> > > b/Documentation/devicetree/bindings/leds/common.txt
> > > index aa1399814a2a..3402b0e1cec9 100644
> > > --- a/Documentation/devicetree/bindings/leds/common.txt
> > > +++ b/Documentation/devicetree/bindings/leds/common.txt
> > > @@ -10,14 +10,23 @@ can influence the way of the LED device 
> > > initialization, the LED components
> > > Â have to be tightly coupled with the LED device binding. They are 
> > > represented
> > > Â by child nodes of the parent LED device binding.
> > > +
> > > Â Optional properties for child nodes:
> > > Â - led-sources : List of device current outputs the LED is connected 
> > > to. The
> > > ÂÂÂÂÂÂÂÂÂ outputs are identified by the numbers that must be defined
> > > ÂÂÂÂÂÂÂÂÂ in the LED device binding documentation.
> > > +- function: LED functon. Use one of the LED_FUNCTION_* prefixed 
> > > definitions
> > > +ÂÂÂÂÂÂÂ from the header include/dt-bindings/leds/common.h.
> > > +ÂÂÂÂÂÂÂ If there is no matching LED_FUNCTION available, add a new one.
> > > +- color : Color of the LED. Use one of the LED_COLOR_NAME_* prefixed 
> > > definitions
> > > +ÂÂÂÂÂÂÂ from the header include/dt-bindings/leds/common.h.
> > > +ÂÂÂÂÂÂÂ If there is no matching LED_COLOR_NAME available, add a new 
> > > one.
> > > +
> >
> > I am assuming multi color can re-use this property as well?
>
> I intended it to be a string, but indeed it would be better if we will
> make it an integer to be consistent with the discussed LED multi color
> design.

Going further, I wonder if it would make sense to make function also
an integer. This way we could enforce use of LED functions known
to kernel.

Additionally, if we introduced a property like function-enum-val
(better name suggestions are welcome), then we could easily solve the
problem of string concatenation limitation in dtc compiler mentioned
in the cover letter, since the concatenation would be done in the LED core.

> > > Â - label : The label for this LED. If omitted, the label is taken 
> > > from the node
> > > ÂÂÂÂÂÂÂ name (excluding the unit address). It has to uniquely identify
> > > ÂÂÂÂÂÂÂ a device, i.e. no other LED class device can be assigned the 
> > > same
> > > -ÂÂÂÂÂ label.
> > > +ÂÂÂÂÂ label. This property is deprecated - use 'function' and 'color'
> > > +ÂÂÂÂÂ properties instead.
> > > Â - default-state : The initial state of the LED. Valid values are 
> > > "on", "off",
> > > ÂÂÂ and "keep". If the LED is already on or off and the default-state 
> > > property is
> > > @@ -87,29 +96,59 @@ Required properties for trigger source:
> > > Â * Examples
> > > -gpio-leds {
> > > +#include <dt-bindings/leds/common.h>
> > > +
> > > +led-controller@0 {
> > > ÂÂÂÂÂ compatible = "gpio-leds";
> > > -ÂÂÂ system-status {
> > > -ÂÂÂÂÂÂÂ label = "Status";
> > > +ÂÂÂ led0 {
> > > +ÂÂÂÂÂÂÂ function = LED_FUNCTION_STATUS;
> >
> > Missing color for example unless there is a reason to omit it for GPIO 
> > LEDs
>
> It is on purpose - to show that it is an optional property for
> monochrome LEDs.
>
> > Also missing reg here
>
> Also on purpose. leds-gpio bindings don't require reg here.
> And when reg is absent the unit address in the node name should
> be omitted as Rob stated in one of recent reviews.
>
> > > ÂÂÂÂÂÂÂÂÂ linux,default-trigger = "heartbeat";
> > > ÂÂÂÂÂÂÂÂÂ gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
> > > ÂÂÂÂÂ };
> > > -ÂÂÂ usb {
> > > +ÂÂÂ led1 {
> > > +ÂÂÂÂÂÂÂ function = LED_FUNCTION_USB;
> >
> > Same as above
> > Also missing reg here
> > > ÂÂÂÂÂÂÂÂÂ gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> > > ÂÂÂÂÂÂÂÂÂ trigger-sources = <&ohci_port1>, <&ehci_port1>;
> > > ÂÂÂÂÂ };
> > > Â };
> > > -max77693-led {
> > > +led-controller@0 {
> > > ÂÂÂÂÂ compatible = "maxim,max77693-led";
> > > -ÂÂÂ camera-flash {
> > > -ÂÂÂÂÂÂÂ label = "Flash";
> > > +ÂÂÂ led {
> > > +ÂÂÂÂÂÂÂ function = LED_FUNCTION_FLASH;
> > > +ÂÂÂÂÂÂÂ color = LED_COLOR_NAME_WHITE;
> > > ÂÂÂÂÂÂÂÂÂ led-sources = <0>, <1>;
> > > ÂÂÂÂÂÂÂÂÂ led-max-microamp = <50000>;
> > > ÂÂÂÂÂÂÂÂÂ flash-max-microamp = <320000>;
> > > ÂÂÂÂÂÂÂÂÂ flash-max-timeout-us = <500000>;
> > > ÂÂÂÂÂ };
> > > Â };
> > > +
> > > +led-controller@30 {
> > > +ÂÂÂÂÂÂÂ compatible = "panasonic,an30259a";
> > > +ÂÂÂÂÂÂÂ reg = <0x30>;
> > > +ÂÂÂÂÂÂÂ #address-cells = <1>;
> > > +ÂÂÂÂÂÂÂ #size-cells = <0>;
> > > +
> > > +ÂÂÂÂÂÂÂ led@1 {
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ reg = <1>;
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ linux,default-trigger = "heartbeat";
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ function = LED_FUNCTION_INDICATOR;
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ color = LED_COLOR_NAME_RED;
> > > +ÂÂÂÂÂÂÂ };
> > > +
> > > +ÂÂÂÂÂÂÂ led@2 {
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ reg = <2>;
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ function = LED_FUNCTION_INDICATOR;
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ color = LED_COLOR_NAME_GREEN;
> > > +ÂÂÂÂÂÂÂ };
> > > +
> > > +ÂÂÂÂÂÂÂ led@3 {
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ reg = <3>;
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ function = LED_FUNCTION_INDICATOR;
> > > +ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ color = LED_COLOR_NAME_BLUE;
> > > +ÂÂÂÂÂÂÂ };
> > > +};

--
Best regards,
Jacek Anaszewski