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

On 10/23/18 1:02 PM, Joakim Tjernlund wrote:

quoted

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

quoted

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

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.

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.

quoted

quoted

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.

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.

quoted

quoted

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.

quoted

quoted

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