[vortex] 3c905 oddities 2

[Bogdan Costescu]

On Wed, 13 Dec 2000, Donald Becker wrote:

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

8-) 8-) 8-) I just can't stop laughing ! What are these engineers
thinking ?
Anyway, with 3Com it seems like the CX cards also break their (Linux)
driver 8-) 8-)

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

Is there _any_ way of doing long waits in the kernel ?
In userspace, one way of avoiding sleep() is to repeatedly check
gettimeofday() or similar; is it possible to use jiffies or something else
(maybe rdtsc()) to do things similarly in the kernel ? (If this question
was already answered somewhere, just a pointer would be fine)

> Note: PHYs are usually at  #0 (usually incorrectly), 1, 2, 8, 24 (3Com only)
> or 31 (bad choice).

How about something like this:

for (phy = 0; phy <= 32 && phy_idx < 1; phy++) {
	int mii_status, phyx = (phy == 0 ? 24 : phy == 32 ? 0 : phy);

which checks: 24, 1->31, 0.
This will check PHY 24 twice, but if it didn't catch it the first time, it
should not catch it the second time. W.r.t. obviousness, I guess that it
can be written using 'if's... 8-)

Now, catching only one transceiver also means that we can change

	unsigned char phys[2];		to
	unsigned char phys;

and change 'phys[0]' to 'phys' all over the driver.

> ... The obvious common area are
>     scanning for transceivers

Yes, but if there are specific rules like "try this first" as for 3Com,
there could be problems.

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

I'm sure that if there is already an exception from the rule, we'll soon
have others. 8-(

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

OK, that explains the mdio_read placed before scanning. The scheme the I
proposed above would reference PHY 24 first, so this extra read could be
removed.

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