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

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

[Tim Harvey]

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?

Does Linux use the ethernet<n> aliases for anything at all?

Best Regards,

Tim

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

[Sean Anderson]

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

--Sean

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

[Michal Suchánek]

On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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

Maybe it's a great opportunity for porting biosdevname to DT based
platforms ;-)

Thanks

Michal

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

[Stephen Hemminger]

On Mon, 8 Aug 2022 23:09:45 +0200
Michal Suchánek <msuchanek@suse.de> wrote:

> On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
> 
> Maybe it's a great opportunity for porting biosdevname to DT based
> platforms ;-)

Sorry, biosdevname was wrong way to do things.
Did you look at the internals, it was dumpster diving as root into BIOS.

Systemd-networkd does things in much more supportable manner using existing
sysfs API's.

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

[Michal Suchánek]

On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> On Mon, 8 Aug 2022 23:09:45 +0200
> Michal Suchánek <msuchanek@suse.de> wrote:
> 
> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
> > 
> > Maybe it's a great opportunity for porting biosdevname to DT based
> > platforms ;-)
> 
> Sorry, biosdevname was wrong way to do things.
> Did you look at the internals, it was dumpster diving as root into BIOS.

When it's BIOS what defines the names then you have to read them from
the BIOS. Recently it was updated to use some sysfs file or whatver.
It's not like you would use any of that code with DT, anyway.

> Systemd-networkd does things in much more supportable manner using existing
> sysfs API's.

Which is a dumpster of systemd code, no thanks.

I want my device naming independent of the init system, especially if
it's systemd.

Thanks

Michal

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

[Sean Anderson]

On 8/8/22 5:45 PM, Michal Suchánek wrote:
> On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
>> On Mon, 8 Aug 2022 23:09:45 +0200
>> Michal Suchánek <msuchanek@suse.de> wrote:
>> 
>> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
>> > 
>> > Maybe it's a great opportunity for porting biosdevname to DT based
>> > platforms ;-)
>> 
>> Sorry, biosdevname was wrong way to do things.
>> Did you look at the internals, it was dumpster diving as root into BIOS.
> 
> When it's BIOS what defines the names then you have to read them from
> the BIOS. Recently it was updated to use some sysfs file or whatver.
> It's not like you would use any of that code with DT, anyway.
> 
>> Systemd-networkd does things in much more supportable manner using existing
>> sysfs API's.
> 
> Which is a dumpster of systemd code, no thanks.
> 
> I want my device naming independent of the init system, especially if
> it's systemd.

Well, there's always nameif...

That said, I have made [1] for people using systemd-networkd.

--Sean

[1] https://github.com/systemd/systemd/pull/24265

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

[Pali Rohár]

On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> On 8/8/22 5:45 PM, Michal Suchánek wrote:
> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> >> On Mon, 8 Aug 2022 23:09:45 +0200
> >> Michal Suchánek <msuchanek@suse.de> wrote:
> >> 
> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
> >> > 
> >> > Maybe it's a great opportunity for porting biosdevname to DT based
> >> > platforms ;-)
> >> 
> >> Sorry, biosdevname was wrong way to do things.
> >> Did you look at the internals, it was dumpster diving as root into BIOS.
> > 
> > When it's BIOS what defines the names then you have to read them from
> > the BIOS. Recently it was updated to use some sysfs file or whatver.
> > It's not like you would use any of that code with DT, anyway.
> > 
> >> Systemd-networkd does things in much more supportable manner using existing
> >> sysfs API's.
> > 
> > Which is a dumpster of systemd code, no thanks.
> > 
> > I want my device naming independent of the init system, especially if
> > it's systemd.
> 
> Well, there's always nameif...
> 
> That said, I have made [1] for people using systemd-networkd.
> 
> --Sean
> 
> [1] https://github.com/systemd/systemd/pull/24265

Hello!

In some cases "label" DT property can be used also as interface name.
For example this property is already used by DSA kernel driver.

I created very simple script which renames all interfaces in system to
their "label" DT property (if there is any defined).

#!/bin/sh
for iface in `ls /sys/class/net/`; do
	for of_node in of_node device/of_node; do
		if test -e /sys/class/net/$iface/$of_node/; then
			label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
			if test -n "$label" && test "$label" != "$iface"; then
				echo "Renaming net interface $iface to $label..."
				up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
				if test "$up" != "0"; then
					ip link set dev $iface down
				fi
				ip link set dev $iface name "$label" && iface=$label
				if test "$up" != "0"; then
					ip link set dev $iface up
				fi
			fi
			break
		fi
	done
done

Maybe it would be better first to use "label" and then use ethernet alias?

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

[Sean Anderson]

On 8/9/22 5:31 PM, Pali Rohár wrote:
> On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
>> On 8/8/22 5:45 PM, Michal Suchánek wrote:
>> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
>> >> On Mon, 8 Aug 2022 23:09:45 +0200
>> >> Michal Suchánek <msuchanek@suse.de> wrote:
>> >> 
>> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
>> >> > 
>> >> > Maybe it's a great opportunity for porting biosdevname to DT based
>> >> > platforms ;-)
>> >> 
>> >> Sorry, biosdevname was wrong way to do things.
>> >> Did you look at the internals, it was dumpster diving as root into BIOS.
>> > 
>> > When it's BIOS what defines the names then you have to read them from
>> > the BIOS. Recently it was updated to use some sysfs file or whatver.
>> > It's not like you would use any of that code with DT, anyway.
>> > 
>> >> Systemd-networkd does things in much more supportable manner using existing
>> >> sysfs API's.
>> > 
>> > Which is a dumpster of systemd code, no thanks.
>> > 
>> > I want my device naming independent of the init system, especially if
>> > it's systemd.
>> 
>> Well, there's always nameif...
>> 
>> That said, I have made [1] for people using systemd-networkd.
>> 
>> --Sean
>> 
>> [1] https://github.com/systemd/systemd/pull/24265
> 
> Hello!
> 
> In some cases "label" DT property can be used also as interface name.
> For example this property is already used by DSA kernel driver.
> 
> I created very simple script which renames all interfaces in system to
> their "label" DT property (if there is any defined).
> 
> #!/bin/sh
> for iface in `ls /sys/class/net/`; do
> 	for of_node in of_node device/of_node; do
> 		if test -e /sys/class/net/$iface/$of_node/; then
> 			label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
> 			if test -n "$label" && test "$label" != "$iface"; then
> 				echo "Renaming net interface $iface to $label..."
> 				up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
> 				if test "$up" != "0"; then
> 					ip link set dev $iface down
> 				fi
> 				ip link set dev $iface name "$label" && iface=$label
> 				if test "$up" != "0"; then
> 					ip link set dev $iface up
> 				fi
> 			fi
> 			break
> 		fi
> 	done
> done
> 
> Maybe it would be better first to use "label" and then use ethernet alias?
> 

It looks like there is already precedent for using ID_NET_LABEL_ONBOARD for
this purpose (on SMBios boards). It should be a fairly simple extension to
add that as well. However, I didn't find any uses of this in Linux or U-Boot
(although I did find plenty of ethernet LEDs). Do you have an example you
could point me to?

--Sean

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

[Pali Rohár]

On Tuesday 09 August 2022 17:36:52 Sean Anderson wrote:
> On 8/9/22 5:31 PM, Pali Rohár wrote:
> > On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> >> On 8/8/22 5:45 PM, Michal Suchánek wrote:
> >> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> >> >> On Mon, 8 Aug 2022 23:09:45 +0200
> >> >> Michal Suchánek <msuchanek@suse.de> wrote:
> >> >> 
> >> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
> >> >> > 
> >> >> > Maybe it's a great opportunity for porting biosdevname to DT based
> >> >> > platforms ;-)
> >> >> 
> >> >> Sorry, biosdevname was wrong way to do things.
> >> >> Did you look at the internals, it was dumpster diving as root into BIOS.
> >> > 
> >> > When it's BIOS what defines the names then you have to read them from
> >> > the BIOS. Recently it was updated to use some sysfs file or whatver.
> >> > It's not like you would use any of that code with DT, anyway.
> >> > 
> >> >> Systemd-networkd does things in much more supportable manner using existing
> >> >> sysfs API's.
> >> > 
> >> > Which is a dumpster of systemd code, no thanks.
> >> > 
> >> > I want my device naming independent of the init system, especially if
> >> > it's systemd.
> >> 
> >> Well, there's always nameif...
> >> 
> >> That said, I have made [1] for people using systemd-networkd.
> >> 
> >> --Sean
> >> 
> >> [1] https://github.com/systemd/systemd/pull/24265
> > 
> > Hello!
> > 
> > In some cases "label" DT property can be used also as interface name.
> > For example this property is already used by DSA kernel driver.
> > 
> > I created very simple script which renames all interfaces in system to
> > their "label" DT property (if there is any defined).
> > 
> > #!/bin/sh
> > for iface in `ls /sys/class/net/`; do
> > 	for of_node in of_node device/of_node; do
> > 		if test -e /sys/class/net/$iface/$of_node/; then
> > 			label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
> > 			if test -n "$label" && test "$label" != "$iface"; then
> > 				echo "Renaming net interface $iface to $label..."
> > 				up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
> > 				if test "$up" != "0"; then
> > 					ip link set dev $iface down
> > 				fi
> > 				ip link set dev $iface name "$label" && iface=$label
> > 				if test "$up" != "0"; then
> > 					ip link set dev $iface up
> > 				fi
> > 			fi
> > 			break
> > 		fi
> > 	done
> > done
> > 
> > Maybe it would be better first to use "label" and then use ethernet alias?
> > 
> 
> It looks like there is already precedent for using ID_NET_LABEL_ONBOARD for
> this purpose (on SMBios boards). It should be a fairly simple extension to
> add that as well. However, I didn't find any uses of this in Linux or U-Boot
> (although I did find plenty of ethernet LEDs). Do you have an example you
> could point me to?
> 
> --Sean

In linux:
$ git grep '"label"' net/dsa/dsa2.c
net/dsa/dsa2.c: const char *name = of_get_property(dn, "label", NULL);

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

[Sean Anderson]

On 8/9/22 5:42 PM, Pali Rohár wrote:
> On Tuesday 09 August 2022 17:36:52 Sean Anderson wrote:
>> On 8/9/22 5:31 PM, Pali Rohár wrote:
>> > On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
>> >> On 8/8/22 5:45 PM, Michal Suchánek wrote:
>> >> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
>> >> >> On Mon, 8 Aug 2022 23:09:45 +0200
>> >> >> Michal Suchánek <msuchanek@suse.de> wrote:
>> >> >> 
>> >> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
>> >> >> > 
>> >> >> > Maybe it's a great opportunity for porting biosdevname to DT based
>> >> >> > platforms ;-)
>> >> >> 
>> >> >> Sorry, biosdevname was wrong way to do things.
>> >> >> Did you look at the internals, it was dumpster diving as root into BIOS.
>> >> > 
>> >> > When it's BIOS what defines the names then you have to read them from
>> >> > the BIOS. Recently it was updated to use some sysfs file or whatver.
>> >> > It's not like you would use any of that code with DT, anyway.
>> >> > 
>> >> >> Systemd-networkd does things in much more supportable manner using existing
>> >> >> sysfs API's.
>> >> > 
>> >> > Which is a dumpster of systemd code, no thanks.
>> >> > 
>> >> > I want my device naming independent of the init system, especially if
>> >> > it's systemd.
>> >> 
>> >> Well, there's always nameif...
>> >> 
>> >> That said, I have made [1] for people using systemd-networkd.
>> >> 
>> >> --Sean
>> >> 
>> >> [1] https://github.com/systemd/systemd/pull/24265
>> > 
>> > Hello!
>> > 
>> > In some cases "label" DT property can be used also as interface name.
>> > For example this property is already used by DSA kernel driver.
>> > 
>> > I created very simple script which renames all interfaces in system to
>> > their "label" DT property (if there is any defined).
>> > 
>> > #!/bin/sh
>> > for iface in `ls /sys/class/net/`; do
>> > 	for of_node in of_node device/of_node; do
>> > 		if test -e /sys/class/net/$iface/$of_node/; then
>> > 			label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
>> > 			if test -n "$label" && test "$label" != "$iface"; then
>> > 				echo "Renaming net interface $iface to $label..."
>> > 				up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
>> > 				if test "$up" != "0"; then
>> > 					ip link set dev $iface down
>> > 				fi
>> > 				ip link set dev $iface name "$label" && iface=$label
>> > 				if test "$up" != "0"; then
>> > 					ip link set dev $iface up
>> > 				fi
>> > 			fi
>> > 			break
>> > 		fi
>> > 	done
>> > done
>> > 
>> > Maybe it would be better first to use "label" and then use ethernet alias?
>> > 
>> 
>> It looks like there is already precedent for using ID_NET_LABEL_ONBOARD for
>> this purpose (on SMBios boards). It should be a fairly simple extension to
>> add that as well. However, I didn't find any uses of this in Linux or U-Boot
>> (although I did find plenty of ethernet LEDs). Do you have an example you
>> could point me to?
>> 
>> --Sean
> 
> In linux:
> $ git grep '"label"' net/dsa/dsa2.c
> net/dsa/dsa2.c: const char *name = of_get_property(dn, "label", NULL);
> 

Hm, if Linux is using the label, then do we need to rename things in userspace?

--Sean

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

[Tim Harvey]

On Tue, Aug 9, 2022 at 3:41 PM Sean Anderson <sean.anderson@seco.com> wrote:
>
>
>
> On 8/9/22 5:42 PM, Pali Rohár wrote:
> > On Tuesday 09 August 2022 17:36:52 Sean Anderson wrote:
> >> On 8/9/22 5:31 PM, Pali Rohár wrote:
> >> > On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> >> >> On 8/8/22 5:45 PM, Michal Suchánek wrote:
> >> >> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> >> >> >> On Mon, 8 Aug 2022 23:09:45 +0200
> >> >> >> Michal Suchánek <msuchanek@suse.de> wrote:
> >> >> >>
> >> >> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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
> >> >> >> >
> >> >> >> > Maybe it's a great opportunity for porting biosdevname to DT based
> >> >> >> > platforms ;-)
> >> >> >>
> >> >> >> Sorry, biosdevname was wrong way to do things.
> >> >> >> Did you look at the internals, it was dumpster diving as root into BIOS.
> >> >> >
> >> >> > When it's BIOS what defines the names then you have to read them from
> >> >> > the BIOS. Recently it was updated to use some sysfs file or whatver.
> >> >> > It's not like you would use any of that code with DT, anyway.
> >> >> >
> >> >> >> Systemd-networkd does things in much more supportable manner using existing
> >> >> >> sysfs API's.
> >> >> >
> >> >> > Which is a dumpster of systemd code, no thanks.
> >> >> >
> >> >> > I want my device naming independent of the init system, especially if
> >> >> > it's systemd.
> >> >>
> >> >> Well, there's always nameif...
> >> >>
> >> >> That said, I have made [1] for people using systemd-networkd.
> >> >>
> >> >> --Sean
> >> >>
> >> >> [1] https://github.com/systemd/systemd/pull/24265
> >> >
> >> > Hello!
> >> >
> >> > In some cases "label" DT property can be used also as interface name.
> >> > For example this property is already used by DSA kernel driver.
> >> >
> >> > I created very simple script which renames all interfaces in system to
> >> > their "label" DT property (if there is any defined).
> >> >
> >> > #!/bin/sh
> >> > for iface in `ls /sys/class/net/`; do
> >> >    for of_node in of_node device/of_node; do
> >> >            if test -e /sys/class/net/$iface/$of_node/; then
> >> >                    label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
> >> >                    if test -n "$label" && test "$label" != "$iface"; then
> >> >                            echo "Renaming net interface $iface to $label..."
> >> >                            up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
> >> >                            if test "$up" != "0"; then
> >> >                                    ip link set dev $iface down
> >> >                            fi
> >> >                            ip link set dev $iface name "$label" && iface=$label
> >> >                            if test "$up" != "0"; then
> >> >                                    ip link set dev $iface up
> >> >                            fi
> >> >                    fi
> >> >                    break
> >> >            fi
> >> >    done
> >> > done
> >> >
> >> > Maybe it would be better first to use "label" and then use ethernet alias?
> >> >
> >>
> >> It looks like there is already precedent for using ID_NET_LABEL_ONBOARD for
> >> this purpose (on SMBios boards). It should be a fairly simple extension to
> >> add that as well. However, I didn't find any uses of this in Linux or U-Boot
> >> (although I did find plenty of ethernet LEDs). Do you have an example you
> >> could point me to?
> >>
> >> --Sean
> >
> > In linux:
> > $ git grep '"label"' net/dsa/dsa2.c
> > net/dsa/dsa2.c: const char *name = of_get_property(dn, "label", NULL);
> >
>
> Hm, if Linux is using the label, then do we need to rename things in userspace?
>

It is only using label for dsa ports, not for the general netdev case
which is what I feel should be added.

Tim

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

[Pali Rohár]

On Tuesday 09 August 2022 18:41:25 Sean Anderson wrote:
> 
> 
> On 8/9/22 5:42 PM, Pali Rohár wrote:
> > On Tuesday 09 August 2022 17:36:52 Sean Anderson wrote:
> >> On 8/9/22 5:31 PM, Pali Rohár wrote:
> >> > On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> >> >> On 8/8/22 5:45 PM, Michal Suchánek wrote:
> >> >> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> >> >> >> On Mon, 8 Aug 2022 23:09:45 +0200
> >> >> >> Michal Suchánek <msuchanek@suse.de> wrote:
> >> >> >> 
> >> >> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
> >> >> >> > 
> >> >> >> > Maybe it's a great opportunity for porting biosdevname to DT based
> >> >> >> > platforms ;-)
> >> >> >> 
> >> >> >> Sorry, biosdevname was wrong way to do things.
> >> >> >> Did you look at the internals, it was dumpster diving as root into BIOS.
> >> >> > 
> >> >> > When it's BIOS what defines the names then you have to read them from
> >> >> > the BIOS. Recently it was updated to use some sysfs file or whatver.
> >> >> > It's not like you would use any of that code with DT, anyway.
> >> >> > 
> >> >> >> Systemd-networkd does things in much more supportable manner using existing
> >> >> >> sysfs API's.
> >> >> > 
> >> >> > Which is a dumpster of systemd code, no thanks.
> >> >> > 
> >> >> > I want my device naming independent of the init system, especially if
> >> >> > it's systemd.
> >> >> 
> >> >> Well, there's always nameif...
> >> >> 
> >> >> That said, I have made [1] for people using systemd-networkd.
> >> >> 
> >> >> --Sean
> >> >> 
> >> >> [1] https://github.com/systemd/systemd/pull/24265
> >> > 
> >> > Hello!
> >> > 
> >> > In some cases "label" DT property can be used also as interface name.
> >> > For example this property is already used by DSA kernel driver.
> >> > 
> >> > I created very simple script which renames all interfaces in system to
> >> > their "label" DT property (if there is any defined).
> >> > 
> >> > #!/bin/sh
> >> > for iface in `ls /sys/class/net/`; do
> >> > 	for of_node in of_node device/of_node; do
> >> > 		if test -e /sys/class/net/$iface/$of_node/; then
> >> > 			label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
> >> > 			if test -n "$label" && test "$label" != "$iface"; then
> >> > 				echo "Renaming net interface $iface to $label..."
> >> > 				up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
> >> > 				if test "$up" != "0"; then
> >> > 					ip link set dev $iface down
> >> > 				fi
> >> > 				ip link set dev $iface name "$label" && iface=$label
> >> > 				if test "$up" != "0"; then
> >> > 					ip link set dev $iface up
> >> > 				fi
> >> > 			fi
> >> > 			break
> >> > 		fi
> >> > 	done
> >> > done
> >> > 
> >> > Maybe it would be better first to use "label" and then use ethernet alias?
> >> > 
> >> 
> >> It looks like there is already precedent for using ID_NET_LABEL_ONBOARD for
> >> this purpose (on SMBios boards). It should be a fairly simple extension to
> >> add that as well. However, I didn't find any uses of this in Linux or U-Boot
> >> (although I did find plenty of ethernet LEDs). Do you have an example you
> >> could point me to?
> >> 
> >> --Sean
> > 
> > In linux:
> > $ git grep '"label"' net/dsa/dsa2.c
> > net/dsa/dsa2.c: const char *name = of_get_property(dn, "label", NULL);
> > 
> 
> Hm, if Linux is using the label, then do we need to rename things in userspace?

It uses it _only_ for DSA drivers. For all other drivers (e.g. USB or
PCIe based network adapters) it does not use label.

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

[Tim Harvey]

On Tue, Aug 9, 2022 at 3:45 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 09 August 2022 18:41:25 Sean Anderson wrote:
> >
> >
> > On 8/9/22 5:42 PM, Pali Rohár wrote:
> > > On Tuesday 09 August 2022 17:36:52 Sean Anderson wrote:
> > >> On 8/9/22 5:31 PM, Pali Rohár wrote:
> > >> > On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> > >> >> On 8/8/22 5:45 PM, Michal Suchánek wrote:
> > >> >> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> > >> >> >> On Mon, 8 Aug 2022 23:09:45 +0200
> > >> >> >> Michal Suchánek <msuchanek@suse.de> wrote:
> > >> >> >>
> > >> >> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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
> > >> >> >> >
> > >> >> >> > Maybe it's a great opportunity for porting biosdevname to DT based
> > >> >> >> > platforms ;-)
> > >> >> >>
> > >> >> >> Sorry, biosdevname was wrong way to do things.
> > >> >> >> Did you look at the internals, it was dumpster diving as root into BIOS.
> > >> >> >
> > >> >> > When it's BIOS what defines the names then you have to read them from
> > >> >> > the BIOS. Recently it was updated to use some sysfs file or whatver.
> > >> >> > It's not like you would use any of that code with DT, anyway.
> > >> >> >
> > >> >> >> Systemd-networkd does things in much more supportable manner using existing
> > >> >> >> sysfs API's.
> > >> >> >
> > >> >> > Which is a dumpster of systemd code, no thanks.
> > >> >> >
> > >> >> > I want my device naming independent of the init system, especially if
> > >> >> > it's systemd.
> > >> >>
> > >> >> Well, there's always nameif...
> > >> >>
> > >> >> That said, I have made [1] for people using systemd-networkd.
> > >> >>
> > >> >> --Sean
> > >> >>
> > >> >> [1] https://github.com/systemd/systemd/pull/24265
> > >> >
> > >> > Hello!
> > >> >
> > >> > In some cases "label" DT property can be used also as interface name.
> > >> > For example this property is already used by DSA kernel driver.
> > >> >
> > >> > I created very simple script which renames all interfaces in system to
> > >> > their "label" DT property (if there is any defined).
> > >> >
> > >> > #!/bin/sh
> > >> > for iface in `ls /sys/class/net/`; do
> > >> >  for of_node in of_node device/of_node; do
> > >> >          if test -e /sys/class/net/$iface/$of_node/; then
> > >> >                  label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
> > >> >                  if test -n "$label" && test "$label" != "$iface"; then
> > >> >                          echo "Renaming net interface $iface to $label..."
> > >> >                          up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
> > >> >                          if test "$up" != "0"; then
> > >> >                                  ip link set dev $iface down
> > >> >                          fi
> > >> >                          ip link set dev $iface name "$label" && iface=$label
> > >> >                          if test "$up" != "0"; then
> > >> >                                  ip link set dev $iface up
> > >> >                          fi
> > >> >                  fi
> > >> >                  break
> > >> >          fi
> > >> >  done
> > >> > done
> > >> >
> > >> > Maybe it would be better first to use "label" and then use ethernet alias?
> > >> >
> > >>
> > >> It looks like there is already precedent for using ID_NET_LABEL_ONBOARD for
> > >> this purpose (on SMBios boards). It should be a fairly simple extension to
> > >> add that as well. However, I didn't find any uses of this in Linux or U-Boot
> > >> (although I did find plenty of ethernet LEDs). Do you have an example you
> > >> could point me to?
> > >>
> > >> --Sean
> > >
> > > In linux:
> > > $ git grep '"label"' net/dsa/dsa2.c
> > > net/dsa/dsa2.c: const char *name = of_get_property(dn, "label", NULL);
> > >
> >
> > Hm, if Linux is using the label, then do we need to rename things in userspace?
>
> It uses it _only_ for DSA drivers. For all other drivers (e.g. USB or
> PCIe based network adapters) it does not use label.

and to my point it doesn't use label for platform devices.

Is something like the following really that crazy of an idea?
diff --git a/net/core/dev.c b/net/core/dev.c
index e0878a500aa9..a679c74a63c6 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1151,6 +1151,15 @@ static int dev_alloc_name_ns(struct net *net,
        int ret;

        BUG_ON(!net);
+#ifdef CONFIG_OF
+       if (dev->dev.parent && dev->dev.parent->of_node) {
+               const char *name =
of_get_property(dev->dev.parent->of_node, "label", NULL);
+               if (name) {
+                       strlcpy(dev->name, name, IFNAMSIZ);
+                       return 0;
+               }
+       }
+#endif
        ret = __dev_alloc_name(net, name, buf);
        if (ret >= 0)
                strlcpy(dev->name, buf, IFNAMSIZ);

I still like using the index from aliases/ethernet* instead as there
is a precedence for that in other Linux drivers as well as U-Boot

Best Regards,

Tim

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

[Andrew Lunn]

> Is something like the following really that crazy of an idea?
> diff --git a/net/core/dev.c b/net/core/dev.c
> index e0878a500aa9..a679c74a63c6 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1151,6 +1151,15 @@ static int dev_alloc_name_ns(struct net *net,
>         int ret;
> 
>         BUG_ON(!net);
> +#ifdef CONFIG_OF
> +       if (dev->dev.parent && dev->dev.parent->of_node) {
> +               const char *name =
> of_get_property(dev->dev.parent->of_node, "label", NULL);
> +               if (name) {
> +                       strlcpy(dev->name, name, IFNAMSIZ);
> +                       return 0;
> +               }
> +       }
> +#endif
>         ret = __dev_alloc_name(net, name, buf);
>         if (ret >= 0)
>                 strlcpy(dev->name, buf, IFNAMSIZ);
> 
> I still like using the index from aliases/ethernet* instead as there
> is a precedence for that in other Linux drivers as well as U-Boot

I guess you are new to the netdev list :-)

This is one of those FAQ sort of things, discussed every
year. Anything like this is always NACKed. I don't see why this time
should be any different.

DSA is somewhat special because it is very old. It comes from before
the times of DT. Its DT binding was proposed relatively earl in DT
times, and would be rejected in modern days. But the rules of ABI mean
the label property will be valid forever. But i very much doubt it
will spread to interfaces in general.

     Andrew

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

[Michal Suchánek]

On Wed, Aug 10, 2022 at 03:11:48AM +0200, Andrew Lunn wrote:
> > Is something like the following really that crazy of an idea?
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index e0878a500aa9..a679c74a63c6 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1151,6 +1151,15 @@ static int dev_alloc_name_ns(struct net *net,
> >         int ret;
> > 
> >         BUG_ON(!net);
> > +#ifdef CONFIG_OF
> > +       if (dev->dev.parent && dev->dev.parent->of_node) {
> > +               const char *name =
> > of_get_property(dev->dev.parent->of_node, "label", NULL);
> > +               if (name) {
> > +                       strlcpy(dev->name, name, IFNAMSIZ);
> > +                       return 0;
> > +               }
> > +       }
> > +#endif
> >         ret = __dev_alloc_name(net, name, buf);
> >         if (ret >= 0)
> >                 strlcpy(dev->name, buf, IFNAMSIZ);
> > 
> > I still like using the index from aliases/ethernet* instead as there
> > is a precedence for that in other Linux drivers as well as U-Boot
> 
> I guess you are new to the netdev list :-)
> 
> This is one of those FAQ sort of things, discussed every
> year. Anything like this is always NACKed. I don't see why this time
> should be any different.
> 
> DSA is somewhat special because it is very old. It comes from before
> the times of DT. Its DT binding was proposed relatively earl in DT
> times, and would be rejected in modern days. But the rules of ABI mean
> the label property will be valid forever. But i very much doubt it
> will spread to interfaces in general.

And if this is a FAQ maybe you can point to a summary (perhaps in
previous mail discusssion) that explains how to provide stable interface
names for Ethernet devices on a DT based platform?

On x86 there is a name derived from the device location in the bus
topology which may be somewhat stable but it is not clear that it
cannot change, and there is an optional BIOS provided table that can
asssign meaningful names to the interfaces.

What are the equivalents for DT?

Thanks

Michal

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

[Andrew Lunn]

> > I guess you are new to the netdev list :-)
> > 
> > This is one of those FAQ sort of things, discussed every
> > year. Anything like this is always NACKed. I don't see why this time
> > should be any different.
> > 
> > DSA is somewhat special because it is very old. It comes from before
> > the times of DT. Its DT binding was proposed relatively earl in DT
> > times, and would be rejected in modern days. But the rules of ABI mean
> > the label property will be valid forever. But i very much doubt it
> > will spread to interfaces in general.
> 
> And if this is a FAQ maybe you can point to a summary (perhaps in
> previous mail discusssion) that explains how to provide stable interface
> names for Ethernet devices on a DT based platform?

As far so the kernel is concerned, interface names are unstable. They
have never been truly stable, but they have got more unstable in the
past decade with multiple busses being probed in parallel, which did
not happen before so much.

> On x86 there is a name derived from the device location in the bus
> topology

This is nothing to do with x86. That is userspace, e.g. systemd,
renaming the interfaces. This applies for any architecture for which
systemd runs on.

> which may be somewhat stable but it is not clear that it
> cannot change, and there is an optional BIOS provided table that can
> asssign meaningful names to the interfaces.

I doubt the kernel is looking at ACPI tables. It is user space which
does that.

The kernel provides udev with a bunch of information about the
interface, its bus location, MAC address, etc. Userspace can then
decide what it wants to call it, and what its alternative names are,
etc.

Also, this is not just a network interface name problem. Any device
with a number/letter in it is unstable. I2C bus devices: i2c0,
i2c1... SPI bus deviceS: spi0, spi1..., Block devices, sda, sdb, sdc,
TPM device, tpm0, tpm1. Nothing is stable in the kernel.

       Andrew

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

[Michal Suchánek]

On Wed, Aug 10, 2022 at 05:17:56PM +0200, Andrew Lunn wrote:
> > > I guess you are new to the netdev list :-)
> > > 
> > > This is one of those FAQ sort of things, discussed every
> > > year. Anything like this is always NACKed. I don't see why this time
> > > should be any different.
> > > 
> > > DSA is somewhat special because it is very old. It comes from before
> > > the times of DT. Its DT binding was proposed relatively earl in DT
> > > times, and would be rejected in modern days. But the rules of ABI mean
> > > the label property will be valid forever. But i very much doubt it
> > > will spread to interfaces in general.
> > 
> > And if this is a FAQ maybe you can point to a summary (perhaps in
> > previous mail discusssion) that explains how to provide stable interface
> > names for Ethernet devices on a DT based platform?
> 
> As far so the kernel is concerned, interface names are unstable. They
> have never been truly stable, but they have got more unstable in the
> past decade with multiple busses being probed in parallel, which did
> not happen before so much.
> 
> > On x86 there is a name derived from the device location in the bus
> > topology
> 
> This is nothing to do with x86. That is userspace, e.g. systemd,
> renaming the interfaces. This applies for any architecture for which
> systemd runs on.
> 
> > which may be somewhat stable but it is not clear that it
> > cannot change, and there is an optional BIOS provided table that can
> > asssign meaningful names to the interfaces.
> 
> I doubt the kernel is looking at ACPI tables. It is user space which
> does that.
> 
> The kernel provides udev with a bunch of information about the
> interface, its bus location, MAC address, etc. Userspace can then
> decide what it wants to call it, and what its alternative names are,
> etc.
> 
> Also, this is not just a network interface name problem. Any device
> with a number/letter in it is unstable. I2C bus devices: i2c0,
> i2c1... SPI bus deviceS: spi0, spi1...,

Thees do have numbered aliases in the DT. I don't know if the kernel
uses them for anything.

> Block devices, sda, sdb, sdc,

These too, at least mmc.

Thanks

Michal

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

[Sean Anderson]

On 8/10/22 11:35 AM, Michal Suchánek wrote:
> On Wed, Aug 10, 2022 at 05:17:56PM +0200, Andrew Lunn wrote:
>> > > I guess you are new to the netdev list :-)
>> > > 
>> > > This is one of those FAQ sort of things, discussed every
>> > > year. Anything like this is always NACKed. I don't see why this time
>> > > should be any different.
>> > > 
>> > > DSA is somewhat special because it is very old. It comes from before
>> > > the times of DT. Its DT binding was proposed relatively earl in DT
>> > > times, and would be rejected in modern days. But the rules of ABI mean
>> > > the label property will be valid forever. But i very much doubt it
>> > > will spread to interfaces in general.
>> > 
>> > And if this is a FAQ maybe you can point to a summary (perhaps in
>> > previous mail discusssion) that explains how to provide stable interface
>> > names for Ethernet devices on a DT based platform?
>> 
>> As far so the kernel is concerned, interface names are unstable. They
>> have never been truly stable, but they have got more unstable in the
>> past decade with multiple busses being probed in parallel, which did
>> not happen before so much.
>> 
>> > On x86 there is a name derived from the device location in the bus
>> > topology
>> 
>> This is nothing to do with x86. That is userspace, e.g. systemd,
>> renaming the interfaces. This applies for any architecture for which
>> systemd runs on.
>> 
>> > which may be somewhat stable but it is not clear that it
>> > cannot change, and there is an optional BIOS provided table that can
>> > asssign meaningful names to the interfaces.
>> 
>> I doubt the kernel is looking at ACPI tables. It is user space which
>> does that.
>> 
>> The kernel provides udev with a bunch of information about the
>> interface, its bus location, MAC address, etc. Userspace can then
>> decide what it wants to call it, and what its alternative names are,
>> etc.
>> 
>> Also, this is not just a network interface name problem. Any device
>> with a number/letter in it is unstable. I2C bus devices: i2c0,
>> i2c1... SPI bus deviceS: spi0, spi1...,
> 
> Thees do have numbered aliases in the DT. I don't know if the kernel
> uses them for anything.

This is an issue for serial devices IMO. The only way to specify a
stable console is to use its address! Things like /dev/ttyS0 can
easily be reordered just by plugging/unplugging a card. You can of
course add a udev rule to create some stable symlinks, but that's
too late.

>> Block devices, sda, sdb, sdc,
> 
> These too, at least mmc.


Which I am very grateful exists. While the block device situation is
not as bad due to e.g. /dev/block/by-foo, it's still nice to be able
to have a consistent name.

--Sean

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

[Pali Rohár]

On Wednesday 10 August 2022 00:45:35 Pali Rohár wrote:
> On Tuesday 09 August 2022 18:41:25 Sean Anderson wrote:
> > On 8/9/22 5:42 PM, Pali Rohár wrote:
> > > On Tuesday 09 August 2022 17:36:52 Sean Anderson wrote:
> > >> On 8/9/22 5:31 PM, Pali Rohár wrote:
> > >> > On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> > >> >> On 8/8/22 5:45 PM, Michal Suchánek wrote:
> > >> >> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> > >> >> >> On Mon, 8 Aug 2022 23:09:45 +0200
> > >> >> >> Michal Suchánek <msuchanek@suse.de> wrote:
> > >> >> >> 
> > >> >> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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  
> > >> >> >> > 
> > >> >> >> > Maybe it's a great opportunity for porting biosdevname to DT based
> > >> >> >> > platforms ;-)
> > >> >> >> 
> > >> >> >> Sorry, biosdevname was wrong way to do things.
> > >> >> >> Did you look at the internals, it was dumpster diving as root into BIOS.
> > >> >> > 
> > >> >> > When it's BIOS what defines the names then you have to read them from
> > >> >> > the BIOS. Recently it was updated to use some sysfs file or whatver.
> > >> >> > It's not like you would use any of that code with DT, anyway.
> > >> >> > 
> > >> >> >> Systemd-networkd does things in much more supportable manner using existing
> > >> >> >> sysfs API's.
> > >> >> > 
> > >> >> > Which is a dumpster of systemd code, no thanks.
> > >> >> > 
> > >> >> > I want my device naming independent of the init system, especially if
> > >> >> > it's systemd.
> > >> >> 
> > >> >> Well, there's always nameif...
> > >> >> 
> > >> >> That said, I have made [1] for people using systemd-networkd.
> > >> >> 
> > >> >> --Sean
> > >> >> 
> > >> >> [1] https://github.com/systemd/systemd/pull/24265
> > >> > 
> > >> > Hello!
> > >> > 
> > >> > In some cases "label" DT property can be used also as interface name.
> > >> > For example this property is already used by DSA kernel driver.
> > >> > 
> > >> > I created very simple script which renames all interfaces in system to
> > >> > their "label" DT property (if there is any defined).
> > >> > 
> > >> > #!/bin/sh
> > >> > for iface in `ls /sys/class/net/`; do
> > >> > 	for of_node in of_node device/of_node; do
> > >> > 		if test -e /sys/class/net/$iface/$of_node/; then
> > >> > 			label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
> > >> > 			if test -n "$label" && test "$label" != "$iface"; then
> > >> > 				echo "Renaming net interface $iface to $label..."
> > >> > 				up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
> > >> > 				if test "$up" != "0"; then
> > >> > 					ip link set dev $iface down
> > >> > 				fi
> > >> > 				ip link set dev $iface name "$label" && iface=$label
> > >> > 				if test "$up" != "0"; then
> > >> > 					ip link set dev $iface up
> > >> > 				fi
> > >> > 			fi
> > >> > 			break
> > >> > 		fi
> > >> > 	done
> > >> > done
> > >> > 
> > >> > Maybe it would be better first to use "label" and then use ethernet alias?
> > >> > 
> > >> 
> > >> It looks like there is already precedent for using ID_NET_LABEL_ONBOARD for
> > >> this purpose (on SMBios boards). It should be a fairly simple extension to
> > >> add that as well. However, I didn't find any uses of this in Linux or U-Boot
> > >> (although I did find plenty of ethernet LEDs). Do you have an example you
> > >> could point me to?
> > >> 
> > >> --Sean
> > > 
> > > In linux:
> > > $ git grep '"label"' net/dsa/dsa2.c
> > > net/dsa/dsa2.c: const char *name = of_get_property(dn, "label", NULL);
> > > 
> > 
> > Hm, if Linux is using the label, then do we need to rename things in userspace?
> 
> It uses it _only_ for DSA drivers. For all other drivers (e.g. USB or
> PCIe based network adapters) it does not use label.

Hello Sean! I would like to ask, are you going to use/implement "label"
support (so it would work also for non-DSA drivers) in userspace, in
similar way how you did aliases? https://github.com/systemd/systemd/pull/24265

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

[Sean Anderson]

On 8/20/22 5:16 AM, Pali Rohár wrote:
> On Wednesday 10 August 2022 00:45:35 Pali Rohár wrote:
>> On Tuesday 09 August 2022 18:41:25 Sean Anderson wrote:
>>> On 8/9/22 5:42 PM, Pali Rohár wrote:
>>>> On Tuesday 09 August 2022 17:36:52 Sean Anderson wrote:
>>>>> On 8/9/22 5:31 PM, Pali Rohár wrote:
>>>>>> On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
>>>>>>> On 8/8/22 5:45 PM, Michal Suchánek wrote:
>>>>>>>> On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
>>>>>>>>> On Mon, 8 Aug 2022 23:09:45 +0200
>>>>>>>>> Michal Suchánek <msuchanek@suse.de> wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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
>>>>>>>>>>
>>>>>>>>>> Maybe it's a great opportunity for porting biosdevname to DT based
>>>>>>>>>> platforms ;-)
>>>>>>>>>
>>>>>>>>> Sorry, biosdevname was wrong way to do things.
>>>>>>>>> Did you look at the internals, it was dumpster diving as root into BIOS.
>>>>>>>>
>>>>>>>> When it's BIOS what defines the names then you have to read them from
>>>>>>>> the BIOS. Recently it was updated to use some sysfs file or whatver.
>>>>>>>> It's not like you would use any of that code with DT, anyway.
>>>>>>>>
>>>>>>>>> Systemd-networkd does things in much more supportable manner using existing
>>>>>>>>> sysfs API's.
>>>>>>>>
>>>>>>>> Which is a dumpster of systemd code, no thanks.
>>>>>>>>
>>>>>>>> I want my device naming independent of the init system, especially if
>>>>>>>> it's systemd.
>>>>>>>
>>>>>>> Well, there's always nameif...
>>>>>>>
>>>>>>> That said, I have made [1] for people using systemd-networkd.
>>>>>>>
>>>>>>> --Sean
>>>>>>>
>>>>>>> [1] https://github.com/systemd/systemd/pull/24265
>>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> In some cases "label" DT property can be used also as interface name.
>>>>>> For example this property is already used by DSA kernel driver.
>>>>>>
>>>>>> I created very simple script which renames all interfaces in system to
>>>>>> their "label" DT property (if there is any defined).
>>>>>>
>>>>>> #!/bin/sh
>>>>>> for iface in `ls /sys/class/net/`; do
>>>>>> 	for of_node in of_node device/of_node; do
>>>>>> 		if test -e /sys/class/net/$iface/$of_node/; then
>>>>>> 			label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
>>>>>> 			if test -n "$label" && test "$label" != "$iface"; then
>>>>>> 				echo "Renaming net interface $iface to $label..."
>>>>>> 				up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
>>>>>> 				if test "$up" != "0"; then
>>>>>> 					ip link set dev $iface down
>>>>>> 				fi
>>>>>> 				ip link set dev $iface name "$label" && iface=$label
>>>>>> 				if test "$up" != "0"; then
>>>>>> 					ip link set dev $iface up
>>>>>> 				fi
>>>>>> 			fi
>>>>>> 			break
>>>>>> 		fi
>>>>>> 	done
>>>>>> done
>>>>>>
>>>>>> Maybe it would be better first to use "label" and then use ethernet alias?
>>>>>>
>>>>>
>>>>> It looks like there is already precedent for using ID_NET_LABEL_ONBOARD for
>>>>> this purpose (on SMBios boards). It should be a fairly simple extension to
>>>>> add that as well. However, I didn't find any uses of this in Linux or U-Boot
>>>>> (although I did find plenty of ethernet LEDs). Do you have an example you
>>>>> could point me to?
>>>>>
>>>>> --Sean
>>>>
>>>> In linux:
>>>> $ git grep '"label"' net/dsa/dsa2.c
>>>> net/dsa/dsa2.c: const char *name = of_get_property(dn, "label", NULL);
>>>>
>>>
>>> Hm, if Linux is using the label, then do we need to rename things in userspace?
>>
>> It uses it _only_ for DSA drivers. For all other drivers (e.g. USB or
>> PCIe based network adapters) it does not use label.
> 
> Hello Sean! I would like to ask, are you going to use/implement "label"
> support (so it would work also for non-DSA drivers) in userspace, in
> similar way how you did aliases? https://github.com/systemd/systemd/pull/24265
> 

Hi Pali,

No, I have no plans to do that.

--Sean

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

[Tim Harvey]

On Tue, Aug 9, 2022 at 2:31 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> > On 8/8/22 5:45 PM, Michal Suchánek wrote:
> > > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> > >> On Mon, 8 Aug 2022 23:09:45 +0200
> > >> Michal Suchánek <msuchanek@suse.de> wrote:
> > >>
> > >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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
> > >> >
> > >> > Maybe it's a great opportunity for porting biosdevname to DT based
> > >> > platforms ;-)
> > >>
> > >> Sorry, biosdevname was wrong way to do things.
> > >> Did you look at the internals, it was dumpster diving as root into BIOS.
> > >
> > > When it's BIOS what defines the names then you have to read them from
> > > the BIOS. Recently it was updated to use some sysfs file or whatver.
> > > It's not like you would use any of that code with DT, anyway.
> > >
> > >> Systemd-networkd does things in much more supportable manner using existing
> > >> sysfs API's.
> > >
> > > Which is a dumpster of systemd code, no thanks.
> > >
> > > I want my device naming independent of the init system, especially if
> > > it's systemd.
> >
> > Well, there's always nameif...
> >
> > That said, I have made [1] for people using systemd-networkd.
> >
> > --Sean
> >
> > [1] https://github.com/systemd/systemd/pull/24265
>
> Hello!
>
> In some cases "label" DT property can be used also as interface name.
> For example this property is already used by DSA kernel driver.
>
> I created very simple script which renames all interfaces in system to
> their "label" DT property (if there is any defined).
>
> #!/bin/sh
> for iface in `ls /sys/class/net/`; do
>         for of_node in of_node device/of_node; do
>                 if test -e /sys/class/net/$iface/$of_node/; then
>                         label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
>                         if test -n "$label" && test "$label" != "$iface"; then
>                                 echo "Renaming net interface $iface to $label..."
>                                 up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
>                                 if test "$up" != "0"; then
>                                         ip link set dev $iface down
>                                 fi
>                                 ip link set dev $iface name "$label" && iface=$label
>                                 if test "$up" != "0"; then
>                                         ip link set dev $iface up
>                                 fi
>                         fi
>                         break
>                 fi
>         done
> done
>
> Maybe it would be better first to use "label" and then use ethernet alias?

I've been wondering the same as well which made me wonder what the
history of the 'aliases' node is and why its not used in most cases in
Linux. I know for the SOC's I work with we've always defined aliases
for ethernet<n>, gpio<n>, serial<n>, spi<n>, i2c<n>, mmc<n> etc. Where
did this practice come from and why are we putting that in Linux dts
files it if it's not used by Linux?

Best Regards,

Tim

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

[Pali Rohár]

On Tuesday 09 August 2022 14:39:05 Tim Harvey wrote:
> I've been wondering the same as well which made me wonder what the
> history of the 'aliases' node is and why its not used in most cases in
> Linux. I know for the SOC's I work with we've always defined aliases
> for ethernet<n>, gpio<n>, serial<n>, spi<n>, i2c<n>, mmc<n> etc. Where
> did this practice come from and why are we putting that in Linux dts
> files it if it's not used by Linux?

U-Boot can modify on-the-fly Linux's DTB file when booting Linux kernel.
For example it can put permanent MAC address into ethernet nodes from
U-Boot env. Similarly it can modify other DT nodes.

So even when Linux itself does not use particular alias, it is used by
the bootloader.

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

[Stephen Hemminger]

On Tue, 9 Aug 2022 14:39:05 -0700
Tim Harvey <tharvey@gateworks.com> wrote:

> > Maybe it would be better first to use "label" and then use ethernet alias?  
> 
> I've been wondering the same as well which made me wonder what the
> history of the 'aliases' node is and why its not used in most cases in
> Linux. I know for the SOC's I work with we've always defined aliases
> for ethernet<n>, gpio<n>, serial<n>, spi<n>, i2c<n>, mmc<n> etc. Where
> did this practice come from and why are we putting that in Linux dts
> files it if it's not used by Linux?
> 
> Best Regards,
> 
> Tim

I added ifalias as part of better SNMP support.
In telco and router equipment they report the type/topology information
as ifAlias in MIB.

In Vyatta distribution this was set to information that came from
the pci subsystem for typical network PCI devices.

Recent distributions added altname support to allow for alternative
or longer names.

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

[Francesco Dolcini]

On Tue, Aug 09, 2022 at 02:39:05PM -0700, Tim Harvey wrote:
> On Tue, Aug 9, 2022 at 2:31 PM Pali Rohár <pali@kernel.org> wrote:
> > On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> > > On 8/8/22 5:45 PM, Michal Suchánek wrote:
> > > > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> > > >> On Mon, 8 Aug 2022 23:09:45 +0200
> > > >> Michal Suchánek <msuchanek@suse.de> wrote:
> > > >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, Sean Anderson wrote:
> > > >> > > 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;
> for ethernet<n>, gpio<n>, serial<n>, spi<n>, i2c<n>, mmc<n> etc. Where
> did this practice come from and why are we putting that in Linux dts
> files it if it's not used by Linux?

These aliases are used also to be sure that the MAC address assigned to
the network device is the same between Linux and U-Boot.

Francesco

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

[Rob Herring]

On Tue, Aug 9, 2022 at 4:39 PM Tim Harvey <tharvey@gateworks.com> wrote:
>
> On Tue, Aug 9, 2022 at 2:31 PM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Tuesday 09 August 2022 16:48:23 Sean Anderson wrote:
> > > On 8/8/22 5:45 PM, Michal Suchánek wrote:
> > > > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> > > >> On Mon, 8 Aug 2022 23:09:45 +0200
> > > >> Michal Suchánek <msuchanek@suse.de> wrote:
> > > >>
> > > >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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?

Ah, the topic that will never die.

> > > >> > >
> > > >> > > 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
> > > >> >
> > > >> > Maybe it's a great opportunity for porting biosdevname to DT based
> > > >> > platforms ;-)
> > > >>
> > > >> Sorry, biosdevname was wrong way to do things.
> > > >> Did you look at the internals, it was dumpster diving as root into BIOS.
> > > >
> > > > When it's BIOS what defines the names then you have to read them from
> > > > the BIOS. Recently it was updated to use some sysfs file or whatver.
> > > > It's not like you would use any of that code with DT, anyway.
> > > >
> > > >> Systemd-networkd does things in much more supportable manner using existing
> > > >> sysfs API's.
> > > >
> > > > Which is a dumpster of systemd code, no thanks.
> > > >
> > > > I want my device naming independent of the init system, especially if
> > > > it's systemd.
> > >
> > > Well, there's always nameif...
> > >
> > > That said, I have made [1] for people using systemd-networkd.
> > >
> > > --Sean
> > >
> > > [1] https://github.com/systemd/systemd/pull/24265
> >
> > Hello!
> >
> > In some cases "label" DT property can be used also as interface name.
> > For example this property is already used by DSA kernel driver.
> >
> > I created very simple script which renames all interfaces in system to
> > their "label" DT property (if there is any defined).
> >
> > #!/bin/sh
> > for iface in `ls /sys/class/net/`; do
> >         for of_node in of_node device/of_node; do
> >                 if test -e /sys/class/net/$iface/$of_node/; then
> >                         label=`cat /sys/class/net/$iface/$of_node/label 2>/dev/null`
> >                         if test -n "$label" && test "$label" != "$iface"; then
> >                                 echo "Renaming net interface $iface to $label..."
> >                                 up=$((`cat /sys/class/net/$iface/flags 2>/dev/null || echo 1` & 0x1))
> >                                 if test "$up" != "0"; then
> >                                         ip link set dev $iface down
> >                                 fi
> >                                 ip link set dev $iface name "$label" && iface=$label
> >                                 if test "$up" != "0"; then
> >                                         ip link set dev $iface up
> >                                 fi
> >                         fi
> >                         break
> >                 fi
> >         done
> > done
> >
> > Maybe it would be better first to use "label" and then use ethernet alias?
>
> I've been wondering the same as well which made me wonder what the
> history of the 'aliases' node is and why its not used in most cases in
> Linux. I know for the SOC's I work with we've always defined aliases
> for ethernet<n>, gpio<n>, serial<n>, spi<n>, i2c<n>, mmc<n> etc. Where
> did this practice come from and why are we putting that in Linux dts
> files it if it's not used by Linux?

It's not 'Linux dts files', but dts files that happen to be hosted in
the Linux kernel. Many are sync'd to u-boot and other places.

While ethernetN is not used by the kernel, the rest are I think.
Personally, I'd do away with gpio, i2c and spi at least, but that ship
has sailed. Then we have some non-standard ones that crept in from
downstream I think (i.MX is the worst).

'label' is supposed to reflect the sticker on a user accessible
port/connector on device. As long as nothing is looking for particular
values of label, it's okay by me to use.

Rob

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

[Tim Harvey]

On Tue, Aug 9, 2022 at 1:48 PM Sean Anderson <sean.anderson@seco.com> wrote:
>
>
>
> On 8/8/22 5:45 PM, Michal Suchánek wrote:
> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
> >> On Mon, 8 Aug 2022 23:09:45 +0200
> >> Michal Suchánek <msuchanek@suse.de> wrote:
> >>
> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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
> >> >
> >> > Maybe it's a great opportunity for porting biosdevname to DT based
> >> > platforms ;-)
> >>
> >> Sorry, biosdevname was wrong way to do things.
> >> Did you look at the internals, it was dumpster diving as root into BIOS.
> >
> > When it's BIOS what defines the names then you have to read them from
> > the BIOS. Recently it was updated to use some sysfs file or whatver.
> > It's not like you would use any of that code with DT, anyway.
> >
> >> Systemd-networkd does things in much more supportable manner using existing
> >> sysfs API's.
> >
> > Which is a dumpster of systemd code, no thanks.
> >
> > I want my device naming independent of the init system, especially if
> > it's systemd.
>
> Well, there's always nameif...
>
> That said, I have made [1] for people using systemd-networkd.
>
> --Sean
>
> [1] https://github.com/systemd/systemd/pull/24265

Sean,

That looks very promising. Linux is definitely flipping eth0/eth1
between fec/eqos for me when booting an Ubuntu rootfs telling me that
the netdev registration between those two drivers is racy.

Can you give me an example udev rule that shows how to invoke the new
naming scheme your adding here?

Best Regards,

Tim

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

[Sean Anderson]

On 8/9/22 5:35 PM, Tim Harvey wrote:
> On Tue, Aug 9, 2022 at 1:48 PM Sean Anderson <sean.anderson@seco.com> wrote:
>>
>>
>>
>> On 8/8/22 5:45 PM, Michal Suchánek wrote:
>> > On Mon, Aug 08, 2022 at 02:38:35PM -0700, Stephen Hemminger wrote:
>> >> On Mon, 8 Aug 2022 23:09:45 +0200
>> >> Michal Suchánek <msuchanek@suse.de> wrote:
>> >>
>> >> > On Mon, Aug 08, 2022 at 03:57:55PM -0400, 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
>> >> >
>> >> > Maybe it's a great opportunity for porting biosdevname to DT based
>> >> > platforms ;-)
>> >>
>> >> Sorry, biosdevname was wrong way to do things.
>> >> Did you look at the internals, it was dumpster diving as root into BIOS.
>> >
>> > When it's BIOS what defines the names then you have to read them from
>> > the BIOS. Recently it was updated to use some sysfs file or whatver.
>> > It's not like you would use any of that code with DT, anyway.
>> >
>> >> Systemd-networkd does things in much more supportable manner using existing
>> >> sysfs API's.
>> >
>> > Which is a dumpster of systemd code, no thanks.
>> >
>> > I want my device naming independent of the init system, especially if
>> > it's systemd.
>>
>> Well, there's always nameif...
>>
>> That said, I have made [1] for people using systemd-networkd.
>>
>> --Sean
>>
>> [1] https://github.com/systemd/systemd/pull/24265
> 
> Sean,
> 
> That looks very promising. Linux is definitely flipping eth0/eth1
> between fec/eqos for me when booting an Ubuntu rootfs telling me that
> the netdev registration between those two drivers is racy.

Yeah, I always end up creating either udev rules or .link files so I
can keep my sanity :)

> Can you give me an example udev rule that shows how to invoke the new
> naming scheme your adding here?

I believe you use 75-net-description.rules, and then ID_NET_* will be
available for you to use in your rules. You can try it out manually by
running

	udevadm test-builtin net_id /sys/class/net/eth0

--Sean

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

[Tim Harvey]

On Mon, Aug 8, 2022 at 12:58 PM Sean Anderson <sean.anderson@seco.com> 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
>

Sean,

Ok - thanks for the confirmation!

Best Regards,

Tim

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

[Florian Fainelli]

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().
-- 
Florian

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

[Tim Harvey]

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.

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,

Tim

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

[Florian Fainelli]

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

Re: 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@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@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