Small change to ukphy

M. Warner Losh imp at bsdimp.com
Wed Apr 1 08:37:55 PDT 2009


In message: <20090401100939.GB12246 at michelle.cdnetworks.co.kr>
            Pyun YongHyeon <pyunyh at gmail.com> writes:
: On Wed, Apr 01, 2009 at 01:32:46AM -0600, M. Warner Losh wrote:
: > 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
: 
: If the purpose is to take PHY out of isolated state couldn't this
: be handled in ifm_change_cb_t handler of parent interface? I guess
: the callback can reset the PHY and subsequent mii_mediachg() call
: may start auto-negotiation.

This callback isn't called.  The problem is that the PHY is in ISO
state.  Since it is in ISO state with auto negotiation enabled, we
never kick off an explicit auto negotiation, so the state never
changes so we never get this callback...

: > well.  The question I have is will we properly go back into ISO state
: > for PHYs that should be isolated.
: > 
: 
: If the PHY requires special handing for ISO state in reset it may
: need separated PHY driver as ukphy(4) does not set MIIF_NOISOLATE. 
: As you said it would be really great if we have a generic way to
: pass various MII flags or driver specific information to mii(4).

This seems to be a common quirk.  I'd hate to have a driver that's
just ukphy but with the one line added above and play what-a-mole with
all the odd-balls that are out there.  Doesn't seem like a strategy
that will win the day.

I think we have a way to do this...  I could do the following in my
attach routine:

	mii = device_get_softc(sc->miibus);
	LIST_FOREACH(miisc, &mii->mii_phys, mii_list) {
		miisc->mii_flags |= MIIF_FORCEANEG;
		mii_phy_reset(miisc);
	}
	mii_mediachg(mii);

which is similar to what fxp does in its change routine (it is what I
put in my status change routine).  Also MIIF_NOISOLATE works as well.

Is the above too insane?

Warner


: > 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
: 


More information about the freebsd-net mailing list