From: Eugen.Hristev at microchip.com <Eugen.Hristev@microchip.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ARM: at91: sama5d2: Wrap cpu detection to fix macb driver
Date: Thu, 28 Mar 2019 07:27:56 +0000 [thread overview]
Message-ID: <153cc294-4133-3669-c5de-e4f737ea38b5@microchip.com> (raw)
In-Reply-To: <20190322132554.5848-1-ada@thorsis.com>
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 at f8008000: PHY present at 1
> ethernet at f8008000: Starting autonegotiation...
> ethernet at f8008000: Autonegotiation complete
> ethernet at 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 !
prev parent reply other threads:[~2019-03-28 7:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-22 13:25 [U-Boot] [PATCH] ARM: at91: sama5d2: Wrap cpu detection to fix macb driver Alexander Dahl
2019-03-23 8:46 ` Alexander Dahl
2019-03-24 9:01 ` Bin Meng
2019-03-25 9:17 ` Alexander Dahl
2019-03-25 9:46 ` Eugen.Hristev at microchip.com
2019-03-25 10:08 ` Alexander Dahl
2019-03-28 7:27 ` Eugen.Hristev at microchip.com [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=153cc294-4133-3669-c5de-e4f737ea38b5@microchip.com \
--to=eugen.hristev@microchip.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox