Hi Andrew,
This morning I've been trying to dig into the tg3 Ethernet driver to get an idea of what happens before the NETDEV_UP event is fired.
The network stack invokes the ndo_open() callback implemented by the driver and, as far as I can see, this function does not return until having set speed and half/full_duplex state. Thus it looks like that when NETDEV_UP is fired the speed and the full_duplex attribute have already a meaningful value.
Of course this may vary depending on the driver, so this may not be the case everywhere.
Hi Antonio
I just looked at mv643xx_eth.c, the ethernet driver for my NAS box. Its ndo_open() function calls phy_start(), but does not wait around for the auto-negotiation to complete.
I hacked together a quick test.
#!/bin/bash ifconfig eth0 down sleep 2 ifconfig eth0 up cat /sys/class/net/eth0/duplex cat /sys/class/net/eth0/speed sleep 0.5 cat /sys/class/net/eth0/duplex cat /sys/class/net/eth0/speed sleep 0.5 cat /sys/class/net/eth0/duplex cat /sys/class/net/eth0/speed sleep 0.5 cat /sys/class/net/eth0/duplex cat /sys/class/net/eth0/speed sleep 0.5 cat /sys/class/net/eth0/duplex cat /sys/class/net/eth0/speed sleep 0.5 cat /sys/class/net/eth0/duplex cat /sys/class/net/eth0/speed sleep 0.5 cat /sys/class/net/eth0/duplex cat /sys/class/net/eth0/speed
Which when run gives:
half 1000 half 1000 half 1000 half 1000 half 1000 half 1000 full 1000
So it is taking 3 seconds after ifconfig returns before it has the right duplex mode.
I think that your NAS might also be a good testing platform, assuming that the owner is willing to insmod batman-adv on that machine :-)
I've no problems with batman on this NAS box. It is a box dedicated to kernel hacking and experienced many an opps. I currently have 3.13-rc1 on it, which happens to break the ethernet PHY on reboot :-(
Andrew