lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 8 Aug 2022 14:28:17 -0700
From:   Tim Harvey <>
To:     Florian Fainelli <>
Cc:     Sean Anderson <>,
        netdev <>, u-boot <>,
        Device Tree Mailing List <>
Subject: Re: ethernet<n> dt aliases implications in U-Boot and Linux

On Mon, Aug 8, 2022 at 2:19 PM Florian Fainelli <> 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:
- systemd predicatable 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.

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.

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.

Best Regards,


Powered by blists - more mailing lists