bus_delete_resource.
Fixes a problem when the probe succeeded, but the attach failed. The
release of the resources was done inproperly.
Approved by: jkh
Some controllers submit bogus pointers to the Done queue.
ohci_hash_find_td fails to find these in its hash and panics. Instead of
panicing we now assume the whole done queue is lost and let the timeout
code to clean up the mess after us.
uhci_check_intr() routine needs to be more careful about deciding when
the end of a transfer has been detected.
This allows me to remove the nasty workaround code from if_aue and if_cue.
Receive performance is now much better for these adapters (500KB/sec
vs. 350KB/sec).
Also removed unused KUE_CUTOFF define from if_kuereg.h.
Submitted by: Lennart Augustsson
Reviewed by: n_hibma
methods for USB devices.
However: with none of the devices I have here suspend seems to work
properly. This is probably a bug in uhci_power which I still have to
look at.
Prodded and pushed by: Christopher Masto <chris@netmonger.net>
- Sync ohci, uhci and usbdi modules with NetBSD in order to obtain the
following improvements:
o New USBD_NO_TSLEEP flag can be used in place of UQ_NO_TSLEEP
quirk. This allows drivers to specify busy waiting only for
certain transfers (namely control transfers for reading/writing
registers and stuff).
o New USBD_FORCE_SHORT_XFER flag can be used to deal with
devices like the ADMtek Pegasus that sense the end of bulk OUT
transfers in a special way (if a transfer is exactly a multiple
of 64 bytes in size, you need to send an extra empty packet
to terminate the transfer).
o usbd_open_pipe_intr() now accepts an interval argument which
can be used to change the rate at which the interrupt callback
routine is invoked. Specifying USBD_DEFAULT_INTERVAL uses the
value specified in the device's config data, but drivers can
override it if needed.
- Change if_aue to use USBD_FORCE_SHORT_XFER for packet transmissions.
- Change if_aue, if_kue and if_cue to use USBD_NO_TSLEEP for all
control transfers. We no longer force the non-tsleep hack for
bulk transfers since these are done asynchronously anyway.
- Removed quirk entry fiddling from if_aue and if_kue since we don't
need it anymore now that we have the USBD_NO_TSLEEP flag.
- Tweak ulpt, uhid, ums and ukbd drivers to use the new arg to
usbd_open_pipe_intr().
- Add a flag to the softc struct in the ethernet drivers to indicate
when a device has been detached, and use this flag to perform
tests to prevent the drivers from trying to do control transfers
if this is the case. This is necessary because calling if_detach()
with INET6 enabled will eventually result in a call to the driver's
ioctl() routine to delete the multicast groups on the interface,
which will result in attempts to perform control transfers. (It's
possible this also happens even without INET6 support enabled.) This
is pointless since we know that if the detach method has been called,
the hardware has been unplugged.
- Changed watchdog timeout routines to just call the driver init routines
to initialize the device states without trying to close and re-open the
pipes. This is partly because we don't want to frob things at interrupt
context, but also because this doesn't seem to work right and I don't
want to panic the system just because a USB device may have stopped
responding.
- Fix aue_rxeof() to be a little smarter about detecting when a double
transfer is needed. Unfortunately, the design of the chip makes it hard
to get this exactly right. Hopefully, this will go away once either
Nick or Lennart finds the bug in the uhci driver that makes this ugly
hack necessary.
- Also sync usbdevs with NetBSD.
- The busy wait hack in usbdi.c was doing its timeout in microseconds
instead of milliseconds.
- if_aue.c:aue_intr() is creating a bitmask by and'ing two bits when it
should be or'ing them.
Submitted by: Lennart Augustsson
running. It turns out that trying to read the MAC address when there's
no firmware creates a zero length transfer. This apparently doesn't
hurt anything on a UHCI controller, but OHCI controllers generate an
IOERROR, and the device doesn't initialize.
Instead, check the bcdDevice revision code. We know this will be
different when the firmware is running, so if we detect the firmware's
code instead of the bare hardware's code, we skip the firmware load.
of the Broadcom BCM5201 PHY on the LinkSys USB100TX adapter so that the
link LED correctly (lights up amber for 10mbps link, green for 100mbps
link).
Note that the sticker on the bottom of the adapter says amber for 10
and green for 100, but the appendix in the manual that comes with
the adapter says green for 10 and amber for 100. Given that there doesn't
seem to be any way to make the hardware produce the latter combination,
I think it's safe to say the sticker is right and the manual is wrong.
I'm just shocked, shocked I tell you.
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.
Do not not not call m_freem() in the txeof routines. Let the netisr routine
do it. This also makes the tx netisr queuing much simpler (I can just use
another ifqueue instead of the mess I had before.)
Thanks to Bosko Milekic for making me actually think about what I was
doing for a minute.
