Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>, Pavel Machek <pavel@ucw.cz>,
	Florian Fainelli <f.fainelli@gmail.com>
Cc: 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: Tue, 27 Jul 2021 02:06:19 +0200	[thread overview]
Message-ID: <20210727020619.2ba78163@thinkpad> (raw)
In-Reply-To: <6d2697b1-f0f6-aa9f-579c-48a7abb8559d@gmail.com>

Hi Heiner (and Pavel and Florian and others),

On Mon, 26 Jul 2021 22:59:05 +0200
Heiner Kallweit <hkallweit1@gmail.com> wrote:

> The issue with this is mentioned by Andrew a few lines before. At least in
> network subsystem the kernel identifiers can be changed from userspace.
> Typical example is the interface renaming from eth0 to e.g. enp1s0.
> Then a LED eth0-led1 would have to be automagically renamed to enp1s0-led1.
> An option for this could be to make a LED renaming function subscribe to
> interface name change notifications. But this looks to me to like using a
> quite big hammer for a rather small nail.

We are not going to be renaming LEDs on inteface rename, that can
introduce a set of problems on it's own.

Yes, if network interface renaming were not possible, the best option
would be to use interface names. It is not possible.

The last time we discussed this (Andrew, Pavel and I), we've decided
that for ethernet PHY controlled LEDs we want the devicename part
should be something like
   phyN  or  ethphyN  or  ethernet-phyN
with N a number unique for every PHY (a simple atomically increased
integer for every ethernet PHY). (This is because the LED pin is
physically connected to the PHY.)

But we can't do this here, because in the case of this igc driver, the
LEDs are controlled by the MAC, not the PHY (as far as I understand).
Which means that the LED is connected to a pin on the SOC or MAC chip.

Florian's suggestion is to use dev_name(), he says:
  FWIW, dev_name() should be the "devicename" from what you described 
  above. This is foundational property for all devices that Linux 
  registers that is used for logging, name spacing within /sys/, uniqe, 
  ABI stable, etc. Anything different would be virtually impossible to 
  maintain and would lead to ABI breakage down the road, guaranteed.

I understand this point of view, since the purpose of dev_name() is
to represent devices in userspace. And for the purpose of LED devicename
part it works beautifully sometimes, for block devices for example,
where the dev_name() is be mmc0, sda1, ...

The problem is that for other kind of devices dev_name() may contain the
':' character (and often it does), which can break parsing LED names,
since the LED name format also contains colons:
  devicename:color:function
So in the case of a block device, it works:
  mmc0::
  sda:red:read
  dm-0::write
But for a PCIe network controller it may contain too many colons:
  0000:02:00.0:yellow:activity

So basically this LED device naming scheme is the reason why we are
trying to make prettier names for LED trigger sources / controllers.

The possible solutions here are the following (the list is not
exhaustive):
- allow using devicenames containing ':' characters, i.e.
    0000:02:00.0:yellow:activity
  This can break existing userspace utilities (there are no official
  ones, though). But IMO it should be a viable solution since we can
  extract the devicename part, because we know that the color and
  function parts do not contain colons.

- substitute ':' characters with a different character in the devicename
  part

- use a prettier name, like we wanted to do with ethernet PHYs.

  The question is what do we want to do for MAC (instead of PHY)
  controlled LEDs, as is the case in this igc driver. We could introduce
  a simple atomically increased integer for every MAC, the same we want
  to do in the PHY case, so the devicename could be something like
  macN (or ethmacN or ethernet-macN)

I confess that I am growing a little frustrated here, because there
seems to be no optimal solution with given constraints and no official
consensus for a suboptimal yet acceptable solution.

Marek

  reply	other threads:[~2021-07-27  0:06 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16 21:24 [PATCH net-next 0/5][pull request] 1GbE Intel Wired LAN Driver Updates 2021-07-16 Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 1/5] igc: Add possibility to add flex filter Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 2/5] igc: Integrate flex filter into ethtool ops Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 3/5] igc: Allow for Flex Filters to be installed Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 4/5] igc: Make flex filter more flexible Tony Nguyen
2021-07-16 21:24 ` [PATCH net-next 5/5] igc: Export LEDs Tony Nguyen
2021-07-16 21:56   ` Andrew Lunn
2021-07-18 22:10     ` Heiner Kallweit
2021-07-18 22:33       ` Andrew Lunn
2021-07-19  6:17         ` Kurt Kanzenbach
2021-07-19  9:46           ` Jakub Kicinski
2021-07-19  6:06     ` Kurt Kanzenbach
2021-07-19 13:15       ` Andrew Lunn
2021-07-20  8:54         ` Kurt Kanzenbach
2021-07-21 19:18         ` Marek Behún
2021-07-18 22:19   ` Heiner Kallweit
2021-07-19  0:40     ` Andrew Lunn
2021-07-20 15:00       ` 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
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 [this message]
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
2021-07-19 21:48   ` Jesse Brandeburg
2021-07-20 13:31     ` Kurt Kanzenbach
2021-07-17  0:30 ` [PATCH net-next 0/5][pull request] 1GbE Intel Wired LAN Driver Updates 2021-07-16 patchwork-bot+netdevbpf
2021-07-17 17:36   ` Andrew Lunn

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=20210727020619.2ba78163@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=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=jacek.anaszewski@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 \
    --subject='Re: [PATCH net-next 5/5] igc: Export LEDs' \
    /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

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).