Small change to ukphy
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
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Small change to ukphy
In message: 20090401100939.gb12...@michelle.cdnetworks.co.kr
Pyun YongHyeon pyu...@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
:
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
pNFS
Are there any efforts underway to implement parallel NFS in FreeBSD? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Small change to ukphy
On Wed, Apr 01, 2009 at 07:09:39PM +0900, Pyun YongHyeon wrote:
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.
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).
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?
FYI, the idea I had for passing MIIF_DOPAUSE from the NIC
drivers to the PHY drivers as required by the flow-control
support without breaking the ABI was to use device flags.
A proof-of-concept patch with an example application of
that approach is:
http://people.freebsd.org/~marius/mii_flags.diff
One could even or the flags together in miibus_attach(),
allowing MIIF_FORCEANEG etc to be additionally set via
hints.
Marius
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: pNFS
Peter Craft wrote: Are there any efforts underway to implement parallel NFS in FreeBSD? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org i've not implemented a line of pnfs, and i've not looked much at the pnfs list since leaving panasas, however ... i thought the question was interesting at the time and i'm responding to your query. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Small change to ukphy
On Wed, Apr 01, 2009 at 09:37:40AM -0600, M. Warner Losh wrote:
In message: 20090401100939.gb12...@michelle.cdnetworks.co.kr
Pyun YongHyeon pyu...@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
Oops, you're right.
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?
That looks ok to me but marius's patch would be the right
direction.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Small change to ukphy
On Wed, Apr 01, 2009 at 11:12:54PM +0200, Marius Strobl wrote:
On Wed, Apr 01, 2009 at 07:09:39PM +0900, Pyun YongHyeon wrote:
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.
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).
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?
FYI, the idea I had for passing MIIF_DOPAUSE from the NIC
drivers to the PHY drivers as required by the flow-control
support without breaking the ABI was to use device flags.
A proof-of-concept patch with an example application of
that approach is:
http://people.freebsd.org/~marius/mii_flags.diff
One could even or the flags together in miibus_attach(),
allowing MIIF_FORCEANEG etc to be additionally set via
hints.
This looks good. As you know some PHY drivers(e.g. brgphy(4),
e1000phy(4)) have to know more information than mii flags. How
about passing one more pointer argument to mii_probe()? The
pointer would be used to point to a driver specific data.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
