[vortex] 3c905 oddities 2

[Donald Becker]

On Wed, 13 Dec 2000, Bogdan Costescu wrote:

> On Wed, 13 Dec 2000, Donald Becker wrote:
> > I multiply the maximum observed value by a big "engineering margin" and
> > clean up the code before release.
> 
> So, what do you think an appropriate value for the RxReset would be in
> this case ?

I haven't seen a report of the actual count, only that bumping up the loop
maximum to a really big number seems to work.

> > This approach can fail when the hardware changes.  Here we have a usual
> > case: 3Com comes out with an apparently new chip revision that is nominally
> > backwards compatible.  No updated manualis available, and the changes might
> > not be documented long after the design is updated again.
> 
> I guess that it would have been better if they would have changed the PCI
> ID too...

Intel tries to make their Ethernet chips be very backwards compatible, and
thus didn't change the PCI ID.  But the chips were only backwards compatible
with their own driver, not with the manual.  Recently they have been doing
the opposite: changing the PCI ID without changing the chip design.

> > ...  And as I frequently warn: never assume
> > that udelay() is accurate,
> 
> I was talking only about the operations that are _known_ to require more
> time, like RxReset in this case; I don't want to do udelay() in
> fast-paths. I haven't checked, but if udelay() is not accurate, can it be
> shorter than the specified time ? If it can only be longer, that's not a
> problem.

It can be either longer or shorter.  On old kernels the initial
calibration didn't take into account the cache alignment.  Kernels before
Intel SpeedStep was introduced don't expect that the CPU clock might change.
I expect thermal control on future CPUs will change the timing as well,
similar to the thermal limiting of memory writes that already exists.

> > Yup, typo.
> >      phyx = (phy == 0 ? 24 : phy == 24 ? 0 : phy);
> >
> > Correct.  We will not detect PHY0 with the above typo.
> 
> Still, you are testing PHY 0 before 25-31. 8-)

Yes, I know.  And the code is still not obvious.
Note: PHYs are usually at  #0 (usually incorrectly), 1, 2, 8, 24 (3Com only)
or 31 (bad choice).

> Some weeks ago I have seen on 3Com's site a mention of a dual-port card
> (after seeing 2 and 4 ports cards based on DEC(-compatible) chips I was
> wondering why 3Com does not release something similar...). Do you think
> that the internal transceiver of one chip will be seen by the other chip
> (at PHYAD != 24, of course) ?

No.  Almost all multiple port cards are single port chips behind a bus
bridge.  The only reason to share the MII management bus is on a repeater,
and there it only saves one pin per transceiver.

> > I also expected that we would need driver-independent MII support routines,
> > including one that would monitor link beat and switch transceivers as needed.
> 
> I was in fact wondering why the MDIO routines are replicated in most of
> the network drivers...

There is similar code in many of the drivers, but relatively little is
repeated verbatim.  The obvious common area are
    scanning for transceivers
    duplex checking
    MDIO serial bit stream generation
    ioctl() dispatch code

Of these, the MDIO serial bit stream is the usually the largest code.  It
looks like it could be table driven, but most chips have quirks.  Any common
support code would have to switch between byte/word16/word32 accesses in I/O
and memory space.  Odds are that someone will have a 64 bit register the day
after any code is released.

Scanning the transceivers could easily be handled by common code.  The
previously mentioned ADMtek chip is the only case where we would end up
turning off the transceiver, and thus losing link beat, during a status
check.

> > ...  The ADMtek chip only powers one transceiver at a time, based
> > on a register bit, and the unpowered transceiver doesn't respond to MII
> > register reads.
> 
> Much better than the CX cards which respond to any read. 8-)

I still don't understand what the 3Com chip designer were trying to do.
Earlier chips had a similar problem -- they would initially respond to
reading *any* MII address, but would only write correctly to address #24.
As soon as address #24 was referenced, they would only respond to that
address.  The work around was to do read address #24
	mdio_read(ioaddr, 24, 1);
before any other operation.


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