> -----Original Message----- > From: Marek Behun [mailto:marek.behun@xxxxxx] > Sent: Samstag, 19. September 2020 22:32 > To: Adrian Schmutzler <freifunk@xxxxxxxxxxxxxxxxxxx> > Cc: linux-leds@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v2 1/2] dt-bindings: leds: add LED_FUNCTION for > wlan2g/wlan5g > > On Sat, 19 Sep 2020 21:24:26 +0200 > Adrian Schmutzler <freifunk@xxxxxxxxxxxxxxxxxxx> wrote: > > > Many consumer "routers" have dedicated LEDs for specific WiFi bands, > > e.g. one for 2.4 GHz and one for 5 GHz. These LEDs specifically > > indicate the state of the relevant band, so the latter should be > > included in the function name. LED_FUNCTION_WLAN will remain for > > general cases or when the LED is used for more than one band. > > > > This essentially is equivalent to how we use LED_FUNCTION_LAN and > > LED_FUNCTION_WAN instead of just having LED_FUNCTION_ETHERNET. > > Dont. If you want the LED name to inform the user about the WiFi device it is > being triggered on, it instead should come from the devicename part: > "wlan0:blue:activity" > > In fact the function should not be "wlan" (nor "wlan2g" or "wlan5g", but > "activity". > > I am going to try to work on this subsystem so that if trigger source of the LED > is set to a WiFi device and function is set to activity, the LED shall blink on wifi > activity. > > This way we can also avoid using the `linux,default-trigger` property in favour > of `function`, i.e. if I have: > > wlan0: wifi@12300 { > compatible = "some-wifi"; > #trigger-source-cells = <0>; > } > > led { > color = <LED_COLOR_ID_BLUE>; > function = LED_FUNCTION_ACTIVITY; > trigger-sources = <&wlan0>; > }; > > Than this will automatically name the LED as > wlan0:blue:activity > and if the corresponding trigger is available, it should set the trigger even if > no `linux,default-trigger` property is present. Thanks for the explanation, I understand why this makes sense conceptually. However, I assume your use of the word "will" indicates that I won't be able to build a solution like this with kernel 5.4? So, easiest surrogate there would be to just stick to label property for the moment ...? How is the "device" part determined? Can I just change the DT label from wlan0 to wlan2g to get a more descriptive name, which will be translated into the led name like wlan2g:blue:activity? And finally, though partly off-topic: Is there any way to determine the full "led name" from device-tree? We currently have aliases for certain leds, like led-upgrade = &led_somename; The allowed us to construct the /sys/class/leds/<label> path directly from /proc/device-tree (in a user-space script), as we could access the label property of the LED. As far as I understand it, the color/function system does not provide a comparable lever, as the final name is only constructed in led-core.c? Best Adrian
Attachment:
openpgp-digital-signature.asc
Description: PGP signature
