From: "Adrian Schmutzler" <mail@adrianschmutzler.de>
To: "'Marek Behun'" <marek.behun@nic.cz>
Cc: <linux-leds@vger.kernel.org>
Subject: RE: [PATCH v2 1/2] dt-bindings: leds: add LED_FUNCTION for wlan2g/wlan5g
Date: Sun, 20 Sep 2020 11:59:21 +0200 [thread overview]
Message-ID: <007001d68f34$b6bded20$2439c760$@adrianschmutzler.de> (raw)
In-Reply-To: <20200920020631.4d36b035@nic.cz>
[-- Attachment #1: Type: text/plain, Size: 4450 bytes --]
> -----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
[-- Attachment #2: openpgp-digital-signature.asc --]
[-- Type: application/pgp-signature, Size: 834 bytes --]
next prev parent reply other threads:[~2020-09-20 9:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-19 19:24 [PATCH v2 1/2] dt-bindings: leds: add LED_FUNCTION for wlan2g/wlan5g Adrian Schmutzler
2020-09-19 19:24 ` [PATCH v2 2/2] dt-bindings: leds: add LED_FUNCTION_RSSI Adrian Schmutzler
2020-09-19 20:31 ` [PATCH v2 1/2] dt-bindings: leds: add LED_FUNCTION for wlan2g/wlan5g Marek Behun
2020-09-19 21:40 ` Adrian Schmutzler
2020-09-19 22:28 ` Marek Behun
2020-09-19 23:09 ` Adrian Schmutzler
2020-09-20 0:06 ` Marek Behun
2020-09-20 9:59 ` Adrian Schmutzler [this message]
2020-09-20 13:16 ` Jacek Anaszewski
2020-09-20 13:37 ` Marek Behun
2020-09-20 14:59 ` Jacek Anaszewski
2020-09-20 15:28 ` Marek Behun
2020-09-20 17:44 ` Jacek Anaszewski
2020-09-21 22:10 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2020-09-19 17:27 Adrian Schmutzler
2020-09-19 21:45 ` Adrian Schmutzler
2020-09-23 21:04 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='007001d68f34$b6bded20$2439c760$@adrianschmutzler.de' \
--to=mail@adrianschmutzler.de \
--cc=linux-leds@vger.kernel.org \
--cc=marek.behun@nic.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.