> -----Original Message----- > From: Marek Behun [mailto:marek.behun@xxxxxx] > Sent: Sonntag, 20. September 2020 02:07 > To: Adrian Schmutzler <mail@xxxxxxxxxxxxxxxxxxx> > Cc: linux-leds@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v2 1/2] dt-bindings: leds: add LED_FUNCTION for > wlan2g/wlan5g > > On Sun, 20 Sep 2020 01:09:49 +0200 > "Adrian Schmutzler" <mail@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > 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? > > > > > > > > > > The files in /sys/class/leds/ are symlinks. The actual files are in > > > /sys/devices/ somewhere. If you know the path of your LED in the > > > device hierarchy, you can find it that way. If your script can > > > access the LED by reading device-tree, you can implement your script > > > so that you can find the LED in the hiearchy in /sys/devices/ (or > > > simply byt reading where do the symlinks in /sys/class/leds/ point to). > > > > Thanks for that pointer; unfortunately though, I was only able to retrieve > lists of leds in [device:]color:function syntax and lists of the DT nodes, but > nothing where a single node from DT is linked or can be related to just one of > the [device:]color:function identifiers. > > > > Best > > > > Adrian > > > > Which driver is this? Normally there is of_node symlink in sysfs device > directory... This is ath79 target on OpenWrt master. I have an of_node symlink for the parent "leds" node, but not for the individual leds: root@OpenWrt:~# ls /sys/devices/ pci0000:00/ platform/ system/ virtual/ root@OpenWrt:~# ls /sys/devices/platform/ Fixed MDIO bus.0/ gpio-export/ reg-dummy/ uevent ahb/ keys/ regulatory.0/ usb-phy/ ath9k-leds/ leds/ serial8250/ root@OpenWrt:~# ls /sys/devices/platform/leds/ driver/ leds/ of_node/ uevent driver_override modalias subsystem/ root@OpenWrt:~# ls /sys/devices/platform/leds/leds/ green:status green:usb green:usb_1 green:wlan-1 green:wps root@OpenWrt:~# ls /sys/devices/platform/leds/leds/green\:status/ brightness device max_brightness subsystem trigger uevent root@OpenWrt:~# cat /sys/devices/platform/leds/leds/green\:status/uevent OF_NAME=system OF_FULLNAME=/leds/system OF_COMPATIBLE_N=0 root@OpenWrt:~# ls /sys/devices/platform/leds/of_node/ compatible name qss system usb1 usb2 wlan2g root@OpenWrt:~# ls /sys/devices/platform/leds/of_node/system/ color default-state function gpios name In the meantime I found the reference in uevent above, but that's not really convenient. I don't think we do anything special about leds here. The target has CONFIG_LEDS_GPIO=y set in config. Kernel 5.4.66. The configuration looks like this (enumerator on wlan2g was for testing only; there is a separate ath9k-leds node which I ignored for this discussion): / { aliases { led-boot = &led_system; led-failsafe = &led_system; led-running = &led_system; led-upgrade = &led_system; }; leds { compatible = "gpio-leds"; wlan2g { function = LED_FUNCTION_WLAN; function-enumerator = <1>; color = <LED_COLOR_ID_GREEN>; gpios = <&gpio 13 GPIO_ACTIVE_LOW>; linux,default-trigger = "phy0tpt"; }; led_system: system { function = LED_FUNCTION_STATUS; color = <LED_COLOR_ID_GREEN>; gpios = <&gpio 14 GPIO_ACTIVE_LOW>; default-state = "on"; }; qss { label = "tp-link:green:qss"; function = LED_FUNCTION_WPS; color = <LED_COLOR_ID_GREEN>; gpios = <&gpio 15 GPIO_ACTIVE_LOW>; }; usb1 { function = LED_FUNCTION_USB; color = <LED_COLOR_ID_GREEN>; gpios = <&gpio 11 GPIO_ACTIVE_LOW>; trigger-sources = <&hub_port1>; linux,default-trigger = "usbport"; }; usb2 { function = LED_FUNCTION_USB; color = <LED_COLOR_ID_GREEN>; gpios = <&gpio 12 GPIO_ACTIVE_LOW>; trigger-sources = <&hub_port2>; linux,default-trigger = "usbport"; }; }; }; While I hacked together an ugly solution to exploit uevent (with recursive grep ...), I'd really prefer a more convenient option so the "new" concept doesn't turn into a drawback from the start. Thanks for your help so far! Best Adrian
Attachment:
openpgp-digital-signature.asc
Description: PGP signature
