[vortex] MII Transceivers

[Bogdan Costescu]

Hi,

I have some questions and suggestions about MII transceiver handling.

Part 1: On-chip vs. external transceivers

For Cyclone, the on-chip transceiver is also at PHYAD 24 (p. 161).

The AutoSelect sequence (p. 213 for B, p. 193 for C) suggests that if
AutoNegotiate is set (in xcvrSelect, which we equate to XCVR_NWAY) only the
on-chip transceiver is to be taken into consideration. If we want to say
XCVR_NWAY means any (on-chip or not on-chip) transceiver that supports
autonegotiation (as this is different from 3Com's interpretation), we should
probably check for NWAY capabilities on the MII transceiver(s) that we find.

If we stay with 3Com's recommandations, we can split the code which now does:
(in vortex_probe1)

if (dev->if_port == XCVR_MII || dev->if_port == XCVR_NWAY)

into something like this:

if (dev->if_port == XCVR_NWAY) {
	phys[0] = 24;
/* eventually some printk to say that it was found and its status */
	}
else if (dev->if_port == XCVR_MII){
	...	<- here we have the current code
/* we can skip PHYAD 24 in scanning for Cyclone and Tornado as 3Com suggests;
probably only set phys[0]=24 if no other PHY is found or even report
no MII devices found if XCVR_MII is forced */
	}

If I understood well, for the older cards XCVR_NWAY is illegal, so I guess
that we don't have to check for card type, only on the XCVR_MII branch if
we want to skip 24.
HomePNA or radio transceivers should be treated as XCVR_MII devices.

Part 2: Scanning for valid transceivers

1.) What is the meaning of

	mdio_read(ioaddr, 24, 1);

just before the for loop used for scanning (in vortex_probe1) ?

2.) Upon entry in vortex_probe1 there is no reset of the card. Should we
try to reset the transceiver (setting bit 15 of Control register (MR0))
before checking the status ?

3.) The driver checks only for existence of up to 2 transceivers (that's the
size of the phys array). I guess that if we'd increase the size to 32, the CX
cards will report at least 31 available interfaces, with all but the one
at PHYAD 24 being set as in Berkan's report. This might mean that the on-chip
transceiver is responding to all PHYADs between 1 and 31 (maybe 0 too), but
only one instance is correctly set at start-up and it actually carries
meaningful info; maybe just to return some consistent data that is to be
replaced when another transceiver is instaled ?
Furthermore, according to their proposed AutoSelect sequence, these data are
only to be read when checking for XCVR_MII, so if we read them when checking
for XCVR_NWAY, we might do something "illegal" and the returned data is
simply bogus...

Part 3: MDIO operations

I know that Don said that the MDIO parts should not be touched, but...

1.) I don't understand the mdio_preamble_required handling. In vortex_probe1,
even for the on-chip transceiver (XCVR_NWAY), mdio_preamble_required is
non-zero (at least 2 x "++" and only one "--"). Why do we check for
mdio_preamble_required in mdio_[read,write] before calling mdio_sync?
Even more, if all transceivers require mdio_sync, why do we bother bother
updating mdio_preamble_required ?

2.) In mdio_read,

	int read_cmd = (0xf6 << 10) | (phy_id << 5) | location;

which will generate an 18-bit field. Then, we only use the first 15 LSB
of it:

	/* Shift the read command bits out. */
	for (i = 14; i >= 0; i--) {

Is there a reason for the extra bits ?

3.) The MDIO timing is based on PCI timing. If the PCI timing is wrong for
some reason, MDIO operations would somehow be affected. I afraid especially
about mdio_delay() which is done as inl(mdio_addr)... Now, there is no
specification about extra reads from mdio_addr during the read/write frames.
How about disturbing the cycle by doing these extra 'in's ? (in case 3Com
decided to do things differently from what they did before...)

Hoping these might shed some light,

Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De