From: Andrew Lunn <andrew@lunn.ch>
To: Tim Harvey <tharvey@gateworks.com>
Cc: netdev <netdev@vger.kernel.org>,
Fabio Estevam <fabio.estevam@nxp.com>,
Lucas Stach <l.stach@pengutronix.de>,
Fugang Duan <fugang.duan@nxp.com>,
Koen Vandeputte <koen.vandeputte@ncentric.com>
Subject: Re: IMX6 FEC connection drops occasionally with 'MDIO read timeout'
Date: Wed, 12 Apr 2017 18:54:23 +0200 [thread overview]
Message-ID: <20170412165423.GA16424@lunn.ch> (raw)
In-Reply-To: <CAJ+vNU2itJEBMLNz--w9FOis_jMHW9c+UPwU6wh+ma59kbeswA@mail.gmail.com>
On Wed, Apr 12, 2017 at 09:15:11AM -0700, Tim Harvey wrote:
> On Fri, Apr 7, 2017 at 9:09 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Fri, Apr 07, 2017 at 07:47:17AM -0700, Tim Harvey wrote:
> >> Greetings,
> >>
> >> I've had a couple of users report that they are getting occasional
> >> link drops when using IMX6 FEC on our boards which are using a Marvell
> >> 88E1510 PHY:
> >>
> >> [ 9348.474418] fec 2188000.ethernet eth0: MDIO read timeout
> >> [ 9350.478804] fec 2188000.ethernet eth0: Link is Down
> >>
> >> If they bring the interface back up it works fine.
> >>
> >> The most recent version of Linux they have tested and seen this on is
> >> v4.9 with CONFIG_MARVELL_PHY=y
> >>
> >> Has anyone else run into this or know what the issue could be? Should
> >> there be any retries at the MDIO level or above?
> >
> > Hi Tim
> >
> > MDIO is assumed to be reliable. It failing is bad.
> >
> > However, ETIMEOUT is interesting. The MDIO protocol has no flow
> > control. There is no way for the PHY to delay replying.
> >
> > I would suggest you look at the power management code. What i have
> > seen with the FEC, when using switches attached to the FEC, is that if
> > the clocks are turned off, you get ETIMEOUT from MDIO.
> >
> > Andrew
>
> Andrew,
>
> Thanks for the reply. Your talking about suspend/resume power
> management right? The users reporting this were not using
> suspend/resume.
Hi Tim
As Fabio just pointed out, i was meaning run time power management.
It used to be, that the FEC driver powered up the clocks when the
interface was opened. But when using a switch connected to the MDIO
bus, you can be using the MDIO bus while the interface is still
closed. And that did not work. So the runtime PM was extended to the
MDIO bus.
It could be there is a race condition in this code somewhere.
Andrew
next prev parent reply other threads:[~2017-04-12 16:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 14:47 IMX6 FEC connection drops occasionally with 'MDIO read timeout' Tim Harvey
2017-04-07 16:09 ` Andrew Lunn
2017-04-12 16:15 ` Tim Harvey
2017-04-12 16:26 ` Fabio Estevam
2017-04-12 16:54 ` Tim Harvey
2017-04-13 5:45 ` Andy Duan
2017-04-12 16:54 ` Andrew Lunn [this message]
2017-04-10 1:42 ` Andy Duan
2017-04-12 16:16 ` Tim Harvey
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=20170412165423.GA16424@lunn.ch \
--to=andrew@lunn.ch \
--cc=fabio.estevam@nxp.com \
--cc=fugang.duan@nxp.com \
--cc=koen.vandeputte@ncentric.com \
--cc=l.stach@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=tharvey@gateworks.com \
/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;
as well as URLs for NNTP newsgroup(s).