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.
NICs. (Finally!) The PCMCIA, ISA and PCI varieties are all supported,
though only the ISA and PCI ones will work on the alpha for now.
PCCARD, ISA and PCI attachments are all provided. Also provided an
ancontrol(8) utility for configuring the NIC, man pages, and updated
pccard.conf.sample. ISA cards are supported in both ISA PnP and hard-wired
mode, although you must configure the kernel explicitly to support the
hardwired mode since you have to know the I/O address and port ahead
of time.
Special thanks to Doug Ambrisko for doing the initial newbus hackery
and getting it to work in infrastructure mode.
USB-EL1202A chipset. Between this and the other two drivers, we should
have support for pretty much every USB ethernet adapter on the market.
The only other USB chip that I know of is the SMC USB97C196, and right
now I don't know of any adapters that use it (including the ones made
by SMC :/ ).
Note that the CATC chip supports a nifty feature: read and write combining.
This allows multiple ethernet packets to be transfered in a single USB
bulk in/out transaction. However I'm again having trouble with large
bulk in transfers like I did with the ADMtek chip, which leads me to
believe that our USB stack needs some work before we can really make
use of this feature. When/if things improve, I intend to revisit the
aue and cue drivers. For now, I've lost enough sanity points.
Kawasaki LSI KL5KUSB101B chip, including the LinkSys USB10T, the
Entrega NET-USB-E45, the Peracom USB Ethernet Adapter, the 3Com
3c19250 and the ADS Technologies USB-10BT. This device is 10mbs
half-duplex only, so there's miibus or ifmedia support. This device
also requires firmware to be loaded into it, however KLSI allows
redistribution of the firmware images (I specifically asked about
this; they said it was ok).
Special thanks to Annelise Anderson for getting me in touch with
KLSI (eventually) and thanks to KLSI for providing the necessary
programming info.
Highlights:
- Add driver files to /sys/dev/usb
- update usbdevs and regenerate attendate files
- update usb_quirks.c
- Update HARDWARE.TXT and RELNOTES.TXT for i386 and alpha
- Update LINT, GENERIC and others for i386, alpha and pc98
- Add man page
- Add module
- Update sysinstall and userconfig.c
USB ethernet chip. Adapters that use this chip include the LinkSys
USB100TX. There are a few others, but I'm not certain of their
availability in the U.S. I used an ADMtek eval board for development.
Note that while the ADMtek chip is a 100Mbps device, you can't really
get 100Mbps speeds over USB. Regardless, this driver uses miibus to
allow speed and duplex mode selection as well as autonegotiation.
Building and kldloading the driver as a module is also supported.
Note that in order to make this driver work, I had to make what some
may consider an ugly hack to sys/dev/usb/usbdi.c. The usbd_transfer()
function will use tsleep() for synchronous transfers that don't complete
right away. This is a problem since there are times when we need to
do sync transfers from an interrupt context (i.e. when reading registers
from the MAC via the control endpoint), where tsleep() us a no-no.
My hack allows the driver to have the code poll for transfer completion
subject to the xfer->timeout timeout rather that calling tsleep().
This hack is controlled by a quirk entry and is only enabled for the
ADMtek device.
Now, I'm sure there are a few of you out there ready to jump on me
and suggest some other approach that doesn't involve a busy wait. The
only solution that might work is to handle the interrupts in a kernel
thread, where you may have something resembling a process context that
makes it okay to tsleep(). This is lovely, except we don't have any
mechanism like that now, and I'm not about to implement such a thing
myself since it's beyond the scope of driver development. (Translation:
I'll be damned if I know how to do it.) If FreeBSD ever aquires such
a mechanism, I'll be glad to revisit the driver to take advantage of
it. In the meantime, I settled for what I perceived to be the solution
that involved the least amount of code changes. In general, the hit
is pretty light.
Also note that my only USB test box has a UHCI controller: I haven't
I don't have a machine with an OHCI controller available.
Highlights:
- Updated usb_quirks.* to add UQ_NO_TSLEEP quirk for ADMtek part.
- Updated usbdevs and regenerated generated files
- Updated HARDWARE.TXT and RELNOTES.TXT files
- Updated sysinstall/device.c and userconfig.c
- Updated kernel configs -- device aue0 is commented out by default
- Updated /sys/conf/files
- Added new kld module directory
