netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Igor Plyatov <plyatov@gmail.com>
To: Michael Heimpold <mhei@heimpold.de>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	f.fainelli@gmail.com, joe@perches.com, luwei.zhou@freescale.com,
	richardcochran@gmail.com, davem@davemloft.net,
	u.kleine-koenig@pengutronix.de, Fabio.Estevam@freescale.com,
	LW@karo-electronics.de, Frank.Li@freescale.com
Subject: Re: [PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging
Date: Fri, 14 Aug 2015 11:03:04 +0300	[thread overview]
Message-ID: <55CDA0B8.5000200@gmail.com> (raw)
In-Reply-To: <5164251.N6KMl6pkAR@kerker>

Dear Michael,

> Hi Igor,
>
> Am Donnerstag, 13. August 2015, 22:18:34 schrieben Sie:
>
> > * Due to HW bug, LAN8700 sometimes does not detect presence of 
> energy in the
>
> > Ethernet cable in Energy Detect Power-Down mode (e.g while EDPWRDOWN 
> bit is
>
> > set, the ENERGYON bit does not asserted sometimes). This is a common 
> bug of
>
> > LAN87xx family of PHY chips.
>
> Is there any offical errata sheet for this PHY family? How do you 
> know, that this is a
>
> common HW bug?
>

The LAN8700, LAN8710, LAN8720 is a product of the SMSC company. 
Microchip acquired SMSC in August 2012.

The LAN8700 is a legacy product for Microchip and they will not update 
anything about it. So, even if Microchip know about HW bug, then there 
is no chance to have Errata sheet or any new documents about LAN8700.

I think same history is for LAN8710/LAN8720 even if they are not marked 
as legacy. They are SMSC products.

The workarounds for same issue in LAN8710/LAN8720 was committed by:
  * Marek Vasut <marex@denx.de> as b629820d18fa65cc598390e4b9712fd5f83ee693.
  * Patrick Trantham <patrick.trantham@fuel7.com> as 
4223dbffed9f89596177ff2b256ef3258b20fa46.

> Me too, I think that this family has some problems with this mode, 
> however, without
>
> hard evidence, I would put it softer.
>

I have discovered this bug by just monitoring of data to/from MDIO 
registers of LAN8700.
And HW issue is proven on 100 % by rare absence of ENERGYON bit when 
cable is plugged in.
Sometimes, it is required to make 2-20 tests to catch this issue.

The configuration of CPU pins, responsible for the MDIO interface, was 
checked carefully by oscilloscope and they are fine (no spikes, no 
garbage, good shape of edges).

> > * The lan87xx_read_status() was improved to acquire ENERGYON bit. 
> Its previous
>
> > algorythm still not reliable on 100 % and sometimes skip cable plugging.
>
> >
>
> > Signed-off-by: Igor Plyatov <plyatov@gmail.com>
>
> > ---
>
> > drivers/net/phy/smsc.c | 15 ++++++++++++---
>
> > 1 file changed, 12 insertions(+), 3 deletions(-)
>
> >
>
> > diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
>
> > index c0f6479..8559ff1 100644
>
> > --- a/drivers/net/phy/smsc.c
>
> > +++ b/drivers/net/phy/smsc.c
>
> > @@ -104,6 +104,7 @@ static int lan911x_config_init(struct phy_device 
> *phydev)
>
> > static int lan87xx_read_status(struct phy_device *phydev)
>
> > {
>
> > int err = genphy_read_status(phydev);
>
> > + int i;
>
> >
>
> > if (!phydev->link) {
>
> > /* Disable EDPD to wake up PHY */
>
> > @@ -116,8 +117,16 @@ static int lan87xx_read_status(struct 
> phy_device *phydev)
>
> > if (rc < 0)
>
> > return rc;
>
> >
>
> > - /* Sleep 64 ms to allow ~5 link test pulses to be sent */
>
> > - msleep(64);
>
> > + /* Wait max 640 ms to detect energy */
>
> Why 640ms and not e.g. 650ms?
>
> I'm no PHY expert, but this looks like an ugly workaround.
>

Such a value was adopted after many trial and probes. It allows to 
detect cable plugging on 100 %.
Ugly or not, but it works and reliable.

> Maybe it would be better to avoid this power saving mode at all, when 
> it is not
>
> reliable, but this are just my 2cts. :-)
>

Power saving mode allow to save around 220 mW of energy consumed from 
power supply, when Ethernet cable is not plugged in.
This is a good value for embedded devices.
Better to keep power save mode on.

> Anyway, I guess you should also update the explanation on top of the 
> function to reflect
>
> your new approach.
>

I propose following comment for the lan87xx_read_status():
/*
  * The LAN87xx suffers from rare absence of the ENERGYON-bit when 
Ethernet cable
  * plugs in while LAN87xx is in Energy Detect Power-Down mode. This 
leads to
  * unstable detection of plugging in Ethernet cable.
  * This workaround disables Energy Detect Power-Down mode and waiting for
  * response on link pulses to detect presence of plugged Ethernet cable.
  * The Energy Detect Power-Down mode enabled again in the end of 
procedure to
  * save approximately 220 mW of power if cable is unplugged.
  */

> > + for (i = 0; i < 64; i++) {
>
> > + /* Sleep to allow link test pulses to be sent */
>
> > + msleep(10);
>
> > + rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
>
> > + if (rc < 0)
>
> > + return rc;
>
> > + if (rc & MII_LAN83C185_ENERGYON)
>
> > + break;
>
> > + };
>
> >
>
> > /* Re-enable EDPD */
>
> > rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
>
> > @@ -191,7 +200,7 @@ static struct phy_driver smsc_phy_driver[] = {
>
> >
>
> > /* basic functions */
>
> > .config_aneg = genphy_config_aneg,
>
> > - .read_status = genphy_read_status,
>
> > + .read_status = lan87xx_read_status,
>
> This one makes sense, since I really guess, that the whole PHY family 
> behave very similar.
>
> But this change alone does not solve your problem, right?
>

Yes, use of non modified lan87xx_read_status() only reduce amount of 
false cable detections, but does not resolve issue completely.

> > .config_init = smsc_phy_config_init,
>
> > .soft_reset = smsc_phy_reset,
>
> >
>
> >
>
> Regards,
>
> Michael
>

Best wishes.

-- 
Igor Plyatov

  parent reply	other threads:[~2015-08-14  8:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-13 19:18 [PATCH v2] net: phy: workaround for buggy cable detection by LAN8700 after cable plugging Igor Plyatov
     [not found] ` <5164251.N6KMl6pkAR@kerker>
2015-08-14  8:03   ` Igor Plyatov [this message]
2015-08-14 16:31     ` Michael Heimpold
2015-08-14 17:12       ` Igor Plyatov

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=55CDA0B8.5000200@gmail.com \
    --to=plyatov@gmail.com \
    --cc=Fabio.Estevam@freescale.com \
    --cc=Frank.Li@freescale.com \
    --cc=LW@karo-electronics.de \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luwei.zhou@freescale.com \
    --cc=mhei@heimpold.de \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=u.kleine-koenig@pengutronix.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;
as well as URLs for NNTP newsgroup(s).