From: Marek Behun <marek.behun@nic.cz>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: linux-leds@vger.kernel.org, pavel@ucw.cz, dmurphy@ti.com
Subject: Re: [PATCH] leds: Document standard LED functions
Date: Sun, 20 Sep 2020 18:44:22 +0200 [thread overview]
Message-ID: <20200920184422.60c04194@nic.cz> (raw)
In-Reply-To: <20200920162625.14754-1-jacek.anaszewski@gmail.com>
On Sun, 20 Sep 2020 18:26:25 +0200
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> Add a documentation for standard LED functions with regard
> to differences in meaning between cases when devicename section
> of an LED name is present or not.
>
> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> ---
> Documentation/leds/led-functions.rst | 226 +++++++++++++++++++++++++++++++++++
> 1 file changed, 226 insertions(+)
> create mode 100644 Documentation/leds/led-functions.rst
>
> diff --git a/Documentation/leds/led-functions.rst b/Documentation/leds/led-functions.rst
> new file mode 100644
> index 000000000000..42621dd81235
> --- /dev/null
> +++ b/Documentation/leds/led-functions.rst
> @@ -0,0 +1,226 @@
> +============================================
> +Standardized LED functions and their meaning
> +============================================
> +
> +Each LED function is described using below template:
> +
> +LED function name
> +-----------------
> +
> + NDEV : <function meaning when LED devicename section is absent>
> + DEV : <function meaning when LED devicename section is present>
> + DEVICENAME : <expected LED devicename for DEV case>
> + TRIGGER: <matching LED trigger>
> +
> +LED functions with corresponding LED trigger support
> +----------------------------------------------------
> +
> +- activity
> + NDEV : system activity
> + DEV : n/a
> + TRIGGER : "activity"
> +
Hi Jacek,
as I wrote in another discussion, but maybe we should discuss this here.
Are your opinions on this matter final or are you open for discussion?
For activity: the thing is that activity is sometimes interpreted as
the union of rx and tx, or read and write. I think the pair (device,function)
could be used better to infer the actual trigger and its settings, than
just (function,). For example:
device function trigger
------ -------- -------
system activity cpu activity
(empty) activity cpu activity
eth0 activity netdev rx/tx
sda activity disk read/write on sda
wlan0 activity phy rx/tx
> +- backlight
> + NDEV : when there is a single one on the platform
> + DEV : backlight of a frame buffer device
> + DEVICENAME : associated frame buffer device, e.g. fb0
> + TRIGGER: "backlight"
> +
> +- disk
> + NDEV : rw activity on any disk in the system
> + DEV : rw activity on specified disk
> + DEVICENAME : associated disk, e.g.: hda, sdb
> + TRIGGER : "disk-activity", applies only to NDEV case
> +
> +- disk-read / disk-write
> + NDEV : read / write activity on any disk in the system
> + DEV : read / write activity on specified disk
> + DEVICENAME : associted disk, e.g.: hda, sdb
> + TRIGGER : "disk-read" / "disk-write" , applies only to NDEV case
> +
Currently the disk trigger blinks on events for any device, user cannot
specify just one. If we implemented this, I think the trigger name
should be just "disk", and whether it is read/write/both should be
decided by sysfs files "read" and "write" as is in netdev trigger files
"rx" and "tx".
Moreover I think it would make more sense (but other people can of
course disagree) if the LED function for LED associated with a disk
could be "activity", "read" or "write",
device function trigger
------ -------- -------
sda activity disk read/write on sda
sda read disk read on sda
sda write disk write on sda
Marek
> +- flash
> + NDEV : flash LED (if there is single available on the platform)
> + DEV : flash LED related to the specified video device
> + DEVICENAME : associated video device, e.g. v4l2-subdev3
> + TRIGGER : "flash"; this LED can be also controlled by v4l2-flash framework
> +
> +- flash-front
> + NDEV : n/a
> + DEV : front flash LED related to the specified video device
> + DEVICENAME : associated video device, e.g. v4l2-subdev3
> + TRIGGER : "flash"; this LED can be also controlled by v4l2-flash framework
> +
> +- flash-rear
> + NDEV : n/a
> + DEV : rear flash LED related to the specified video device
> + DEVICENAME : associated video device, e.g. v4l2-subdev3
> + TRIGGER : "flash"; this LED can be also controlled by v4l2-flash framework
> +
> +- heartbeat
> + NDEV : cpu load average expressed as heartbeat-fashion blink frequency
> + DEV : n/a
> + TRIGGER : "heartbeat"
> +
> +- lan
> + NDEV : n/a
> + DEV : network traffic on selected network device
> + DEVICENAME : associated phy, e.g. phy1
> + TRIGGER : "netdev"
>
> +- wlan
> + NDEV : activity on any wlan device
> + DEV : activity on a specified wlan device
> + DEVICENAME: associated phy, e.g. phy1
> + TRIGGER: wlan device drivers may implement their own triggers
> + using phyN-function naming
> +
> +- mute
> + NDEV : platform audio output mute state
> + DEV : mute state of specified audio device output
> + DEVICENAME : associated audio device
> + TRIGGER : "audio-mute"
> +
> +- micmute
> + NDEV : plaform microphone input mute state
> + DEV : mute state of a microphone belonging to the specified device
> + DEVICENAME : associated audio device
> + TRIGGER : "audio-micmute"
> +
> +- mtd
> + NDEV : rw actvity on any mtd device in the system
> + DEV : rw actvity on specified mtd device
> + DEVICENAME : associated mtd device, e.g mtdN
> + TRIGGER : "mtd"
> +
> +- panic
> + NDEV : signals kernel panic
> + DEV : n/a
> + TRIGGER : "panic"
> +
> +- torch
> + NDEV : torch LED (if there is single available on the platform)
> + DEV : torch LED related to the specified video device
> + DEVICENAME : associated video device, e.g. video1, v4l2-subdev3
> + TRIGGER : "torch"; this LED can be also controlled by v4l2-flash framework
> +
> +- usb
> + NDEV : activity on any USB port
> + DEV : activity on a specified USB port
> + DEVICENAME: associated USB device identifier
> + TRIGGER : "usbport"
> +
> +- numlock
> + NDEV : n/a
> + DEV : keyboard numlock state related to the specified input device
> + DEVICENAME : associated input device, e.g. input1
> + TRIGGER : "kbd-numlock"
> +
> +- capslock
> + NDEV : n/a
> + DEV : keyboard capslock state related to the specified input device
> + DEVICENAME : associated input device, e.g. input1
> + TRIGGER : "kbd-capslock"
> +
> +- scrolllock
> + NDEV : n/a
> + DEV : keyboard scrollock state related to the specified input device
> + DEVICENAME : associated input device, e.g. input1
> + TRIGGER : "kbd-scrolllock"
> +
> +
> +LED functions without corresponding trigger support
> +---------------------------------------------------
> +
> +- alarm
> + NDEV : system wide alarm
> + DEV : n/a
> +
> +- bluetooth
> + NDEV : activity on platform bluetooth adapter
> + DEV : activity on bluetooth adapter related to the specified device
> + DEVICENAME : associated device
> +
> +- boot
> + NDEV : when lit indicates system boot
> + DEV : n/a
> +
> +- charging
> + NDEV : battery charging status
> + DEV : n/a
> +
> +- debug
> + NDEV : signals if device runs in debug mode
> + DEV : n/a
> +
> +- disk-err
> + NDEV : failure on any disk in the system
> + DEV : failure on specified disk
> + DEVICENAME : associted disk, e.g.: hda, sdb
> +
> +- fault
> + NDEV : general system fault
> + DEV : fault on specified system device
> + DEVICENAME : related device name
> +
> +- indicator
> + NDEV : signals if platform camera sensor is active
> + DEV : signals if camera sensor related to the specified video device is active
> + DEVICENAME : associated video device, e.g.: v4l2-subdev3
> +
> +- kbd_backlight
> + NDEV : platform keyboard backlight state
> + DEV : backlight state related to the specified device
> + DEVICENAME : associated device, e.g. input1
> +
> +- mail
> + NDEV : signals a new massage in mailbox
> + DEV : n/a
> +
> +- programming
> + NDEV : platform firmware update is in progress
> + DEV : n/a
> +
> +- power
> + NDEV : power plug presence indicator
> + DEV : n/a
> +
> +- rx
> + NDEV : n/a
> + DEV : activity on rx line of serial port related to the specified tty device
> + DEVICENAME: associated tty device, e.g.: tty1, ttyUSB2
> +
> +- tx
> + NDEV : n/a
> + DEV : activity on tx line of serial port related to the specified tty device
> + DEVICENAME: associated tty device, e.g.: tty1, ttyUSB2
> +
> +- sd
> + NDEV : n/a
> + DEV : activity on sd card related to the specified device
> + DEVICENAME: associated disk, e.g. sdb
> +
> +- sleep
> + NDEV : signals any variant of system hibernation or suspend state
> + DEV : n/a
> +
> +- standby
> + NDEV : device standby status
> + DEV : n/a
> +
> +- status
> + NDEV : system wide status LED
> + DEV : n/a
> +
> +- system
> + NDEV : system is fully operating
> + DEV : n/a
> +
> +- wan
> + NDEV : activity on any WAN device
> + DEV : activity on a specified WAN device
> + DEVICENAME: associated WAN device identifier
> +
> +- wps
> + NDEV : n/a
> + DEV : wps functionality activation state related to the specified device
> + DEVICENAME : associated device name
next prev parent reply other threads:[~2020-09-20 16:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-20 16:26 [PATCH] leds: Document standard LED functions Jacek Anaszewski
2020-09-20 16:44 ` Marek Behun [this message]
2020-09-20 17:21 ` Jacek Anaszewski
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=20200920184422.60c04194@nic.cz \
--to=marek.behun@nic.cz \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox