-> the current names are confusing (didn't change other drivers)
* fix invalid memory access in usbd_transfer (kern/24636)
-> needed for this driver
* fix USB HC detach race condition (kern/32011)
-> main patch needed for this driver, sc_dying changes in other drivers
not necessary but seem right to me
Patch from Matthew Orgass.
http://mail-index.netbsd.org/tech-kern/2007/06/26/0001.html
device gets removed. However, when the diagnostic check fails,
it is much better to complete the free operation than to abort
it, because this just causes an infinite loop.
exist in newer spec revisions, and is recommended to be set to 1.
So call it _MBO and also use it in the fake root hub descriptors, just
for sanity, even if nothing ever looks at it.
when one occured -- this makes that events get lost (or delayed until
the next change), in particular in the handover process from the EHCI
to a companion controller, laeving the port dead under some circumstances.
This fixes the "can't reconnect" symptom for me.
I don't see why the interrupt should be disabled - it is acknowledged
in the interrupt handler and shouldn't be active again until the next
status change.
poll interval: since this is a highspeed device, it should be a "12"
(just for sanity; this stuff is not used by the kernel, only userland
usb exploration code might see it)
transfer. It was wrong because it didn't consider block boundaries.
Instead, use the updated toggle from the transfer descriptor -- this
is supposedly cheaper than modulo arithmetics.
This fixes a problem similar to PR kern/34070 for me.
USB2/highspeed: This is an exponent now, not milliseconds.
(There are wrong example descriptors for hubs in the USB2 spec; tolerate
invalid values and assume 256ms which is good for hubs, just in case
someone blindly copied from the book.)
-being here, fix an obvious memory leak
one for tasks of the host controllers. This is needed for drivers like
ural(4) that want to do synchronous USB transfers from the task handler.
Before the split timeouts could not be handled correctly as the task
thread was still blocked. From FreeBSD.
--
Add a workaround for VIA EHCI controllers which, under load, signal qTD
completion before they have performed writeback from the overlay qTD.
This condition would exhibit itself as a umass stall that never recovers.
--
This fixes the problem reported by Thomas Klausner on current-users@:
http://mail-index.netbsd.org/current-users/2006/01/17/0000.html
field has error bits set doesn't mean there has been an error, unless the
HALTED bit is set as well. The old behaviour could result in a transfer
being considered failed by the software, but a success by the device.
This seems to have affected mostly mass storage devices.
Pointed out by Dan Ellis in kern/29731.
An xfer could be aborted twice (which means that the second abort might
access deallocated memory). This happened when an xfer timed out and
the timeout started an abort. While that abort was taking place the
xfer could be cancelled (usually by closing the pipe), causing a second
abort to begin.
This is now handled by having flags indicating the abort state of an xfer.
Hopefully this will fix the occasional crashes when printing.
have a chance to work, so allow them (with a warning).
Make a small change to the transaction translator scheduling to make it
at least hobble along (again from Dan Ellis).
in the wanted bus_dma space. If an allocation fails during operation
(i.e. when hotplugging an umass device), fall back to using the reserve.
The amount can be configured as USB_MEM_RESERVE. The default value is
256k.
Ideally, there would be a way to steal pages in the desired area from
UVM, but that's far more complicated, and this is not intrusive, plus
it works.
set the transaction translator fields for the transfer.
Add a gross hack for split transaction completion in the ehci driver that
allows control transfers to be translated. Interrupt transfers do not work.
Warn when any low/full speed device is opened.
Having interrupt transfers enables some more device types to be used,
most notably USB2 hubs. USB2 hubs still cannot handle anything but
USB2 devices, because there is node code to handle hub Transaction Translation
yet.
XXX This code doesn't do good bw scheduling, but it's certainly better than
nothing. :)
ad