ethernet "bus" number in DTS ?

[Michal Suchánek]

On Fri, 26 Oct 2018 15:57:15 -0700
Florian Fainelli <f.fainelli at gmail.com> wrote:

> On 10/23/18 11:22 PM, Michal Suchánek wrote:
> > On Tue, 23 Oct 2018 11:20:36 -0700
> > Florian Fainelli <f.fainelli at gmail.com> wrote:
> >   
> >> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:  
> >>> On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:    
> >   
> >>>
> >>> I also noted that using status = "disabled" didn't work either to
> >>> create a fix name scheme. Even worse, all the eth I/F after gets
> >>> renumbered. It seems to me there is value in having stability in
> >>> eth I/F naming at boot. Then userspace(udev) can rename if need
> >>> be. 
> >>>
> >>> Sure would like to known more about why this feature is not
> >>> wanted ?
> >>>
> >>> I found
> >>>   https://patchwork.kernel.org/patch/4122441/
> >>> You quote policy as reason but surely it must be better to
> >>> have something stable, connected to the hardware name, than
> >>> semirandom naming?    
> >>
> >> If the Device Tree nodes are ordered by ascending base register
> >> address, my understanding is that you get the same order as far as
> >> platform_device creation goes, this may not be true in the future
> >> if Rob decides to randomize that, but AFAICT this is still true.
> >> This may not work well with status = disabled properties being
> >> inserted here and there, but we have used that here and it has
> >> worked for as far as I can remember doing it.  
> > 
> > So this is unstable in several respects. First is changing the
> > enabled/disabled status in the deivecetrees provided by the kernel.
> > 
> > Second is if you have hardware hotplug mechanism either by firmware
> > or by loading device overlays.
> > 
> > Third is the case when the devicetree is not built as part of the
> > kernel but is instead provided by firmware that initializes the
> > low-level hardware details. Then the ordering by address is not
> > guaranteed nor is that the same address will be used to access the
> > same interface every time. There might be multiple ways to
> > configure the hardware depending on firmware configuration and/or
> > version.
> > 
> >    
> >> Second, you might want to name network devices ethX, but what if I
> >> want to name them ethernetX or fooX or barX? Should we be
> >> accepting a mechanism in the kernel that would allow someone to
> >> name the interfaces the way they want straight from a name being
> >> provided in Device Tree?  
> > 
> > Clearly if there is text Ethernet1 printed above the Ethernet port
> > we should provide a mechanism to name the port Ethernet1 by
> > default.  
> 
> Yes, but then have a specific property that is flexible enough to
> retrieve things like "vital product information". For DSA switches, we
> have an optional "label" property which names the network device
> directly like it would be found on the product's case. Ideally this
> should be much more flexible such that it can point to the appropriate
> node/firmware service/whatever to get that name, which is what some
> people have been working on lately, see [1].
> 
> [1]: https://lkml.org/lkml/2018/8/14/1039

That's nice for something unique per-device like MAC address. However,
for something per-model like port labels DT properties should suffice.

> 
> The point is don't re-purpose the aliases which is something that
> exists within Device Tree to basically provide a shorter path to a
> specific set of nodes for the boot program to mangle and muck with
> instead of having to resolve a full path to a node. At least that is
> how I conceive it.
> 
> Now what complicates the matter is that some OSes like Linux tend to
> use it to also generate seemingly stable index for peripherals that
> are numbered by index such as SPI, I2C, etc buses, which is why we are
> having this conversation here, see below for more.
> 
> >   
> >>
> >> Aliases are fine for providing relative stability within the Device
> >> Tree itself and boot programs that might need to modify the Device
> >> Tree (e.g: inserting MAC addresses) such that you don't have to
> >> encode logic to search for nodes by compatible strings etc. but
> >> outside of that use case, it seems to me that you can resolve every
> >> naming decision in user-space.  
> > 
> > However, this is pushing platform-specific knowledge to userspace.
> > The way the Ethernet interface is attached and hence the device
> > properties usable for identifying the device uniquely are
> > platform-specific.  
> 
> There is always going to be some amount of platform specific knowledge
> to user-space, what matters is the level of abstraction that is
> presented to you.
> 
> > 
> > On the other hand, aliases are universal when provided. If they are
> > good enough to assign a MAC address they are good enough to provide
> > a stable default name.  
> 
> We are not talking about the same aliases then. The special Device
> Tree node named "aliases" is a way to create shorted Device Tree node
> paths, it is not by any means an equivalent for what I would rather
> call a "label", or "port name" or silk screen annotation on a PCB for
> instance.

However, if the kernel ethN names are deterministic based on something
like aliases it is trivial to translate them to "port name". As it is
they are pretty much random which is the issue aliases *can* solve.

> 
> > 
> > I think this is indeed forcing the userspace to reinvent several
> > wheels for no good reason.  
> 
> udev or systemd will come up with some stable names for your network
> device right off the bat.

As has been already pointed out these names are not stable for various
reasons. *Making* them stable is the whole point of this discussion.
 
> If you are deeply embedded maybe you don't
> want those, but then use something like the full path in /sys to get
> some stable names based on the SoC's topology.

However, it some devices might be disabled depending on the device
configuration generating stable names is not that easy. Also if bus
topology may differ depending on device/firmware configuration you
cannot assign stable names based just on /sys hierarchy. Also it is
said that /sys hierarchy is not an ABI in the kernel docs so you should
not base your stable device names which *are* an ABI on the
unstable /sys hierarchy.

> 
> > 
> > What is the problem with adding the aliases?  
> 
> aliases is IMHO the wrong tool for the job because it is too limiting,
> you want it to be used to have Ethernet controller instance N to be
> named "ethN", what if someone tomorrows says, no this is not good, I
> want the aliases to automatically name my network devices
> "ethernet-controllerN" or "blahblahN"? You see where I am getting
> with that?

Then you can write udev rule to translate ethN to blahlbahN and so long
as the ethN is stable the translation is stable as well. Alternatively
you might want to use a different devicetree property if one existed.

> 
> And yes, I do realize that Linux has traditionally named Ethernet
> adapters ethN, but also allows people to name interfaces just the way
> they want even from within the drivers themselves.
> 
> Now imagine your platform uses ACPI, and there are no aliases there to
> point a node with a shorter name, how we would go about naming your
> Ethernet controller unless there is a specific VPD/label/sticker
> property that can be somehow be retried?

There is biosdevname for that which uses proprietary BIOS extensions to
look up device names in BIOS.

Thanks

Michal