On Wed, 2009-02-04 at 17:07 -0600, Andy Fleming wrote:
On Wed, Feb 4, 2009 at 3:26 PM, Wolfgang Denk wd@denx.de wrote:
Dear Andy Fleming,
In message 2acbd3e40902041320l3bce93c1p989c4c33ca8e7ae@mail.gmail.com you wrote:
Hmmm....I made that change for a reason. Waiting for autonegotiation to finish on a tsec with no link was quite tiresome. If you've hooked up the 4th tsec, and try to boot, you end up waiting for *three* tsecs to timeout. If dhcp fails because the link isn't up you can always try again, or add a delay before dhcp starts so that the link is up.
Why that? Don't you always enable only the interface you are trying to use?
The problem is that you don't always know which interface you have hooked up. So u-boot tries the one set in ethact, and then the next, etc. With the old method, the penalty for being wrong was quite high. I hadn't run into an issue with the link not being up. Why don't we look up the spec, and find out the maximum time we'd have to wait for that to happen. That way we get the best of both worlds. My sense is that the link comes up fast, but autonegotiation potentially takes a while.
My understanding was that link was was never achieved until autonegotiation was finished. How could link be up before autonegotiation was complete?
With the original code I always saw 1 of 2 situations with a variety of Broadcom PHYs: 1. Autonegotiation completed and link was detected 2. Autonegotiation was in process and link was not detected
I never saw the case that the code referenced: 3. Autonegotiation was in process and link was detected
Do others see #3?
Thanks, Peter