netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Behun <marek.behun@nic.cz>
To: netdev <netdev@vger.kernel.org>
Cc: linux-leds@vger.kernel.org, David Miller <davem@davemloft.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Russell King <linux@armlinux.org.uk>
Subject: Request for Comment: LED device naming for netdev LEDs
Date: Sun, 27 Sep 2020 00:40:25 +0200	[thread overview]
Message-ID: <20200927004025.33c6cfce@nic.cz> (raw)

Hi,

linux-leds is trying to create a consistent naming mechanism for LEDs
The schema is:
  device:color:function
for example
  system:green:power
  keyboard0:green:capslock

But we are not there yet.

LEDs are often dedicated to specific function by manufacturers, for
example there can be an icon or a text next to the LED on the case of a
router, indicating that the LED should blink on activity on a specific
ethernet port.

This can be specified in device tree via the trigger-sources property.

We therefore want to select the device part of the LED name to
correspond to the device it should trigger to according to the
manufacturer.

What I am wondering is how should we select a name for the device part
of the LED for network devices, when network namespaces are enabled.

a) We could just use the interface name (eth0:yellow:activity). The
   problem is what should happen when the interface is renamed, or
   moved to another network namespace.
   Pavel doesn't want to complicate the LED subsystem with LED device
   renaming, nor, I think, with namespace mechanism. I, for my part, am
   not opposed to LED renaming, but do not know what should happen when
   the interface is moved to another namespace.

b) We could use the device name, as in struct device *. But these names
   are often too long and may contain characters that we do not want in
   LED name (':', or '/', for example).

c) We could create a new naming mechanism, something like
   device_pretty_name(dev), which some classes may implement somehow.

What are your ideas about this problem?

Marek

             reply	other threads:[~2020-09-26 22:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-26 22:40 Marek Behun [this message]
2020-09-27  0:29 ` Request for Comment: LED device naming for netdev LEDs Andrew Lunn
2020-09-27  0:45   ` Marek Behun
2020-09-27  1:13     ` Andrew Lunn
2020-09-27  0:52 ` Marek Behun
2020-09-28 13:04   ` Alexander Dahl
2020-09-28 15:52     ` Marek Behun
2020-09-28 17:10       ` Alexander Dahl
2020-09-28 17:22         ` Marek Behun
2020-11-25 10:59     ` Pavel Machek
2020-11-25 10:57   ` Pavel Machek

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=20200927004025.33c6cfce@nic.cz \
    --to=marek.behun@nic.cz \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.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).