1USB_SUBMIT_URB(9)                USB Core APIs               USB_SUBMIT_URB(9)
2
3
4

NAME

6       usb_submit_urb - issue an asynchronous transfer request for an endpoint
7

SYNOPSIS

9       int usb_submit_urb(struct urb * urb, gfp_t mem_flags);
10

ARGUMENTS

12       urb
13           pointer to the urb describing the request
14
15       mem_flags
16           the type of memory to allocate, see kmalloc for a list of valid
17           options for this.
18

DESCRIPTION

20       This submits a transfer request, and transfers control of the URB
21       describing that request to the USB subsystem. Request completion will
22       be indicated later, asynchronously, by calling the completion handler.
23       The three types of completion are success, error, and unlink (a
24       software-induced fault, also called “request cancellation”).
25
26       URBs may be submitted in interrupt context.
27
28       The caller must have correctly initialized the URB before submitting
29       it. Functions such as usb_fill_bulk_urb and usb_fill_control_urb are
30       available to ensure that most fields are correctly initialized, for the
31       particular kind of transfer, although they will not initialize any
32       transfer flags.
33
34       Successful submissions return 0; otherwise this routine returns a
35       negative error number. If the submission is successful, the complete
36       callback from the URB will be called exactly once, when the USB core
37       and Host Controller Driver (HCD) are finished with the URB. When the
38       completion function is called, control of the URB is returned to the
39       device driver which issued the request. The completion handler may then
40       immediately free or reuse that URB.
41
42       With few exceptions, USB device drivers should never access URB fields
43       provided by usbcore or the HCD until its complete is called. The
44       exceptions relate to periodic transfer scheduling. For both interrupt
45       and isochronous urbs, as part of successful URB submission
46       urb->interval is modified to reflect the actual transfer period used
47       (normally some power of two units). And for isochronous urbs,
48       urb->start_frame is modified to reflect when the URB's transfers were
49       scheduled to start. Not all isochronous transfer scheduling policies
50       will work, but most host controller drivers should easily handle ISO
51       queues going from now until 10-200 msec into the future.
52
53       For control endpoints, the synchronous usb_control_msg call is often
54       used (in non-interrupt context) instead of this call. That is often
55       used through convenience wrappers, for the requests that are
56       standardized in the USB 2.0 specification. For bulk endpoints, a
57       synchronous usb_bulk_msg call is available.
58

REQUEST QUEUING

60       URBs may be submitted to endpoints before previous ones complete, to
61       minimize the impact of interrupt latencies and system overhead on data
62       throughput. With that queuing policy, an endpoint's queue would never
63       be empty. This is required for continuous isochronous data streams, and
64       may also be required for some kinds of interrupt transfers. Such
65       queuing also maximizes bandwidth utilization by letting USB controllers
66       start work on later requests before driver software has finished the
67       completion processing for earlier (successful) requests.
68
69       As of Linux 2.6, all USB endpoint transfer queues support depths
70       greater than one. This was previously a HCD-specific behavior, except
71       for ISO transfers. Non-isochronous endpoint queues are inactive during
72       cleanup after faults (transfer errors or cancellation).
73

RESERVED BANDWIDTH TRANSFERS

75       Periodic transfers (interrupt or isochronous) are performed repeatedly,
76       using the interval specified in the urb. Submitting the first urb to
77       the endpoint reserves the bandwidth necessary to make those transfers.
78       If the USB subsystem can't allocate sufficient bandwidth to perform the
79       periodic request, submitting such a periodic request should fail.
80
81       For devices under xHCI, the bandwidth is reserved at configuration
82       time, or when the alt setting is selected. If there is not enough bus
83       bandwidth, the configuration/alt setting request will fail. Therefore,
84       submissions to periodic endpoints on devices under xHCI should never
85       fail due to bandwidth constraints.
86
87       Device drivers must explicitly request that repetition, by ensuring
88       that some URB is always on the endpoint's queue (except possibly for
89       short periods during completion callacks). When there is no longer an
90       urb queued, the endpoint's bandwidth reservation is canceled. This
91       means drivers can use their completion handlers to ensure they keep
92       bandwidth they need, by reinitializing and resubmitting the
93       just-completed urb until the driver longer needs that periodic
94       bandwidth.
95

MEMORY FLAGS

97       The general rules for how to decide which mem_flags to use are the same
98       as for kmalloc. There are four different possible values; GFP_KERNEL,
99       GFP_NOFS, GFP_NOIO and GFP_ATOMIC.
100
101       GFP_NOFS is not ever used, as it has not been implemented yet.
102
103       GFP_ATOMIC is used when (a) you are inside a completion handler, an
104       interrupt, bottom half, tasklet or timer, or (b) you are holding a
105       spinlock or rwlock (does not apply to semaphores), or (c)
106       current->state != TASK_RUNNING, this is the case only after you've
107       changed it.
108
109       GFP_NOIO is used in the block io path and error handling of storage
110       devices.
111
112       All other situations use GFP_KERNEL.
113
114       Some more specific rules for mem_flags can be inferred, such as (1)
115       start_xmit, timeout, and receive methods of network drivers must use
116       GFP_ATOMIC (they are called with a spinlock held); (2) queuecommand
117       methods of scsi drivers must use GFP_ATOMIC (also called with a
118       spinlock held); (3) If you use a kernel thread with a network driver
119       you must use GFP_NOIO, unless (b) or (c) apply; (4) after you have done
120       a down you can use GFP_KERNEL, unless (b) or (c) apply or your are in a
121       storage driver's block io path; (5) USB probe and disconnect can use
122       GFP_KERNEL unless (b) or (c) apply; and (6) changing firmware on a
123       running storage or net device uses GFP_NOIO, unless b) or c) apply
124
126Kernel Hackers Manual 2.6.       November 2011               USB_SUBMIT_URB(9)
Impressum