it is invoked every time the interface is brought up. So if you disconnect and then reconnect the cable (e.g. to connect the NIC to a faster switch) this function is invoked again and the bandwidth is updated.
Are we sure that auto-negotiation has finished? It can take a few seconds to complete after the interface is brought up. It would not be good to have batman use 10Mbps/Half Duplex on my gigabit links...
So it can take up to "few" seconds? I did not expect such a delay!
It varies a lot between devices. I have a NAS box which i use for kernel hacking. I TFTP boot the kernel, using u-boot configuration variables. I found that for a cold boot it works great, but a warm boot seems to be faster and the TFTP GET command is sent while the phy is still auto-negotiating, and it gets lost. This then triggers a bug in u-boot, it never re-transmits the GET command, and then whole TFTP boot times out eventually.
So i'm just cautious about making assumptions here, especially assumptions which might be mostly true, but in some odd edge case turn out to be false.
However this function if invoked when the NETDEV_UP event is issued by the underlying system. I expect the event to be thrown when the interface is ready to be used, not when the auto-negotiatin is still going on. I will double check.
I had a quick look at the code. It seems like NETDEV_UP is issued directly after the device is opened. There does not seem to be any waiting around for auto-neg.
Andrew