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

[Jerry Van Baren]

Andy Fleming wrote:
> 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:

[snip]

>> 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

s/many/all/

> support "Parallel detection" which allows the PHY to essentially
> notice by the link response what speeds seem to be supported.  And,

(speed, but not duplex)

> 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 understand "parallel detection".  The problem is that the percentage 
of times that it results in a properly configured link is (in my 
experience) very very low.  Not because "parallel detection" doesn't 
work, but because the humans configuring the fixed side don't understand 
parallel detection and set it up for full duplex.

Ignoring the configuration where both ends are (presumably correctly) 
manually configured, you end up with five cases, two of them 
misconfigured and WRONG:
1) Autonegotiation <-> autonegotiation - reliable.
2) 10bT half duplex <-> autonegotiation - reliable.
3) 100bT half duplex <-> autonegotiation - reliable.
4) 10bT *FULL* duplex <-> autonegotiation - *UNreliable*.
5) 100bT *FULL* duplex <-> autonegotiation - *UNreliable*.

The problem that I've observed is that the *humans* (the weak links) 
that do the manual configuration don't understand that "parallel 
detection" *must be* half duplex by definition in the spec (it is hard 
to define a reliable algorithm to detect full duplex capability so the 
spec writers punted).  As a result, the human invariably picks "full 
duplex" because everybody knows full duplex is better... and end up as 
case (4) or (5).  They inadvertently end up with a slower unreliable 
link (lots of "collisions" resulting in runt packets) rather than the 
faster better link they thought they were picking (d'oh!).  The really 
bad thing is that the network works fine in testing on an isolated LAN 
with no traffic and absolutely craps its pants when it hits the real world.

That is my reasoning behind my statement that we can generally ignore 
the autonegotiation <-> fixed configuration case because the odds of it 
working properly are poor anyway.

Having said all that, I don't have any problem with using 3.5 seconds as 
the safe timeout value.  it isn't worth timing out too soon just to 
shave 0.5 or even 1.0 seconds off the negotiation timeout time.

>> 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

Best regards,
gvb