This commit adds device driver support for the ADMtek AN986 Pegasus
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
1999-12-28 02:01:18 +00:00
|
|
|
.\" Copyright (c) 1997, 1998, 1999
|
|
|
|
|
.\" Bill Paul <wpaul@ee.columbia.edu>. All rights reserved.
|
|
|
|
|
.\"
|
|
|
|
|
.\" Redistribution and use in source and binary forms, with or without
|
|
|
|
|
.\" modification, are permitted provided that the following conditions
|
|
|
|
|
.\" are met:
|
|
|
|
|
.\" 1. Redistributions of source code must retain the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer.
|
|
|
|
|
.\" 2. Redistributions in binary form must reproduce the above copyright
|
|
|
|
|
.\" notice, this list of conditions and the following disclaimer in the
|
|
|
|
|
.\" documentation and/or other materials provided with the distribution.
|
|
|
|
|
.\" 3. All advertising materials mentioning features or use of this software
|
|
|
|
|
.\" must display the following acknowledgement:
|
|
|
|
|
.\" This product includes software developed by Bill Paul.
|
|
|
|
|
.\" 4. Neither the name of the author nor the names of any co-contributors
|
|
|
|
|
.\" may be used to endorse or promote products derived from this software
|
|
|
|
|
.\" without specific prior written permission.
|
|
|
|
|
.\"
|
|
|
|
|
.\" THIS SOFTWARE IS PROVIDED BY Bill Paul AND CONTRIBUTORS ``AS IS'' AND
|
|
|
|
|
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
|
|
|
|
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
|
|
|
|
.\" ARE DISCLAIMED. IN NO EVENT SHALL Bill Paul OR THE VOICES IN HIS HEAD
|
|
|
|
|
.\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
|
|
|
|
|
.\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
|
|
|
|
|
.\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
|
.\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
|
|
|
|
|
.\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
|
|
|
|
|
.\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
|
|
|
|
|
.\" THE POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
|
.\"
|
|
|
|
|
.\" $FreeBSD$
|
|
|
|
|
.\"
|
|
|
|
|
.Dd December 25, 1999
|
|
|
|
|
.Dt AUE 4 i386
|
|
|
|
|
.Os FreeBSD
|
|
|
|
|
.Sh NAME
|
|
|
|
|
.Nm aue
|
|
|
|
|
.Nd
|
|
|
|
|
ADMtek AN986 Pegasus USB Ethernet driver
|
|
|
|
|
.Sh SYNOPSIS
|
2000-01-17 02:17:55 +00:00
|
|
|
.Cd "device uhci0"
|
|
|
|
|
.Cd "device ohci0"
|
|
|
|
|
.Cd "device usb0"
|
|
|
|
|
.Cd "device miibus0"
|
This commit adds device driver support for the ADMtek AN986 Pegasus
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
1999-12-28 02:01:18 +00:00
|
|
|
.Cd "device aue0"
|
|
|
|
|
.Sh DESCRIPTION
|
|
|
|
|
The
|
|
|
|
|
.Nm
|
|
|
|
|
driver provides support for USB ethernet adapters based on the ADMtek
|
|
|
|
|
AN986 Pegasus chipset, including the LinkSys USB100TX, the Billionton
|
Add the vendor and device IDs for a whole bunch of additional USB
ethernet adapters that are supported by the aue and kue drivers.
There are actually a couple more out there from Accton, Asante and
EXP Computer, however I was not able to find any Windows device
drivers for these on their servers, and hence could not harvest
their vendor/device ID info. If somebody has one of these things
and can look in the .inf file that comes with the Windows driver,
I'd appreciate knowing what it says for 'VID' and 'PID.'
Additional adapters include: the D-Link DSB-650 and DSB-650TX, the
SMC 2102USB, 2104USB and 2202USB, the ATen UC10T, and the Netgear EA101.
These are all mentioned in the man pages, relnotes and LINT.
Also correct the date in the kue(4) man page. I wrote this thing
on Jan, 4 2000, not 1999.
2000-01-07 22:18:49 +00:00
|
|
|
Systems USB100, the Melco Inc. LU-ATX, the D-Link DSB-650TX and the
|
|
|
|
|
SMC 2202USB.
|
|
|
|
|
.Pp
|
|
|
|
|
The Pegasus contains a 10/100
|
This commit adds device driver support for the ADMtek AN986 Pegasus
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
1999-12-28 02:01:18 +00:00
|
|
|
ethernet MAC with MII interface and is designed to work with both
|
|
|
|
|
ethernet and HomePNA transceivers. Although designed to interface with
|
|
|
|
|
100Mbps peripherals, the existing USB standard specifies a maximum
|
|
|
|
|
transfer speed of 12Mbps. Users should therefore not expect to actually
|
|
|
|
|
achieve 100Mbps speeds with these devices.
|
|
|
|
|
.Pp
|
|
|
|
|
The Pegasus supports a 64-bit multicast hash table, single perfect
|
|
|
|
|
filter entry for the station address and promiscuous mode. Packets are
|
|
|
|
|
received and transmitted over separate USB bulk transfer endpoints.
|
|
|
|
|
.Pp
|
|
|
|
|
The
|
|
|
|
|
.Nm
|
|
|
|
|
driver supports the following media types:
|
|
|
|
|
.Pp
|
|
|
|
|
.Bl -tag -width xxxxxxxxxxxxxxxxxxxx
|
|
|
|
|
.It autoselect
|
|
|
|
|
Enable autoselection of the media type and options.
|
|
|
|
|
The user can manually override
|
|
|
|
|
the autoselected mode by adding media options to the
|
|
|
|
|
.Pa /etc/rc.conf
|
|
|
|
|
file.
|
|
|
|
|
.It 10baseT/UTP
|
|
|
|
|
Set 10Mbps operation. The
|
|
|
|
|
.Ar mediaopt
|
|
|
|
|
option can also be used to enable
|
|
|
|
|
.Ar full-duplex
|
|
|
|
|
operation. Not specifying
|
|
|
|
|
.Ar full duplex
|
|
|
|
|
implies
|
|
|
|
|
.Ar half-duplex
|
|
|
|
|
mode.
|
|
|
|
|
.It 100baseTX
|
|
|
|
|
Set 100Mbps (fast ethernet) operation. The
|
|
|
|
|
.Ar mediaopt
|
|
|
|
|
option can also be used to enable
|
|
|
|
|
.Ar full-duplex
|
|
|
|
|
operation. Not specifying
|
|
|
|
|
.Ar full duplex
|
|
|
|
|
implies
|
|
|
|
|
.Ar half-duplex
|
|
|
|
|
mode.
|
|
|
|
|
.El
|
|
|
|
|
.Pp
|
|
|
|
|
The
|
|
|
|
|
.Nm
|
|
|
|
|
driver supports the following media options:
|
|
|
|
|
.Pp
|
|
|
|
|
.Bl -tag -width xxxxxxxxxxxxxxxxxxxx
|
|
|
|
|
.It full-duplex
|
|
|
|
|
Force full duplex operation. The interface will operate in
|
|
|
|
|
half duplex mode if this media option is not specified.
|
|
|
|
|
.El
|
|
|
|
|
.Pp
|
|
|
|
|
For more information on configuring this device, see
|
|
|
|
|
.Xr ifconfig 8 .
|
|
|
|
|
.Sh DIAGNOSTICS
|
|
|
|
|
.Bl -diag
|
|
|
|
|
.It "aue%d: watchdog timeout"
|
|
|
|
|
A packet was queued for transmission and a transmit command was
|
|
|
|
|
issued, however the device failed to acknowledge the transmission
|
|
|
|
|
before a timeout expired.
|
|
|
|
|
.It "aue%d: no memory for rx list"
|
|
|
|
|
The driver failed to allocate an mbuf for the receiver ring.
|
|
|
|
|
.El
|
|
|
|
|
.Sh SEE ALSO
|
|
|
|
|
.Xr arp 4 ,
|
|
|
|
|
.Xr netintro 4 ,
|
|
|
|
|
.Xr ifconfig 8
|
|
|
|
|
.Rs
|
|
|
|
|
.%T ADMtek AN986 data sheet
|
|
|
|
|
.%O http://www.admtek.com.tw
|
|
|
|
|
.Re
|
|
|
|
|
.Sh HISTORY
|
|
|
|
|
The
|
|
|
|
|
.Nm
|
|
|
|
|
device driver first appeared in
|
|
|
|
|
.Fx 4.0 .
|
|
|
|
|
.Sh AUTHORS
|
|
|
|
|
The
|
|
|
|
|
.Nm
|
|
|
|
|
driver was written by
|
|
|
|
|
.An Bill Paul Aq wpaul@ee.columbia.edu .
|
|
|
|
|
.Sh BUGS
|
|
|
|
|
For some reason, outgoing bulk transfers (i.e. packet transmissions)
|
|
|
|
|
fail if the transfer is exactly a multiple of 64 bytes in size. The
|
|
|
|
|
.Nm
|
|
|
|
|
driver works around this by padding such transfers up by one additional
|
|
|
|
|
byte. This does not affect connectivity, however it does cause packets
|
|
|
|
|
to occasionaly appear on the wire with one additional byte for no good
|
|
|
|
|
reason. It is not known if this bug is due to a problem with Pegasus
|
|
|
|
|
chip itself or some peculiarity of the underlying USB support.
|