> -----Original Message-----
> From: Marek Behun [mailto:marek.behun@nic.cz]
> Sent: Sonntag, 20. September 2020 02:07
> To: Adrian Schmutzler <mail@adrianschmutzler.de>
> Cc: linux-leds@vger.kernel.org
> 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@adrianschmutzler.de> 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