linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Pavel Machek <pavel@ucw.cz>,
	Tony Nguyen <anthony.l.nguyen@intel.com>,
	davem@davemloft.net, kuba@kernel.org,
	Kurt Kanzenbach <kurt@linutronix.de>,
	netdev@vger.kernel.org, sasha.neftin@intel.com,
	vitaly.lifshits@intel.com, vinicius.gomes@intel.com,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Dvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Subject: Re: [PATCH net-next 5/5] igc: Export LEDs
Date: Wed, 21 Jul 2021 22:07:16 +0200	[thread overview]
Message-ID: <20210721220716.539f780e@thinkpad> (raw)
In-Reply-To: <YPh6b+dTZqQNX+Zk@lunn.ch>

On Wed, 21 Jul 2021 21:50:07 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> > Hi Heiner,
> > 
> > in sysfs, all devices registered under LED class will have symlinks in
> > /sys/class/leds. This is how device classes work in Linux.
> > 
> > There is a standardized format for LED device names, please look at
> > Documentation/leds/leds-class.rst.
> > 
> > Basically the LED name is of the format
> >   devicename:color:function  
> 
> The interesting part here is, what does devicename mean, in this
> context?
> 
> We cannot use the interface name, because it is not unique, and user
> space can change it whenever it wants. So we probably need to build
> something around the bus ID, e.g. pci_id. Which is not very friendly
> :-(

Unfortunately there isn't consensus about what the devicename should
mean. There are two "schools of thought":

1. device name of the trigger source for the LED, i.e. if the LED
   blinks on activity on mmc0, the devicename should be mmc0. We have
   talked about this in the discussions about ethernet PHYs.
   In the case of the igc driver if the LEDs are controlled by the MAC,
   I guess some PCI identifier would be OK. Or maybe ethernet-mac
   identifier, if we have something like that? (Since we can't use
   interface names due to the possibility of renaming.)

   Pavel and I are supporters of this scheme.

2. device name of the LED controller. For example LEDs controlled by
   the maxim,max77650-led controller (leds-max77650.c) define device
   name as "max77650"

   Jacek supports this scheme.

The complication is that both these schemes are used already in
upstream kernel, and we have to maintain backwards compatibility of
sysfs ABI, so we can't change that.

I have been thinking for some time that maybe we should poll Linux
kernel developers about these two schemes, so that a consensus is
reached. Afterwards we can deprecate the other scheme and add a Kconfig
option (default n for backwards compatibility) to use the new scheme.

What do you think?

Marek

  reply	other threads:[~2021-07-21 20:07 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210716212427.821834-1-anthony.l.nguyen@intel.com>
     [not found] ` <20210716212427.821834-6-anthony.l.nguyen@intel.com>
     [not found]   ` <f705bcd6-c55c-0b07-612f-38348d85bbee@gmail.com>
     [not found]     ` <YPTKB0HGEtsydf9/@lunn.ch>
2021-07-20 15:00       ` [PATCH net-next 5/5] igc: Export LEDs Heiner Kallweit
2021-07-20 15:42         ` Andrew Lunn
2021-07-20 20:29           ` Heiner Kallweit
2021-07-21 14:35             ` Andrew Lunn
2021-07-21 16:02               ` Heiner Kallweit
2021-07-21 18:23               ` Pavel Machek
2021-07-21 18:25                 ` Pavel Machek
2021-07-21 18:45             ` Marek Behún
2021-07-21 19:50               ` Andrew Lunn
2021-07-21 20:07                 ` Marek Behún [this message]
2021-07-21 20:54                   ` Andrew Lunn
2021-07-21 21:31                     ` Marek Behún
2021-07-21 22:45                     ` Pavel Machek
2021-07-22  1:45                       ` Andrew Lunn
2021-07-22  2:19                         ` Marek Behún
2021-07-21 22:34                   ` Pavel Machek
2021-07-22  3:52                   ` Florian Fainelli
2021-07-26 17:42                   ` Jacek Anaszewski
2021-07-26 18:44                     ` Marek Behún
2021-07-26 20:59                     ` Heiner Kallweit
2021-07-27  0:06                       ` Marek Behún
2021-07-27  1:57                         ` Andrew Lunn
2021-07-27  8:15                           ` Michael Walle
2021-07-27 14:56                             ` Marek Behún
2021-07-27 15:03                               ` Michael Walle
2021-07-27 15:24                                 ` Andrew Lunn
2021-07-27 15:28                                 ` Marek Behún
2021-07-27 15:53                                   ` Michael Walle
2021-07-27 16:23                                     ` Andrew Lunn
2021-07-27 16:32                                     ` Marek Behún
2021-07-27 16:42                                       ` Andrew Lunn
2021-07-27 19:42                                       ` Michael Walle
2021-07-28 20:43                                       ` Heiner Kallweit
2021-07-29  6:39                                         ` Kurt Kanzenbach
2021-07-29  8:59                                         ` Marek Behún
2021-07-29 21:54                                           ` Heiner Kallweit
2021-08-10 17:29                                         ` Pavel Machek
2021-08-10 17:55                                           ` Marek Behún
2021-08-10 19:53                                             ` Pavel Machek
2021-08-10 20:53                                               ` Marek Behún
2021-08-17 19:02                                                 ` Pavel Machek
2021-08-25 15:26                                                   ` Marek Behún
2021-08-26 12:45                                                     ` Pavel Machek
2021-08-10 20:46                                           ` Heiner Kallweit
2021-08-10 21:21                                             ` Andrew Lunn
2021-07-27 13:55                           ` Marek Behún
2021-08-10 17:22                             ` Documentation for naming LEDs was " 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=20210721220716.539f780e@thinkpad \
    --to=kabel@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=anthony.l.nguyen@intel.com \
    --cc=bigeasy@linutronix.de \
    --cc=davem@davemloft.net \
    --cc=dvorax.fuxbrumer@linux.intel.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=kurt@linutronix.de \
    --cc=linux-leds@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=sasha.neftin@intel.com \
    --cc=vinicius.gomes@intel.com \
    --cc=vitaly.lifshits@intel.com \
    /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).