diff options
| author | David Brownell <david-b@pacbell.net> | 2002-10-24 19:59:54 -0700 |
|---|---|---|
| committer | Greg Kroah-Hartman <greg@kroah.com> | 2002-10-24 19:59:54 -0700 |
| commit | e9c72b556ab5a5c2354305c22f67debca46b056a (patch) | |
| tree | 33dc23fa6814234e5b95d885863bc5870735478c /include | |
| parent | df0cca210c3be40f9738891a15b0e00b7313a85c (diff) | |
[PATCH] rm "automagic resubmit" for usb interrupt transfers
Here's that promised patch to remove the problematic "automagic
resubmit" mode from the API for interrupt transfers. It covers
the core (including main HCDs) and a few essential drivers.
All urbs now obey a simple rule: submit them once, then wait for
some completion callback. Or unlink the urb if you're impatient,
canceling the i/o request (which may have been partially completed).
Bulk and interrupt transfers now behave the same at the API level,
except that only interrupt transfers have bandwidth failure modes.
Previously, interrupt transfers were different from bulk transfers
in several ways that made limited sense. The only thing that's
supposed to be special is achieving service latency guarantees by
using the reserved periodic bandwidth.
But there were a lot of other restrictions, plus HCD-dependent
behaviors/bugs. Doing something like sending a 97 byte message
to a device portably was a thing of pain, since the low-level
"one packet per interval" rule was pushed up to drivers instead
of being handled inside HCDs like it is for bulk, and sending a
final "short" packet meant an urb unlink/relink. (Fixing this
required UHCI to use a queue of TDs, like EHCI and OHCI; fixed
by 2.5.44, and a small change in this patch. I'm not sure the
unlink/relink issues have ever been really addressed.) Neither
1-msec transfer intervals nor USB 2.0 "high bandwidth" mode can
reliably be serviced without a multi-buffered queue of interrupt
transfers. (Comes almost for free with TD queueing; as of 2.5.44
all HCDs should do this.)
And then there's "automagic resubmission", which made HCDs
keep urbs during their complete() callbacks in a rather curious
state ... half-owned by HCD, half-owned by device driver, not
exactly linked but maybe not unlinked either. Bug-prone, and
hard to test.
So that's all gone now! This particular patch
- updates the main hcds to use normal urb-completion logic
for interrupt transfers, nothing special. (*)
- makes usbcore (hub and root hub drivers) expect that, and
removes an old kernel 2.3 "urb state confusion" workaround.
(urb->dev is no longer nulled to distinguish unlinked urbs,
since there's no longer a "half-in/half-out" state.) also
the relevent kerneldoc is updated.
- enables the 'usbtest' support for interrupt transfers, in
both queued and non-queued modes. (but I haven't made time
to test this ... the hcds "should" be fine since they use the
same code now for bulk and interrupt, and bulk checked out.)
- teaches hid-core, usbkbd, and usbmouse how to resubmit
interrupt transfers explicitly. usb keyboards/mice work,
but some less-common HID devices won't.
- updated usb/net drivers (catc, kaweth, pegasus, rtl8150)
But it doesn't update all device drivers that use interrupt
transfers. The failure mode for un-converted drivers will
be that interrupts after the first one get lost, and the
fix for those drivers will be simple (see what the drivers
here do).
(*) It doesn't touch non-{E,O,U}HCI HCDs, like the SL-811HS,
since those changes will require hardware as well as
some quality time with 'usbtest'.
Diffstat (limited to 'include')
| -rw-r--r-- | include/linux/usb.h | 8 |
1 files changed, 1 insertions, 7 deletions
diff --git a/include/linux/usb.h b/include/linux/usb.h index fe144bda56f0..e6aa90053d54 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -791,8 +791,7 @@ typedef void (*usb_complete_t)(struct urb *); * @context: For use in completion functions. This normally points to * request-specific driver context. * @complete: Completion handler. This URB is passed as the parameter to the - * completion function. Except for interrupt or isochronous transfers - * that aren't being unlinked, the completion function may then do what + * completion function. The completion function may then do what * it likes with the URB, including resubmitting or freeing it. * @iso_frame_desc: Used to provide arrays of ISO transfer buffers and to * collect the transfer status for each buffer. @@ -885,11 +884,6 @@ typedef void (*usb_complete_t)(struct urb *); * When completion callback is invoked for non-isochronous URBs, the * actual_length field tells how many bytes were transferred. * - * For interrupt URBs, the URB provided to the callback - * function is still "owned" by the USB core subsystem unless the status - * indicates that the URB has been unlinked. Completion handlers should - * not modify such URBs until they have been unlinked. - * * ISO transfer status is reported in the status and actual_length fields * of the iso_frame_desc array, and the number of errors is reported in * error_count. Completion callbacks for ISO transfers will normally |
