| Age | Commit message (Collapse) | Author |
|---|
|
|
|
if interface was attached.
both are correct but this is for consistency with other drivers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ok phessler
|
|
be run from the generic task kthread, because xfers that need to be
aborted block newly queued tasks from running (i.e. the xfer to be aborted
blocks the abort of that task). as there are now three types of usb
tasks, add an argument to usb_init_task() and another member to struct
usb_task to specify the task type.
fixes boot hangs that are showing up because we now use usb tasks to
attach/detach usb devices.
|
|
"Feel free to commit!" krw@
|
|
|
|
commit controls, use the hardware frame idenfitier instead of the
software identifier since they can differ, and the hardware only
knows about it's own identifiers
|
|
instead of the first one that has enough bandwidth as it may be too much
|
|
|
|
Planex GW-USMicro300.
|
|
Some other products use more than one generation of chipset. e.g. both
DL160 and DL165. Change to a later chipset if the family is newer than
expected. ok mglocker@ -moj
|
|
OK yuo, fkr, jsg
|
|
|
|
OK yuo, fkr, jsg
|
|
|
|
member the way uaudio does, make the variable sized member as large
as it can be and don't define the following members.
* reenable control support for devices where bControlSize != 2 in
the processing unit descriptor.
tested on alpha, amd64, i386, sparc64 and zaurus, as well as the machine
where previous support for variable bControlSize caused a hang.
|
|
control.
|
|
a crash with Kodak S100 webcam.
|
|
device so it can be used in userland.
ok jasper@
|
|
ok jasper@
|
|
|
|
|
|
|
|
apparently it reorders stores in a bad way. Mostly from NetBSD.
earlier diff tested by landry@ (who noticed the problems on macppc)
ok deraadt@
|
|
I can figure out why it causes boot hangs with some Sonix camera
|
|
|
|
and add support for more processing unit controls.
from Martin Pieuchot, thanks!
|
|
The dying flag will be set in activate()/DEACTIVATE.
ok deraadt@
|
|
it with slow operations.
ok jsg yuo
|
|
woken up by a wakeup, but only by the actual timeout expiry. On
architectures which share a kva upage area between processes, we would
not want an accidental wakeup (too short).
discussed with various
|
|
the device driver which has DEACTIVATE processing seems to no need to
set dying flag in the detach() function because the flag will be set
in the DEACTIVATE process before detach().
ok jsg@, ok for experiment deraadt@
|
|
ok deraadt@
|
|
becaue it skips a wakeup() later on. this is the only error condition
that returns before the wakeup. not sure why this particular case is
handled differently, and not certain what the error code should be, but
this is better than breaking all of usb because of a problem on one port.
dicussed with deraadt
|
|
* usbd_device_handle dev - the device responsible for the task. use
this to not run the task if the device's hub is dying.
* int running - a flag to be set when the task is running.
add usb_rem_wait_task(), a wrapper for usb_rem_task() that waits for
the task to complete if the task is already running.
s/usb_rem_task/usb_rem_wait_task/ in usb_detach(). probably most
drivers using usb_tasks should do this as well. although device
attach/detach is serialized in normal cases, in the special case
where the usb bus is hotpluggable (like cardbus/pcmcia), devices
are not detached in the task thread.
|
|
is dying, instead of setting a flag in struct usb_softc. as
usbd_device_handle has a pointer to the usbd_bus it's attached to,
usb devices, and functions they run or functions run on their behalf,
can now easily check if their bus is dying. use this to stop
usbd_do_request* from running and the usb task thread from adding
new tasks when a device's bus is dying.
|
|
hubs before their first port explore, check how long it's actually
been since power up and only wait as necessary. saves a little time
on boot, especially now that explore tasks are serialized.
ok yuo@
|
|
USB bus, make usb_explore() a usb_task. reduces races during normal
USB device detach, since now usb_tasks and detach happen in the same
process.
ok yuo@, matthew@ helped with the task thread loop
|
|
OK krw
|
|
ok jsg@
|
|
determined by bNbrPorts in hub descriptor.
USB hub sends status packet to host, it contains status bits for each port
and hub itself. So, the packet size is ceil((port + 1) / 8) bytes.
If host requests smaller than that size, the hub behavior is undefined.
Some hub (Intel's RMH for example) sends whole status every time,
it makes babble of USB. This is the reason that uhub_intr() of old code
was suffered from USBD_IOERROR,
Okay deraadt@ and yuo@.
|
|
fixes problems seen with Linksys USB300M.
|
|
in time, which is a problem if your umass device has multiple luns
on it. if multiple commands are issued at the same time then they
step on some shared state, which in turn causes some interesting
panics.
this diff introduces an iopool in umass so only one command can be
"allocated" and scheduled at a time.
found, reproduced and investigated by krw@
fix verified by krw@
ok matthew@ krw@
|
|
for now. But since it is not being handled, do not ack it on the
chip.
Discussed with kettenis a while back
|
|
that crept in with rev 1.77, spotted by the clang static analyser.
ok deraadt@
|
