[PATCH 1/3] net: give a different name to rtl8169 interfaces

[Dragan Simic]

Hello,

On 2024-06-25 12:03, Quentin Schulz wrote:
> On 6/25/24 8:38 AM, Etienne Dublé wrote:
>> Thanks for reviewing my patches.
>> 
>> Le 24/06/2024 à 15:08, Quentin Schulz a écrit :
>>> [...]
>>> 
>>>>   1 file changed, 11 insertions(+)
>>>> 
>>>> diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
>>>> index 93e83661ce..b30d51731f 100644
>>>> --- a/drivers/net/rtl8169.c
>>>> +++ b/drivers/net/rtl8169.c
>>>> @@ -1091,6 +1091,16 @@ static int rtl8169_eth_probe(struct udevice 
>>>> *dev)
>>>>       return 0;
>>>>   }
>>>>   +static int rtl8169_eth_bind(struct udevice *dev)
>>>> +{
>>>> +    static int card_number;
>>>> +    char name[16];
>>>> +
>>>> +    sprintf(name, "RTL8169#%u", card_number++);
>>>> +
>>>> +    return device_set_name(dev, name);
>>>> +}
>>>> +
>>> 
>>> I don't think we can guarantee bind order so this may not be stable 
>>> over time.
>>> 
>>> I'm wondering if there isn't a way to use the "ethernet" (ethernet0, 
>>> ethernet1) alias in DT instead?
>> 
>> Actually the ethernet interfaces are not declared in the device tree, 
>> only PCI buses are (at least on this Nanopi board).
>> The ethernet interfaces are only detected when running "pci enum".
>> 
> 
> Ah shoot.
> 
>> Another option may be to name them "rtl8169@<hexa>", with "<hexa>" 
>> reflecting the PCI region address (so it is unique and stable). What 
>> do you think?
>> 
> 
> I guess that's one way, I'm also wondering how systemd renames those
> to be unique but stable on the same machine, maybe we could take some
> inspiration from them for that?

Systemd also allows renaming of network interfaces using some rules
predefined by the user, so there's also the possibility to rename the
interfaces in U-Boot to ethernet0 and ethernet1, using fixed rules
that would be based on the PCI region address.

> FYI, for NVMEs I also have
> /dev/disk/by-path/platform-fe190000.pcie-pci-0004:41:00.0-nvme-1 for
> example. platform-fe19000.pcie- being the pcie controller at address
> fe19000 on the platform root bus, no clue about what's after that
> though. I also assume the N in nvme-N isn't necessarily stable over
> time but whatever's before should be? Maybe there's something like
> ports/addresses on the PCIe bus that will never change or rely on
> probe order/timings to keep a stable naming?
> Sorry, don't know much about PCIe so cannot suggest anything meaningful 
> :/