staging: most: usb: remove reference to USB error codes (bffea154) · Commits · github.com / kvm-riscv / linux

drivers/staging/most/usb/usb.c

+0 −97

Original line number	Diff line number	Diff line
		@@ -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)
		{