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

[Andy Fleming]

On Fri, Feb 6, 2009 at 1:30 PM, Jerry Van Baren <gerald.vanbaren at ge.com> wrote:
> Andy Fleming wrote:
>>
>> On Fri, Feb 6, 2009 at 7:32 AM, Jerry Van Baren <gerald.vanbaren at ge.com>
>> wrote:
>>>
>>> Peter Tyser wrote:
>>
>>>>> 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.
>>
>> Could you point me at where in the spec it says this?  I've been
>> digging around in it, and found nothing concrete so far.
>
> I've been sweating bullets just *knowing* someone was going to call me on
> this.  Oh man, I am ***SO*** lucky... I had to dig back to October 2002 to
> find it, but find it I did.  :-) :-) :-)
>
> My experience is that "The second case assumes that the far end link partner
> fully supports Auto-Negotiation:" / "Min spec" time is what occurs.  I've
> never seen a PHY take anything other than bang-on 2 seconds (OK, 2.054
> seconds).
>
> IIRC, the "min spec" time is the minimum time a PHY is allowed to take for
> autonegotiation.  The "max spec" time is the maximum time the PHY is allowed
> to take for autonegotiation.  The PHY *has* everything it needs to know by
> the "min spec" time, which is why all PHYs (that I've ever used) take
> exactly 2 seconds for autonegotiation.
>
> If you wanted to be safer than my semi-empirical 2 second number, 2.8 (round
> up to 3?) seconds is probably a good choice.


Based on my reading of the below, "safe" is 3.5 seconds.

>
> Note that the first case mentioned below is oddball in that the far end
> doesn't support autonegotiation.  In real life, you are probably screwed in
> this case regardless of the time it takes for autonegotiation to fail.

  If the link partner doesn't support autonegotiation, many PHYs
support "Parallel detection" which allows the PHY to essentially
notice by the link response what speeds seem to be supported.  And,
really, my issue is not with autonegotiation failing, but failing due
to no link actually being present.  If the link isn't there, it's
annoying to wait and wait and wait.

>
> I recall verifying the DP83840 calculations against chapter 28 of the IEEE
> 802.3u and I *clearly* recall not wanting to go back there ever again.  If
> you doubt the numbers, *you* can go there.  ;-)

I'll trust your math.  My curiosity has to do with whether the link
status will be reported as up once the break link time has elapsed.
But 3.5 is still better than what at some point was a much longer
timeout.

Andy