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