On 8/8/22 14:28, Tim Harvey wrote:
On Mon, Aug 8, 2022 at 2:19 PM Florian Fainelli <f.fainelli@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx/
- 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
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
