On 22.03.2019 15:25, Alexander Dahl wrote:
When introducing the SAMA5D27 SoCs, the SAMA5D2 series got an additional chip id. The check if the cpu is sama5d2 was changed from a preprocessor definition (inlining a call to 'get_chip_id()') to a C function, probably to not call get_chip_id twice?
That however broke a check in the macb ethernet driver. That driver is more generic and also used for other platforms. I suppose this solution was implemented to use it in 'gem_is_gigabit_capable()', without having to stricly depend on the at91 platform:
#ifndef cpu_is_sama5d2 #define cpu_is_sama5d2() 0 #endif
That only works as long as cpu_is_sama5d2 is a preprocessor definition. (The same is still true for sama5d4 by the way.) So this is a straight forward fix for the workaround.
The not working check on the SAMA5D2 CPU lead to an issue on a custom board with a LAN8720A ethernet phy connected to the SoC:
=> dhcp ethernet@f8008000: PHY present at 1 ethernet@f8008000: Starting autonegotiation... ethernet@f8008000: Autonegotiation complete ethernet@f8008000: link up, 1000Mbps full-duplex (lpa: 0xffff) BOOTP broadcast 1 BOOTP broadcast 2 BOOTP broadcast 3 BOOTP broadcast 4 BOOTP broadcast 5 BOOTP broadcast 6 BOOTP broadcast 7 BOOTP broadcast 8 BOOTP broadcast 9 BOOTP broadcast 10 BOOTP broadcast 11 BOOTP broadcast 12 BOOTP broadcast 13 BOOTP broadcast 14 BOOTP broadcast 15 BOOTP broadcast 16 BOOTP broadcast 17
Retry time exceeded; starting again
Notice the wrong reported link speed, although both SoC and phy only support 100 MBit/s!
The real issue on reliably detecting the features of that cadence ethernet mac IP block, is probably more complicated, though.
Fixes: 245cbc583db7c1ca52aa32428b8e86f3449d4af2 Signed-off-by: Alexander Dahl ada@thorsis.com
Applied to u-boot-atmel/next , with a minor tweak on fixes tag Thanks !