Re: ethernet "bus" number in DTS ?

On Tue, 2018-10-23 at 11:20 -0700, Florian Fainelli wrote:

On 10/23/18 11:02 AM, Joakim Tjernlund wrote:

quoted

On Tue, 2018-10-23 at 10:03 -0700, Florian Fainelli wrote:

quoted

On 10/23/18 9:49 AM, Joakim Tjernlund wrote:

quoted

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.

quoted

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.

quoted

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