[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link

[Peter Tyser <ptyser@xes-inc.com>]

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