public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
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 !

      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