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

[Jerry Van Baren]

Wolfgang Denk wrote:
> Dear Scott Wood,
> 
> In message <498A0D5C.5060901 at freescale.com> you wrote:
>> Andy Fleming 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.
>>>
>>> I'm open to other suggestions, but I really don't want to go back to
>>> the old behavior.
>> Is there any way that you could do the auto-negotiation in parallel?

Excellent suggestion!

Related suggestion: if we knew that the PHY was strapped to start 
autonegotiation on power up (it is a board-specific option, typically 
true), we could enhance the code to use those autonegotiation results 
rather than hitting the PHY with the reset hammer and restarting 
autonegotiation.  This would have an added advantage of "reducing" 
network start up time by 2 seconds (assuming normal power up time is 
more than 2 seconds) by overlapping the software initialization and PHY 
autonegotiation.

> You definitely do not want to do that.
> 
> Requirement is NOT to initialize network interfaces unless used by
> U-Boot.

Autonegotiation is *not necessarily* a violation of this principle.  The 
autonegotiation is in the PHY and is (should be) logically completely 
separate from initializing the network interface (MAC).

Just because the PHY is ready to run should have no impact on u-boot or 
linux start up.  Case in point: most PHYs actually start their 
autonegotiation when power is applied (it typically is a strapping option).

Caveats:
* I have not looked at the code, but the PHY initialization is probably 
coupled in s/w with the MAC (ethernet chip) initialization.  This would 
have to be changed to decouple the two.

* Typically, PHYs have an interrupt output line.  I'm assuming here that 
the interrupt is disabled.  If the interrupt is *enabled,* it *would* 
violate u-boot's ground rule about not leaving hardware grenades laying 
around.  The interrupt can be disabled in the PHY itself or at the CPU 
end of the interrupt line.
   1) It would be very unusual to have the interrupt enabled in u-boot.
        I would be surprised if any PHY initialization enables the
        interrupt (it is a control bit in a register in the PHY,
        I forgot if it is a standard register or PHY-specific).
   2) If a PHY interrupt causes a problem in linux, it is a driver bug
        IMHO because it would mean the linux driver enabled the interrupt
        before initializing the handler.  This would be a race condition
        bug regardless of what u-boot does with the PHY and I trust none
        of these are present in linux.  ;-/

> Best regards,
> 
> Wolfgang Denk

Ditto,
gvb