On Wed, 11 Dec 2002, Roger Luethi wrote:
> pci-skeleton (and some other net drivers) figure out the duplex setting
> like this (leaving duplex locks out here):
> int duplex = (lpar & 0x0100) || (lpar & 0x01C0) == 0x0040;
I'm not certain what version of pci-skeleton.c you are looking at, but
the current version is
int mii_reg5 = mdio_read(dev, np->phys, 5);
int negotiated = mii_reg5 & np->advertising;
int duplex = (negotiated & 0x0100) || (negotiated & 0x01C0) == 0x0040;
We are looking for the highest negotiated capability, according to the
rules described in
You did read the reference documentation, didn't you?
I put the documentation references at the top of the driver because you
may need to read them to understand what is going on. Or was it so
unusual to have written priciples of operation that you skipped that
I'll explain the cases:
(negotiated & 0x0100) 100baseTx full duplex
(negotiated & 0x01C0) == 0x0040 No capability above 10baseT full duplex
Note that the second check ignores 100baseT4, despite it have priority
over 10baseT-*. That was intentional to work around, "a specific issue"
with a transceiver.
> If we get past the first condition, we already know bit 8 must be 0. Why do
> we check again in the second condition?
The is no extra cost to the extra bit, and it makes it clear we are
testing for 10baseT-FDX.
(The test was originally implemented as part of a complete set of
cases. The test code needed while building a driver is more complex
than what you see in the concise final result.)
Donald Becker becker@xxxxxxxxx
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Scyld Beowulf cluster system
Annapolis MD 21403 410-990-9993