| Age | Commit message (Collapse) | Author | Files | Lines |
|
DH89XX/Cave Creek PCH which seem to function like a 82580 with some
external Marvell PHYs.
|
|
|
|
|
|
|
|
|
|
Requested by miod@ (since xbow(4) on sgi secretly modifies the string behind
out back when interrupts get established).
|
|
|
|
|
|
From Alex Deucher
93e2a4108f7d2665136d6051727471731889ea5f in ubuntu 3.8
d45b964a22cad962d3ede1eba8d24f5cee7b2a92 in mainline linux
|
|
|
|
discussed with kettenis some time last year
|
|
|
|
- Add Realtek RTL8152 / RTL8153 ids
- Add Davicom DM96xx ids
|
|
|
|
bits for the 8168G controller. This fixes operation of the 8168G controllers.
This makes reception of packets work with the 8168G controllers in the Shuttle
DS47 and other systems.
From FreeBSD, based on the Realtek Linux driver.
ok sthen@ giovani@
|
|
|
|
|
|
|
|
|
|
|
|
isp(4) and the linux qla1280 driver seem to do this.
|
|
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 :)
|
|
non-superspeed hub descriptors. This is the minimal change I
came with to be able to properly attach and use USB 3.0 devices
attached to a xHCI root hub, uhub(4) clearly needs some love.
|
|
the correct speed. This has no effect for the moment since there is no
such driver in our tree, but something tells me it might change soon.
|
|
keep similar userland exported API definitions.
|
|
|
|
initialize the per-controller part.
ok deraadt@, kettenis@
|
|
read from nvram, just like we did for isp(4).
|
|
entries per SCSI command.
|
|
for USB2 devices.
|
|
This will help us deal with the different hub device descriptors used
by super speed devices.
|
|
|
|
really impossible to debug the USB stack when any single device you plug
in your machine starts to vomit its own poetry,
|
|
sparc64.
|
|
descriptor they are linked to, so no need to dereference their pipe
pointer. Simplify a lot of affectations, no functional change.
ok pirofti@
|
|
so merge them into usbd_str() to not introduce other copies with
the upcoming HC drivers.
|
|
|
|
it in various drivers, mainly HC, instead of always rerolling our
own.
|
|
|
|
because upcoming xhci(4) driver won't use it.
|
|
ISP12160 they're using as their underlying SCSI controller.
|
|
|
|
ok mikeb@
|
|
|
|
|
|
supports the PCI variants; SBUs support will follow. Works reasonably
well now. Others are encouraged to test it.
|
|
but at least lets the reader on X220 work pretty reliably, rather than about
1/4 of the time. ok stsp@
|
|
integrated in the Vortex86EX SoC. Based on a diff by sasano@.
ok tedu@
|
|
drivers attaching to uhidev(4) do not always do it. Seems to fix one of
the transfer aborting races triggering a lot of "ehci_idone: ..." vomit
upon resume.
Reported by and fix tested by Ville Valkonen, ok deraadt@
|
|
some missing format arguments pointed out by jsg@
|