ethernet<n> dt aliases implications in U-Boot and Linux

[Tim Harvey]

On Mon, Aug 8, 2022 at 2:34 PM Florian Fainelli <f.fainelli at gmail.com> wrote:
>
> On 8/8/22 14:28, Tim Harvey wrote:
> > On Mon, Aug 8, 2022 at 2:19 PM Florian Fainelli <f.fainelli at gmail.com> wrote:
> >>
> >> On 8/8/22 12:57, Sean Anderson wrote:
> >>> Hi Tim,
> >>>
> >>> On 8/8/22 3:18 PM, Tim Harvey wrote:
> >>>> Greetings,
> >>>>
> >>>> I'm trying to understand if there is any implication of 'ethernet<n>'
> >>>> aliases in Linux such as:
> >>>>           aliases {
> >>>>                   ethernet0 = &eqos;
> >>>>                   ethernet1 = &fec;
> >>>>                   ethernet2 = &lan1;
> >>>>                   ethernet3 = &lan2;
> >>>>                   ethernet4 = &lan3;
> >>>>                   ethernet5 = &lan4;
> >>>>                   ethernet6 = &lan5;
> >>>>           };
> >>>>
> >>>> I know U-Boot boards that use device-tree will use these aliases to
> >>>> name the devices in U-Boot such that the device with alias 'ethernet0'
> >>>> becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
> >>>> appears that the naming of network devices that are embedded (ie SoC)
> >>>> vs enumerated (ie pci/usb) are always based on device registration
> >>>> order which for static drivers depends on Makefile linking order and
> >>>> has nothing to do with device-tree.
> >>>>
> >>>> Is there currently any way to control network device naming in Linux
> >>>> other than udev?
> >>>
> >>> You can also use systemd-networkd et al. (but that is the same kind of mechanism)
> >>>
> >>>> Does Linux use the ethernet<n> aliases for anything at all?
> >>>
> >>> No :l
> >>
> >> It is actually used, but by individual drivers, not by the networking
> >> stack AFAICT:
> >>
> >> git grep -E "of_alias_get_id\((.*), \"(eth|ethernet)\"\)" *
> >> drivers/net/ethernet/broadcom/genet/bcmmii.c:           id =
> >> of_alias_get_id(dn, "eth");
> >> drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:    plat->bus_id =
> >> of_alias_get_id(np, "ethernet");
> >> drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:   plat->bus_id =
> >> of_alias_get_id(np, "ethernet");
> >> drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:  plat->bus_id =
> >> of_alias_get_id(np, "ethernet");
> >>
> >> There were discussions about using that alias to name ethernet network
> >> devices in the past (cannot quite point to the thread), the current
> >> consensus appears to be that if you use the "label" property (which was
> >> primed by DSA) then your network device will follow that name, still not
> >> something the networking stack does for you within the guts of
> >> register_netdev().
> >
> > Right, I recall several discussions and debates about this.
> >
> > I did find a few references:
> > - failed attempt at using dt for naming:
> > https://patchwork.kernel.org/project/linux-arm-kernel/patch/1399390594-1409-1-git-send-email-boris.brezillon@free-electrons.com/
> > - systemd predicatable interface names:
> > https://systemd.io/PREDICTABLE_INTERFACE_NAMES/
> >
> > I do find it odd that for DSA devices the port names are defined in dt
> > yet the cpu uplink port can not be.
>
> There is no network interface created for the CPU port on the switch
> side, and the other network device (named the DSA conduit) is just a
> conduit, so its name does not matter so much except for making sure that
> it is brought up before the DSA ports that are dependent upon it and
> that can be resolved via "ip link show (the interface after the '@'). It
> matter even less nowadays that it gets brought up automatically by any
> of the user facing ports of the DSA switch:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d5ef190e5615a7b63af89f88c4106a5bc127974
>

Florian,

Thanks for pointing this out - I had not noticed that addition which
looks like it made it in at v5.12.

Tim

> >
> > The issue I was trying to work through is an IMX8MP board which has
> > IMX8MP FEC as the cpu uplink port to a GbE switch and IMX8MP EQOS as
> > an additional GbE. In this case the FEC enumerates first becoming eth0
> > and the EQOS second becoming eth1. I wanted to make the EQOS eth0 as
> > it is the first RJ45 on the board physically followed by
> > lan1/lan2/lan3/lan4/lan5. While I can do this in U-Boot by controlling
> > the aliases for fec/eqos the same doesn't work for Linux so it's not
> > worth doing as that would add user confusion.
>
> None of that should matter in Linux anymore however, the names of the
> Ethernet controller(s) connected to your switch have no significance,
> see above.
>
> >
> > I have never liked the idea of using systemd to deal with network
> > interface re-naming as that's just another dependency where embedded
> > Linux users typically want to strip things down to the bare minimum.
>
> Fair enough.
> --
> Florian