How to name multiple LEDs of the same type and color

How to name multiple LEDs of the same type and color

[Adrian Schmutzler]

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

Hi,

I wonder what would be the correct way to deal with a set of LEDs with the same color/function combination, e.g.

	leds {
		compatible = "gpio-leds";

		link1 {
			function = LED_FUNCTION_RSSI;
			color = <LED_COLOR_ID_GREEN>;
			gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
		};

		link2 {
			function = LED_FUNCTION_RSSI;
			color = <LED_COLOR_ID_GREEN>;
			gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
		};

		link3 {
			function = LED_FUNCTION_RSSI;
			color = <LED_COLOR_ID_GREEN>;
			gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
		};
	};

or

	leds {
		compatible = "gpio-leds";

		lan1 {
			function = LED_FUNCTION_LAN;
			color = <LED_COLOR_ID_GREEN>;
			gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
		};
		lan2 {
			function = LED_FUNCTION_LAN;
			color = <LED_COLOR_ID_GREEN>;
			gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
		};
		lan3 {
			function = LED_FUNCTION_LAN;
			color = <LED_COLOR_ID_GREEN>;
			gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
		};
	};

These nodes will automatically create names like green:lan, green:lan_1, etc.

Is there a way to force a certain numbering scheme, e.g.
green:lan1, green:lan2, etc.
?

(For the RSSI leds, we currently even have stuff like ...:green:rssilow, ...:green:rssimedium, etc. in the label now)

How does this match into the color/function concept?

Thanks for some pointers ...

Best

Adrian

[-- Attachment #2: openpgp-digital-signature.asc --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: How to name multiple LEDs of the same type and color

[Marek Behun]

On Sat, 19 Sep 2020 23:21:22 +0200
"Adrian Schmutzler" <mail@adrianschmutzler.de> wrote:

> Hi,
> 
> I wonder what would be the correct way to deal with a set of LEDs with the same color/function combination, e.g.
> 
> 	leds {
> 		compatible = "gpio-leds";
> 
> 		link1 {
> 			function = LED_FUNCTION_RSSI;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> 		};
> 
> 		link2 {
> 			function = LED_FUNCTION_RSSI;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> 		};
> 
> 		link3 {
> 			function = LED_FUNCTION_RSSI;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> 		};
> 	};
> 
> or
> 
> 	leds {
> 		compatible = "gpio-leds";
> 
> 		lan1 {
> 			function = LED_FUNCTION_LAN;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
> 		};
> 		lan2 {
> 			function = LED_FUNCTION_LAN;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
> 		};
> 		lan3 {
> 			function = LED_FUNCTION_LAN;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 11 GPIO_ACTIVE_LOW>;
> 		};
> 	};
> 
> These nodes will automatically create names like green:lan, green:lan_1, etc.
> 
> Is there a way to force a certain numbering scheme, e.g.
> green:lan1, green:lan2, etc.
> ?
> 
> (For the RSSI leds, we currently even have stuff like ...:green:rssilow, ...:green:rssimedium, etc. in the label now)
> 
> How does this match into the color/function concept?
> 
> Thanks for some pointers ...
> 
> Best
> 
> Adrian

Please look at function-enumerator property.

Re: How to name multiple LEDs of the same type and color

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

Hi!

> I wonder what would be the correct way to deal with a set of LEDs with the same color/function combination, e.g.
>

(Please wrap at 72).

> 	leds {
> 		compatible = "gpio-leds";
> 
> 		link1 {
> 			function = LED_FUNCTION_RSSI;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
> 		};
> 
> 		link2 {
> 			function = LED_FUNCTION_RSSI;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
> 		};
> 
> 		link3 {
> 			function = LED_FUNCTION_RSSI;
> 			color = <LED_COLOR_ID_GREEN>;
> 			gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
> 		};
> 	};

Well, this is not really three LEDs. This is more like... LED meter
composed of three LEDs. And we don't have good support for that.

But I guess we'll need it one day. There were some previous attempts:
https://lwn.net/Articles/802967/

Do you plan to control RSSI LEDs from kernel?

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

RE: How to name multiple LEDs of the same type and color

[Adrian Schmutzler]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

> >               link3 { 
> >                       function = LED_FUNCTION_RSSI; 
> >                       color = <LED_COLOR_ID_GREEN>; 
> >                       gpios = <&gpio 15 GPIO_ACTIVE_LOW>; 
> >               }; 
> >       }; 
> Well, this is not really three LEDs. This is more like... LED meter 
> composed of three LEDs. And we don't have good support for that. 
> But I guess we'll need it one day. There were some previous attempts: 
> https://lwn.net/Articles/802967/ 
> Do you plan to control RSSI LEDs from kernel? 

To be honest, I mostly sent this patch for completeness.

OpenWrt uses a very simple process written in C for updating these LEDs, which is quite old and has essentially remained unchanged for years, but does its job.
I personally don't think there will be overwhelming interest in touching this and migrate it to whatever different implementation without a pressing need.

My main interest here was/is that I started to evaluate how OpenWrt can migrate from LED labels to the "new" color/function syntax and to me the rssi leds are a dedicated type that should be supported.
So I fear I won't be helpful for the implementation of RSSI leds in the kernel in general.

For the three leds vs. set of leds discussion: Note that we are interested in (and already do) exposing each LED to the user individually (in user-space via sysfs), so the user can redefine the purpose of the LED freely based on his/her desire. Therefore, a total abstraction of the set of LEDs as a single entity would be detrimental for us here.

Best

Adrian 

[-- Attachment #2: openpgp-digital-signature.asc --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: How to name multiple LEDs of the same type and color

[Marek Behun]

On Mon, 21 Sep 2020 01:31:23 +0200
"Adrian Schmutzler" <mail@adrianschmutzler.de> wrote:

> > >               link3 { 
> > >                       function = LED_FUNCTION_RSSI; 
> > >                       color = <LED_COLOR_ID_GREEN>; 
> > >                       gpios = <&gpio 15 GPIO_ACTIVE_LOW>; 
> > >               }; 
> > >       };   
> > Well, this is not really three LEDs. This is more like... LED meter 
> > composed of three LEDs. And we don't have good support for that. 
> > But I guess we'll need it one day. There were some previous attempts: 
> > https://lwn.net/Articles/802967/ 
> > Do you plan to control RSSI LEDs from kernel?   
> 
> To be honest, I mostly sent this patch for completeness.
> 
> OpenWrt uses a very simple process written in C for updating these LEDs, which is quite old and has essentially remained unchanged for years, but does its job.
> I personally don't think there will be overwhelming interest in touching this and migrate it to whatever different implementation without a pressing need.
> 
> My main interest here was/is that I started to evaluate how OpenWrt can migrate from LED labels to the "new" color/function syntax and to me the rssi leds are a dedicated type that should be supported.
> So I fear I won't be helpful for the implementation of RSSI leds in the kernel in general.
> 
> For the three leds vs. set of leds discussion: Note that we are interested in (and already do) exposing each LED to the user individually (in user-space via sysfs), so the user can redefine the purpose of the LED freely based on his/her desire. Therefore, a total abstraction of the set of LEDs as a single entity would be detrimental for us here.
> 
> Best
> 
> Adrian 

This is interesting. How does this work? Better signal => faster
blinking?

Where is the signal strength taken from?

Marek

Re: How to name multiple LEDs of the same type and color

[Pavel Machek]

Hi!


> > My main interest here was/is that I started to evaluate how OpenWrt can migrate from LED labels to the "new" color/function syntax and to me the rssi leds are a dedicated type that should be supported.
> > So I fear I won't be helpful for the implementation of RSSI leds in the kernel in general.

Yep, I guess staying with old "label" is the right solution for you
for now.

> > For the three leds vs. set of leds discussion: Note that we are interested in (and already do) exposing each LED to the user individually (in user-space via sysfs), so the user can redefine the purpose of the LED freely based on his/her desire. Therefore, a total abstraction of the set of LEDs as a single entity would be detrimental for us here.
> > 
> 
> This is interesting. How does this work? Better signal => faster
> blinking?

I suspect it is "no signal" -> "all LEDs off". "weak signal" -> "one
LED on", "medium signal" -> "two LEDs on", "string signal" -> "three
LEDs on".

Best regards,
								Pavel

RE: How to name multiple LEDs of the same type and color

[Adrian Schmutzler]

[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]

Hi,

> -----Original Message-----
> From: Pavel Machek [mailto:pavel@ucw.cz]
> Sent: Montag, 21. September 2020 10:31
> To: Marek Behun <marek.behun@nic.cz>
> Cc: Adrian Schmutzler <mail@adrianschmutzler.de>; linux-
> leds@vger.kernel.org
> Subject: Re: How to name multiple LEDs of the same type and color
> 
> Hi!
> 
> 
> > > My main interest here was/is that I started to evaluate how OpenWrt can
> migrate from LED labels to the "new" color/function syntax and to me the rssi
> leds are a dedicated type that should be supported.
> > > So I fear I won't be helpful for the implementation of RSSI leds in the
> kernel in general.
> 
> Yep, I guess staying with old "label" is the right solution for you for now.
> 
> > > For the three leds vs. set of leds discussion: Note that we are interested
> in (and already do) exposing each LED to the user individually (in user-space
> via sysfs), so the user can redefine the purpose of the LED freely based on
> his/her desire. Therefore, a total abstraction of the set of LEDs as a single
> entity would be detrimental for us here.
> > >
> >
> > This is interesting. How does this work? Better signal => faster
> > blinking?
> 
> I suspect it is "no signal" -> "all LEDs off". "weak signal" -> "one LED on",
> "medium signal" -> "two LEDs on", "string signal" -> "three LEDs on".

Indeed, it's just on/off, no blinking. We essentially mirror the behavior of OEM firmwares in this case.

The signal strength where one LED is active is defined in a config file by defining a range within 1 to 100.

E.g. rssilow (1 < signal < 100), rssimediumlow (25 < signal < 100), rssimediumhigh (50 < signal < 100), rssihigh (75 < signal < 100)

Therefore, the more LEDs you see, the better your RSSI is. Note that LEDs might have different (fixed) colors, i.e. low is red, mediumlow is amber, and the other two are green.

Some vendors do it differently of course and have one LED "position" where the color changes, or LEDs go off again for high RSSI or whatever, but my example should be the most abundant case.

FYI:

Device example: https://dl.ubnt.com/datasheets/picostationm/picom2hp_DS.pdf

OpenWrt rssileds code: https://github.com/openwrt/openwrt/blob/master/package/network/utils/rssileds/src/rssileds.c

Hope this helps.

Best

Adrian

> 
> Best regards,
> 								Pavel
> 

[-- Attachment #2: openpgp-digital-signature.asc --]
[-- Type: application/pgp-signature, Size: 834 bytes --]