From: "Marek Behún" <kabel@kernel.org>
To: Pavel Machek <pavel@ucw.cz>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Rob Herring <robh+dt@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org
Subject: lets settle the LED `function` property regarding the netdev trigger
Date: Fri, 1 Oct 2021 14:36:01 +0200 [thread overview]
Message-ID: <20211001143601.5f57eb1a@thinkpad> (raw)
Hello Pavel, Jacek, Rob and others,
I'd like to settle DT binding for the LED function property regarding
the netdev LED trigger.
Currently we have, in include/dt-bindings/leds/common.h, the following
functions defined that could be interpreted as request to enable netdev
trigger on given LEDs:
activity
lan
rx tx
wan
wlan
The "activity" function was originally meant to imply the CPU
activity trigger, while "rx" and "tx" are AFAIK meant as UART indicators
(tty LED trigger), see
https://lore.kernel.org/linux-leds/20190609190803.14815-27-jacek.anaszewski@gmail.com/
The netdev trigger supports different settings:
- indicate link
- blink on rx, blink on tx, blink on both
The current scheme does not allow for implying these.
I therefore propose that when a LED has a network device handle in the
trigger-sources property, the "rx", "tx" and "activity" functions
should also imply netdev trigger (with the corresponding setting).
A "link" function should be added, also implying netdev trigger.
What about if a LED is meant by the device vendor to indicate both link
(on) and activity (blink)?
The function property is currently a string. This could be changed to
array of strings, and then we can have
function = "link", "activity";
Since the function property is also used for composing LED classdev
names, I think only the first member should be used for that.
This would allow for ethernet LEDs with names
ethphy-0:green:link
ethphy-0:yellow:activity
to be controlled by netdev trigger in a specific setting without the
need to set the trigger in /sys/class/leds.
Opinions?
Marek
next reply other threads:[~2021-10-01 12:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-01 12:36 Marek Behún [this message]
2021-10-03 18:56 ` lets settle the LED `function` property regarding the netdev trigger Andrew Lunn
2021-10-03 19:26 ` Marek Behún
2021-10-04 14:50 ` Andrew Lunn
2021-10-04 15:08 ` Marek Behún
2021-10-04 17:28 ` Andrew Lunn
2021-10-05 20:30 ` Marek Behún
2021-10-05 21:52 ` Andrew Lunn
2021-10-05 19:58 ` Jacek Anaszewski
2021-10-05 20:12 ` Andrew Lunn
2021-10-05 20:26 ` Marek Behún
2021-10-05 21:01 ` Andrew Lunn
2021-10-05 21:43 ` Marek Behún
2021-10-05 22:06 ` Andrew Lunn
2021-10-05 23:06 ` Marek Behún
2021-10-06 12:57 ` Andrew Lunn
2021-10-07 17:13 ` Marek Behún
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=20211001143601.5f57eb1a@thinkpad \
--to=kabel@kernel.org \
--cc=andrew@lunn.ch \
--cc=devicetree@vger.kernel.org \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).