All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Behún" <kabel@kernel.org>
To: Pavel Machek <pavel@ucw.cz>, Andrew Lunn <andrew@lunn.ch>
Cc: "linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	netdev@vger.kernel.org,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>
Subject: devicename part of LEDs under ethernet MAC / PHY
Date: Fri, 1 Oct 2021 13:30:57 +0200	[thread overview]
Message-ID: <20211001133057.5287f150@thinkpad> (raw)

Hello Pavel, Andrew,

previously we discussed devicename part of LEDs connected under
ethernet MACs and/or ethrenet PHYs.

I would like to finally settle this, but there is one more thing that
may be problematic.

To remind the current proposal, discussed in previous e-mails:

- for LEDs under an ethernet PHY, the devicename part of the LED should
  be "ethphyN", with N an auto-incrementing number for each struct
  phy_device
- for LEDs under an ethernet MAC, it should be similar: "ethmacN"

- the numbers in ethmac and ethphy are unrelated and cannot be related

- Andrew proposed that the numbering should start at non-zero number,
  for example at 42, to prevent people from thinking that the numbers
  are related to numbers in network interface names (ethN).
  A system with interfaces
    eth0
    eth1
  and LEDs
    ethphy0:green:link
    ethphy1:green:link
  may make user think that the ethphy0 LED does correspond to eth0
  interface, which is not necessarily true.
  Instead if LEDs are
    ethphy42:green:link
    ethphy43:green:link 
  the probability of confusing the user into relating them to network
  interfaces by these numbers is lower.

Anyway, the issue with these naming is that it is not stable. Upgrading
the kernel, enabling drivers and so on can change these names between
reboots. Also for LEDs on USB ethernet adapters, removing the USB and
plugging it again would change the name, although the device path does
not change if the adapter is re-plugged into the same port.

To finally settle this then, I would like to ask your opinion on
whether this naming of LEDs should be stable.

Note that this names are visible to userspace as symlinks
/sys/class/leds directory. If they are unstable, it is not that big an
issue, because mostly these LEDs should be accessed via
/sys/class/net/<interface>/device/leds for eth MAC LEDs and via
/sys/class/net/<interface>/phydev/leds for eth PHY LEDs.

If we wanted to make these names stable, we would need to do something
like
  ethphy-BUS-ID
for example
  ethphy-usb3,2
  ethmac-pci0,19,0
  ethphy-mdio0,1
or
  ethmac-DEVICE_PATH (with '/'s and ':'s replaced with ',' or something)
for example
  ethphy-platform,soc,soc,internal-regs,f10f0000.usb3,usb3,3-0,1:0

The first scheme is nicer but would need some additional code for each
bus.
The second scheme is simpler to implement, but the naming is hideous -
the whole point of devicename part of LEDs was (in my understanding) to
be a nice name, like "mmc0".

Marek

             reply	other threads:[~2021-10-01 11:31 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-01 11:30 Marek Behún [this message]
2021-10-01 12:29 ` devicename part of LEDs under ethernet MAC / PHY Andrew Lunn
2021-10-01 12:40   ` Marek Behún
2021-10-03 20:53     ` are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY) Marek Behún
2021-10-04  6:37       ` Greg Kroah-Hartman
2021-10-04  7:04         ` Marek Behún
2021-10-04  7:10           ` Greg Kroah-Hartman
2021-10-04  7:25             ` Marek Behún
2021-10-04  7:38             ` Pavel Machek
2021-10-04  8:30               ` Greg Kroah-Hartman
2021-10-04 12:14                 ` 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=20211001133057.5287f150@thinkpad \
    --to=kabel@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=netdev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.