11:07 <milkylainen> hmm. no linux networking on libera?

11:25 <mwalle> arnd: I made a new driver within the nvmem subsystem, but the device tree changes did go through the nxp soc tree. I forgot to enable the driver though. I expect that it will prevent networking from probing because it adds a phandle how to get the mac address. Thus the boards in kernelci will probably have some regressions. Do you have an idea how to handle that one?

11:26 <mwalle> I can't really go through the soc tree because the driver isn't there.

11:27 <mwalle> Maybe I can wait until after the merge window and try to get that defconfig for the rc

11:57 <geertu> mwalle: So the driver and defconfig update had to go in first, and the DTS update in the next cycle.

11:58 <geertu> mwalle: I assume both the driver and DTS update are destined for v6.3?

11:59 <geertu> Perhaps you can still get the defconfig in for v6.2? Although that wouldn't really help, as the issue will only show up during the merge window (and in linux-next now).

11:59 <geertu> SO I think the best is make sure the defconfig update will be in v6.3-rc1, too, i.e. sent it to soc now.

12:09 <arnd> mwalle: I can take the defconfig change even without the driver being there. It would be nice to have a fallback in the network driver to make it still work even when the nvmem driver is missing, but I realize this is a hard problem when the netwirj driver doesn't know if it should defer probing or fall back to a random address

12:34 <mwalle> arnd: well, it just went sideways anyway. greg just naked the series. seems like i have to revert the dts change

12:35 <mwalle> arnd: and I presume fwlink will prevent probing the network driver

12:36 <mwalle> geertu: ^^ but I hope to remember for next time :)

19:31 <milkylainen> Is there a way to feed a default ethernet advertisment mask for nics without a userspace?

20:04 <geertu> milkylainen: Documentation/admin-guide/nfs/nfsroot.rst:ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>

20:38 <milkylainen> geertu: hmm. advertisment mask?

20:41 <milkylainen> The phy advertised link speeds.

20:49 <rfs613> milkylainen: milkylainen: you could perhaps set it in the devicetree PHY using reg-init

20:53 <rfs613> (though it seems that might be Marvell-specific)

20:54 <milkylainen> rfs613: hmm. interesting.

20:55 <milkylainen> So what I'm trying to do is the following: Bootloader tends to poke nic adv and up & down. Linux tends to reset phy, leaving it down. So I get to wait for a gigabit link-up after userspace has initialized it. And link-ups for gigabit can take a while. Which adds seconds before the device can communicate.

20:56 <milkylainen> I'd want a way to set an advertisment that matches runtime adv list and let the phy do linkup immediately after initialization. So that ifup is just carrier changes, since the adv list is the same.

20:58 <milkylainen> Should be perfectly sane to do so to cut time to "first communication".

21:01 <rfs613> milkylainen: hmm so your phy chip defaults to not advertising gigabit after reset? that seems unusual (for a gigabit capable phy)

21:04 <rfs613> I've never tried to optimise the time for ethernet to come up, but at least in my experience, from when I do "ifconfig eth0 up; udhcpc eth0" it typically takes only a couple of seconds to establish link.

21:06 <rfs613> If it takes 30 seconds or minutes, then you likely have some fancy networking gear (cisco's are famous for this) which essentially block traffic for quite a while, purportedly to "improve" network performance (not exactly sure how, perhaps prevent duplciate IPs?)

21:08 <rfs613> the simple fix in that case is to stick a cheap non-managed switch in between ;-)

21:17 <milkylainen> rfs613: it does, but advertisment list is reset by linux if anything is diff. After which the phy goes through mandatory renegotiation. Also phy tends to be down until "ifconfig eth0 up".

21:17 <milkylainen> rfs613: yes, it usually takes a few seconds to autoneg a gigabit link.

21:21 <milkylainen> I think it's highly relevant. Network is getting work done. It's annoying to wait for a gigabit link (upwards 4 seconds) on a previously negotiated phy link after userspace is up. If the goal is to come up quickly and talk to whatever needs to be talked to, that re-negotiation time is substantial. To say the least.

21:26 <rfs613> No argument from me, but, it's never bothered me enough to try to do something about. I'm content if it comes up reliably every time I boot...

21:30 <milkylainen> It's been a pet peeve for quite some time. :)

21:32 <milkylainen> iirc linux didn't use to poke the reset immediately on ethernet phys on initialization. Means I could carry the link from the bootloader straight into Linux. This was ages ago. I don't know when and why that changed. If it was the phy state machine that went "you have to be initialized and pass through a reset to be sure".