| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
of zero length TDs can cause our free TRBs to run out, causing xhci(4)
to return USBD_NOMEM to the USB stack.
The issue was reported by
Jonathon Fletcher <jonathon.fletcher () gmail ! com> -- Thanks!
Reviewed/suggestions by patrick@.
ok mpi@
|
|
|
|
| |
ok visa@, kn@
|
|
|
|
|
|
|
| |
Prevent triggering an assert if two drivers try to submit a command
at the same time.
Issue reported by Tom Murphy.
|
|
|
|
| |
ok patrick@, kettenis@
|
|
|
|
| |
maintain a list of possibly submitted commands.
|
|
|
|
|
|
|
|
|
| |
is detected, simply keep track of the faulty xfer instead of completing
all the pending ones.
Fix a race condition where we could end up aborting a freshly enqueued
xfer when two different threads are submitting control transfers (i.e.
usbdevs(8) and a kernel driver).
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since xhci(4) does not allocate memory for its rings in interrupt
context, it has no use for the free lists offered by the USB memory
allocator.
Using bus_dmamem_alloc(9) and friends also allows us to respect the
boundary requirement for the various structures specified in Table 54.
While here make use of defines for every alignment and boundary
requirements which are different than a page size.
|
|
|
|
|
|
|
| |
Express Card is plugged with USB devices on it.
While here do not print an unitialized error value if xhci_init() fails,
from Patrick Wildt.
|
|
|
|
|
|
| |
per-driver pool(9) instead.
With inputs from mikeb@
|
|
|
|
|
|
|
| |
because USB_START_ADDR is defined to 0 and the softc is M_ZERO'd,
assume that root hubs are the only devices with a depth of 0.
Root hubs can now happily be detached and reattached.
|
|
|
|
|
|
|
| |
rings, and rewrite all the addresses in the registers.
While here don't keep a copy of our usb(4) child device, autoconf(9)
knows how to reach our children.
|
|
This driver does not handle isochronous endpoint (yet) and has no logical
TD representation. Each transfer is linked to the raw TRB of its related
endpoint.
Most of the transfer error completion codes are not handled, even with all
the cheese provided by miod@ I couldn't find a proper way to reset an
endpoint asynchronously when a device babbles. Or maybe it was the wine?
Anyway this will come soon.
In general the endpoint configuration and reset code is really crude and
requires some love, but our stack should be fixed to properly open only
once the default pipe of every new USB device first.
This means this driver wont work as it is, our stack needs other changes
first.
Suspend/resume works but ports are not suspended for the moment.
But even with these problems, interrupt devices: ukbd(4), ums(4) and
sensors like ugold(4) work properly and USB 3.0 umass(4) devices give
me a reasonnable read/write speed.
Timeouts to cancel USB transfers are not enabled *on purpose*, to be able
to track down potential timing issues.
I'm committing now so that others can help fixing my bugs (8
All this work has been done on an ExpressCard with a NEC xHCI 0.96, other
implementations/versions might trigger more bugs :)
|