Hi folks...

This is to longjump back to an old conversation about NWAY autonegotiation
and its interaction with forcing media on a host via ifconfig(8).

To recap, the problem is that some people are noticing that when you
force e.g. 100baseTX-FDX on a host, the switch isn't picking it up,
causing bad performance.  When this happens, using "auto" clears it up.

After reading IEEE 802.3, and studying the section on autonegotiation
(Section 28, aka 802.3u) pretty thoroughly, and studying the datasheets
of several commonly-available 802.3u-compliant PHYs, I have determined
that my suggested fix of always setting BMCR_AUTOEN isn't going to work.

802.3u is quite clear that if BMCR_AUTOEN is set, both BMCR_S100 and
BMCR_FDX are ignored.  Therefore, it is not possible to force a media
setting with BMCR_AUTOEN enabled.

Furthermore, NWAY FLPs (Fast Link Pulses, the signaling mechanism
used to implement NWAY) are only sent out when the BMCR_STARTNEG
bit is set, which is only valid if BMCR_AUTOEN is set [this point
isn't very clear in 802.3u, but is mentioned in some PHY data sheets].

802.3u also says that NWAY will only be performed under the following
circumstances:

	(1) the PHY has just powered up.

	(2) the user sets BMCR_STARTNEG in the PHY.

802.3u is *NOT* clear on when ANER_LPAN will appear on the link partner.
However, it seems to infer that if BMCR_AUTOEN is *not* set, then
ANER_LPAN won't be set on the link partner, either.  This is the key
for the link partner to do Parallel Detection [a method of determining
10Mb/s or 100Mb/s signaling rate without NWAY].  Parallel detection is,
by definition, to never detect full-duplex mode.  Basically, if you're
not doing NWAY, you shouldn't be doing full-duplex unless you're going
to hard-wire the media on BOTH ENDS OF THE CONNECTION.

Now, with all of this in mind, this is what I would like to do to fix
the problem:

	(1) Change the way we hard-wire media:

		(a) If ANER_LPAN, set ANAR_x to the appropriate
		    bits corresponding to our media, and set
		    BMCR_AUTOEN|BMCR_STARTNEG.

		    Our link partner is NWAY-capable, so advertise
		    only the media we want to switch to, and begin
		    NWAY.  This should cause both ends to resolve
		    to the specific media we want.

		(b) If not ANER_LPAN, set BMCR_x to the appropriate
		    bits corresponding to our media.

	(2) Change how we handle restarting NWAY in link-down conditions:

		(a) Never assume that NWAY is "already enabled".  Some
		    PHY drivers do this, because some PHYs claim to
		    support that, but it's not clear that all PHYs
		    will correctly retransmit FLPs.  PHYs should always
		    *respond* to FLPs that are received, but since 802.3u
		    says we should only transmit them when requested, we
		    should request it at all the appropriate times.

		(b) Redefine the times when we want to retransmit FLPs.
		    We currently only do it when IFF_AUTO is set, or
		    if we have no link for 5 seconds.  We should latch
		    loss of link and retransmit and FLP when we see
		    that.  This way we can detect if we were unplugged
		    and then plugged into a host which does not support
		    NWAY (i.e. our ANER_LPAN will be clear).  This will
		    cause us to do Parallel Detection (to properly get
		    us out of full-duplex if we were previously in
		    full-duplex).

		(c) Retransmit FLPs when we detect link down and we're
		    hard-wiring media per the (1a) case above.

I think all of these changes will make our MII code do the right thing
in most circumstances.  Unfortunately, there are still some cases where
this can fail, but I don't think there's anything we can do about that
because 802.3u is, in my opinion, underspecified.  Sadly, it's also clear
there weren't any software people giving input into all of this (damn
hardware weasels!).  No, there is no generic way to detect what mode
was detected by Parallel Detection [you can make a very good guess
at the result of NWAY by taking the greatest common denominator of
the ANAR and ANLPAR registers].  This means that PHY-specific drivers
will still be required.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>