[U-Boot] [PATCH] tsec: Wait for auto-negotiation to complete without link
Peter Tyser
ptyser at xes-inc.com
Thu Feb 5 17:27:51 CET 2009
On Wed, 2009-02-04 at 17:07 -0600, Andy Fleming wrote:
> On Wed, Feb 4, 2009 at 3:26 PM, Wolfgang Denk <wd at denx.de> wrote:
> > Dear Andy Fleming,
> >
> > In message <2acbd3e40902041320l3bce93c1p989c4c33ca8e7ae at 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
More information about the U-Boot
mailing list