Sorry for the delayed response,
On Tue, 2009-02-10 at 11:31 -0600, Scott Wood wrote:
On Tue, Feb 10, 2009 at 08:59:11AM -0500, Jerry Van Baren wrote:
That is my reasoning behind my statement that we can generally ignore the autonegotiation <-> fixed configuration case because the odds of it working properly are poor anyway.
I'm not fond of giving up any ability to support a configuration just because some people get it wrong (including configurations where the human *can't* screw it up because the fixed end is some old hub or NIC that doesn't support anything other than 10Mbit, half-duplex), especially when the benefit of not supporting it is so low.
Having said all that, I don't have any problem with using 3.5 seconds as the safe timeout value. it isn't worth timing out too soon just to shave 0.5 or even 1.0 seconds off the negotiation timeout time.
OK, good. :-)
I agree, I'd prefer to err on the conservative side too. The spec Jerry mentioned was for a 100M PHY. I'm guessing it could take longer for a 1000M PHY... I've looked around a fair bit and couldn't find anything concrete either. I see a few references to a 4.5 second autonegotiation timeout in the Linux kernel (e1000 and e1000e drivers), but of course no mention of where those numbers came from. I see timeout values of 4 and 5 seconds in U-Boot also.
What if I keep this patch as is, then submit an additional patch which would replace all PHY_AUTONEGOTIATE_TIMEOUT references with CONFIG_SYS_PHY_AUTONEG_TIMEOUT. A conservative default value of 4.5 seconds would be assigned to CONFIG_SYS_AUTONEG_TIMEOUT in net.h, but this could be overridden by board config files if wanted/needed?
Thanks, Peter