Date: Wed, 01 Apr 2009 01:32:46 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: net@freebsd.org Subject: Small change to ukphy Message-ID: <20090401.013246.-1253043078.imp@bsdimp.com>
next in thread | raw e-mail | index | archive | help
I've encountered a number of PHY chips that need auto negotiation
kicked off to come out of ISO state. This makes sense, because the
ukphy driver never seems to take the PHY out of isolation state
otherwise.
Index: ukphy.c
===================================================================
--- ukphy.c (revision 190463)
+++ ukphy.c (working copy)
@@ -146,6 +146,7 @@
sc->mii_phy = ma->mii_phyno;
sc->mii_service = ukphy_service;
sc->mii_pdata = mii;
+ sc->mii_flags |= MIIF_FORCEANEG;
mii->mii_instance++;
This forces auto negotiation. The reason for this is that it takes it
out of ISO state (Isolate). Once out of that state, things work
well. The question I have is will we properly go back into ISO state
for PHYs that should be isolated.
NetBSD has many of its NIC drivers setting this flag. Their APIs
allow them to set this directly at mii attach time. Ours don't, so
none of our drivers set this flag.
The other fix for this might be:
Index: mii_physubr.c
===================================================================
--- mii_physubr.c (revision 190463)
+++ mii_physubr.c (working copy)
@@ -113,7 +113,9 @@
int bmcr, anar, gtcr;
if (IFM_SUBTYPE(ife->ifm_media) == IFM_AUTO) {
- if ((PHY_READ(sc, MII_BMCR) & BMCR_AUTOEN) == 0 ||
+ bmcr = PHY_READ(sc, MII_BMCR);
+ if ((bmcr & BMCR_AUTOEN) == 0 ||
+ (bmcr & BMCR_ISO) ||
(sc->mii_flags & MIIF_FORCEANEG))
(void) mii_phy_auto(sc);
return;
Which says that if auto negotiation is enabled, and ISO is set to go
ahead and kick off an auto negotiation. I'm less sure of this path,
but it is an alternative. Otherwise, we never write to the BMCR to
take the device out of isolation. If there's a better place to do
this, then I'm all ears.
Either one of these hacks make several PC Cards that I have start to
work... In fact, I'm starting to approach 100% (up from 50%) of my
ed-based PC Cards working with this simple change (and others to the
ed driver). I know that these cards are a little behind the leading
edge, but I'd like to get them working since I've put a few hours into
investigating things here.
Comments?
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090401.013246.-1253043078.imp>