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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.