| Message ID | 20180906135005.6718-1-dmurphy@ti.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v6,1/2] dt-bindings: leds: Add bindings for lm3697 driver | expand |
Hi! > >> index 000000000000..3256dec21075 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/leds/leds-lm3697.txt > >> @@ -0,0 +1,86 @@ > >> +* Texas Instruments - LM3697 Highly Efficient White LED Driver > >> + > >> +The LM3697 11-bit LED driver provides high- > >> +performance backlight dimming for 1, 2, or 3 series > >> +LED strings while delivering up to 90% efficiency. > > > > Hmm. We already have second set of bindings for 3697: > > > > ./devicetree/bindings/mfd/ti-lmu.txt > > > > (Sorry for not noticing that earlier). Advantage is that those have > > had discussion with device tree people and have acks: > > > > What to do there? > > UGH! IMO this should have not been accepted without the support code. > I think this MFD driver is complete over kill to try to commonize features > into a MFD device. The LM3631 and LM3632 seem to be the only true MFD devices > here since they provide regulator support. They are not yet in mainline; but they have Rob's acknowledges. ...but I see there are improvements possible. > The LM3697 fault monitoring is only for test purposes according to the data > sheet. Not sure the customer can trust this or they should be warned at boot > that the Fault monitoring is for test purposes only. Ok, but that's topic for the driver, not for binding, right? > And I think Jacek pointed out that the bindings references in this bindings > don't even exist. > > I am thinking we need to deprecate this MFD driver and consolidate these drivers > in the LED directory as we indicated before. I did not find any ti-lmu support > code. > > ti-lmu common core code and then the LED children appending the feature differentiation. > Need some maintainer weigh in here. Hehe. I'm maintnainer. Fun. Is there something obviously wrong with 287cce719d85311f61d1b6b7f7b0d93f7907cd46 + d774c7e447ac911e73a1b3c775e6d89f0422218c ? If not, as it already had discussion/Acks so I'd prefer that one. We may move it to LEDs directory if neccessary, or something like that... Best regards, Pavel > > commit 287cce719d85311f61d1b6b7f7b0d93f7907cd46 > > Author: Milo Kim <milo.kim@ti.com> > > Date: Tue Feb 28 15:45:14 2017 +0900 > > > > dt-bindings: mfd: Add TI LMU device binding information > > > > This patch describes overall binding for TI LMU MFD devices. > > > > Signed-off-by: Milo Kim <milo.kim@ti.com> > > Acked-by: Rob Herring <robh+dt@kernel.org> > > Acked-by: Tony Lindgren <tony@atomide.com> > > Signed-off-by: Lee Jones <lee.jones@linaro.org> > > > > > > commit d774c7e447ac911e73a1b3c775e6d89f0422218c > > Author: Sebastian Reichel <sebastian.reichel@collabora.co.uk> > > Date: Mon Aug 27 09:15:08 2018 -0700 > > > > dt-bindings: mfd: ti-lmu: update for backlight > > > > Update binding to integrate the backlight feature directly into > > the main node, as suggested by Rob Herring. > > > > Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk> > > > > diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt b/Documentation/devicetree/bindings/mfd/ti-lmu.txt > > index c885cf8..b3433e9 100644 > > --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt > > +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt > > @@ -28,10 +28,9 @@ Required properties: > > > > Optional property: > > - enable-gpios: A GPIO specifier for hardware enable pin. > > - > > -Required node: > > - - backlight: All LMU devices have backlight child nodes. > > - For the properties, please refer to [1]. > > + - pwm-names: Should be either "lmu-backlight" or unset > > + - pwm: This should be a PWM specifier following ../pwm/pwm.txt and must > > + only be specified, if the backlight should be used in PWM mode. > > > > Optional nodes: > > - fault-monitor: Hardware fault monitoring driver for LM3633 and LM3697. > > @@ -42,8 +41,31 @@ Optional nodes: > > - leds: LED properties for LM3633. Please refer to [2]. > > - regulators: Regulator properties for LM3631 and LM3632. > > Please refer to [3]. > > + - bank0, bank1, bank2: This contains the backlight configuration > > + for each backlight control bank. > > + > > +Required properties in the bank subnodes: > > + - label: A string describing the backlight. Should contain "keyboard" > > + for a keyboard backlight and "lcd" for LCD panel backlights. > > + - ti,led-sources: A list of channels, that should be driven. Each channel > > + should only be driven by one bank. > > + > > +Optional properties in the bank subnodes: > > + - default-brightness-level: Backlight initial brightness value. > > + Type is <u32>. It is set as soon as backlight > > + device is created. > > + 0 ~ 2047 = LM3631, LM3632, LM3633, LM3695 and > > + LM3697 > > + 0 ~ 255 = LM3532 > > + - ti,ramp-up-ms, ti,ramp-down-ms: Light dimming effect properties. > > + Type is <u32>. Unit is millisecond. > > + 0 ~ 65 ms = LM3532 > > + 0 ~ 4000 ms = LM3631 > > + 0 ~ 16000 ms = LM3633 and LM3697 > > + - pwm-period: PWM period. Only valid in PWM brightness mode. > > + Type is <u32>. If this property is missing, then control > > + mode is set to I2C by default. > > > > -[1] ../leds/backlight/ti-lmu-backlight.txt > > [2] ../leds/leds-lm3633.txt > > [3] ../regulator/lm363x-regulator.txt > > > > @@ -53,14 +75,11 @@ lm3532@38 { > > > > enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>; > > > > - backlight { > > - compatible = "ti,lm3532-backlight"; > > - > > - lcd { > > - led-sources = <0 1 2>; > > - ramp-up-msec = <30>; > > - ramp-down-msec = <0>; > > - }; > > + bank0 { > > + label = "lcd"; > > + led-sources = <0 1 2>; > > + ramp-up-msec = <30>; > > + ramp-down-msec = <0>; > > }; > > }; > > > > @@ -105,13 +124,10 @@ lm3631@29 { > > }; > > }; > > > > - backlight { > > - compatible = "ti,lm3631-backlight"; > > - > > - lcd_bl { > > - led-sources = <0 1>; > > - ramp-up-msec = <300>; > > - }; > > + bank0 { > > + label = "lcd_bl"; > > + led-sources = <0 1>; > > + ramp-up-msec = <300>; > > }; > > }; > > > > @@ -147,16 +163,13 @@ lm3632@11 { > > }; > > }; > > > > - backlight { > > - compatible = "ti,lm3632-backlight"; > > - > > - pwms = <&pwm0 0 10000 0>; /* pwm number, period, polarity */ > > - pwm-names = "lmu-backlight"; > > + pwms = <&pwm0 0 10000 0>; /* pwm number, period, polarity */ > > + pwm-names = "lmu-backlight"; > > > > - lcd { > > - led-sources = <0 1>; > > - pwm-period = <10000>; > > - }; > > + bank0 { > > + label = "lcd"; > > + led-sources = <0 1>; > > + pwm-period = <10000>; > > }; > > }; > > > > @@ -166,22 +179,18 @@ lm3633@36 { > > > > enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>; > > > > - backlight { > > - compatible = "ti,lm3633-backlight"; > > - > > - main { > > - label = "main_lcd"; > > - led-sources = <1 2>; > > - ramp-up-msec = <500>; > > - ramp-down-msec = <500>; > > - }; > > + bank0 { > > + label = "main_lcd"; > > + led-sources = <1 2>; > > + ramp-up-msec = <500>; > > + ramp-down-msec = <500>; > > + }; > > > > - front { > > - label = "front_lcd"; > > - led-sources = <0>; > > - ramp-up-msec = <1000>; > > - ramp-down-msec = <0>; > > - }; > > + bank1 { > > + label = "front_lcd"; > > + led-sources = <0>; > > + ramp-up-msec = <1000>; > > + ramp-down-msec = <0>; > > }; > > > > leds { > > @@ -211,13 +220,9 @@ lm3695@63 { > > > > enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>; > > > > - backlight { > > - compatible = "ti,lm3695-backlight"; > > - > > - lcd { > > - label = "bl"; > > - led-sources = <0 1>; > > - }; > > + bank0 { > > + label = "lcd_bl"; > > + led-sources = <0 1>; > > }; > > }; > > > > @@ -227,14 +232,10 @@ lm3697@36 { > > > > enable-gpios = <&pioC 2 GPIO_ACTIVE_HIGH>; > > > > - backlight { > > - compatible = "ti,lm3697-backlight"; > > - > > - lcd { > > - led-sources = <0 1 2>; > > - ramp-up-msec = <200>; > > - ramp-down-msec = <200>; > > - }; > > + bank0 { > > + led-sources = <0 1 2>; > > + ramp-up-msec = <200>; > > + ramp-down-msec = <200>; > > }; > > > > fault-monitor { > > > > -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Dan, On 09/07/2018 03:52 PM, Dan Murphy wrote: [...] >> >>> And I think Jacek pointed out that the bindings references in this bindings >>> don't even exist. >>> >>> I am thinking we need to deprecate this MFD driver and consolidate these drivers >>> in the LED directory as we indicated before. I did not find any ti-lmu support >>> code. >>> >>> ti-lmu common core code and then the LED children appending the feature differentiation. >> >>> Need some maintainer weigh in here. >> >> Hehe. I'm maintnainer. Fun. > > I know. I want to see if there was any other opinion. Especially for the LED driver. > [...] I have a question - is this lm3697 LED controller a cell of some MFD device? Or is it a self-contained chip? -- Best regards, Jacek Anaszewski
On Sat 2018-09-08 21:53:00, Jacek Anaszewski wrote: > Dan, > > On 09/07/2018 03:52 PM, Dan Murphy wrote: > [...] > >> > >>> And I think Jacek pointed out that the bindings references in this bindings > >>> don't even exist. > >>> > >>> I am thinking we need to deprecate this MFD driver and consolidate these drivers > >>> in the LED directory as we indicated before. I did not find any ti-lmu support > >>> code. > >>> > >>> ti-lmu common core code and then the LED children appending the feature differentiation. > >> > >>> Need some maintainer weigh in here. > >> > >> Hehe. I'm maintnainer. Fun. > > > > I know. I want to see if there was any other opinion. Especially for the LED driver. > > > [...] > > I have a question - is this lm3697 LED controller a cell of some MFD > device? Or is it a self-contained chip? lm3697 is number for stand-alone device, but same hardware seems to be embedded into multi-functional chips, with other numbers in lm36xx series. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Dan, Pavel, On 09/10/2018 04:37 PM, Dan Murphy wrote: > Jacek > > On 09/08/2018 02:53 PM, Jacek Anaszewski wrote: >> Dan, >> >> On 09/07/2018 03:52 PM, Dan Murphy wrote: >> [...] >>>> >>>>> And I think Jacek pointed out that the bindings references in this bindings >>>>> don't even exist. >>>>> >>>>> I am thinking we need to deprecate this MFD driver and consolidate these drivers >>>>> in the LED directory as we indicated before. I did not find any ti-lmu support >>>>> code. >>>>> >>>>> ti-lmu common core code and then the LED children appending the feature differentiation. >>>> >>>>> Need some maintainer weigh in here. >>>> >>>> Hehe. I'm maintnainer. Fun. >>> >>> I know. I want to see if there was any other opinion. Especially for the LED driver. >>> >> [...] >> >> I have a question - is this lm3697 LED controller a cell of some MFD >> device? Or is it a self-contained chip? >> > > This is a self contained chip. And the LM3697 only function is a LED driver. > It does not have any other special functions like the LM363X drivers for GPIO and Regulator support. This is an argument for merging it as a standalone LED class driver then. It is even more justifiable, taking into account uncertainties related to the proper way of adding the support for it to the existing MFD driver, whereas the code reuse would be the only advantage of having thus support in MFD subsystem. -- Best regards, Jacek Anaszewski
Dan, On 09/10/2018 09:51 PM, Dan Murphy wrote: > Jacek > > On 09/10/2018 02:07 PM, Jacek Anaszewski wrote: >> Dan, Pavel, >> >> On 09/10/2018 04:37 PM, Dan Murphy wrote: >>> Jacek >>> >>> On 09/08/2018 02:53 PM, Jacek Anaszewski wrote: >>>> Dan, >>>> >>>> On 09/07/2018 03:52 PM, Dan Murphy wrote: >>>> [...] >>>>>> >>>>>>> And I think Jacek pointed out that the bindings references in this bindings >>>>>>> don't even exist. >>>>>>> >>>>>>> I am thinking we need to deprecate this MFD driver and consolidate these drivers >>>>>>> in the LED directory as we indicated before. I did not find any ti-lmu support >>>>>>> code. >>>>>>> >>>>>>> ti-lmu common core code and then the LED children appending the feature differentiation. >>>>>> >>>>>>> Need some maintainer weigh in here. >>>>>> >>>>>> Hehe. I'm maintnainer. Fun. >>>>> >>>>> I know. I want to see if there was any other opinion. Especially for the LED driver. >>>>> >>>> [...] >>>> >>>> I have a question - is this lm3697 LED controller a cell of some MFD >>>> device? Or is it a self-contained chip? >>>> >>> >>> This is a self contained chip. And the LM3697 only function is a LED driver. >>> It does not have any other special functions like the LM363X drivers for GPIO and Regulator support. >> >> This is an argument for merging it as a standalone LED class driver >> then. It is even more justifiable, taking into account uncertainties >> related to the proper way of adding the support for it to the existing >> MFD driver, whereas the code reuse would be the only advantage of having >> thus support in MFD subsystem. >> > > Does the argument carry over to the other devices? If we want to be consequent - yes. > Like the LM3632 (part of the ti-lmu) has flash and torch and no other special functions > so it would look like the lm3601x family with different register mappings. Yes, this is obvious candidate for LED class flash driver. > The LM3631 seems to also be just a LED driver with no extra functionality > > I could go buy an EVM and put together a driver for that device as well using the lm3601x as > reference. I'm not going to encourage you to make this expense, but to put it politically - I'd happily welcome those drivers in the LED subsystem ;-) -- Best regards, Jacek Anaszewski
Jacek On 09/11/2018 01:27 PM, Jacek Anaszewski wrote: > Dan, > > On 09/10/2018 09:51 PM, Dan Murphy wrote: >> Jacek >> >> On 09/10/2018 02:07 PM, Jacek Anaszewski wrote: >>> Dan, Pavel, >>> >>> On 09/10/2018 04:37 PM, Dan Murphy wrote: >>>> Jacek >>>> >>>> On 09/08/2018 02:53 PM, Jacek Anaszewski wrote: >>>>> Dan, >>>>> >>>>> On 09/07/2018 03:52 PM, Dan Murphy wrote: >>>>> [...] >>>>>>> >>>>>>>> And I think Jacek pointed out that the bindings references in this bindings >>>>>>>> don't even exist. >>>>>>>> >>>>>>>> I am thinking we need to deprecate this MFD driver and consolidate these drivers >>>>>>>> in the LED directory as we indicated before. I did not find any ti-lmu support >>>>>>>> code. >>>>>>>> >>>>>>>> ti-lmu common core code and then the LED children appending the feature differentiation. >>>>>>> >>>>>>>> Need some maintainer weigh in here. >>>>>>> >>>>>>> Hehe. I'm maintnainer. Fun. >>>>>> >>>>>> I know. I want to see if there was any other opinion. Especially for the LED driver. >>>>>> >>>>> [...] >>>>> >>>>> I have a question - is this lm3697 LED controller a cell of some MFD >>>>> device? Or is it a self-contained chip? >>>>> >>>> >>>> This is a self contained chip. And the LM3697 only function is a LED driver. >>>> It does not have any other special functions like the LM363X drivers for GPIO and Regulator support. >>> >>> This is an argument for merging it as a standalone LED class driver >>> then. It is even more justifiable, taking into account uncertainties >>> related to the proper way of adding the support for it to the existing >>> MFD driver, whereas the code reuse would be the only advantage of having >>> thus support in MFD subsystem. >>> >> >> Does the argument carry over to the other devices? > > If we want to be consequent - yes. > >> Like the LM3632 (part of the ti-lmu) has flash and torch and no other special functions >> so it would look like the lm3601x family with different register mappings. > > Yes, this is obvious candidate for LED class flash driver. > >> The LM3631 seems to also be just a LED driver with no extra functionality >> >> I could go buy an EVM and put together a driver for that device as well using the lm3601x as >> reference. > > I'm not going to encourage you to make this expense, but to put it > politically - I'd happily welcome those drivers in the LED subsystem ;-) > Understood. I am waiting on hardware to test. Dan -- ------------------ Dan Murphy
Hi! > >>>>>> And I think Jacek pointed out that the bindings references in this bindings > >>>>>> don't even exist. > >>>>>> > >>>>>> I am thinking we need to deprecate this MFD driver and consolidate these drivers > >>>>>> in the LED directory as we indicated before. I did not find any ti-lmu support > >>>>>> code. > >>>>>> > >>>>>> ti-lmu common core code and then the LED children appending the feature differentiation. > >>>>> > >>>>>> Need some maintainer weigh in here. > >>>>> > >>>>> Hehe. I'm maintnainer. Fun. > >>>> > >>>> I know. I want to see if there was any other opinion. Especially for the LED driver. > >>>> > >>> [...] > >>> > >>> I have a question - is this lm3697 LED controller a cell of some MFD > >>> device? Or is it a self-contained chip? > >>> > >> > >> This is a self contained chip. And the LM3697 only function is a LED driver. > >> It does not have any other special functions like the LM363X drivers for GPIO and Regulator support. > > > > This is an argument for merging it as a standalone LED class driver > > then. It is even more justifiable, taking into account uncertainties > > related to the proper way of adding the support for it to the existing > > MFD driver, whereas the code reuse would be the only advantage of having > > thus support in MFD subsystem. > > Does the argument carry over to the other devices? We really need something reasonable, that works for stand-alone LEDs, and also works for LEDs that are part of MFD when the hardware is similar. > Like the LM3632 (part of the ti-lmu) has flash and torch and no other special functions > so it would look like the lm3601x family with different register mappings. > > The LM3631 seems to also be just a LED driver with no extra functionality > > I could go buy an EVM and put together a driver for that device as well using the lm3601x as > reference. I do have hardware with lm3532. I can test patches, and I guess I can port driver easily if it is obvious how to do that. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 09/11/2018 03:55 PM, Pavel Machek wrote: > Hi! > >>>>>>>> And I think Jacek pointed out that the bindings references in this bindings >>>>>>>> don't even exist. >>>>>>>> >>>>>>>> I am thinking we need to deprecate this MFD driver and consolidate these drivers >>>>>>>> in the LED directory as we indicated before. I did not find any ti-lmu support >>>>>>>> code. >>>>>>>> >>>>>>>> ti-lmu common core code and then the LED children appending the feature differentiation. >>>>>>> >>>>>>>> Need some maintainer weigh in here. >>>>>>> >>>>>>> Hehe. I'm maintnainer. Fun. >>>>>> >>>>>> I know. I want to see if there was any other opinion. Especially for the LED driver. >>>>>> >>>>> [...] >>>>> >>>>> I have a question - is this lm3697 LED controller a cell of some MFD >>>>> device? Or is it a self-contained chip? >>>>> >>>> >>>> This is a self contained chip. And the LM3697 only function is a LED driver. >>>> It does not have any other special functions like the LM363X drivers for GPIO and Regulator support. >>> >>> This is an argument for merging it as a standalone LED class driver >>> then. It is even more justifiable, taking into account uncertainties >>> related to the proper way of adding the support for it to the existing >>> MFD driver, whereas the code reuse would be the only advantage of having >>> thus support in MFD subsystem. >> >> Does the argument carry over to the other devices? > > We really need something reasonable, that works for stand-alone LEDs, > and also works for LEDs that are part of MFD when the hardware is similar. I agree that LED drivers that have other functional blocks beyond driving a LED chain belongs in the MFD space. The amount of code that is similar is very small. And like I pointed out Droid 4 may be only one use case where it makes sense to combine all the LED code into a central place. But most customers will just want a LED specific driver to maintain. > >> Like the LM3632 (part of the ti-lmu) has flash and torch and no other special functions >> so it would look like the lm3601x family with different register mappings. >> >> The LM3631 seems to also be just a LED driver with no extra functionality >> >> I could go buy an EVM and put together a driver for that device as well using the lm3601x as >> reference. > > I do have hardware with lm3532. I can test patches, and I guess I can > port driver easily if it is obvious how to do that. I can get the LM3532 EVM. I wrote a similar driver for the original Droid 10 years ago. Upstreaming was not a priority for that company. Here is a reference to the LM3530 code from back in the day on Google OMAP kernel. https://android.googlesource.com/kernel/omap/+/android-omap-3.0/drivers/leds/leds-lm3530.c Otherwise I can create the LM3532 driver as well and look at the LM3530 Dan > > Pavel > -- ------------------ Dan Murphy
diff --git a/Documentation/devicetree/bindings/leds/leds-lm3697.txt b/Documentation/devicetree/bindings/leds/leds-lm3697.txt new file mode 100644 index 000000000000..3256dec21075 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-lm3697.txt @@ -0,0 +1,86 @@ +* Texas Instruments - LM3697 Highly Efficient White LED Driver + +The LM3697 11-bit LED driver provides high- +performance backlight dimming for 1, 2, or 3 series +LED strings while delivering up to 90% efficiency. + +This device is suitable for display and keypad Lighting + +Required properties: + - compatible: + "ti,lm3967" + - reg : I2C slave address + - #address-cells : 1 + - #size-cells : 0 + +Optional properties: + - enable-gpios : GPIO pin to enable/disable the device + - vled-supply : LED supply + +Required child properties: + - reg : 0 - LED is Controlled by bank A + 1 - LED is Controlled by bank B + - led-sources : Indicates which HVLED string is associated to which + control bank. Each element in the array is associated + with a specific HVLED string. Element 0 is HVLED1, + element 1 is HVLED2 and element 2 HVLED3. + Additional information is contained + in Documentation/devicetree/bindings/leds/common.txt + 0 - HVLED is not active in this control bank + 1 - HVLED string is controlled by this control bank + +Optional child properties: + - label : see Documentation/devicetree/bindings/leds/common.txt + - linux,default-trigger : + see Documentation/devicetree/bindings/leds/common.txt + +Example: + +HVLED string 1 and 3 are controlled by control bank A and HVLED 2 string is +controlled by control bank B. + +led-controller@36 { + compatible = "ti,lm3967"; + reg = <0x36>; + #address-cells = <1>; + #size-cells = <0>; + + enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; + vled-supply = <&vbatt>; + + led@0 { + reg = <0>; + led-sources = <1 0 1>; + label = "white:first_backlight_cluster"; + linux,default-trigger = "backlight"; + }; + + led@1 { + reg = <1>; + led-sources = <0 1 0>; + label = "white:second_backlight_cluster"; + linux,default-trigger = "backlight"; + }; +} + +All HVLED strings controlled by control bank A + +led-controller@36 { + compatible = "ti,lm3967"; + reg = <0x36>; + #address-cells = <1>; + #size-cells = <0>; + + enable-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; + vled-supply = <&vbatt>; + + led@0 { + reg = <0>; + led-sources = <1 1 1>; + label = "white:backlight_cluster"; + linux,default-trigger = "backlight"; + }; +} + +For more product information please see the link below: +http://www.ti.com/lit/ds/symlink/lm3697.pdf
Add the device tree bindings for the lm3697 LED driver for backlighting and display. Signed-off-by: Dan Murphy <dmurphy@ti.com> --- v6 - Fix minor issues - https://lore.kernel.org/patchwork/patch/975387/ v5 - Fix the comment for the example - https://lore.kernel.org/patchwork/patch/975060/ v4 - Removed HVLED definition in favor of HVLED place definition - https://lore.kernel.org/patchwork/patch/974812/ v3 - Updated subject with prefered title - https://lore.kernel.org/patchwork/patch/972337/ v2 - Fixed subject and patch commit message - https://lore.kernel.org/patchwork/patch/971326/ .../devicetree/bindings/leds/leds-lm3697.txt | 86 +++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3697.txt -- 2.17.0.1855.g63749b2dea