This patch removes the reference to the driver API file for USB error codes. Signed-off-by: Christian Gromm <christian.gromm@xxxxxxxxxxxxx> Reported-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> --- v2: removed copied USB error code section v3: drivers/staging/most/usb/usb.c | 97 ------------------------------------------ 1 file changed, 97 deletions(-) diff --git a/drivers/staging/most/usb/usb.c b/drivers/staging/most/usb/usb.c index 85d4fa0..dbb6003 100644 --- a/drivers/staging/most/usb/usb.c +++ b/drivers/staging/most/usb/usb.c @@ -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) { -- 2.7.4
