|
Linux Kernel
3.7.1
|
All Data Structures Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Groups Pages
|
Linux Kernel
3.7.1
|
#include <linux/module.h>#include <linux/string.h>#include <linux/bitops.h>#include <linux/slab.h>#include <linux/init.h>#include <linux/log2.h>#include <linux/usb.h>#include <linux/wait.h>#include <linux/usb/hcd.h>Go to the source code of this file.
Macros | |
| #define | to_urb(d) container_of(d, struct urb, kref) |
| EXPORT_SYMBOL_GPL | ( | usb_init_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_alloc_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_free_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_get_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_anchor_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_unanchor_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_submit_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_unlink_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_kill_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_poison_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_unpoison_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_block_urb | ) |
| EXPORT_SYMBOL_GPL | ( | usb_kill_anchored_urbs | ) |
| EXPORT_SYMBOL_GPL | ( | usb_poison_anchored_urbs | ) |
| EXPORT_SYMBOL_GPL | ( | usb_unpoison_anchored_urbs | ) |
| EXPORT_SYMBOL_GPL | ( | usb_unlink_anchored_urbs | ) |
| EXPORT_SYMBOL_GPL | ( | usb_wait_anchor_empty_timeout | ) |
| EXPORT_SYMBOL_GPL | ( | usb_get_from_anchor | ) |
| EXPORT_SYMBOL_GPL | ( | usb_scuttle_anchored_urbs | ) |
| EXPORT_SYMBOL_GPL | ( | usb_anchor_empty | ) |
usb_alloc_urb - creates a new urb for a USB driver to use : number of iso packets for this urb : the type of memory to allocate, see kmalloc() for a list of valid options for this.
Creates an urb for the USB driver to use, initializes a few internal structures, incrementes the usage counter, and returns a pointer to it.
If no memory is available, NULL is returned.
If the driver want to use this urb for interrupt, control, or bulk endpoints, pass '0' as the number of iso packets.
The driver must call usb_free_urb() when it is finished with the urb.
usb_block_urb - reliably prevent further use of an URB : pointer to URB to be blocked, may be NULL
After the routine has run, attempts to resubmit the URB will fail with error -EPERM. Thus even if the URB's completion handler always tries to resubmit, it will not succeed and the URB will become idle.
The URB must not be deallocated while this routine is running. In particular, when a driver calls this routine, it must insure that the completion handler cannot deallocate the URB.
usb_free_urb - frees the memory used by a urb when all users of it are finished : pointer to the urb to free, may be NULL
Must be called when a user of a urb is finished with it. When the last user of the urb calls this function, the memory of the urb is freed.
Note: The transfer buffer associated with the urb is not freed unless the URB_FREE_BUFFER transfer flag is set.
usb_get_urb - increments the reference count of the urb : pointer to the urb to modify, may be NULL
This must be called whenever a urb is transferred from a device driver to a host controller driver. This allows proper reference counting to happen for urbs.
A pointer to the urb with the incremented reference counter is returned.
usb_init_urb - initializes a urb so that it can be used by a USB driver : pointer to the urb to initialize
Initializes a urb so that the USB subsystem can use it properly.
If a urb is created with a call to usb_alloc_urb() it is not necessary to call this function. Only use this if you allocate the space for a struct urb on your own. If you call this function, be careful when freeing the memory for your urb that it is no longer in use by the USB core.
Only use this function if you really understand what you are doing.
usb_kill_urb - cancel a transfer request and wait for it to finish : pointer to URB describing a previously submitted request, may be NULL
This routine cancels an in-progress request. It is guaranteed that upon return all completion handlers will have finished and the URB will be totally idle and available for reuse. These features make this an ideal way to stop I/O in a disconnect() callback or close() function. If the request has not already finished or been unlinked the completion handler will see urb->status == -ENOENT.
While the routine is running, attempts to resubmit the URB will fail with error -EPERM. Thus even if the URB's completion handler always tries to resubmit, it will not succeed and the URB will become idle.
The URB must not be deallocated while this routine is running. In particular, when a driver calls this routine, it must insure that the completion handler cannot deallocate the URB.
This routine may not be used in an interrupt context (such as a bottom half or a completion handler), or when holding a spinlock, or in other situations where the caller can't schedule().
This routine should not be called by a driver after its disconnect method has returned.
usb_poison_urb - reliably kill a transfer and prevent further use of an URB : pointer to URB describing a previously submitted request, may be NULL
This routine cancels an in-progress request. It is guaranteed that upon return all completion handlers will have finished and the URB will be totally idle and cannot be reused. These features make this an ideal way to stop I/O in a disconnect() callback. If the request has not already finished or been unlinked the completion handler will see urb->status == -ENOENT.
After and while the routine runs, attempts to resubmit the URB will fail with error -EPERM. Thus even if the URB's completion handler always tries to resubmit, it will not succeed and the URB will become idle.
The URB must not be deallocated while this routine is running. In particular, when a driver calls this routine, it must insure that the completion handler cannot deallocate the URB.
This routine may not be used in an interrupt context (such as a bottom half or a completion handler), or when holding a spinlock, or in other situations where the caller can't schedule().
This routine should not be called by a driver after its disconnect method has returned.
usb_submit_urb - issue an asynchronous transfer request for an endpoint : pointer to the urb describing the request : the type of memory to allocate, see kmalloc() for a list of valid options for this.
This submits a transfer request, and transfers control of the URB describing that request to the USB subsystem. Request completion will be indicated later, asynchronously, by calling the completion handler. The three types of completion are success, error, and unlink (a software-induced fault, also called "request cancellation").
URBs may be submitted in interrupt context.
The caller must have correctly initialized the URB before submitting it. Functions such as usb_fill_bulk_urb() and usb_fill_control_urb() are available to ensure that most fields are correctly initialized, for the particular kind of transfer, although they will not initialize any transfer flags.
Successful submissions return 0; otherwise this routine returns a negative error number. If the submission is successful, the complete() callback from the URB will be called exactly once, when the USB core and Host Controller Driver (HCD) are finished with the URB. When the completion function is called, control of the URB is returned to the device driver which issued the request. The completion handler may then immediately free or reuse that URB.
With few exceptions, USB device drivers should never access URB fields provided by usbcore or the HCD until its complete() is called. The exceptions relate to periodic transfer scheduling. For both interrupt and isochronous urbs, as part of successful URB submission urb->interval is modified to reflect the actual transfer period used (normally some power of two units). And for isochronous urbs, urb->start_frame is modified to reflect when the URB's transfers were scheduled to start. Not all isochronous transfer scheduling policies will work, but most host controller drivers should easily handle ISO queues going from now until 10-200 msec into the future.
For control endpoints, the synchronous usb_control_msg() call is often used (in non-interrupt context) instead of this call. That is often used through convenience wrappers, for the requests that are standardized in the USB 2.0 specification. For bulk endpoints, a synchronous usb_bulk_msg() call is available.
Request Queuing:
URBs may be submitted to endpoints before previous ones complete, to minimize the impact of interrupt latencies and system overhead on data throughput. With that queuing policy, an endpoint's queue would never be empty. This is required for continuous isochronous data streams, and may also be required for some kinds of interrupt transfers. Such queuing also maximizes bandwidth utilization by letting USB controllers start work on later requests before driver software has finished the completion processing for earlier (successful) requests.
As of Linux 2.6, all USB endpoint transfer queues support depths greater than one. This was previously a HCD-specific behavior, except for ISO transfers. Non-isochronous endpoint queues are inactive during cleanup after faults (transfer errors or cancellation).
Reserved Bandwidth Transfers:
Periodic transfers (interrupt or isochronous) are performed repeatedly, using the interval specified in the urb. Submitting the first urb to the endpoint reserves the bandwidth necessary to make those transfers. If the USB subsystem can't allocate sufficient bandwidth to perform the periodic request, submitting such a periodic request should fail.
For devices under xHCI, the bandwidth is reserved at configuration time, or when the alt setting is selected. If there is not enough bus bandwidth, the configuration/alt setting request will fail. Therefore, submissions to periodic endpoints on devices under xHCI should never fail due to bandwidth constraints.
Device drivers must explicitly request that repetition, by ensuring that some URB is always on the endpoint's queue (except possibly for short periods during completion callacks). When there is no longer an urb queued, the endpoint's bandwidth reservation is canceled. This means drivers can use their completion handlers to ensure they keep bandwidth they need, by reinitializing and resubmitting the just-completed urb until the driver longer needs that periodic bandwidth.
Memory Flags:
The general rules for how to decide which mem_flags to use are the same as for kmalloc. There are four different possible values; GFP_KERNEL, GFP_NOFS, GFP_NOIO and GFP_ATOMIC.
GFP_NOFS is not ever used, as it has not been implemented yet.
GFP_ATOMIC is used when (a) you are inside a completion handler, an interrupt, bottom half, tasklet or timer, or (b) you are holding a spinlock or rwlock (does not apply to semaphores), or (c) current->state != TASK_RUNNING, this is the case only after you've changed it.
GFP_NOIO is used in the block io path and error handling of storage devices.
All other situations use GFP_KERNEL.
Some more specific rules for mem_flags can be inferred, such as (1) start_xmit, timeout, and receive methods of network drivers must use GFP_ATOMIC (they are called with a spinlock held); (2) queuecommand methods of scsi drivers must use GFP_ATOMIC (also called with a spinlock held); (3) If you use a kernel thread with a network driver you must use GFP_NOIO, unless (b) or (c) apply; (4) after you have done a down() you can use GFP_KERNEL, unless (b) or (c) apply or your are in a storage driver's block io path; (5) USB probe and disconnect can use GFP_KERNEL unless (b) or (c) apply; and (6) changing firmware on a running storage or net device uses GFP_NOIO, unless b) or c) apply
usb_unlink_anchored_urbs - asynchronously cancel transfer requests en masse the requests are bound to
this allows all outstanding URBs to be unlinked starting from the back of the queue. This function is asynchronous. The unlinking is just tiggered. It may happen after this function has returned.
This routine should not be called by a driver after its disconnect method has returned.
usb_unlink_urb - abort/cancel a transfer request for an endpoint : pointer to urb describing a previously submitted request, may be NULL
This routine cancels an in-progress request. URBs complete only once per submission, and may be canceled only once per submission. Successful cancellation means termination of will be expedited and the completion handler will be called with a status code indicating that the request has been canceled (rather than any other code).
Drivers should not call this routine or related routines, such as usb_kill_urb() or usb_unlink_anchored_urbs(), after their disconnect method has returned. The disconnect function should synchronize with a driver's I/O routines to insure that all URB-related activity has completed before it returns.
This request is asynchronous, however the HCD might call the ->complete() callback during unlink. Therefore when drivers call usb_unlink_urb(), they must not hold any locks that may be taken by the completion function. Success is indicated by returning -EINPROGRESS, at which time the URB will probably not yet have been given back to the device driver. When it is eventually called, the completion function will see ->status == -ECONNRESET. Failure is indicated by usb_unlink_urb() returning any other value. Unlinking will fail when is not currently "linked" (i.e., it was never submitted, or it was unlinked before, or the hardware is already finished with it), even if the completion handler has not yet run.
The URB must not be deallocated while this routine is running. In particular, when a driver calls this routine, it must insure that the completion handler cannot deallocate the URB.
Unlinking and Endpoint Queues:
[The behaviors and guarantees described below do not apply to virtual root hubs but only to endpoint queues for physical USB devices.]
Host Controller Drivers (HCDs) place all the URBs for a particular endpoint in a queue. Normally the queue advances as the controller hardware processes each request. But when an URB terminates with an error its queue generally stops (see below), at least until that URB's completion routine returns. It is guaranteed that a stopped queue will not restart until all its unlinked URBs have been fully retired, with their completion routines run, even if that's not until some time after the original completion handler returns. The same behavior and guarantee apply when an URB terminates because it was unlinked.
Bulk and interrupt endpoint queues are guaranteed to stop whenever an URB terminates with any sort of error, including -ECONNRESET, -ENOENT, and -EREMOTEIO. Control endpoint queues behave the same way except that they are not guaranteed to stop for -EREMOTEIO errors. Queues for isochronous endpoints are treated differently, because they must advance at fixed rates. Such queues do not stop when an URB encounters an error or is unlinked. An unlinked isochronous URB may leave a gap in the stream of packets; it is undefined whether such gaps can be filled in.
Note that early termination of an URB because a short packet was received will generate a -EREMOTEIO error if and only if the URB_SHORT_NOT_OK flag is set. By setting this flag, USB device drivers can build deep queues for large or complex bulk transfers and clean them up reliably after any sort of aborted transfer by unlinking all pending URBs at the first fault.
When a control URB terminates with an error other than -EREMOTEIO, it is quite likely that the status stage of the transfer will not take place.
1.8.2