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

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Peter Tyser wrote:
> 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.

2 seconds minimum, it is written in the autonegotiation spec.  If you 
add the spec-required minimum times for each step of the dance, it is 2 
seconds.  It could take longer, but I've never seen anything but 2 seconds.

> 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

I never tried #3 personally, but my understanding of the link and 
autonegotiation dance is that #3 is not possible.

You may see what appears to be #3 *if* your PHY is strapped to start 
autonegotiation on application of power (typically true) and *if* you 
don't do a software reset on the PHY as part of your power up sequence 
(see also my previous email on this thread).  This really isn't #3, it is...
4. Strap the PHY to autonegotiate on application of power and use the
      results from that rather than resetting the PHY and re-starting
      auto-negotiation in software.

Best regards,
gvb