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

[Florian Fainelli <f.fainelli@gmail.com>]

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

> 
> 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