[v2,2/7] dt: bindings: Add multicolor class dt bindings documention
diff mbox series

Message ID 20190411193848.23140-3-dmurphy@ti.com
State Changes Requested
Headers show
Series
  • Multicolor Framework
Related show

Checks

Context Check Description
robh/checkpatch warning "total: 4 errors, 0 warnings, 150 lines checked"

Commit Message

Dan Murphy April 11, 2019, 7:38 p.m. UTC
Add DT bindings for the LEDs multicolor class framework.

Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
 .../devicetree/bindings/leds/common.txt       |   2 +
 .../bindings/leds/leds-class-multicolor.txt   | 142 ++++++++++++++++++
 2 files changed, 144 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.txt

Comments

Marek Behun April 11, 2019, 10:07 p.m. UTC | #1
Hi Dan,
this probaly was discussed, but I did not follow brightness model
discussions:
what will happen if I set yellow by writing into yellow mode
brightness, and then orange by writing orange model brightness?
Will the resulting color be a mix of yellow and orange, or will the
orange overwrite the yellow setting?

Marek
Dan Murphy April 12, 2019, 11:50 a.m. UTC | #2
Marek

On 4/11/19 5:07 PM, Marek Behun wrote:
> Hi Dan,
> this probaly was discussed, but I did not follow brightness model
> discussions:
> what will happen if I set yellow by writing into yellow mode
> brightness, and then orange by writing orange model brightness?
> Will the resulting color be a mix of yellow and orange, or will the
> orange overwrite the yellow setting?
> 

This was not discussed and is a good question.  If you write the yellow mode for a group of
LEDs then yellow would be produced for the brightness requested.

If orange is then requested then orange should be displayed at the brightness level requested.
So yes the orange will over write the yellow.

The next question is if the absolute colors are written does it produce the same behavior?

So if you have yellow and write to the red should the red LED brightness be modified or should the
color switch to red?
And if the red LED is on and the blue LED is written should the color switch to blue or should the blue and red LEDs be mixed together?

This is tricky as the user space can write the individual absolute colors and mix the LEDs to produce varying
colors.  But the behavior writing the brightness models are different.

I would almost prefer that the user space reads the available absolute LED colors and creates the devices supported color palette and write the absolute LED colors only.  But this violates the requirements asked for.

Dan

> Marek
>
Jacek Anaszewski April 12, 2019, 6:14 p.m. UTC | #3
Hi Marek,

On 4/12/19 12:07 AM, Marek Behun wrote:
> Hi Dan,
> this probaly was discussed, but I did not follow brightness model
> discussions:
> what will happen if I set yellow by writing into yellow mode
> brightness, and then orange by writing orange model brightness?
> Will the resulting color be a mix of yellow and orange, or will the
> orange overwrite the yellow setting?

Orange will overwrite yellow settings. When color name is given
it should be treated as a hue. Then changing brightness level
should affect the lightness of a hue, similarly like changing
L component of HSL color model. This will be however entirely
up to DT brightness-model designer how they will design their models.
We are not going to verify that in the LED multi color class.

It implies that it will be possible to define arbitrary range
of color levels, not necessarily adhering to any established color
model. I think it could be useful to define brightness model
that allows to go from blue color (for cold) up to red (hot)
for representing a temperature for instance.

These ideas will need however more documentation. Generally
we aim to propose only a convention.
Dan Murphy April 12, 2019, 6:46 p.m. UTC | #4
Jacek

On 4/12/19 1:14 PM, Jacek Anaszewski wrote:
> Hi Marek,
> 
> On 4/12/19 12:07 AM, Marek Behun wrote:
>> Hi Dan,
>> this probaly was discussed, but I did not follow brightness model
>> discussions:
>> what will happen if I set yellow by writing into yellow mode
>> brightness, and then orange by writing orange model brightness?
>> Will the resulting color be a mix of yellow and orange, or will the
>> orange overwrite the yellow setting?
> 
> Orange will overwrite yellow settings. When color name is given
> it should be treated as a hue. Then changing brightness level
> should affect the lightness of a hue, similarly like changing
> L component of HSL color model. This will be however entirely
> up to DT brightness-model designer how they will design their models.
> We are not going to verify that in the LED multi color class.
> 
> It implies that it will be possible to define arbitrary range
> of color levels, not necessarily adhering to any established color
> model. I think it could be useful to define brightness model
> that allows to go from blue color (for cold) up to red (hot)
> for representing a temperature for instance.
> 
> These ideas will need however more documentation. Generally
> we aim to propose only a convention.
> 

Ah but what about the issue of writing the monochrome LED color.  With your description
it implies that when we write the red LED, the red LED will come on and if we write the blue
LED then the red LED in theory should turn off and the blue come on.

But these could be used to mix the colors to create some abstract violet that is not defined in the brightness
model.  Why should the brightness models and monochrome LEDs have two different operations.

Dan
Jacek Anaszewski April 12, 2019, 7:10 p.m. UTC | #5
Dan,

On 4/12/19 1:50 PM, Dan Murphy wrote:
> Marek
> 
> On 4/11/19 5:07 PM, Marek Behun wrote:
>> Hi Dan,
>> this probaly was discussed, but I did not follow brightness model
>> discussions:
>> what will happen if I set yellow by writing into yellow mode
>> brightness, and then orange by writing orange model brightness?
>> Will the resulting color be a mix of yellow and orange, or will the
>> orange overwrite the yellow setting?
>>
> 
> This was not discussed and is a good question.  If you write the yellow mode for a group of
> LEDs then yellow would be produced for the brightness requested.
> 
> If orange is then requested then orange should be displayed at the brightness level requested.
> So yes the orange will over write the yellow.

Yes, and individual color brightness levels should correspond
to the color components of the brightness-model level currently set.

> The next question is if the absolute colors are written does it produce the same behavior?
> 
> So if you have yellow and write to the red should the red LED brightness be modified or should the
> color switch to red?
> And if the red LED is on and the blue LED is written should the color switch to blue or should the blue and red LEDs be mixed together?

Now, if any of the color brightness files is altered it should update
the hardware with this new setting, but brightness-model and main
brightness level should not be changed. The thing that is missing in our
proposal is lack of the way to check if brightness-model is up to date
(i.e. if it reflects what is written to the hardware).

How about utilizing the sync file from the new colors directory?
It could return 1 on read when brightness levels of all colors
match exactly the ones assigned to the brightness model level currently
set.

> This is tricky as the user space can write the individual absolute colors and mix the LEDs to produce varying
> colors.  But the behavior writing the brightness models are different.
> 
> I would almost prefer that the user space reads the available absolute LED colors and creates the devices supported color palette and write the absolute LED colors only.  But this violates the requirements asked for.
> 
> Dan
> 
>> Marek
>>
>
Jacek Anaszewski April 12, 2019, 7:24 p.m. UTC | #6
Dan,

On 4/12/19 8:46 PM, Dan Murphy wrote:
> Jacek
> 
> On 4/12/19 1:14 PM, Jacek Anaszewski wrote:
>> Hi Marek,
>>
>> On 4/12/19 12:07 AM, Marek Behun wrote:
>>> Hi Dan,
>>> this probaly was discussed, but I did not follow brightness model
>>> discussions:
>>> what will happen if I set yellow by writing into yellow mode
>>> brightness, and then orange by writing orange model brightness?
>>> Will the resulting color be a mix of yellow and orange, or will the
>>> orange overwrite the yellow setting?
>>
>> Orange will overwrite yellow settings. When color name is given
>> it should be treated as a hue. Then changing brightness level
>> should affect the lightness of a hue, similarly like changing
>> L component of HSL color model. This will be however entirely
>> up to DT brightness-model designer how they will design their models.
>> We are not going to verify that in the LED multi color class.
>>
>> It implies that it will be possible to define arbitrary range
>> of color levels, not necessarily adhering to any established color
>> model. I think it could be useful to define brightness model
>> that allows to go from blue color (for cold) up to red (hot)
>> for representing a temperature for instance.
>>
>> These ideas will need however more documentation. Generally
>> we aim to propose only a convention.
>>
> 
> Ah but what about the issue of writing the monochrome LED color.  With your description
> it implies that when we write the red LED, the red LED will come on and if we write the blue
> LED then the red LED in theory should turn off and the blue come on.

Where did I write that? Probably the way I used word "color"
was not adequate in at least two cases, which may have confused
the reader.

Modifying monochrome color brightness levels (under colors dir)
will just modify corresponding IOUT brightness. Not affecting the
other. I'll try to rephrase what seems to may sound equivocal:

s/When color name is given/When brightness-model is given a color name/

s/arbitrary range of color levels/arbitrary range of brightness-model 
levels/


> But these could be used to mix the colors to create some abstract violet that is not defined in the brightness
> model.  Why should the brightness models and monochrome LEDs have two different operations.
> 
> Dan
>
Dan Murphy April 12, 2019, 10:02 p.m. UTC | #7
All

On 4/12/19 2:10 PM, Jacek Anaszewski wrote:
> Dan,
> 
> On 4/12/19 1:50 PM, Dan Murphy wrote:
>> Marek
>>
>> On 4/11/19 5:07 PM, Marek Behun wrote:
>>> Hi Dan,
>>> this probaly was discussed, but I did not follow brightness model
>>> discussions:
>>> what will happen if I set yellow by writing into yellow mode
>>> brightness, and then orange by writing orange model brightness?
>>> Will the resulting color be a mix of yellow and orange, or will the
>>> orange overwrite the yellow setting?
>>>
>>
>> This was not discussed and is a good question.  If you write the yellow mode for a group of
>> LEDs then yellow would be produced for the brightness requested.
>>
>> If orange is then requested then orange should be displayed at the brightness level requested.
>> So yes the orange will over write the yellow.
> 
> Yes, and individual color brightness levels should correspond
> to the color components of the brightness-model level currently set.
> 
>> The next question is if the absolute colors are written does it produce the same behavior?
>>
>> So if you have yellow and write to the red should the red LED brightness be modified or should the
>> color switch to red?
>> And if the red LED is on and the blue LED is written should the color switch to blue or should the blue and red LEDs be mixed together?
> 
> Now, if any of the color brightness files is altered it should update
> the hardware with this new setting, but brightness-model and main
> brightness level should not be changed. The thing that is missing in our
> proposal is lack of the way to check if brightness-model is up to date
> (i.e. if it reflects what is written to the hardware).
> 
> How about utilizing the sync file from the new colors directory?
> It could return 1 on read when brightness levels of all colors
> match exactly the ones assigned to the brightness model level currently
> set.
> 

There maybe a more pragmatic way to set the color brightness as opposed to defining each level. By defining the monochrome LEDs base maximum brightness for the brightness model and calculating a percentage for each LED from max   I shared this with Jacek earlier and he did not go for it but lets see if others agree or disagree.

With this method we don't have to define a slew of levels. This in theory may work but not sure it will work in practice.

For instance

	lp5024_model_yellow: brightness-models {
		led-brightness-model;
		model@0 {
			model_name = "yellow";
			layout = <LED_COLOR_ID_RED
				  LED_COLOR_ID_GREEN
				  LED_COLOR_ID_BLUE>;
			max_level = <255 247 196>;  //max level of the monochrome LEDs to obtain the color model.
		};
	};

Assumption made that a linear slope for each color model is expected.

Then in the code when a new brightness level is requested for the color the brightness of the monochrome LEDs would be based off the percentage from the max_brightness of the max in the max_level array

The hue is presented as just another color in the colors dir with brightness and max_brightness files.  So it "appears" as a single LED.

max_brightness = 255 This is the max of the LEDs in the array and this would also be presented to the user in the max_brightness of the hue. 

Red = (255/255)  = 100%
Green = (247/255) = 97%
Blue = (196/255) = 77%

brightness_val 128

Red = (128 * 100) / 100 = 128
Green = (128 * 97) / 100 = 124
Blue = (128 * 77) / 100 = 98

brightness_val 80

Red = (80 * 100) / 100 = 80
Green = (80 * 97) / 100 = 77
Blue = (80 * 77) / 100 = 61

brightness_val 10

Red = (10 * 100) / 100 = 10
Green = (10 * 97) / 100 = 9
Blue = (10 * 77) / 100 = 7

This method maintains a rough percentage delta between the LEDs.  Where in the MAX brightness case (255) blue is 77% dimmer in intensity then Red and with a brightness that is 1/4 max the delta percentage is 75% so the delta is within 5% tolerance.

This would keep the directory structures clean and the user space would just need to know colors, brightness and max_brightness for each color.

Also with this simplistic model we can simplify the DT nodes to
	lp5024_model_yellow: brightness-models {
		led-brightness-model;
		model@0 {
			model_name = "yellow";
			layout = <LED_COLOR_ID_RED
				  LED_COLOR_ID_GREEN
				  LED_COLOR_ID_BLUE>;
			max_level = <255 247 196>;
		};
	};

	lp5024_model_orange: brightness-models {
		led-brightness-model;
		model@1 {
			model_name = "orange";
			layout = <LED_COLOR_ID_RED
				  LED_COLOR_ID_GREEN
				  LED_COLOR_ID_BLUE>;
			max_level = <236 140 16>;
		};
	}; 

For orange
max_brightness = 236 This is the max of the LEDs in the array and this would also be presented to the user in the max_brightness of the hue. 

Red = (236/236)  = 100%
Green = (140/236) = 59%
Blue = (16/236) = 6%

<same math from above involved here>

After all of this most likely someone will say this will not work.
Like I indicated it works in principle maybe not in practice but it keeps the user interface simple and keeps the dt small.

The other alternative is to have the user space define the color models and just expose the monochrome LEDs.

Dan

<snip>
Jacek Anaszewski April 13, 2019, 9:54 a.m. UTC | #8
Dan,

On 4/13/19 12:02 AM, Dan Murphy wrote:
> All
> 
> On 4/12/19 2:10 PM, Jacek Anaszewski wrote:
>> Dan,
>>
>> On 4/12/19 1:50 PM, Dan Murphy wrote:
>>> Marek
>>>
>>> On 4/11/19 5:07 PM, Marek Behun wrote:
>>>> Hi Dan,
>>>> this probaly was discussed, but I did not follow brightness model
>>>> discussions:
>>>> what will happen if I set yellow by writing into yellow mode
>>>> brightness, and then orange by writing orange model brightness?
>>>> Will the resulting color be a mix of yellow and orange, or will the
>>>> orange overwrite the yellow setting?
>>>>
>>>
>>> This was not discussed and is a good question.  If you write the yellow mode for a group of
>>> LEDs then yellow would be produced for the brightness requested.
>>>
>>> If orange is then requested then orange should be displayed at the brightness level requested.
>>> So yes the orange will over write the yellow.
>>
>> Yes, and individual color brightness levels should correspond
>> to the color components of the brightness-model level currently set.
>>
>>> The next question is if the absolute colors are written does it produce the same behavior?
>>>
>>> So if you have yellow and write to the red should the red LED brightness be modified or should the
>>> color switch to red?
>>> And if the red LED is on and the blue LED is written should the color switch to blue or should the blue and red LEDs be mixed together?
>>
>> Now, if any of the color brightness files is altered it should update
>> the hardware with this new setting, but brightness-model and main
>> brightness level should not be changed. The thing that is missing in our
>> proposal is lack of the way to check if brightness-model is up to date
>> (i.e. if it reflects what is written to the hardware).
>>
>> How about utilizing the sync file from the new colors directory?
>> It could return 1 on read when brightness levels of all colors
>> match exactly the ones assigned to the brightness model level currently
>> set.
>>
> 
> There maybe a more pragmatic way to set the color brightness as opposed to defining each level. By defining the monochrome LEDs base maximum brightness for the brightness model and calculating a percentage for each LED from max   I shared this with Jacek earlier and he did not go for it but lets see if others agree or disagree.
> 
> With this method we don't have to define a slew of levels. This in theory may work but not sure it will work in practice.
> 
> For instance
> 
> 	lp5024_model_yellow: brightness-models {
> 		led-brightness-model;
> 		model@0 {
> 			model_name = "yellow";
> 			layout = <LED_COLOR_ID_RED
> 				  LED_COLOR_ID_GREEN
> 				  LED_COLOR_ID_BLUE>;
> 			max_level = <255 247 196>;  //max level of the monochrome LEDs to obtain the color model.
> 		};
> 	};
> 
> Assumption made that a linear slope for each color model is expected.
> 
> Then in the code when a new brightness level is requested for the color the brightness of the monochrome LEDs would be based off the percentage from the max_brightness of the max in the max_level array
> 
> The hue is presented as just another color in the colors dir with brightness and max_brightness files.  So it "appears" as a single LED.
> 
> max_brightness = 255 This is the max of the LEDs in the array and this would also be presented to the user in the max_brightness of the hue.
> 
> Red = (255/255)  = 100%
> Green = (247/255) = 97%
> Blue = (196/255) = 77%
> 
> brightness_val 128
> 
> Red = (128 * 100) / 100 = 128
> Green = (128 * 97) / 100 = 124
> Blue = (128 * 77) / 100 = 98
> 
> brightness_val 80
> 
> Red = (80 * 100) / 100 = 80
> Green = (80 * 97) / 100 = 77
> Blue = (80 * 77) / 100 = 61
> 
> brightness_val 10
> 
> Red = (10 * 100) / 100 = 10
> Green = (10 * 97) / 100 = 9
> Blue = (10 * 77) / 100 = 7
> 
> This method maintains a rough percentage delta between the LEDs.  Where in the MAX brightness case (255) blue is 77% dimmer in intensity then Red and with a brightness that is 1/4 max the delta percentage is 75% so the delta is within 5% tolerance.
> 
> This would keep the directory structures clean and the user space would just need to know colors, brightness and max_brightness for each color.
> 
> Also with this simplistic model we can simplify the DT nodes to
> 	lp5024_model_yellow: brightness-models {
> 		led-brightness-model;
> 		model@0 {
> 			model_name = "yellow";
> 			layout = <LED_COLOR_ID_RED
> 				  LED_COLOR_ID_GREEN
> 				  LED_COLOR_ID_BLUE>;
> 			max_level = <255 247 196>;
> 		};
> 	};
> 
> 	lp5024_model_orange: brightness-models {
> 		led-brightness-model;
> 		model@1 {
> 			model_name = "orange";
> 			layout = <LED_COLOR_ID_RED
> 				  LED_COLOR_ID_GREEN
> 				  LED_COLOR_ID_BLUE>;
> 			max_level = <236 140 16>;
> 		};
> 	};
> 
> For orange
> max_brightness = 236 This is the max of the LEDs in the array and this would also be presented to the user in the max_brightness of the hue.
> 
> Red = (236/236)  = 100%
> Green = (140/236) = 59%
> Blue = (16/236) = 6%
> 
> <same math from above involved here>
> 
> After all of this most likely someone will say this will not work.
> Like I indicated it works in principle maybe not in practice but it keeps the user interface simple and keeps the dt small.

Great, we will have simple. not working interface.

If you will prove that it works for the whole range of devices and
LEDs and is able to produce uniform colors then I'm all in.

Especially, I'd expect it will be able to keep the same hue
and increase only lightness as brightness level rises.

> The other alternative is to have the user space define the color models and just expose the monochrome LEDs.

Please propose the whole interface since I don't see how it would work,
and especially how its functionality would differ from the discussed
approach.

Would it allow to support LEDn_BRIGHTNESS of lp50xx devices?

I'm afraid we're making a full circle now.

We've discussed many aspects of the problem throughout last months -
does your design introduce some novelty in regard to what has been
discussed so far?

If not, and if there is no consensus regarding brightness-models, then
let's implement iouts as monochrome LEDs, without the support for
LEDn_BRIGHTNESS.

Patch
diff mbox series

diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt
index 7497a3c221fe..bc424a9ba547 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -23,6 +23,8 @@  Optional properties for child nodes:
 - color : Color of the LED. Use one of the LED_COLOR_ID_* prefixed definitions
 	  from the header include/dt-bindings/leds/common.h.
 	  If there is no matching LED_COLOR_ID available, add a new one.
+	  For multi color LED support see leds-multicolor.txt within this
+	  directory.
 
 - led-enumerator: Integer to be used for LED differentiation when neither
 		  function nor color can be used for that purpose.
diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.txt b/Documentation/devicetree/bindings/leds/leds-class-multicolor.txt
new file mode 100644
index 000000000000..9cbc4aece53d
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.txt
@@ -0,0 +1,142 @@ 
+* Multicolor LED properties
+
+Multicolor LEDs can consist of a RGB, RGBW or a RGBA LED clusters.  These devices
+can be grouped together and also provide a modeling mechanism so that the
+cluster LEDs can vary in hue and intensity to produce a wide range of colors.
+
+The nodes and properties defined in this document are unique to the multicolor 
+LED class.  Common LED nodes and properties are inherited from the common.txt
+within this documentation directory.
+
+Required LED Child properties:
+	- color : For multicolor LED support this property should be defined as
+		  LED_COLOR_ID_MULTI and further definition can be found in
+		  include/linux/leds/common.h.
+
+Optional LED Child properties:
+	- available-brightness-models : This is the phandle to the brightness-model
+					node(s) that this LED cluster can support.
+
+Required Brightness model properties
+	- led-brightness-model : This flag alerts the device driver and class
+				 code that this node is a brightness model node
+				 and to process the properties differently.
+
+Required Brightness model child properties
+	- model_name : This is the name of the model presented to the user.  This
+		       should be a color that the LED cluster can produce for
+		       the device it is attached to.
+	- layout : This is the LED layout for the levels.  This layout will
+		   determine the color order of the levels.  The layout and
+		   level-x properties array should be the same size.
+	- level-x : These are the values for the LEDs to produce the color that
+		    is defined.  These values are placed in the array according
+		    to the layout property.
+
+led-controller@30 {
+	#address-cells = <1>;
+	#size-cells = <0>;
+	compatible = "ti,lp5024";
+	reg = <0x29>;
+
+	lp5024_model_yellow: brightness-models {
+		led-brightness-model;
+		model@0 {
+			model_name = "yellow";
+			layout = <LED_COLOR_ID_RED
+				  LED_COLOR_ID_GREEN
+				  LED_COLOR_ID_BLUE>;
+			level-1 = <255 227 40>;
+			level-2 = <255 240 136>;
+			level-3 = <255 247 196>;
+		};
+	};
+
+	lp5024_model_orange: brightness-models {
+		led-brightness-model;
+		model@1 {
+			model_name = "orange";
+			layout = <LED_COLOR_ID_RED
+				  LED_COLOR_ID_GREEN
+				  LED_COLOR_ID_BLUE>;
+			level-1 = <236 140 16>;
+			level-2 = <236 157 55>;
+			level-3 = <236 183 115>;
+		};
+	}; 
+
+	multi-led@4 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <4>;
+		color = <LED_COLOR_ID_MULTI>;
+		function = LED_FUNCTION_ACTIVITY;
+		available-brightness-models = <&lp5024_model_yellow>;
+		
+		led@12 {
+			reg = <12>;
+			color = <LED_COLOR_ID_RED>;
+		};
+
+		led@13 {
+			reg = <13>;
+			color = <LED_COLOR_ID_GREEN>;
+		};
+
+		led@14 {
+			reg = <14>;
+			color = <LED_COLOR_ID_BLUE>;
+		};
+	};
+
+	/* Only support RGB no model defined */
+	multi-led@1 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		reg = <1>;
+		label = "rgb:led_mod1";
+		
+		led@3 {
+			reg = <3>;
+			color = <LED_COLOR_ID_RED>;
+		};
+
+		led@4 {
+			reg = <4>;
+			color = <LED_COLOR_ID_GREEN>;
+		};
+
+		led@5 {
+			reg = <5>;
+			color = <LED_COLOR_ID_BLUE>;
+		};
+	};
+
+	multi-led@2 {
+		#address-cells = <1>;
+		#size-cells = <0>;
+		label = "rgb:banks";
+		reg = <2>;
+		ti,led-bank = <2 3 5>;
+		available-brightness-models = <&lp5024_model_orange>;
+
+		led@6 {
+			reg = <0x6>;
+			color = <LED_COLOR_ID_RED>;
+			led-sources = <6 9 15>;
+		};
+
+		led@7 {
+			reg = <0x7>;
+			color = <LED_COLOR_ID_GREEN>;
+			led-sources = <7 10 16>;
+		};
+
+		led@8 {
+			reg = <0x8>;
+			color = <LED_COLOR_ID_BLUE>;
+			led-sources = <8 11 17>;
+		};
+	};
+
+};