Netdev List
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Daniel Walker <danielwa@cisco.com>,
	Claudiu Manoil <claudiu.manoil@freescale.com>
Cc: Hemant Ramdasi <hramdasi@cisco.com>, netdev@vger.kernel.org
Subject: Re: gianfar: Implement MAC reset and reconfig procedure
Date: Tue, 16 Oct 2018 15:03:07 -0700	[thread overview]
Message-ID: <80884e5e-d3ab-d575-eec1-131a29c00915@gmail.com> (raw)
In-Reply-To: <20181016213629.mjgrkifpt265hvvm@zorba>

On 10/16/2018 02:36 PM, Daniel Walker wrote:
> Hi,
> 
> I would like to report an issue in the gianfar driver. The issue is as follows. 
> 
> We have a P2020 board that uses the gianfar driver, and we have a m88e1101
> PHY connect. When the interface is initially brought up traffic flows as
> normal. If you take the interface down then bring it back up traffic stops
> flowing. If you do this sequence over and over up/down/up we find that the
> interface will allow traffic to flow at a low percentage.
> 
> In v4.9 interface allows traffic about %10 of the time.
> 
> In v4.19-rc8 the allows traffic %30 of the time.
> 
> After bisecting I found that in v3.14 the interface was rock solid and never did
> we see this issue. However, v3.15 we started to see this issue. After bisecting I
> found the following change is the first one which causes the issue,
> 
> a328ac9 gianfar: Implement MAC reset and reconfig procedure
> 
> I was able to revert this in v3.15 , however with later development a revert
> doesn't appear to be possible. We have no fix for this currently.
> 
> I can do testing if you have an idea what might cause the issue.

What we have seen being typically the problem is that when you have a
PHY connection whereby the PHY provides the RX clock to the MAC (e.g:
RGMII), it is very easy to get in a situation where the PHY clock is
stopped, and the MAC is asked to be reset, but the HW design does not
like that at all since it e.g: stops on packet boundaries and need some
clock cycles to do that, and that results in all sorts of issues (in our
case it was some FIFO corruption). We solved that in bcmgenet.c with
looping internally the TX clock to the RX clock to make sure the
Ethernet MAC (UniMAC in our designs) was successfully reset:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28c2d1a7a0bfdf3617800d2beae1c67983c03d15

Could that somehow be the problem here?
-- 
Florian

  reply	other threads:[~2018-10-17  5:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-16 21:36 gianfar: Implement MAC reset and reconfig procedure Daniel Walker
2018-10-16 22:03 ` Florian Fainelli [this message]
2018-10-17 22:23   ` Daniel Walker

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=80884e5e-d3ab-d575-eec1-131a29c00915@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=claudiu.manoil@freescale.com \
    --cc=danielwa@cisco.com \
    --cc=hramdasi@cisco.com \
    --cc=netdev@vger.kernel.org \
    /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