Commit bd9ef4d9 authored by David Brownell's avatar David Brownell Committed by Greg Kroah-Hartman

[PATCH] USB: usb error code docs

This has various updates to the USB error code documentation that I've
had floating around.
Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
parent 7fe1864a
Revised: 2002-Feb-09. Revised: 2004-Oct-21
This is the documentation of (hopefully) all possible error codes (and This is the documentation of (hopefully) all possible error codes (and
their interpretation) that can be returned from usbcore. their interpretation) that can be returned from usbcore.
Some of them are returned by the Host Controller Drivers (HCDs), which 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 device drivers only see through usbcore. As a rule, all the HCDs should
behave the same except for transfer speed dependent behaviors. behave the same except for transfer speed dependent behaviors and the
way certain faults are reported.
************************************************************************** **************************************************************************
...@@ -26,29 +27,35 @@ USB-specific: ...@@ -26,29 +27,35 @@ USB-specific:
of urb. (treat as a host controller bug.) of urb. (treat as a host controller bug.)
-EINVAL a) Invalid transfer type specified (or not supported) -EINVAL a) Invalid transfer type specified (or not supported)
b) Invalid interrupt interval (0<=n<256) b) Invalid or unsupported periodic transfer interval
c) more than one interrupt packet requested c) ISO: attempted to change transfer interval
d) ISO: number_of_packets is < 0 d) ISO: number_of_packets is < 0
e) various other cases
-EAGAIN a) specified ISO start frame too early -EAGAIN a) specified ISO start frame too early
b) (using ISO-ASAP) too much scheduled for the future b) (using ISO-ASAP) too much scheduled for the future
wait some time and try again. wait some time and try again.
-EFBIG too much ISO frames requested (currently uhci>900) -EFBIG Host controller driver can't schedule that many ISO frames.
-EPIPE Specified endpoint is stalled. For non-control endpoints, -EPIPE Specified endpoint is stalled. For non-control endpoints,
reset this status with usb_clear_halt(). reset this status with usb_clear_halt().
-EMSGSIZE endpoint message size is zero, do interface/alternate setting -EMSGSIZE (a) endpoint maxpacket size is zero; it is not usable
in the current interface altsetting.
(b) ISO packet is biger than endpoint maxpacket
(c) requested data transfer size is invalid (negative)
-ENOSPC The host controller's bandwidth is already consumed and -ENOSPC This request would overcommit the usb bandwidth reserved
this request would push it past its allowed limit. for periodic transfers (interrupt, isochronous).
-ESHUTDOWN The host controller has been disabled due to some -ESHUTDOWN The device or host controller has been disabled due to some
problem that could not be worked around. problem that could not be worked around.
-EPERM Submission failed because urb->reject was set. -EPERM Submission failed because urb->reject was set.
-EHOSTUNREACH URB was rejected because the device is suspended.
************************************************************************** **************************************************************************
* Error codes returned by in urb->status * * Error codes returned by in urb->status *
...@@ -71,14 +78,14 @@ one or more packets could finish before an error stops further endpoint I/O. ...@@ -71,14 +78,14 @@ one or more packets could finish before an error stops further endpoint I/O.
-EINPROGRESS URB still pending, no results yet -EINPROGRESS URB still pending, no results yet
(That is, if drivers see this it's a bug.) (That is, if drivers see this it's a bug.)
-EPROTO (*) a) bitstuff error -EPROTO (*, **) a) bitstuff error
b) no response packet received within the b) no response packet received within the
prescribed bus turn-around time prescribed bus turn-around time
c) unknown USB error c) unknown USB error
-EILSEQ (*) CRC mismatch -EILSEQ (*, **) CRC mismatch
-EPIPE Endpoint stalled. For non-control endpoints, -EPIPE (**) Endpoint stalled. For non-control endpoints,
reset this status with usb_clear_halt(). reset this status with usb_clear_halt().
-ECOMM During an IN transfer, the host controller -ECOMM During an IN transfer, the host controller
...@@ -97,7 +104,7 @@ one or more packets could finish before an error stops further endpoint I/O. ...@@ -97,7 +104,7 @@ one or more packets could finish before an error stops further endpoint I/O.
specified buffer, and URB_SHORT_NOT_OK was set in specified buffer, and URB_SHORT_NOT_OK was set in
urb->transfer_flags. urb->transfer_flags.
-ETIMEDOUT transfer timed out, NAK -ETIMEDOUT (**) transfer timed out, NAK
-ENODEV Device was removed. Often preceded by a burst of -ENODEV Device was removed. Often preceded by a burst of
other errors, since the hub driver does't detect other errors, since the hub driver does't detect
...@@ -110,13 +117,19 @@ one or more packets could finish before an error stops further endpoint I/O. ...@@ -110,13 +117,19 @@ one or more packets could finish before an error stops further endpoint I/O.
-ECONNRESET URB was asynchronously unlinked by usb_unlink_urb -ECONNRESET URB was asynchronously unlinked by usb_unlink_urb
-ESHUTDOWN The host controller has been disabled due to some -ESHUTDOWN The device or host controller has been disabled due
problem that could not be worked around. to some problem that could not be worked around,
such as a physical disconnect.
(*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
hardware problems such as bad devices (including firmware) or cables. 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 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.
************************************************************************** **************************************************************************
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment