* devicename part of LEDs under ethernet MAC / PHY
@ 2021-10-01 11:30 Marek Behún
2021-10-01 12:29 ` Andrew Lunn
0 siblings, 1 reply; 11+ messages in thread
From: Marek Behún @ 2021-10-01 11:30 UTC (permalink / raw)
To: Pavel Machek, Andrew Lunn; +Cc: linux-leds, netdev, Jacek Anaszewski
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: devicename part of LEDs under ethernet MAC / PHY
2021-10-01 11:30 devicename part of LEDs under ethernet MAC / PHY Marek Behún
@ 2021-10-01 12:29 ` Andrew Lunn
2021-10-01 12:40 ` Marek Behún
0 siblings, 1 reply; 11+ messages in thread
From: Andrew Lunn @ 2021-10-01 12:29 UTC (permalink / raw)
To: Marek Behún; +Cc: Pavel Machek, linux-leds, netdev, Jacek Anaszewski
> - 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.
Sure, eth0 can become eth1, eth1 can become eth0. That is why we have
udev rules, systemd interface names etc. Interface names have never
been guaranteed to be stable. Also, you can have multiple interfaces
named eth0, so long as they are in different network name spaces.
> 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.
No. They should be unstable like everything else.
> 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.
Yes, this also handles network name space nicely.
> 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
I guess Systemd can be extended to do this, maybe, rename the LEDs
when it renames the interface? This is not really a kernel problem.
Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: devicename part of LEDs under ethernet MAC / PHY
2021-10-01 12:29 ` 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
0 siblings, 1 reply; 11+ messages in thread
From: Marek Behún @ 2021-10-01 12:40 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Pavel Machek, linux-leds, netdev, Jacek Anaszewski
On Fri, 1 Oct 2021 14:29:17 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> > - 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.
>
> Sure, eth0 can become eth1, eth1 can become eth0. That is why we have
> udev rules, systemd interface names etc. Interface names have never
> been guaranteed to be stable. Also, you can have multiple interfaces
> named eth0, so long as they are in different network name spaces.
>
> > 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.
>
> No. They should be unstable like everything else.
LED classdev names are something different.
For etherent interfaces, the interface name is different from name of
the underlying struct device. But LED classdev names are also
corresponding struct device names, and thus part of sysfs ABI, which,
as far as I understand, 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.
>
> Yes, this also handles network name space nicely.
>
> > 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
>
> I guess Systemd can be extended to do this, maybe, rename the LEDs
> when it renames the interface? This is not really a kernel problem.
Pavel is against LED classdev renaming.
Marek
^ permalink raw reply [flat|nested] 11+ messages in thread
* are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)
2021-10-01 12:40 ` Marek Behún
@ 2021-10-03 20:53 ` Marek Behún
2021-10-04 6:37 ` Greg Kroah-Hartman
0 siblings, 1 reply; 11+ messages in thread
From: Marek Behún @ 2021-10-03 20:53 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andrew Lunn, Pavel Machek, linux-leds, netdev, Jacek Anaszewski,
linux-kernel
Hello Greg,
could you give your opinion on this discussion?
Are device names (as returned by dev_name() function) also part of
sysfs ABI? Should these names be stable across reboots / kernel
upgrades?
Marek
On Fri, 1 Oct 2021 14:40:53 +0200
Marek Behún <kabel@kernel.org> wrote:
> On Fri, 1 Oct 2021 14:29:17 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > - 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.
> >
> > Sure, eth0 can become eth1, eth1 can become eth0. That is why we have
> > udev rules, systemd interface names etc. Interface names have never
> > been guaranteed to be stable. Also, you can have multiple interfaces
> > named eth0, so long as they are in different network name spaces.
> >
> > > 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.
> >
> > No. They should be unstable like everything else.
>
> LED classdev names are something different.
> For etherent interfaces, the interface name is different from name of
> the underlying struct device. But LED classdev names are also
> corresponding struct device names, and thus part of sysfs ABI, which,
> as far as I understand, should be stable.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)
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
0 siblings, 1 reply; 11+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-04 6:37 UTC (permalink / raw)
To: Marek Behún
Cc: Andrew Lunn, Pavel Machek, linux-leds, netdev, Jacek Anaszewski,
linux-kernel
On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> Hello Greg,
>
> could you give your opinion on this discussion?
What discussion? Top posting ruins that :(
> Are device names (as returned by dev_name() function) also part of
> sysfs ABI? Should these names be stable across reboots / kernel
> upgrades?
Stable in what exact way?
Numbering of devices (where a dynamic value is part of a name, like the
"42" in "usb42"), is never guaranteed to be stable, but the non-number
part of the name (like "usb" is in "usb42") is stable, as that is what
you have properly documented in the Documentation/ABI/ files defining
the bus and class devices, right?
The very reason we export all of this information to userspace is so
that userspace can figure it all out in ways it wants to, if it wants
to, and no naming scheme that has to be static and deterministic is
forced into the kernel, where it does NOT belong.
That is 1/2 of the reason why we created the whole "unified
device/driver model" in the kernel in the first place all those years
ago.
Does that help? I can't figure out what the "problem" is here...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)
2021-10-04 6:37 ` Greg Kroah-Hartman
@ 2021-10-04 7:04 ` Marek Behún
2021-10-04 7:10 ` Greg Kroah-Hartman
0 siblings, 1 reply; 11+ messages in thread
From: Marek Behún @ 2021-10-04 7:04 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andrew Lunn, Pavel Machek, linux-leds, netdev, Jacek Anaszewski,
linux-kernel
Hi Greg,
On Mon, 4 Oct 2021 08:37:37 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> > Hello Greg,
> >
> > could you give your opinion on this discussion?
>
> What discussion? Top posting ruins that :(
Sorry, the discussion is here
https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
But the basic question is below, so you don't need to read the
discussion.
> > Are device names (as returned by dev_name() function) also part of
> > sysfs ABI? Should these names be stable across reboots / kernel
> > upgrades?
>
> Stable in what exact way?
Example:
- Board has an ethernet PHYs that is described in DT, and therefore
has stable sysfs path (derived from DT path), something like
/sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
- The PHY has a subnode describing a LED.
The LED subsystem has a different naming scheme (it uses DT node name
as a last resort). When everything is okay, the dev_name() of the LED
will be something like
ethphy42:green:link
- Now suppose that the PHY driver is unloaded and loaded again. The PHY
sysfs path is unchanged, but the LED will now be named
ethphy43:green:link
Is this OK?
> Numbering of devices (where a dynamic value is part of a name, like the
> "42" in "usb42"), is never guaranteed to be stable, but the non-number
> part of the name (like "usb" is in "usb42") is stable, as that is what
> you have properly documented in the Documentation/ABI/ files defining
> the bus and class devices, right?
It does make sense for removable devices like USB. What I am asking
is whether it is also OK for devices that have stable DT nodes.
Marek
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)
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
0 siblings, 2 replies; 11+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-04 7:10 UTC (permalink / raw)
To: Marek Behún
Cc: Andrew Lunn, Pavel Machek, linux-leds, netdev, Jacek Anaszewski,
linux-kernel
On Mon, Oct 04, 2021 at 09:04:38AM +0200, Marek Behún wrote:
> Hi Greg,
>
> On Mon, 4 Oct 2021 08:37:37 +0200
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
>
> > On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> > > Hello Greg,
> > >
> > > could you give your opinion on this discussion?
> >
> > What discussion? Top posting ruins that :(
>
> Sorry, the discussion is here
> https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
> But the basic question is below, so you don't need to read the
> discussion.
>
> > > Are device names (as returned by dev_name() function) also part of
> > > sysfs ABI? Should these names be stable across reboots / kernel
> > > upgrades?
> >
> > Stable in what exact way?
>
> Example:
> - Board has an ethernet PHYs that is described in DT, and therefore
> has stable sysfs path (derived from DT path), something like
> /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
None of the numbers there are "stable", right?
> - The PHY has a subnode describing a LED.
> The LED subsystem has a different naming scheme (it uses DT node name
> as a last resort). When everything is okay, the dev_name() of the LED
> will be something like
> ethphy42:green:link
Wonderful, but the "42" means nothing.
> - Now suppose that the PHY driver is unloaded and loaded again. The PHY
> sysfs path is unchanged, but the LED will now be named
> ethphy43:green:link
>
> Is this OK?
Yup!
The "link" should point to the device it is associated with, right? You
need to have some way to refer to the device.
> > Numbering of devices (where a dynamic value is part of a name, like the
> > "42" in "usb42"), is never guaranteed to be stable, but the non-number
> > part of the name (like "usb" is in "usb42") is stable, as that is what
> > you have properly documented in the Documentation/ABI/ files defining
> > the bus and class devices, right?
>
> It does make sense for removable devices like USB. What I am asking
> is whether it is also OK for devices that have stable DT nodes.
Any device can be "removed" from the system and added back thanks to the
joy of the driver model :)
Also, what prevents your DT from renumbering things in an update to it
in the future? The kernel doesn't care, and userspace should be able to
handle it.
Again, any numbering scheme is NEVER stable, just because it feels like
it is at the moment for your device, you should NEVER rely on that, but
instead rely on the attributes of the device to determine what it is and
where it is in the device hierarchy (serial number, position location,
partition name, etc.) in order to know what it associated with.
And again, this is 1/2 of the whole reason _why_ we created the unified
driver model in the kernel. Don't try to go back to the nightmare that
we had in the 2.4 and earlier kernel days please.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)
2021-10-04 7:10 ` Greg Kroah-Hartman
@ 2021-10-04 7:25 ` Marek Behún
2021-10-04 7:38 ` Pavel Machek
1 sibling, 0 replies; 11+ messages in thread
From: Marek Behún @ 2021-10-04 7:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Andrew Lunn, Pavel Machek, linux-leds, netdev, Jacek Anaszewski,
linux-kernel
On Mon, 4 Oct 2021 09:10:35 +0200
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Mon, Oct 04, 2021 at 09:04:38AM +0200, Marek Behún wrote:
> > Hi Greg,
> >
> > On Mon, 4 Oct 2021 08:37:37 +0200
> > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >
> > > On Sun, Oct 03, 2021 at 10:53:38PM +0200, Marek Behún wrote:
> > > > Hello Greg,
> > > >
> > > > could you give your opinion on this discussion?
> > >
> > > What discussion? Top posting ruins that :(
> >
> > Sorry, the discussion is here
> > https://lore.kernel.org/linux-leds/20211001144053.3952474a@thinkpad/T/
> > But the basic question is below, so you don't need to read the
> > discussion.
> >
> > > > Are device names (as returned by dev_name() function) also part of
> > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > upgrades?
> > >
> > > Stable in what exact way?
> >
> > Example:
> > - Board has an ethernet PHYs that is described in DT, and therefore
> > has stable sysfs path (derived from DT path), something like
> > /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
>
> None of the numbers there are "stable", right?
>
> > - The PHY has a subnode describing a LED.
> > The LED subsystem has a different naming scheme (it uses DT node name
> > as a last resort). When everything is okay, the dev_name() of the LED
> > will be something like
> > ethphy42:green:link
>
> Wonderful, but the "42" means nothing.
>
> > - Now suppose that the PHY driver is unloaded and loaded again. The PHY
> > sysfs path is unchanged, but the LED will now be named
> > ethphy43:green:link
> >
> > Is this OK?
>
> Yup!
>
> The "link" should point to the device it is associated with, right? You
> need to have some way to refer to the device.
>
> > > Numbering of devices (where a dynamic value is part of a name, like the
> > > "42" in "usb42"), is never guaranteed to be stable, but the non-number
> > > part of the name (like "usb" is in "usb42") is stable, as that is what
> > > you have properly documented in the Documentation/ABI/ files defining
> > > the bus and class devices, right?
> >
> > It does make sense for removable devices like USB. What I am asking
> > is whether it is also OK for devices that have stable DT nodes.
>
> Any device can be "removed" from the system and added back thanks to the
> joy of the driver model :)
>
> Also, what prevents your DT from renumbering things in an update to it
> in the future? The kernel doesn't care, and userspace should be able to
> handle it.
>
> Again, any numbering scheme is NEVER stable, just because it feels like
> it is at the moment for your device, you should NEVER rely on that, but
> instead rely on the attributes of the device to determine what it is and
> where it is in the device hierarchy (serial number, position location,
> partition name, etc.) in order to know what it associated with.
>
> And again, this is 1/2 of the whole reason _why_ we created the unified
> driver model in the kernel. Don't try to go back to the nightmare that
> we had in the 2.4 and earlier kernel days please.
OK, thanks Greg. This simplifies things. I shall send another version
of LEDs under ethernet PHYs soon :)
Marek
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)
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
1 sibling, 1 reply; 11+ messages in thread
From: Pavel Machek @ 2021-10-04 7:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Marek Behún, Andrew Lunn, linux-leds, netdev,
Jacek Anaszewski, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Hi!
> > > > Are device names (as returned by dev_name() function) also part of
> > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > upgrades?
> > >
> > > Stable in what exact way?
> >
> > Example:
> > - Board has an ethernet PHYs that is described in DT, and therefore
> > has stable sysfs path (derived from DT path), something like
> > /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
>
> None of the numbers there are "stable", right?
At least f1072004 part is stable (and probably whole path). DT has
advantages here, and we should provide stable paths when we can.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)
2021-10-04 7:38 ` Pavel Machek
@ 2021-10-04 8:30 ` Greg Kroah-Hartman
2021-10-04 12:14 ` Andrew Lunn
0 siblings, 1 reply; 11+ messages in thread
From: Greg Kroah-Hartman @ 2021-10-04 8:30 UTC (permalink / raw)
To: Pavel Machek
Cc: Marek Behún, Andrew Lunn, linux-leds, netdev,
Jacek Anaszewski, linux-kernel
On Mon, Oct 04, 2021 at 09:38:41AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > > Are device names (as returned by dev_name() function) also part of
> > > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > > upgrades?
> > > >
> > > > Stable in what exact way?
> > >
> > > Example:
> > > - Board has an ethernet PHYs that is described in DT, and therefore
> > > has stable sysfs path (derived from DT path), something like
> > > /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
> >
> > None of the numbers there are "stable", right?
>
> At least f1072004 part is stable (and probably whole path). DT has
> advantages here, and we should provide stable paths when we can.
The kernel should enumerate the devices as best that it can, but it
never has the requirement of always enumerating them in the same way
each time as many busses are not deterministic.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: are device names part of sysfs ABI? (was Re: devicename part of LEDs under ethernet MAC / PHY)
2021-10-04 8:30 ` Greg Kroah-Hartman
@ 2021-10-04 12:14 ` Andrew Lunn
0 siblings, 0 replies; 11+ messages in thread
From: Andrew Lunn @ 2021-10-04 12:14 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Pavel Machek, Marek Behún, linux-leds, netdev,
Jacek Anaszewski, linux-kernel
On Mon, Oct 04, 2021 at 10:30:25AM +0200, Greg Kroah-Hartman wrote:
> On Mon, Oct 04, 2021 at 09:38:41AM +0200, Pavel Machek wrote:
> > Hi!
> >
> > > > > > Are device names (as returned by dev_name() function) also part of
> > > > > > sysfs ABI? Should these names be stable across reboots / kernel
> > > > > > upgrades?
> > > > >
> > > > > Stable in what exact way?
> > > >
> > > > Example:
> > > > - Board has an ethernet PHYs that is described in DT, and therefore
> > > > has stable sysfs path (derived from DT path), something like
> > > > /sys/devices/.../mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:01
> > >
> > > None of the numbers there are "stable", right?
> >
> > At least f1072004 part is stable (and probably whole path). DT has
> > advantages here, and we should provide stable paths when we can.
>
> The kernel should enumerate the devices as best that it can, but it
> never has the requirement of always enumerating them in the same way
> each time as many busses are not deterministic.
And for this particular SoC, it is possible to map the memory mapped
IO at a different address range. It is the bootloader which determines
this. There are some Marvell uboot's which use 0xd0000000, not
0xf0000000. So strictly speaking, f1072004 is not stable, it is not
hard wired in the silicon.
Andrew
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-10-04 12:14 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-01 11:30 devicename part of LEDs under ethernet MAC / PHY Marek Behún
2021-10-01 12:29 ` 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
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).