usb/uas: one only one status URB/host on stream-less connection
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>
Tue, 20 Dec 2011 13:50:26 +0000 (14:50 +0100)
committerLuis Henriques <luis.henriques@canonical.com>
Mon, 30 Apr 2012 18:15:15 +0000 (19:15 +0100)
commitaf2bf3762aee4ede2907dac6d0d369d32d1b947f
tree10fb0d243ec58eac6aef0d9316e1d981793595dc
parentb503b11ee0ca9369d7f7e1b772985fd230c95a34
usb/uas: one only one status URB/host on stream-less connection

BugLink: http://bugs.launchpad.net/bugs/901215

The status/sense URB is allocated on per-command basis. A read/write
looks the following way on a stream-less connection:

- send cmd tag X, queue status
- receive status, oh it is a read for tag X. queue status & read
- receive read
- receive status, oh I'm done for tag X. Cool call complete and free
  status urb.

This block repeats itself 1:1 for further commands and looks great so
far. Lets take a look now what happens if we do allow multiple commands:

- send cmd tag X, queue statusX (belongs to the command with the X tag)
- send cmd tag Y, queue statusY (belongs to the command with the Y tag)
- receive statusX, oh it is a read for tag X. queue statusX & a read
- receive read
- receive statusY, oh I'm done for tag X. Cool call complete and free statusY.
- receive statusX, oh it is a read for tag Y. queue statusY & before we
  queue the read the the following message can be observed:
  |sd 0:0:0:0: [sda] sense urb submission failure
  followed by a second attempt with the same result.

In order to address this problem we will use only one status URB for
each scsi host in case we don't have stream support (as suggested by
Matthew). This URB is requeued until the device removed. Nothing changes
on stream based endpoints.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
(cherry picked from commit ceb3f91fd53c9fbd7b292fc2754ba4efffeeeedb)

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com>
drivers/usb/storage/uas.c