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: 245cbc583d ("ARM: at91: Get the Chip ID of SAMA5D2 SiP")
Signed-off-by: Alexander Dahl <ada@thorsis.com>
7dee1848d7