[tulip] Tulip media types 5 and 6 ? (Allied Telesyn AT-2800TX Cardbus)

[Donald Becker]

On Wed, 3 Jan 2001, Matti Aarnio wrote:

>   (This is a story of how AT-2800TX got to work at my IBM ThinkPad T20,
>    plus things to ponder/patch at various instances of the driver.)
..
>   I have strange media types 5 and 6 at an Allied Telesyn AT-2800TX

These are new SROM entry types.
They are pretty obscure, and I didn't expect to see them.

> CardBus network card, and I tried lots of things before (somehow) realized
> that "tulip-diag -ee" spoke of "reset sequence" on them both.  Then I made
> following change to Linux 2.4.0-prerelease code, and now using 240prerel
> builtin cardbus code, and tulip driver (plus small pcmcia config file),
> it is working just fine.
> 
> The Scyld driver has type 5 supported, and somehow I thought that 6 is
> just a variant of that.

No, it's a different type of reset.

Type 5 was introduced because some SYM transceivers needed to be reset
in order to switch back to 10baseT mode so that autonegotiation could take
place.  It isn't needed for MII transceivers since they retain the
autonegotiated capability word, and have their own reset sequence.

My driver uses block type 5 only for SYM transceivers.

Type 6 appeared to be a hack to work around a bug in a specific piece of
hardware.  The driver had to shut down the SYM transceiver when the cable
was physically removed, but there was circuitry to restart the transceiver
when the cable was inserted.  It only applied starting at a specific
revision of the 21143, and the SROM manual had a note about how the Intel
drivers were broken, uhmmm, had unpredictable results for the general case.

My driver ignores block type 6.  I believe that this is correct.

> Linux Tulip driver version 0.9.12 (December 17, 2000)
> eth0: Digital DS21143 Tulip rev 65 at 0x1400, 00:A0:D2:AF:0C:96, IRQ 9.
> eth0:  EEPROM default media type Autosense.
> eth0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
> eth0:  Index #1 - Media 100baseTx (#3) described by a 21143 reset method (5) block.
> eth0:  Index #2 - Media MII 100baseT4 (#15) described by a UNKNOWN (6) block.

I just tweaked my driver to emit better messages in the latter two entries.

> tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com)
>  http://www.scyld.com/diag/index.html
...
> Leaf node at offset 30, default media type 0800 (Autosense).
>  3 transceiver description blocks:
>   Media MII, block type 3, length 19.
>    MII interface PHY 0 (media type 11).
>    21143 MII initialization sequence is 0 words:.
>    21143 MII reset sequence is 3 words: 0807 0000 0002.
>     Media capabilities are 7800, advertising 01e1.
>     Full-duplex map 5000, Threshold map 1800.
>     No MII interrupt.
>   Media MII, block type 5, length 8.
>    Adapter Reset Sequence, sequence length 3: 0807 0000 0002.

OK, so this is bogus.  A Type 5 block isn't needed for MII transceivers,
since the reset sequence is already in the Type 3 block.  Indeed, they are
identical here.

>   Media MII 100baseT4, block type 6, length 11.
>    Adapter Reset Sequence, sequence length 15: 0704 0008 0000 0200 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 4000.

I'm guessing that you added this case to the tulip-diag program.  It's not
quite right.  It should read something like

   Media Reset, block type 6, length 11.
     Adapter Reset Sequence, sequence length 4: 0807 0000 0000 0002

I'll add a correct line to 'tulip-diag'.

But this is completely bogus.  This type of reset only applies to SYM
transceivers, not MII transceivers.  I suspect that it is harmless to ignore
this, since all three reset sequences are exactly the same.

> diff -u --recursive --new-file v2.4.0-prerelease/linux/drivers/net/tulip/media.c linux/drivers/net/tulip/media.c
> --- v2.4.0-prerelease/linux/drivers/net/tulip/media.c	Mon Jun 19 13:42:39 2000
> +++ linux/drivers/net/tulip/media.c	Mon Jan  1 09:54:07 2001
> @@ -263,6 +263,24 @@
>  			tulip_mdio_write(dev, tp->phys[phy_num], 4, to_advertise);
>  			break;
>  		}
> +		case 5: case 6: {
> +			u16 setup[5];
> +			u32 csr13val, csr14val, csr15dir, csr15val;
> +			for (i = 0; i < 5; i++)
> +				setup[i] = get_u16(&p[i*2 + 1]);

Errrmmm, this code is pretty bogus.  Did it really do anything for you?

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993