From: Johan Hovold <johan@kernel.org>
To: Bruno Thomsen <bth@kamstrup.dk>
Cc: Johan Hovold <johan@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
"bruno.thomsen@gmail.com" <bruno.thomsen@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: phy/micrel: KSZ8031RNL RMII clock reconfiguration bug
Date: Sat, 15 Nov 2014 15:18:04 +0100 [thread overview]
Message-ID: <20141115141804.GA24633@localhost> (raw)
In-Reply-To: <915054555B5659448ACF8A70E114824D01704B9131@Exchange2010.kamstrup.dk>
On Wed, Nov 12, 2014 at 12:17:57PM +0000, Bruno Thomsen wrote:
> Hi Johan,
>
> > As you may have seen by now, I've been working on refactoring the
> > micrel phy driver to be able to use common initialisation code.
> >
> > Specifically, I've added generic support for disabling the broadcast
> > address, which is what the MII_KSZPHY_OMSO write above does.
> >
> > Generally you want this to be the first thing you do in order to
> > avoid unnecessary reconfigurations. If we ever were to allow
> > concurrent probing this would also be a requirement.
> >
> > Could you provide some detail about the setup were you find that the
> > PHY becomes unresponsive without your patch? Do you have more than
> > one PHY on the bus? Using what addresses? And using what clock modes
> > (i.e. 25 MHz or 50 MHz)?
> >
> > Also, what exactly do you mean by "unresponsive"? Are you still able
> > to read the PHY registers for example?
>
> I think it sounds like a good idea to refactor the init code.
>
> My setup:
> iMX28 processor with dual Ethernet MAC; FEC0 (enabled) and FEC1 (disabled).
> There is a single KSZ8031 PHY that receives 50MHz RMII clock from the MAC.
> I am unable to read PHY registers from both user-land tools and extra
> debug PHY reads in driver code.
Did you specify a led-mode as well, or was the Operation Mode Strap
Override (OMSO) write the first access after the soft reset?
Did you try any other workarounds besides setting the clock mode before
doing the OMSO write?
And REF_CLK (pin 16) is not connected?
> Boot trace:
> [ 22.277785] fec 800f0000.ethernet eth0: Freescale FEC PHY driver [Micrel KSZ8031] (mii_bus:phy_addr=800f0000.etherne:00, irq=-1)
> [ 22.292527] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [ 24.276217] libphy: 800f0000.etherne:00 - Link is Up - 100/Full
> [ 24.285094] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Ok, so you use a single PHY strapped to address 0.
Would you able to test my series on your setup, and possibly a couple of
diagnostic patches on top?
Thanks,
Johan
next prev parent reply other threads:[~2014-11-15 14:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-09 14:48 [PATCH] phy/micrel: KSZ8031RNL RMII clock reconfiguration bug Bruno Thomsen
2014-10-10 10:02 ` Angelo Dureghello
2014-10-10 11:24 ` Bruno Thomsen
2014-10-14 16:41 ` David Miller
2014-11-11 19:41 ` Johan Hovold
2014-11-12 12:17 ` Bruno Thomsen
2014-11-15 14:18 ` Johan Hovold [this message]
2014-11-17 14:56 ` Bruno Thomsen
2014-11-17 16:00 ` Johan Hovold
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=20141115141804.GA24633@localhost \
--to=johan@kernel.org \
--cc=bruno.thomsen@gmail.com \
--cc=bth@kamstrup.dk \
--cc=f.fainelli@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=s.hauer@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).