On Mon, Jan 11, 2021 at 11:19:09AM -0800, Jakub Kicinski wrote: > > > devlink_port_attrs_set() should be called before netdev is registered, > > > and devlink_port_type_eth_set() after. So this sequence makes me a tad > > > suspicious. > > > > > > In particular IIRC devlink's .ndo_get_phys_port_name depends on it, > > > because udev event needs to carry the right info for interface renaming > > > to work reliably. No? > > > > If I change the driver's Kconfig from tristate to bool, all is fine, > > isn't it? > > How does Kconfig change the order of registration of objects to > subsystems _within_ the driver?
The registration order within the driver is not what matters. What matters is that the devlink_port and net_device are both registered _before_ udev is up. > Can you unbind and bind the driver back and see if phys_port_name > always gets the correct value? (replay/udevadm test is not sufficient) Yes, and that udev renaming test failed miserably still. I have dhcpcd in my system, and it races with my udev script by auto-upping the interfaces when they probe. Then, dev_change_name() returns -EBUSY because the interfaces are up but its priv_flags do not declare IFF_LIVE_RENAME_OK. How is that one solved?
