ethernet "bus" number in DTS ?

ethernet "bus" number in DTS ?

[Joakim Tjernlund]

SPI (and others) has a way to define bus number in a aliases:
	aliases {
		ethernet4 = &enet4;
		ethernet0 = &enet0;
		ethernet1 = &enet1;
		ethernet2 = &enet2;
		ethernet3 = &enet3;
		spi0 = &spi0
	};
The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
I am looking for the same for ethernet devices:
 ethernet4 = &enet4;  /* should become eth4 */
 ethernet0 = &enet0;  /* should become eth0 */
but I cannot find something like that for eth devices.

Could such functionality be added?

 Jocke

Re: ethernet "bus" number in DTS ?

[Florian Fainelli]

On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
> SPI (and others) has a way to define bus number in a aliases:
> 	aliases {
> 		ethernet4 = &enet4;
> 		ethernet0 = &enet0;
> 		ethernet1 = &enet1;
> 		ethernet2 = &enet2;
> 		ethernet3 = &enet3;
> 		spi0 = &spi0
> 	};
> The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
> I am looking for the same for ethernet devices:
>  ethernet4 = &enet4;  /* should become eth4 */
>  ethernet0 = &enet0;  /* should become eth0 */
> but I cannot find something like that for eth devices.
> 
> Could such functionality be added?

It could, do we want and need to, no. You have the Ethernet alias in
/sys/class/net/*/device/uevent already that would allow you to perform
that (re)naming in user-space:

# cat /sys/class/net/eth0/device/uevent
DRIVER=bcmgenet
OF_NAME=ethernet
OF_FULLNAME=/rdb/ethernet@f0480000
OF_TYPE=network
OF_COMPATIBLE_0=brcm,genet-v5
OF_COMPATIBLE_N=1
OF_ALIAS_0=eth0			<==================
MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
-- 
Florian

Re: ethernet "bus" number in DTS ?

[Andrew Lunn]

On Tue, Oct 23, 2018 at 04:49:59PM +0000, Joakim Tjernlund wrote:
> SPI (and others) has a way to define bus number in a aliases:
> 	aliases {
> 		ethernet4 = &enet4;
> 		ethernet0 = &enet0;
> 		ethernet1 = &enet1;
> 		ethernet2 = &enet2;
> 		ethernet3 = &enet3;
> 		spi0 = &spi0
> 	};
> The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
> I am looking for the same for ethernet devices:
>  ethernet4 = &enet4;  /* should become eth4 */
>  ethernet0 = &enet0;  /* should become eth0 */
> but I cannot find something like that for eth devices.
> 
> Could such functionality be added?

Hi Jocke

This has been discussed before. Take a look at
arch/arm/boot/dts/armada-38x.dtsi

                        /*
                         * As a special exception to the "order by
                         * register address" rule, the eth0 node is
                         * placed here to ensure that it gets
                         * registered as the first interface, since
                         * the network subsystem doesn't allow naming
                         * interfaces using DT aliases. Without this,
                         * the ordering of interfaces is different
                         * from the one used in U-Boot and the
                         * labeling of interfaces on the boards, which
                         * is very confusing for users.
                         */

You should be able to find the discuss about this, and why aliases
cannot be used.

       Andrew

Re: ethernet "bus" number in DTS ?

[Andrew Lunn]

On Tue, Oct 23, 2018 at 04:49:59PM +0000, Joakim Tjernlund wrote:
> SPI (and others) has a way to define bus number in a aliases:
> 	aliases {
> 		ethernet4 = &enet4;
> 		ethernet0 = &enet0;
> 		ethernet1 = &enet1;
> 		ethernet2 = &enet2;
> 		ethernet3 = &enet3;
> 		spi0 = &spi0
> 	};
> The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
> I am looking for the same for ethernet devices:
>  ethernet4 = &enet4;  /* should become eth4 */
>  ethernet0 = &enet0;  /* should become eth0 */
> but I cannot find something like that for eth devices.
> 
> Could such functionality be added?

Hi Jocke

This has been discussed before. Take a look at
arch/arm/boot/dts/armada-38x.dtsi

                        /*
                         * As a special exception to the "order by
                         * register address" rule, the eth0 node is
                         * placed here to ensure that it gets
                         * registered as the first interface, since
                         * the network subsystem doesn't allow naming
                         * interfaces using DT aliases. Without this,
                         * the ordering of interfaces is different
                         * from the one used in U-Boot and the
                         * labeling of interfaces on the boards, which
                         * is very confusing for users.
                         */

You should be able to find the discuss about this, and why aliases
cannot be used.

       Andrew

Re: ethernet "bus" number in DTS ?

[Joakim Tjernlund]

On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
> > SPI (and others) has a way to define bus number in a aliases:
> >       aliases {
> >               ethernet4 = &enet4;
> >               ethernet0 = &enet0;
> >               ethernet1 = &enet1;
> >               ethernet2 = &enet2;
> >               ethernet3 = &enet3;
> >               spi0 = &spi0
> >       };
> > The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
> > I am looking for the same for ethernet devices:
> >  ethernet4 = &enet4;  /* should become eth4 */
> >  ethernet0 = &enet0;  /* should become eth0 */
> > but I cannot find something like that for eth devices.
> > 
> > Could such functionality be added?
> 
> It could, do we want and need to, no. You have the Ethernet alias in
> /sys/class/net/*/device/uevent already that would allow you to perform
> that (re)naming in user-space:
> 
> # cat /sys/class/net/eth0/device/uevent
> DRIVER=bcmgenet
> OF_NAME=ethernet
> OF_FULLNAME=/rdb/ethernet@f0480000
> OF_TYPE=network
> OF_COMPATIBLE_0=brcm,genet-v5
> OF_COMPATIBLE_N=1
> OF_ALIAS_0=eth0                 <==================
> MODALIAS=of:NethernetTnetworkCbrcm,genet-v5

Yes, one can if one uses udev and can find something to identify the hw I/F with, my
cat /sys/class/net/eth0/device/uevent looks like:
DRIVER=fsl_dpa
MODALIAS=platform:dpaa-ethernet

not sure mdev supports this, does it?
Our simple installer FS(initramfs) doesn't have either udev or mdev.

I also noted that using status = "disabled" didn't work either to create a fix name scheme.
Even worse, all the eth I/F after gets renumbered. It seems to me there
is value in having stability in eth I/F naming at boot.
Then userspace(udev) can rename if need be. 

Sure would like to known more about why this feature is not wanted ?

I found
  https://patchwork.kernel.org/patch/4122441/
You quote policy as reason but surely it must be better to
have something stable, connected to the hardware name, than semirandom naming?

 Jocke

Re: ethernet "bus" number in DTS ?

[Florian Fainelli]

On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>
>>
>> On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
>>> SPI (and others) has a way to define bus number in a aliases:
>>>       aliases {
>>>               ethernet4 = &enet4;
>>>               ethernet0 = &enet0;
>>>               ethernet1 = &enet1;
>>>               ethernet2 = &enet2;
>>>               ethernet3 = &enet3;
>>>               spi0 = &spi0
>>>       };
>>> The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
>>> I am looking for the same for ethernet devices:
>>>  ethernet4 = &enet4;  /* should become eth4 */
>>>  ethernet0 = &enet0;  /* should become eth0 */
>>> but I cannot find something like that for eth devices.
>>>
>>> Could such functionality be added?
>>
>> It could, do we want and need to, no. You have the Ethernet alias in
>> /sys/class/net/*/device/uevent already that would allow you to perform
>> that (re)naming in user-space:
>>
>> # cat /sys/class/net/eth0/device/uevent
>> DRIVER=bcmgenet
>> OF_NAME=ethernet
>> OF_FULLNAME=/rdb/ethernet@f0480000
>> OF_TYPE=network
>> OF_COMPATIBLE_0=brcm,genet-v5
>> OF_COMPATIBLE_N=1
>> OF_ALIAS_0=eth0                 <==================
>> MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
> 
> Yes, one can if one uses udev and can find something to identify the hw I/F with, my
> cat /sys/class/net/eth0/device/uevent looks like:
> DRIVER=fsl_dpa
> MODALIAS=platform:dpaa-ethernet

Does not dpaa have a notion of Ethernet ports and those should have
proper information? Maybe that is part of your problem here, it should
have the OF_ALIAS information somehow available.

> 
> not sure mdev supports this, does it?
> Our simple installer FS(initramfs) doesn't have either udev or mdev.

I don't know, but you could have a simple shell script that looks at
specific network device properties to decide on the naming and call
ifrename.

> 
> I also noted that using status = "disabled" didn't work either to create a fix name scheme.
> Even worse, all the eth I/F after gets renumbered. It seems to me there
> is value in having stability in eth I/F naming at boot.
> Then userspace(udev) can rename if need be. 
> 
> Sure would like to known more about why this feature is not wanted ?
> 
> I found
>   https://patchwork.kernel.org/patch/4122441/
> You quote policy as reason but surely it must be better to
> have something stable, connected to the hardware name, than semirandom naming?

If the Device Tree nodes are ordered by ascending base register address,
my understanding is that you get the same order as far as
platform_device creation goes, this may not be true in the future if Rob
decides to randomize that, but AFAICT this is still true. This may not
work well with status = disabled properties being inserted here and
there, but we have used that here and it has worked for as far as I can
remember doing it.

Second, you might want to name network devices ethX, but what if I want
to name them ethernetX or fooX or barX? Should we be accepting a
mechanism in the kernel that would allow someone to name the interfaces
the way they want straight from a name being provided in Device Tree?

Aliases are fine for providing relative stability within the Device Tree
itself and boot programs that might need to modify the Device Tree (e.g:
inserting MAC addresses) such that you don't have to encode logic to
search for nodes by compatible strings etc. but outside of that use
case, it seems to me that you can resolve every naming decision in
user-space.
-- 
Florian

Re: ethernet "bus" number in DTS ?

[Joakim Tjernlund]

On Tue, 2018-10-23 at 11:20 -0700, Florian Fainelli wrote:
> 
> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
> > > 
> > > 
> > > On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
> > > > SPI (and others) has a way to define bus number in a aliases:
> > > >       aliases {
> > > >               ethernet4 = &enet4;
> > > >               ethernet0 = &enet0;
> > > >               ethernet1 = &enet1;
> > > >               ethernet2 = &enet2;
> > > >               ethernet3 = &enet3;
> > > >               spi0 = &spi0
> > > >       };
> > > > The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
> > > > I am looking for the same for ethernet devices:
> > > >  ethernet4 = &enet4;  /* should become eth4 */
> > > >  ethernet0 = &enet0;  /* should become eth0 */
> > > > but I cannot find something like that for eth devices.
> > > > 
> > > > Could such functionality be added?
> > > 
> > > It could, do we want and need to, no. You have the Ethernet alias in
> > > /sys/class/net/*/device/uevent already that would allow you to perform
> > > that (re)naming in user-space:
> > > 
> > > # cat /sys/class/net/eth0/device/uevent
> > > DRIVER=bcmgenet
> > > OF_NAME=ethernet
> > > OF_FULLNAME=/rdb/ethernet@f0480000
> > > OF_TYPE=network
> > > OF_COMPATIBLE_0=brcm,genet-v5
> > > OF_COMPATIBLE_N=1
> > > OF_ALIAS_0=eth0                 <==================
> > > MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
> > 
> > Yes, one can if one uses udev and can find something to identify the hw I/F with, my
> > cat /sys/class/net/eth0/device/uevent looks like:
> > DRIVER=fsl_dpa
> > MODALIAS=platform:dpaa-ethernet
> 
> Does not dpaa have a notion of Ethernet ports and those should have
> proper information? Maybe that is part of your problem here, it should
> have the OF_ALIAS information somehow available.

I cannot say ATM, but this lack of standard does not make it easier to rename I/F's in udev.

> 
> > not sure mdev supports this, does it?
> > Our simple installer FS(initramfs) doesn't have either udev or mdev.
> 
> I don't know, but you could have a simple shell script that looks at
> specific network device properties to decide on the naming and call
> ifrename.

This reinventing of the wheel is what I am trying to avoid.

> 
> > I also noted that using status = "disabled" didn't work either to create a fix name scheme.
> > Even worse, all the eth I/F after gets renumbered. It seems to me there
> > is value in having stability in eth I/F naming at boot.
> > Then userspace(udev) can rename if need be.
> > 
> > Sure would like to known more about why this feature is not wanted ?
> > 
> > I found
> >   https://patchwork.kernel.org/patch/4122441/
> > You quote policy as reason but surely it must be better to
> > have something stable, connected to the hardware name, than semirandom naming?
> 
> If the Device Tree nodes are ordered by ascending base register address,
> my understanding is that you get the same order as far as
> platform_device creation goes, this may not be true in the future if Rob
> decides to randomize that, but AFAICT this is still true. This may not
> work well with status = disabled properties being inserted here and
> there, but we have used that here and it has worked for as far as I can
> remember doing it.

I recall it is the order in which the eth alias appear that controls the naming,
not 100% sure though.

> 
> Second, you might want to name network devices ethX, but what if I want
> to name them ethernetX or fooX or barX? Should we be accepting a
> mechanism in the kernel that would allow someone to name the interfaces
> the way they want straight from a name being provided in Device Tree?

I just want to have stable boot names, aka ethX, which can defined in
the platforms DT. Then userspace can go from there to whatever it needs,
udev could possibly use these stable boot names to identify the I/F's to rename.

ATM, it is pretty hard to even use udev when /sys/class/net/eth0/device/uevent
can look different even for OF created interfaces.

> 
> Aliases are fine for providing relative stability within the Device Tree
> itself and boot programs that might need to modify the Device Tree (e.g:
> inserting MAC addresses) such that you don't have to encode logic to
> search for nodes by compatible strings etc. but outside of that use
> case, it seems to me that you can resolve every naming decision in
> user-space.

Well, you can resolve MAC address assignment in user space too but most
will agree that is not convenient. I suggest it is also handy to have
some control of I/F enumeration(ethX that is) from platform code like DT.

 Jocke

Re: ethernet "bus" number in DTS ?

[Florian Fainelli]

On 10/23/18 1:02 PM, Joakim Tjernlund wrote:
> On Tue, 2018-10-23 at 11:20 -0700, Florian Fainelli wrote:
>>
>> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
>>> On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
>>>>
>>>>
>>>> On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
>>>>> SPI (and others) has a way to define bus number in a aliases:
>>>>>       aliases {
>>>>>               ethernet4 = &enet4;
>>>>>               ethernet0 = &enet0;
>>>>>               ethernet1 = &enet1;
>>>>>               ethernet2 = &enet2;
>>>>>               ethernet3 = &enet3;
>>>>>               spi0 = &spi0
>>>>>       };
>>>>> The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
>>>>> I am looking for the same for ethernet devices:
>>>>>  ethernet4 = &enet4;  /* should become eth4 */
>>>>>  ethernet0 = &enet0;  /* should become eth0 */
>>>>> but I cannot find something like that for eth devices.
>>>>>
>>>>> Could such functionality be added?
>>>>
>>>> It could, do we want and need to, no. You have the Ethernet alias in
>>>> /sys/class/net/*/device/uevent already that would allow you to perform
>>>> that (re)naming in user-space:
>>>>
>>>> # cat /sys/class/net/eth0/device/uevent
>>>> DRIVER=bcmgenet
>>>> OF_NAME=ethernet
>>>> OF_FULLNAME=/rdb/ethernet@f0480000
>>>> OF_TYPE=network
>>>> OF_COMPATIBLE_0=brcm,genet-v5
>>>> OF_COMPATIBLE_N=1
>>>> OF_ALIAS_0=eth0                 <==================
>>>> MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
>>>
>>> Yes, one can if one uses udev and can find something to identify the hw I/F with, my
>>> cat /sys/class/net/eth0/device/uevent looks like:
>>> DRIVER=fsl_dpa
>>> MODALIAS=platform:dpaa-ethernet
>>
>> Does not dpaa have a notion of Ethernet ports and those should have
>> proper information? Maybe that is part of your problem here, it should
>> have the OF_ALIAS information somehow available.
> 
> I cannot say ATM, but this lack of standard does not make it easier to rename I/F's in udev.
> 
>>
>>> not sure mdev supports this, does it?
>>> Our simple installer FS(initramfs) doesn't have either udev or mdev.
>>
>> I don't know, but you could have a simple shell script that looks at
>> specific network device properties to decide on the naming and call
>> ifrename.
> 
> This reinventing of the wheel is what I am trying to avoid.

Embedded is all about being a special snowflake and re-inventing the
wheel, but having some desktop-like distribution user-space would
certainly allow you to re-invent other parts of the wheel.

> 
>>
>>> I also noted that using status = "disabled" didn't work either to create a fix name scheme.
>>> Even worse, all the eth I/F after gets renumbered. It seems to me there
>>> is value in having stability in eth I/F naming at boot.
>>> Then userspace(udev) can rename if need be.
>>>
>>> Sure would like to known more about why this feature is not wanted ?
>>>
>>> I found
>>>   https://patchwork.kernel.org/patch/4122441/
>>> You quote policy as reason but surely it must be better to
>>> have something stable, connected to the hardware name, than semirandom naming?
>>
>> If the Device Tree nodes are ordered by ascending base register address,
>> my understanding is that you get the same order as far as
>> platform_device creation goes, this may not be true in the future if Rob
>> decides to randomize that, but AFAICT this is still true. This may not
>> work well with status = disabled properties being inserted here and
>> there, but we have used that here and it has worked for as far as I can
>> remember doing it.
> 
> I recall it is the order in which the eth alias appear that controls the naming,
> not 100% sure though.

Aliases are not looked up at all by the platform bus code other that
with of_get_alias() and friends, it is the order in which the nodes are
declared in the Device Tree, preferably ordered by base address that
dictates the order in which platform devices are created.

> 
>>
>> Second, you might want to name network devices ethX, but what if I want
>> to name them ethernetX or fooX or barX? Should we be accepting a
>> mechanism in the kernel that would allow someone to name the interfaces
>> the way they want straight from a name being provided in Device Tree?
> 
> I just want to have stable boot names, aka ethX, which can defined in
> the platforms DT. Then userspace can go from there to whatever it needs,
> udev could possibly use these stable boot names to identify the I/F's to rename.
> 
> ATM, it is pretty hard to even use udev when /sys/class/net/eth0/device/uevent
> can look different even for OF created interfaces.

network devices have a gazillion of other sysfs attributes that all make
them unique enough to create stable names.

> 
>>
>> Aliases are fine for providing relative stability within the Device Tree
>> itself and boot programs that might need to modify the Device Tree (e.g:
>> inserting MAC addresses) such that you don't have to encode logic to
>> search for nodes by compatible strings etc. but outside of that use
>> case, it seems to me that you can resolve every naming decision in
>> user-space.
> 
> Well, you can resolve MAC address assignment in user space too but most
> will agree that is not convenient. I suggest it is also handy to have
> some control of I/F enumeration(ethX that is) from platform code like DT.

If that is what you desire because you do not want to use user-space to
do that job, that is probably fine, it's open source after all, an not
every patch is a candidate for being included upstream. A patch doing
what you describe would likely be rejected again.
-- 
Florian

Re: ethernet "bus" number in DTS ?

[Joakim Tjernlund]

On Tue, 2018-10-23 at 13:07 -0700, Florian Fainelli wrote:
> 
> On 10/23/18 1:02 PM, Joakim Tjernlund wrote:
> > On Tue, 2018-10-23 at 11:20 -0700, Florian Fainelli wrote:
> > > On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> > > > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
> > > > > 
> > > > > On 10/23/18 9:49 AM, Joakim Tjernlund wrote:
> > > > > > SPI (and others) has a way to define bus number in a aliases:
> > > > > >       aliases {
> > > > > >               ethernet4 = &enet4;
> > > > > >               ethernet0 = &enet0;
> > > > > >               ethernet1 = &enet1;
> > > > > >               ethernet2 = &enet2;
> > > > > >               ethernet3 = &enet3;
> > > > > >               spi0 = &spi0
> > > > > >       };
> > > > > > The 0 in the spi0 alias will translate to bus num 0 so one can control the /dev nodes, like /dev/spidev0
> > > > > > I am looking for the same for ethernet devices:
> > > > > >  ethernet4 = &enet4;  /* should become eth4 */
> > > > > >  ethernet0 = &enet0;  /* should become eth0 */
> > > > > > but I cannot find something like that for eth devices.
> > > > > > 
> > > > > > Could such functionality be added?
> > > > > 
> > > > > It could, do we want and need to, no. You have the Ethernet alias in
> > > > > /sys/class/net/*/device/uevent already that would allow you to perform
> > > > > that (re)naming in user-space:
> > > > > 
> > > > > # cat /sys/class/net/eth0/device/uevent
> > > > > DRIVER=bcmgenet
> > > > > OF_NAME=ethernet
> > > > > OF_FULLNAME=/rdb/ethernet@f0480000
> > > > > OF_TYPE=network
> > > > > OF_COMPATIBLE_0=brcm,genet-v5
> > > > > OF_COMPATIBLE_N=1
> > > > > OF_ALIAS_0=eth0                 <==================
> > > > > MODALIAS=of:NethernetTnetworkCbrcm,genet-v5
> > > > 
> > > > Yes, one can if one uses udev and can find something to identify the hw I/F with, my
> > > > cat /sys/class/net/eth0/device/uevent looks like:
> > > > DRIVER=fsl_dpa
> > > > MODALIAS=platform:dpaa-ethernet
> > > 
> > > Does not dpaa have a notion of Ethernet ports and those should have
> > > proper information? Maybe that is part of your problem here, it should
> > > have the OF_ALIAS information somehow available.
> > 
> > I cannot say ATM, but this lack of standard does not make it easier to rename I/F's in udev.
> > 
> > > > not sure mdev supports this, does it?
> > > > Our simple installer FS(initramfs) doesn't have either udev or mdev.
> > > 
> > > I don't know, but you could have a simple shell script that looks at
> > > specific network device properties to decide on the naming and call
> > > ifrename.
> > 
> > This reinventing of the wheel is what I am trying to avoid.
> 
> Embedded is all about being a special snowflake and re-inventing the
> wheel, but having some desktop-like distribution user-space would
> certainly allow you to re-invent other parts of the wheel.
> 
> > > > I also noted that using status = "disabled" didn't work either to create a fix name scheme.
> > > > Even worse, all the eth I/F after gets renumbered. It seems to me there
> > > > is value in having stability in eth I/F naming at boot.
> > > > Then userspace(udev) can rename if need be.
> > > > 
> > > > Sure would like to known more about why this feature is not wanted ?
> > > > 
> > > > I found
> > > >   https://patchwork.kernel.org/patch/4122441/
> > > > You quote policy as reason but surely it must be better to
> > > > have something stable, connected to the hardware name, than semirandom naming?
> > > 
> > > If the Device Tree nodes are ordered by ascending base register address,
> > > my understanding is that you get the same order as far as
> > > platform_device creation goes, this may not be true in the future if Rob
> > > decides to randomize that, but AFAICT this is still true. This may not
> > > work well with status = disabled properties being inserted here and
> > > there, but we have used that here and it has worked for as far as I can
> > > remember doing it.
> > 
> > I recall it is the order in which the eth alias appear that controls the naming,
> > not 100% sure though.
> 
> Aliases are not looked up at all by the platform bus code other that
> with of_get_alias() and friends, it is the order in which the nodes are
> declared in the Device Tree, preferably ordered by base address that
> dictates the order in which platform devices are created.

I see, thanks.

> 
> > > Second, you might want to name network devices ethX, but what if I want
> > > to name them ethernetX or fooX or barX? Should we be accepting a
> > > mechanism in the kernel that would allow someone to name the interfaces
> > > the way they want straight from a name being provided in Device Tree?
> > 
> > I just want to have stable boot names, aka ethX, which can defined in
> > the platforms DT. Then userspace can go from there to whatever it needs,
> > udev could possibly use these stable boot names to identify the I/F's to rename.
> > 
> > ATM, it is pretty hard to even use udev when /sys/class/net/eth0/device/uevent
> > can look different even for OF created interfaces.
> 
> network devices have a gazillion of other sysfs attributes that all make
> them unique enough to create stable names.

That is kind of my point, there doesn't seem to be any stable source of info
that can be relied on. Each platform/driver is it own, DT/OF created I/F's should
look the same in /sys/class/net/eth0/device/uevent but that is not so.

I am sure I can find something though.

> 
> > > Aliases are fine for providing relative stability within the Device Tree
> > > itself and boot programs that might need to modify the Device Tree (e.g:
> > > inserting MAC addresses) such that you don't have to encode logic to
> > > search for nodes by compatible strings etc. but outside of that use
> > > case, it seems to me that you can resolve every naming decision in
> > > user-space.
> > 
> > Well, you can resolve MAC address assignment in user space too but most
> > will agree that is not convenient. I suggest it is also handy to have
> > some control of I/F enumeration(ethX that is) from platform code like DT.
> 
> If that is what you desire because you do not want to use user-space to
> do that job, that is probably fine, it's open source after all, an not
> every patch is a candidate for being included upstream. A patch doing
> what you describe would likely be rejected again.
> --

Of course, but I didn't start this thread just to hack my own patch. I wanted
buy in from the community and that is not happening so I will rest now.

Thanks you for taking the time to discuss this,

        Jocke

Re: ethernet "bus" number in DTS ?

[Michal Suchánek]

On Tue, 23 Oct 2018 11:20:36 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:

> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:  

> > 
> > I also noted that using status = "disabled" didn't work either to
> > create a fix name scheme. Even worse, all the eth I/F after gets
> > renumbered. It seems to me there is value in having stability in
> > eth I/F naming at boot. Then userspace(udev) can rename if need be. 
> > 
> > Sure would like to known more about why this feature is not wanted ?
> > 
> > I found
> >   https://patchwork.kernel.org/patch/4122441/
> > You quote policy as reason but surely it must be better to
> > have something stable, connected to the hardware name, than
> > semirandom naming?  
> 
> If the Device Tree nodes are ordered by ascending base register
> address, my understanding is that you get the same order as far as
> platform_device creation goes, this may not be true in the future if
> Rob decides to randomize that, but AFAICT this is still true. This
> may not work well with status = disabled properties being inserted
> here and there, but we have used that here and it has worked for as
> far as I can remember doing it.

So this is unstable in several respects. First is changing the
enabled/disabled status in the deivecetrees provided by the kernel.

Second is if you have hardware hotplug mechanism either by firmware or
by loading device overlays.

Third is the case when the devicetree is not built as part of the
kernel but is instead provided by firmware that initializes the
low-level hardware details. Then the ordering by address is not
guaranteed nor is that the same address will be used to access the same
interface every time. There might be multiple ways to configure the
hardware depending on firmware configuration and/or version.

 
> Second, you might want to name network devices ethX, but what if I
> want to name them ethernetX or fooX or barX? Should we be accepting a
> mechanism in the kernel that would allow someone to name the
> interfaces the way they want straight from a name being provided in
> Device Tree?

Clearly if there is text Ethernet1 printed above the Ethernet port we
should provide a mechanism to name the port Ethernet1 by default.

> 
> Aliases are fine for providing relative stability within the Device
> Tree itself and boot programs that might need to modify the Device
> Tree (e.g: inserting MAC addresses) such that you don't have to
> encode logic to search for nodes by compatible strings etc. but
> outside of that use case, it seems to me that you can resolve every
> naming decision in user-space.

However, this is pushing platform-specific knowledge to userspace. The
way the Ethernet interface is attached and hence the device properties
usable for identifying the device uniquely are platform-specific. 

On the other hand, aliases are universal when provided. If they are
good enough to assign a MAC address they are good enough to provide a
stable default name.

I think this is indeed forcing the userspace to reinvent several wheels
for no good reason.

What is the problem with adding the aliases?

Thanks

Michal

Re: ethernet "bus" number in DTS ?

[Michal Suchánek]

On Tue, 23 Oct 2018 11:20:36 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:

> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:  

> > 
> > I also noted that using status = "disabled" didn't work either to
> > create a fix name scheme. Even worse, all the eth I/F after gets
> > renumbered. It seems to me there is value in having stability in
> > eth I/F naming at boot. Then userspace(udev) can rename if need be. 
> > 
> > Sure would like to known more about why this feature is not wanted ?
> > 
> > I found
> >   https://patchwork.kernel.org/patch/4122441/
> > You quote policy as reason but surely it must be better to
> > have something stable, connected to the hardware name, than
> > semirandom naming?  
> 
> If the Device Tree nodes are ordered by ascending base register
> address, my understanding is that you get the same order as far as
> platform_device creation goes, this may not be true in the future if
> Rob decides to randomize that, but AFAICT this is still true. This
> may not work well with status = disabled properties being inserted
> here and there, but we have used that here and it has worked for as
> far as I can remember doing it.

So this is unstable in several respects. First is changing the
enabled/disabled status in the deivecetrees provided by the kernel.

Second is if you have hardware hotplug mechanism either by firmware or
by loading device overlays.

Third is the case when the devicetree is not built as part of the
kernel but is instead provided by firmware that initializes the
low-level hardware details. Then the ordering by address is not
guaranteed nor is that the same address will be used to access the same
interface every time. There might be multiple ways to configure the
hardware depending on firmware configuration and/or version.

 
> Second, you might want to name network devices ethX, but what if I
> want to name them ethernetX or fooX or barX? Should we be accepting a
> mechanism in the kernel that would allow someone to name the
> interfaces the way they want straight from a name being provided in
> Device Tree?

Clearly if there is text Ethernet1 printed above the Ethernet port we
should provide a mechanism to name the port Ethernet1 by default.

> 
> Aliases are fine for providing relative stability within the Device
> Tree itself and boot programs that might need to modify the Device
> Tree (e.g: inserting MAC addresses) such that you don't have to
> encode logic to search for nodes by compatible strings etc. but
> outside of that use case, it seems to me that you can resolve every
> naming decision in user-space.

However, this is pushing platform-specific knowledge to userspace. The
way the Ethernet interface is attached and hence the device properties
usable for identifying the device uniquely are platform-specific. 

On the other hand, aliases are universal when provided. If they are
good enough to assign a MAC address they are good enough to provide a
stable default name.

I think this is indeed forcing the userspace to reinvent several wheels
for no good reason.

What is the problem with adding the aliases?

Thanks

Michal

Re: ethernet "bus" number in DTS ?

[Joakim Tjernlund]

On Wed, 2018-10-24 at 08:22 +0200, Michal Suchánek wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> On Tue, 23 Oct 2018 11:20:36 -0700
> Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
> > On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
> > > On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:
> > > I also noted that using status = "disabled" didn't work either to
> > > create a fix name scheme. Even worse, all the eth I/F after gets
> > > renumbered. It seems to me there is value in having stability in
> > > eth I/F naming at boot. Then userspace(udev) can rename if need be.
> > > 
> > > Sure would like to known more about why this feature is not wanted ?
> > > 
> > > I found
> > >   https://patchwork.kernel.org/patch/4122441/
> > > You quote policy as reason but surely it must be better to
> > > have something stable, connected to the hardware name, than
> > > semirandom naming?
> > 
> > If the Device Tree nodes are ordered by ascending base register
> > address, my understanding is that you get the same order as far as
> > platform_device creation goes, this may not be true in the future if
> > Rob decides to randomize that, but AFAICT this is still true. This
> > may not work well with status = disabled properties being inserted
> > here and there, but we have used that here and it has worked for as
> > far as I can remember doing it.
> 
> So this is unstable in several respects. First is changing the
> enabled/disabled status in the deivecetrees provided by the kernel.
> 
> Second is if you have hardware hotplug mechanism either by firmware or
> by loading device overlays.
> 
> Third is the case when the devicetree is not built as part of the
> kernel but is instead provided by firmware that initializes the
> low-level hardware details. Then the ordering by address is not
> guaranteed nor is that the same address will be used to access the same
> interface every time. There might be multiple ways to configure the
> hardware depending on firmware configuration and/or version.
> 
> 
> > Second, you might want to name network devices ethX, but what if I
> > want to name them ethernetX or fooX or barX? Should we be accepting a
> > mechanism in the kernel that would allow someone to name the
> > interfaces the way they want straight from a name being provided in
> > Device Tree?

Just to be clear, I am saying that we don't need to control the full
name of the Ethernet device, just the numerical id so one can tie eth0
to a fixed physical device.

> 
> Clearly if there is text Ethernet1 printed above the Ethernet port we
> should provide a mechanism to name the port Ethernet1 by default.
> 
> > Aliases are fine for providing relative stability within the Device
> > Tree itself and boot programs that might need to modify the Device
> > Tree (e.g: inserting MAC addresses) such that you don't have to
> > encode logic to search for nodes by compatible strings etc. but
> > outside of that use case, it seems to me that you can resolve every
> > naming decision in user-space.
> 
> However, this is pushing platform-specific knowledge to userspace. The
> way the Ethernet interface is attached and hence the device properties
> usable for identifying the device uniquely are platform-specific.
> 
> On the other hand, aliases are universal when provided. If they are
> good enough to assign a MAC address they are good enough to provide a
> stable default name.
> 
> I think this is indeed forcing the userspace to reinvent several wheels
> for no good reason.
> 
> What is the problem with adding the aliases?

Well put above, thanks.

   Jocke

Re: ethernet "bus" number in DTS ?

[Florian Fainelli]

On 10/23/18 11:22 PM, Michal Suchánek wrote:
> On Tue, 23 Oct 2018 11:20:36 -0700
> Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
>> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
>>> On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:  
> 
>>>
>>> I also noted that using status = "disabled" didn't work either to
>>> create a fix name scheme. Even worse, all the eth I/F after gets
>>> renumbered. It seems to me there is value in having stability in
>>> eth I/F naming at boot. Then userspace(udev) can rename if need be. 
>>>
>>> Sure would like to known more about why this feature is not wanted ?
>>>
>>> I found
>>>   https://patchwork.kernel.org/patch/4122441/
>>> You quote policy as reason but surely it must be better to
>>> have something stable, connected to the hardware name, than
>>> semirandom naming?  
>>
>> If the Device Tree nodes are ordered by ascending base register
>> address, my understanding is that you get the same order as far as
>> platform_device creation goes, this may not be true in the future if
>> Rob decides to randomize that, but AFAICT this is still true. This
>> may not work well with status = disabled properties being inserted
>> here and there, but we have used that here and it has worked for as
>> far as I can remember doing it.
> 
> So this is unstable in several respects. First is changing the
> enabled/disabled status in the deivecetrees provided by the kernel.
> 
> Second is if you have hardware hotplug mechanism either by firmware or
> by loading device overlays.
> 
> Third is the case when the devicetree is not built as part of the
> kernel but is instead provided by firmware that initializes the
> low-level hardware details. Then the ordering by address is not
> guaranteed nor is that the same address will be used to access the same
> interface every time. There might be multiple ways to configure the
> hardware depending on firmware configuration and/or version.
> 
>  
>> Second, you might want to name network devices ethX, but what if I
>> want to name them ethernetX or fooX or barX? Should we be accepting a
>> mechanism in the kernel that would allow someone to name the
>> interfaces the way they want straight from a name being provided in
>> Device Tree?
> 
> Clearly if there is text Ethernet1 printed above the Ethernet port we
> should provide a mechanism to name the port Ethernet1 by default.

Yes, but then have a specific property that is flexible enough to
retrieve things like "vital product information". For DSA switches, we
have an optional "label" property which names the network device
directly like it would be found on the product's case. Ideally this
should be much more flexible such that it can point to the appropriate
node/firmware service/whatever to get that name, which is what some
people have been working on lately, see [1].

[1]: https://lkml.org/lkml/2018/8/14/1039

The point is don't re-purpose the aliases which is something that exists
within Device Tree to basically provide a shorter path to a specific set
of nodes for the boot program to mangle and muck with instead of having
to resolve a full path to a node. At least that is how I conceive it.

Now what complicates the matter is that some OSes like Linux tend to use
it to also generate seemingly stable index for peripherals that are
numbered by index such as SPI, I2C, etc buses, which is why we are
having this conversation here, see below for more.

> 
>>
>> Aliases are fine for providing relative stability within the Device
>> Tree itself and boot programs that might need to modify the Device
>> Tree (e.g: inserting MAC addresses) such that you don't have to
>> encode logic to search for nodes by compatible strings etc. but
>> outside of that use case, it seems to me that you can resolve every
>> naming decision in user-space.
> 
> However, this is pushing platform-specific knowledge to userspace. The
> way the Ethernet interface is attached and hence the device properties
> usable for identifying the device uniquely are platform-specific.

There is always going to be some amount of platform specific knowledge
to user-space, what matters is the level of abstraction that is
presented to you.

> 
> On the other hand, aliases are universal when provided. If they are
> good enough to assign a MAC address they are good enough to provide a
> stable default name.

We are not talking about the same aliases then. The special Device Tree
node named "aliases" is a way to create shorted Device Tree node paths,
it is not by any means an equivalent for what I would rather call a
"label", or "port name" or silk screen annotation on a PCB for instance.

> 
> I think this is indeed forcing the userspace to reinvent several wheels
> for no good reason.

udev or systemd will come up with some stable names for your network
device right off the bat. If you are deeply embedded maybe you don't
want those, but then use something like the full path in /sys to get
some stable names based on the SoC's topology.

> 
> What is the problem with adding the aliases?

aliases is IMHO the wrong tool for the job because it is too limiting,
you want it to be used to have Ethernet controller instance N to be
named "ethN", what if someone tomorrows says, no this is not good, I
want the aliases to automatically name my network devices
"ethernet-controllerN" or "blahblahN"? You see where I am getting with that?

And yes, I do realize that Linux has traditionally named Ethernet
adapters ethN, but also allows people to name interfaces just the way
they want even from within the drivers themselves.

Now imagine your platform uses ACPI, and there are no aliases there to
point a node with a shorter name, how we would go about naming your
Ethernet controller unless there is a specific VPD/label/sticker
property that can be somehow be retried?
-- 
Florian

Re: ethernet "bus" number in DTS ?

[Florian Fainelli]

On 10/23/18 11:22 PM, Michal Suchánek wrote:
> On Tue, 23 Oct 2018 11:20:36 -0700
> Florian Fainelli <f.fainelli@gmail.com> wrote:
> 
>> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:
>>> On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:  
> 
>>>
>>> I also noted that using status = "disabled" didn't work either to
>>> create a fix name scheme. Even worse, all the eth I/F after gets
>>> renumbered. It seems to me there is value in having stability in
>>> eth I/F naming at boot. Then userspace(udev) can rename if need be. 
>>>
>>> Sure would like to known more about why this feature is not wanted ?
>>>
>>> I found
>>>   https://patchwork.kernel.org/patch/4122441/
>>> You quote policy as reason but surely it must be better to
>>> have something stable, connected to the hardware name, than
>>> semirandom naming?  
>>
>> If the Device Tree nodes are ordered by ascending base register
>> address, my understanding is that you get the same order as far as
>> platform_device creation goes, this may not be true in the future if
>> Rob decides to randomize that, but AFAICT this is still true. This
>> may not work well with status = disabled properties being inserted
>> here and there, but we have used that here and it has worked for as
>> far as I can remember doing it.
> 
> So this is unstable in several respects. First is changing the
> enabled/disabled status in the deivecetrees provided by the kernel.
> 
> Second is if you have hardware hotplug mechanism either by firmware or
> by loading device overlays.
> 
> Third is the case when the devicetree is not built as part of the
> kernel but is instead provided by firmware that initializes the
> low-level hardware details. Then the ordering by address is not
> guaranteed nor is that the same address will be used to access the same
> interface every time. There might be multiple ways to configure the
> hardware depending on firmware configuration and/or version.
> 
>  
>> Second, you might want to name network devices ethX, but what if I
>> want to name them ethernetX or fooX or barX? Should we be accepting a
>> mechanism in the kernel that would allow someone to name the
>> interfaces the way they want straight from a name being provided in
>> Device Tree?
> 
> Clearly if there is text Ethernet1 printed above the Ethernet port we
> should provide a mechanism to name the port Ethernet1 by default.

Yes, but then have a specific property that is flexible enough to
retrieve things like "vital product information". For DSA switches, we
have an optional "label" property which names the network device
directly like it would be found on the product's case. Ideally this
should be much more flexible such that it can point to the appropriate
node/firmware service/whatever to get that name, which is what some
people have been working on lately, see [1].

[1]: https://lkml.org/lkml/2018/8/14/1039

The point is don't re-purpose the aliases which is something that exists
within Device Tree to basically provide a shorter path to a specific set
of nodes for the boot program to mangle and muck with instead of having
to resolve a full path to a node. At least that is how I conceive it.

Now what complicates the matter is that some OSes like Linux tend to use
it to also generate seemingly stable index for peripherals that are
numbered by index such as SPI, I2C, etc buses, which is why we are
having this conversation here, see below for more.

> 
>>
>> Aliases are fine for providing relative stability within the Device
>> Tree itself and boot programs that might need to modify the Device
>> Tree (e.g: inserting MAC addresses) such that you don't have to
>> encode logic to search for nodes by compatible strings etc. but
>> outside of that use case, it seems to me that you can resolve every
>> naming decision in user-space.
> 
> However, this is pushing platform-specific knowledge to userspace. The
> way the Ethernet interface is attached and hence the device properties
> usable for identifying the device uniquely are platform-specific.

There is always going to be some amount of platform specific knowledge
to user-space, what matters is the level of abstraction that is
presented to you.

> 
> On the other hand, aliases are universal when provided. If they are
> good enough to assign a MAC address they are good enough to provide a
> stable default name.

We are not talking about the same aliases then. The special Device Tree
node named "aliases" is a way to create shorted Device Tree node paths,
it is not by any means an equivalent for what I would rather call a
"label", or "port name" or silk screen annotation on a PCB for instance.

> 
> I think this is indeed forcing the userspace to reinvent several wheels
> for no good reason.

udev or systemd will come up with some stable names for your network
device right off the bat. If you are deeply embedded maybe you don't
want those, but then use something like the full path in /sys to get
some stable names based on the SoC's topology.

> 
> What is the problem with adding the aliases?

aliases is IMHO the wrong tool for the job because it is too limiting,
you want it to be used to have Ethernet controller instance N to be
named "ethN", what if someone tomorrows says, no this is not good, I
want the aliases to automatically name my network devices
"ethernet-controllerN" or "blahblahN"? You see where I am getting with that?

And yes, I do realize that Linux has traditionally named Ethernet
adapters ethN, but also allows people to name interfaces just the way
they want even from within the drivers themselves.

Now imagine your platform uses ACPI, and there are no aliases there to
point a node with a shorter name, how we would go about naming your
Ethernet controller unless there is a specific VPD/label/sticker
property that can be somehow be retried?
-- 
Florian

Re: ethernet "bus" number in DTS ?

[Michal Suchánek]

On Fri, 26 Oct 2018 15:57:15 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:

> On 10/23/18 11:22 PM, Michal Suchánek wrote:
> > On Tue, 23 Oct 2018 11:20:36 -0700
> > Florian Fainelli <f.fainelli@gmail.com> wrote:
> >   
> >> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:  
> >>> On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:    
> >   
> >>>
> >>> I also noted that using status = "disabled" didn't work either to
> >>> create a fix name scheme. Even worse, all the eth I/F after gets
> >>> renumbered. It seems to me there is value in having stability in
> >>> eth I/F naming at boot. Then userspace(udev) can rename if need
> >>> be. 
> >>>
> >>> Sure would like to known more about why this feature is not
> >>> wanted ?
> >>>
> >>> I found
> >>>   https://patchwork.kernel.org/patch/4122441/
> >>> You quote policy as reason but surely it must be better to
> >>> have something stable, connected to the hardware name, than
> >>> semirandom naming?    
> >>
> >> If the Device Tree nodes are ordered by ascending base register
> >> address, my understanding is that you get the same order as far as
> >> platform_device creation goes, this may not be true in the future
> >> if Rob decides to randomize that, but AFAICT this is still true.
> >> This may not work well with status = disabled properties being
> >> inserted here and there, but we have used that here and it has
> >> worked for as far as I can remember doing it.  
> > 
> > So this is unstable in several respects. First is changing the
> > enabled/disabled status in the deivecetrees provided by the kernel.
> > 
> > Second is if you have hardware hotplug mechanism either by firmware
> > or by loading device overlays.
> > 
> > Third is the case when the devicetree is not built as part of the
> > kernel but is instead provided by firmware that initializes the
> > low-level hardware details. Then the ordering by address is not
> > guaranteed nor is that the same address will be used to access the
> > same interface every time. There might be multiple ways to
> > configure the hardware depending on firmware configuration and/or
> > version.
> > 
> >    
> >> Second, you might want to name network devices ethX, but what if I
> >> want to name them ethernetX or fooX or barX? Should we be
> >> accepting a mechanism in the kernel that would allow someone to
> >> name the interfaces the way they want straight from a name being
> >> provided in Device Tree?  
> > 
> > Clearly if there is text Ethernet1 printed above the Ethernet port
> > we should provide a mechanism to name the port Ethernet1 by
> > default.  
> 
> Yes, but then have a specific property that is flexible enough to
> retrieve things like "vital product information". For DSA switches, we
> have an optional "label" property which names the network device
> directly like it would be found on the product's case. Ideally this
> should be much more flexible such that it can point to the appropriate
> node/firmware service/whatever to get that name, which is what some
> people have been working on lately, see [1].
> 
> [1]: https://lkml.org/lkml/2018/8/14/1039

That's nice for something unique per-device like MAC address. However,
for something per-model like port labels DT properties should suffice.

> 
> The point is don't re-purpose the aliases which is something that
> exists within Device Tree to basically provide a shorter path to a
> specific set of nodes for the boot program to mangle and muck with
> instead of having to resolve a full path to a node. At least that is
> how I conceive it.
> 
> Now what complicates the matter is that some OSes like Linux tend to
> use it to also generate seemingly stable index for peripherals that
> are numbered by index such as SPI, I2C, etc buses, which is why we are
> having this conversation here, see below for more.
> 
> >   
> >>
> >> Aliases are fine for providing relative stability within the Device
> >> Tree itself and boot programs that might need to modify the Device
> >> Tree (e.g: inserting MAC addresses) such that you don't have to
> >> encode logic to search for nodes by compatible strings etc. but
> >> outside of that use case, it seems to me that you can resolve every
> >> naming decision in user-space.  
> > 
> > However, this is pushing platform-specific knowledge to userspace.
> > The way the Ethernet interface is attached and hence the device
> > properties usable for identifying the device uniquely are
> > platform-specific.  
> 
> There is always going to be some amount of platform specific knowledge
> to user-space, what matters is the level of abstraction that is
> presented to you.
> 
> > 
> > On the other hand, aliases are universal when provided. If they are
> > good enough to assign a MAC address they are good enough to provide
> > a stable default name.  
> 
> We are not talking about the same aliases then. The special Device
> Tree node named "aliases" is a way to create shorted Device Tree node
> paths, it is not by any means an equivalent for what I would rather
> call a "label", or "port name" or silk screen annotation on a PCB for
> instance.

However, if the kernel ethN names are deterministic based on something
like aliases it is trivial to translate them to "port name". As it is
they are pretty much random which is the issue aliases *can* solve.

> 
> > 
> > I think this is indeed forcing the userspace to reinvent several
> > wheels for no good reason.  
> 
> udev or systemd will come up with some stable names for your network
> device right off the bat.

As has been already pointed out these names are not stable for various
reasons. *Making* them stable is the whole point of this discussion.
 
> If you are deeply embedded maybe you don't
> want those, but then use something like the full path in /sys to get
> some stable names based on the SoC's topology.

However, it some devices might be disabled depending on the device
configuration generating stable names is not that easy. Also if bus
topology may differ depending on device/firmware configuration you
cannot assign stable names based just on /sys hierarchy. Also it is
said that /sys hierarchy is not an ABI in the kernel docs so you should
not base your stable device names which *are* an ABI on the
unstable /sys hierarchy.

> 
> > 
> > What is the problem with adding the aliases?  
> 
> aliases is IMHO the wrong tool for the job because it is too limiting,
> you want it to be used to have Ethernet controller instance N to be
> named "ethN", what if someone tomorrows says, no this is not good, I
> want the aliases to automatically name my network devices
> "ethernet-controllerN" or "blahblahN"? You see where I am getting
> with that?

Then you can write udev rule to translate ethN to blahlbahN and so long
as the ethN is stable the translation is stable as well. Alternatively
you might want to use a different devicetree property if one existed.

> 
> And yes, I do realize that Linux has traditionally named Ethernet
> adapters ethN, but also allows people to name interfaces just the way
> they want even from within the drivers themselves.
> 
> Now imagine your platform uses ACPI, and there are no aliases there to
> point a node with a shorter name, how we would go about naming your
> Ethernet controller unless there is a specific VPD/label/sticker
> property that can be somehow be retried?

There is biosdevname for that which uses proprietary BIOS extensions to
look up device names in BIOS.

Thanks

Michal

Re: ethernet "bus" number in DTS ?

[Michal Suchánek]

On Fri, 26 Oct 2018 15:57:15 -0700
Florian Fainelli <f.fainelli@gmail.com> wrote:

> On 10/23/18 11:22 PM, Michal Suchánek wrote:
> > On Tue, 23 Oct 2018 11:20:36 -0700
> > Florian Fainelli <f.fainelli@gmail.com> wrote:
> >   
> >> On 10/23/18 11:02 AM, Joakim Tjernlund wrote:  
> >>> On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:    
> >   
> >>>
> >>> I also noted that using status = "disabled" didn't work either to
> >>> create a fix name scheme. Even worse, all the eth I/F after gets
> >>> renumbered. It seems to me there is value in having stability in
> >>> eth I/F naming at boot. Then userspace(udev) can rename if need
> >>> be. 
> >>>
> >>> Sure would like to known more about why this feature is not
> >>> wanted ?
> >>>
> >>> I found
> >>>   https://patchwork.kernel.org/patch/4122441/
> >>> You quote policy as reason but surely it must be better to
> >>> have something stable, connected to the hardware name, than
> >>> semirandom naming?    
> >>
> >> If the Device Tree nodes are ordered by ascending base register
> >> address, my understanding is that you get the same order as far as
> >> platform_device creation goes, this may not be true in the future
> >> if Rob decides to randomize that, but AFAICT this is still true.
> >> This may not work well with status = disabled properties being
> >> inserted here and there, but we have used that here and it has
> >> worked for as far as I can remember doing it.  
> > 
> > So this is unstable in several respects. First is changing the
> > enabled/disabled status in the deivecetrees provided by the kernel.
> > 
> > Second is if you have hardware hotplug mechanism either by firmware
> > or by loading device overlays.
> > 
> > Third is the case when the devicetree is not built as part of the
> > kernel but is instead provided by firmware that initializes the
> > low-level hardware details. Then the ordering by address is not
> > guaranteed nor is that the same address will be used to access the
> > same interface every time. There might be multiple ways to
> > configure the hardware depending on firmware configuration and/or
> > version.
> > 
> >    
> >> Second, you might want to name network devices ethX, but what if I
> >> want to name them ethernetX or fooX or barX? Should we be
> >> accepting a mechanism in the kernel that would allow someone to
> >> name the interfaces the way they want straight from a name being
> >> provided in Device Tree?  
> > 
> > Clearly if there is text Ethernet1 printed above the Ethernet port
> > we should provide a mechanism to name the port Ethernet1 by
> > default.  
> 
> Yes, but then have a specific property that is flexible enough to
> retrieve things like "vital product information". For DSA switches, we
> have an optional "label" property which names the network device
> directly like it would be found on the product's case. Ideally this
> should be much more flexible such that it can point to the appropriate
> node/firmware service/whatever to get that name, which is what some
> people have been working on lately, see [1].
> 
> [1]: https://lkml.org/lkml/2018/8/14/1039

That's nice for something unique per-device like MAC address. However,
for something per-model like port labels DT properties should suffice.

> 
> The point is don't re-purpose the aliases which is something that
> exists within Device Tree to basically provide a shorter path to a
> specific set of nodes for the boot program to mangle and muck with
> instead of having to resolve a full path to a node. At least that is
> how I conceive it.
> 
> Now what complicates the matter is that some OSes like Linux tend to
> use it to also generate seemingly stable index for peripherals that
> are numbered by index such as SPI, I2C, etc buses, which is why we are
> having this conversation here, see below for more.
> 
> >   
> >>
> >> Aliases are fine for providing relative stability within the Device
> >> Tree itself and boot programs that might need to modify the Device
> >> Tree (e.g: inserting MAC addresses) such that you don't have to
> >> encode logic to search for nodes by compatible strings etc. but
> >> outside of that use case, it seems to me that you can resolve every
> >> naming decision in user-space.  
> > 
> > However, this is pushing platform-specific knowledge to userspace.
> > The way the Ethernet interface is attached and hence the device
> > properties usable for identifying the device uniquely are
> > platform-specific.  
> 
> There is always going to be some amount of platform specific knowledge
> to user-space, what matters is the level of abstraction that is
> presented to you.
> 
> > 
> > On the other hand, aliases are universal when provided. If they are
> > good enough to assign a MAC address they are good enough to provide
> > a stable default name.  
> 
> We are not talking about the same aliases then. The special Device
> Tree node named "aliases" is a way to create shorted Device Tree node
> paths, it is not by any means an equivalent for what I would rather
> call a "label", or "port name" or silk screen annotation on a PCB for
> instance.

However, if the kernel ethN names are deterministic based on something
like aliases it is trivial to translate them to "port name". As it is
they are pretty much random which is the issue aliases *can* solve.

> 
> > 
> > I think this is indeed forcing the userspace to reinvent several
> > wheels for no good reason.  
> 
> udev or systemd will come up with some stable names for your network
> device right off the bat.

As has been already pointed out these names are not stable for various
reasons. *Making* them stable is the whole point of this discussion.
 
> If you are deeply embedded maybe you don't
> want those, but then use something like the full path in /sys to get
> some stable names based on the SoC's topology.

However, it some devices might be disabled depending on the device
configuration generating stable names is not that easy. Also if bus
topology may differ depending on device/firmware configuration you
cannot assign stable names based just on /sys hierarchy. Also it is
said that /sys hierarchy is not an ABI in the kernel docs so you should
not base your stable device names which *are* an ABI on the
unstable /sys hierarchy.

> 
> > 
> > What is the problem with adding the aliases?  
> 
> aliases is IMHO the wrong tool for the job because it is too limiting,
> you want it to be used to have Ethernet controller instance N to be
> named "ethN", what if someone tomorrows says, no this is not good, I
> want the aliases to automatically name my network devices
> "ethernet-controllerN" or "blahblahN"? You see where I am getting
> with that?

Then you can write udev rule to translate ethN to blahlbahN and so long
as the ethN is stable the translation is stable as well. Alternatively
you might want to use a different devicetree property if one existed.

> 
> And yes, I do realize that Linux has traditionally named Ethernet
> adapters ethN, but also allows people to name interfaces just the way
> they want even from within the drivers themselves.
> 
> Now imagine your platform uses ACPI, and there are no aliases there to
> point a node with a shorter name, how we would go about naming your
> Ethernet controller unless there is a specific VPD/label/sticker
> property that can be somehow be retried?

There is biosdevname for that which uses proprietary BIOS extensions to
look up device names in BIOS.

Thanks

Michal