Root/
1 | Revised: 2004-Oct-21 |
2 | |
3 | This is the documentation of (hopefully) all possible error codes (and |
4 | their interpretation) that can be returned from usbcore. |
5 | |
6 | Some of them are returned by the Host Controller Drivers (HCDs), which |
7 | device drivers only see through usbcore. As a rule, all the HCDs should |
8 | behave the same except for transfer speed dependent behaviors and the |
9 | way certain faults are reported. |
10 | |
11 | |
12 | ************************************************************************** |
13 | * Error codes returned by usb_submit_urb * |
14 | ************************************************************************** |
15 | |
16 | Non-USB-specific: |
17 | |
18 | 0 URB submission went fine |
19 | |
20 | -ENOMEM no memory for allocation of internal structures |
21 | |
22 | USB-specific: |
23 | |
24 | -ENODEV specified USB-device or bus doesn't exist |
25 | |
26 | -ENOENT specified interface or endpoint does not exist or |
27 | is not enabled |
28 | |
29 | -ENXIO host controller driver does not support queuing of this type |
30 | of urb. (treat as a host controller bug.) |
31 | |
32 | -EINVAL a) Invalid transfer type specified (or not supported) |
33 | b) Invalid or unsupported periodic transfer interval |
34 | c) ISO: attempted to change transfer interval |
35 | d) ISO: number_of_packets is < 0 |
36 | e) various other cases |
37 | |
38 | -EAGAIN a) specified ISO start frame too early |
39 | b) (using ISO-ASAP) too much scheduled for the future |
40 | wait some time and try again. |
41 | |
42 | -EFBIG Host controller driver can't schedule that many ISO frames. |
43 | |
44 | -EPIPE The pipe type specified in the URB doesn't match the |
45 | endpoint's actual type. |
46 | |
47 | -EMSGSIZE (a) endpoint maxpacket size is zero; it is not usable |
48 | in the current interface altsetting. |
49 | (b) ISO packet is larger than the endpoint maxpacket. |
50 | (c) requested data transfer length is invalid: negative |
51 | or too large for the host controller. |
52 | |
53 | -ENOSPC This request would overcommit the usb bandwidth reserved |
54 | for periodic transfers (interrupt, isochronous). |
55 | |
56 | -ESHUTDOWN The device or host controller has been disabled due to some |
57 | problem that could not be worked around. |
58 | |
59 | -EPERM Submission failed because urb->reject was set. |
60 | |
61 | -EHOSTUNREACH URB was rejected because the device is suspended. |
62 | |
63 | -ENOEXEC A control URB doesn't contain a Setup packet. |
64 | |
65 | |
66 | ************************************************************************** |
67 | * Error codes returned by in urb->status * |
68 | * or in iso_frame_desc[n].status (for ISO) * |
69 | ************************************************************************** |
70 | |
71 | USB device drivers may only test urb status values in completion handlers. |
72 | This is because otherwise there would be a race between HCDs updating |
73 | these values on one CPU, and device drivers testing them on another CPU. |
74 | |
75 | A transfer's actual_length may be positive even when an error has been |
76 | reported. That's because transfers often involve several packets, so that |
77 | one or more packets could finish before an error stops further endpoint I/O. |
78 | |
79 | |
80 | 0 Transfer completed successfully |
81 | |
82 | -ENOENT URB was synchronously unlinked by usb_unlink_urb |
83 | |
84 | -EINPROGRESS URB still pending, no results yet |
85 | (That is, if drivers see this it's a bug.) |
86 | |
87 | -EPROTO (*, **) a) bitstuff error |
88 | b) no response packet received within the |
89 | prescribed bus turn-around time |
90 | c) unknown USB error |
91 | |
92 | -EILSEQ (*, **) a) CRC mismatch |
93 | b) no response packet received within the |
94 | prescribed bus turn-around time |
95 | c) unknown USB error |
96 | |
97 | Note that often the controller hardware does not |
98 | distinguish among cases a), b), and c), so a |
99 | driver cannot tell whether there was a protocol |
100 | error, a failure to respond (often caused by |
101 | device disconnect), or some other fault. |
102 | |
103 | -ETIME (**) No response packet received within the prescribed |
104 | bus turn-around time. This error may instead be |
105 | reported as -EPROTO or -EILSEQ. |
106 | |
107 | -ETIMEDOUT Synchronous USB message functions use this code |
108 | to indicate timeout expired before the transfer |
109 | completed, and no other error was reported by HC. |
110 | |
111 | -EPIPE (**) Endpoint stalled. For non-control endpoints, |
112 | reset this status with usb_clear_halt(). |
113 | |
114 | -ECOMM During an IN transfer, the host controller |
115 | received data from an endpoint faster than it |
116 | could be written to system memory |
117 | |
118 | -ENOSR During an OUT transfer, the host controller |
119 | could not retrieve data from system memory fast |
120 | enough to keep up with the USB data rate |
121 | |
122 | -EOVERFLOW (*) The amount of data returned by the endpoint was |
123 | greater than either the max packet size of the |
124 | endpoint or the remaining buffer size. "Babble". |
125 | |
126 | -EREMOTEIO The data read from the endpoint did not fill the |
127 | specified buffer, and URB_SHORT_NOT_OK was set in |
128 | urb->transfer_flags. |
129 | |
130 | -ENODEV Device was removed. Often preceded by a burst of |
131 | other errors, since the hub driver doesn't detect |
132 | device removal events immediately. |
133 | |
134 | -EXDEV ISO transfer only partially completed |
135 | look at individual frame status for details |
136 | |
137 | -EINVAL ISO madness, if this happens: Log off and go home |
138 | |
139 | -ECONNRESET URB was asynchronously unlinked by usb_unlink_urb |
140 | |
141 | -ESHUTDOWN The device or host controller has been disabled due |
142 | to some problem that could not be worked around, |
143 | such as a physical disconnect. |
144 | |
145 | |
146 | (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate |
147 | hardware problems such as bad devices (including firmware) or cables. |
148 | |
149 | (**) This is also one of several codes that different kinds of host |
150 | controller use to indicate a transfer has failed because of device |
151 | disconnect. In the interval before the hub driver starts disconnect |
152 | processing, devices may receive such fault reports for every request. |
153 | |
154 | |
155 | |
156 | ************************************************************************** |
157 | * Error codes returned by usbcore-functions * |
158 | * (expect also other submit and transfer status codes) * |
159 | ************************************************************************** |
160 | |
161 | usb_register(): |
162 | -EINVAL error during registering new driver |
163 | |
164 | usb_get_*/usb_set_*(): |
165 | usb_control_msg(): |
166 | usb_bulk_msg(): |
167 | -ETIMEDOUT Timeout expired before the transfer completed. |
168 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9