is already in 32-bit mode, we need to be able to detect this and still
read the chip ID code. Detecting 32-bit mode is actually a little
tricky, since we want to avoid turning it on accidentally. The easiest
way to do it is to just try and read the PCI subsystem ID from the
bus control registers using 16-bit accesses and compare that with the
value read from PCI config space. If they match, then we know we're in
16-bit mode, otherwise we assume 32-bit mode.
16-bit mode. Technically, pcn_probe() is destructive because once the
chip goes into 32-bit mode, the only way to get it out again is a
hardware reset. And once the device is in 32-bit mode, the lnc driver
won't be able to talk to it. So if pcn_probe() is called before the
lnc probe routine, and pcn_probe() rejects the chip as one it doesn't
support, the lnc driver will be SOL.
I don't like this. I think it's a design flaw that you can't switch
the chip out of 32-bit mode once it's selected. The only 'right'
solution is for the pcn driver to support all of the PCI devices
in 32-bit mode, however I don't have samples of all the PCnet series
cards for testing.
and nobroadcast bits in the mode register and call it both from
pcn_init() and pcn_ioctl(). Sometimes we need to force the state
of the nobroadcast bit after switching out of promisc mode.
takes care of all the 10/100 and gigE PCI drivers that I've done.
Next will be the wireless drivers, then the USB ones. I may pick up
some stragglers along the way. I'm sort of playing this by ear: if
anyone spots any places where I've screwed up horribly, please let me
know.
of the Am79c973 with "AlertIT Technology," whatever that is. Also mention
support for the PCnet/FAST III cards in the documentation. The
PCnet/FAST III chips have integrated 10/100 PHYs.
this just involves adding the chip ID to the supported list: the PCnet/PRO
is compatible with the PCnet/FAST+ and friends and should "just work"
with this driver.
Also try to handle mbuf allocation failures in the receive handler
more gracefully.
a result of mii_phy_probe()) and use that rather than hardcoding a
constant. The hardcoded way was too specific to the particular card
I had and caused PHY probing to fail on at least one laptop with a
built-in AMD chip.
Reported by: rjk@grauel.com (Richard J Kuhns)
Previously, these cards were supported by the lnc driver (and they
still are, but the pcn driver will claim them first), which is fine
except the lnc driver runs them in 16-bit LANCE compatibility mode.
The pcn driver runs these chips in 32-bit mode and uses the RX alignment
feature to achieve zero-copy receive. (Which puts it in the same
class as the xl, fxp and tl chipsets.) This driver is also MI, so it
will work on the x86 and alpha platforms. (The lnc driver is still
needed to support non-PCI cards. At some point, I'll need to newbusify
it so that it too will me MI.)
The Am79c978 HomePNA adapter is also supported.
