[vortex] 3c905 oddities 2

[Bogdan Costescu]

On Wed, 13 Dec 2000, Donald Becker wrote:

> The manual indicates maximum times for some commands.

This must be a different thing than the PDF that I downloaded from 3Com's
"developer documentation" page. I haven't seen any indication of maximum
times in there and I read the whole 212 pages.

> 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 ?

> 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...

> Using udelay() is not a better solution.  If you must, use udelay(1) instead
> of udelay(10): there is no point in wasting 10 microseconds for an operation
> that usually completes instantly.  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.

> ...  Your interrupt handler might end
> interrupting another interrupt handler.  If you do a long timing loop, you
> have just blocked both interrupts.  A similar thing happens when you
> interrupt code that has just disabled a specific IRQ.

I know, I've done a lot of programming with interrupts back in the old
MSDOS days.

> 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-)

> We don't have the driver code to switch transceivers, and I haven't seen a
> 3Com card design that supports multiple MII transceivers.

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) ?

> 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...

> ...  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-)

Sincerely,

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