|  | Revised: 2004-Oct-21 | 
|  |  | 
|  | This is the documentation of (hopefully) all possible error codes (and | 
|  | their interpretation) that can be returned from usbcore. | 
|  |  | 
|  | Some of them are returned by the Host Controller Drivers (HCDs), which | 
|  | device drivers only see through usbcore.  As a rule, all the HCDs should | 
|  | behave the same except for transfer speed dependent behaviors and the | 
|  | way certain faults are reported. | 
|  |  | 
|  |  | 
|  | ************************************************************************** | 
|  | *                   Error codes returned by usb_submit_urb               * | 
|  | ************************************************************************** | 
|  |  | 
|  | Non-USB-specific: | 
|  |  | 
|  | 0		URB submission went fine | 
|  |  | 
|  | -ENOMEM		no memory for allocation of internal structures | 
|  |  | 
|  | USB-specific: | 
|  |  | 
|  | -EBUSY		The URB is already active. | 
|  |  | 
|  | -ENODEV		specified USB-device or bus doesn't exist | 
|  |  | 
|  | -ENOENT		specified interface or endpoint does not exist or | 
|  | is not enabled | 
|  |  | 
|  | -ENXIO		host controller driver does not support queuing of this type | 
|  | of urb.  (treat as a host controller bug.) | 
|  |  | 
|  | -EINVAL		a) Invalid transfer type specified (or not supported) | 
|  | b) Invalid or unsupported periodic transfer interval | 
|  | c) ISO: attempted to change transfer interval | 
|  | d) ISO: number_of_packets is < 0 | 
|  | e) various other cases | 
|  |  | 
|  | -EXDEV		ISO: URB_ISO_ASAP wasn't specified and all the frames | 
|  | the URB would be scheduled in have already expired. | 
|  |  | 
|  | -EFBIG		Host controller driver can't schedule that many ISO frames. | 
|  |  | 
|  | -EPIPE		The pipe type specified in the URB doesn't match the | 
|  | endpoint's actual type. | 
|  |  | 
|  | -EMSGSIZE	(a) endpoint maxpacket size is zero; it is not usable | 
|  | in the current interface altsetting. | 
|  | (b) ISO packet is larger than the endpoint maxpacket. | 
|  | (c) requested data transfer length is invalid: negative | 
|  | or too large for the host controller. | 
|  |  | 
|  | -ENOSPC		This request would overcommit the usb bandwidth reserved | 
|  | for periodic transfers (interrupt, isochronous). | 
|  |  | 
|  | -ESHUTDOWN	The device or host controller has been disabled due to some | 
|  | problem that could not be worked around. | 
|  |  | 
|  | -EPERM		Submission failed because urb->reject was set. | 
|  |  | 
|  | -EHOSTUNREACH	URB was rejected because the device is suspended. | 
|  |  | 
|  | -ENOEXEC	A control URB doesn't contain a Setup packet. | 
|  |  | 
|  |  | 
|  | ************************************************************************** | 
|  | *                   Error codes returned by in urb->status               * | 
|  | *                   or in iso_frame_desc[n].status (for ISO)             * | 
|  | ************************************************************************** | 
|  |  | 
|  | USB device drivers may only test urb status values in completion handlers. | 
|  | This is because otherwise there would be a race between HCDs updating | 
|  | these values on one CPU, and device drivers testing them on another CPU. | 
|  |  | 
|  | A transfer's actual_length may be positive even when an error has been | 
|  | reported.  That's because transfers often involve several packets, so that | 
|  | one or more packets could finish before an error stops further endpoint I/O. | 
|  |  | 
|  | For isochronous URBs, the urb status value is non-zero only if the URB is | 
|  | unlinked, the device is removed, the host controller is disabled, or the total | 
|  | transferred length is less than the requested length and the URB_SHORT_NOT_OK | 
|  | flag is set.  Completion handlers for isochronous URBs should only see | 
|  | urb->status set to zero, -ENOENT, -ECONNRESET, -ESHUTDOWN, or -EREMOTEIO. | 
|  | Individual frame descriptor status fields may report more status codes. | 
|  |  | 
|  |  | 
|  | 0			Transfer completed successfully | 
|  |  | 
|  | -ENOENT			URB was synchronously unlinked by usb_unlink_urb | 
|  |  | 
|  | -EINPROGRESS		URB still pending, no results yet | 
|  | (That is, if drivers see this it's a bug.) | 
|  |  | 
|  | -EPROTO (*, **)		a) bitstuff error | 
|  | b) no response packet received within the | 
|  | prescribed bus turn-around time | 
|  | c) unknown USB error | 
|  |  | 
|  | -EILSEQ (*, **)		a) CRC mismatch | 
|  | b) no response packet received within the | 
|  | prescribed bus turn-around time | 
|  | c) unknown USB error | 
|  |  | 
|  | Note that often the controller hardware does not | 
|  | distinguish among cases a), b), and c), so a | 
|  | driver cannot tell whether there was a protocol | 
|  | error, a failure to respond (often caused by | 
|  | device disconnect), or some other fault. | 
|  |  | 
|  | -ETIME (**)		No response packet received within the prescribed | 
|  | bus turn-around time.  This error may instead be | 
|  | reported as -EPROTO or -EILSEQ. | 
|  |  | 
|  | -ETIMEDOUT		Synchronous USB message functions use this code | 
|  | to indicate timeout expired before the transfer | 
|  | completed, and no other error was reported by HC. | 
|  |  | 
|  | -EPIPE (**)		Endpoint stalled.  For non-control endpoints, | 
|  | reset this status with usb_clear_halt(). | 
|  |  | 
|  | -ECOMM			During an IN transfer, the host controller | 
|  | received data from an endpoint faster than it | 
|  | could be written to system memory | 
|  |  | 
|  | -ENOSR			During an OUT transfer, the host controller | 
|  | could not retrieve data from system memory fast | 
|  | enough to keep up with the USB data rate | 
|  |  | 
|  | -EOVERFLOW (*)		The amount of data returned by the endpoint was | 
|  | greater than either the max packet size of the | 
|  | endpoint or the remaining buffer size.  "Babble". | 
|  |  | 
|  | -EREMOTEIO		The data read from the endpoint did not fill the | 
|  | specified buffer, and URB_SHORT_NOT_OK was set in | 
|  | urb->transfer_flags. | 
|  |  | 
|  | -ENODEV			Device was removed.  Often preceded by a burst of | 
|  | other errors, since the hub driver doesn't detect | 
|  | device removal events immediately. | 
|  |  | 
|  | -EXDEV			ISO transfer only partially completed | 
|  | (only set in iso_frame_desc[n].status, not urb->status) | 
|  |  | 
|  | -EINVAL			ISO madness, if this happens: Log off and go home | 
|  |  | 
|  | -ECONNRESET		URB was asynchronously unlinked by usb_unlink_urb | 
|  |  | 
|  | -ESHUTDOWN		The device or host controller has been disabled due | 
|  | to some problem that could not be worked around, | 
|  | such as a physical disconnect. | 
|  |  | 
|  |  | 
|  | (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate | 
|  | hardware problems such as bad devices (including firmware) or cables. | 
|  |  | 
|  | (**) This is also one of several codes that different kinds of host | 
|  | controller use to indicate a transfer has failed because of device | 
|  | disconnect.  In the interval before the hub driver starts disconnect | 
|  | processing, devices may receive such fault reports for every request. | 
|  |  | 
|  |  | 
|  |  | 
|  | ************************************************************************** | 
|  | *              Error codes returned by usbcore-functions                 * | 
|  | *           (expect also other submit and transfer status codes)         * | 
|  | ************************************************************************** | 
|  |  | 
|  | usb_register(): | 
|  | -EINVAL			error during registering new driver | 
|  |  | 
|  | usb_get_*/usb_set_*(): | 
|  | usb_control_msg(): | 
|  | usb_bulk_msg(): | 
|  | -ETIMEDOUT		Timeout expired before the transfer completed. |