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
