UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity

staging: most: usb: remove reference to USB error codes 

This patch removes the reference to the driver API file for USB error
codes.

Signed-off-by: Christian Gromm <christian.gromm@microchip.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/1589534465-7423-3-git-send-email-christian.gromm@microchip.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Christian Gromm 2020-05-15 11:21:00 +02:00 committed by Greg Kroah-Hartman
parent 6257322124
commit bffea154b2
1 changed files with 0 additions and 97 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
drivers/staging/most/usb/usb.c
View File

@ -382,103 +382,6 @@ static void hdm_write_completion(struct urb *urb)
* padding bytes -if necessary- and calls the completion function.
*
* Context: interrupt!
*
* **************************************************************************
* 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.
*
* See <https://www.kernel.org/doc/Documentation/driver-api/usb/error-codes.rst>
*/
static void hdm_read_completion(struct urb *urb)
{