| 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: |
| |
| -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. |