On Friday 07 January 2022 17:55:25 Andrew Lunn wrote: > On Fri, Jan 07, 2022 at 04:29:31PM +0000, Russell King (Oracle) wrote: > > On Fri, Jan 07, 2022 at 05:12:21PM +0100, Pali Rohár wrote: > > > Adds a new helper function of_get_ethdev_label() which sets initial name of > > > specified netdev interface based on DT "label" property. It is same what is > > > doing DSA function dsa_port_parse_of() for DSA ports. > > > > > > This helper function can be useful for drivers to make consistency between > > > DSA and netdev interface names. > > > > > > Signed-off-by: Pali Rohár <pali@xxxxxxxxxx> > > > > Doesn't this also need a patch to update the DT binding document > > Documentation/devicetree/bindings/net/ethernet-controller.yaml ? > > > > Also it needs a covering message for the series, and a well thought > > out argument why this is required. Consistency with DSA probably > > isn't a good enough reason. > > > > >From what I remember, there have been a number of network interface > > naming proposals over the years, and as you can see, none of them have > > been successful... but who knows what will happen this time. > > I agree with Russell here. I doubt this is going to be accepted. > > DSA is special because DSA is very old, much older than DT, and maybe > older than udev. The old DSA platform drivers had a mechanism to > supply the interface name to the DSA core. When we added a DT binding > to DSA we kept that mechanism, since that mechanism had been used for > a long time. > > Even if you could show there was a generic old mechanism, from before > the days of DT, that allowed interface names to be set from platform > drivers, i doubt it would be accepted because there is no continuity, > which DSA has. Well, DT should universally describe HW board wiring. From HW point of view, it is really does not matter if RJ45 port is connected to embedded PHY on SoC itself or to the external PHY chip, or to the switch chip with embedded PHY. And if board has mix of these options, also labels (as printed on product box) should be in DTS described in the same way, independently of which software solution / driver is used for particular chip. It really should not matter for DTS if kernel is using for particular HW part DSA driver or ethernet driver. So there really should be some common way. And if the one which DSA is using is the old mechanism, what is the new mechanism then?
