Since we use a fixed tag / stream for tasks we cannot allow more then one
to run at the same time. This could happen before this time if a task timed
out.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The fixed endpoint config code was only necessary to deal with an early
uas prototype which has never been released, so lets drop it and enforce
proper uas endpoint descriptors.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The loop uses up to 3 bytes of the endpoint extra data.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This is a preparation patch for adding better descriptor validation.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Once we start supporting uas hardware, and as more and more uas devices
become available, we will likely start seeing broken devices. This patch
prepares for the inevitable need for blacklisting those devices from
using the uas driver (they will use usb-storage instead).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This is a preparation patch for teaching usb-storage to not bind to
uas devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This is a preparation patch for teaching usb-storage to not bind to
uas devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
If we get ie 16 streams we can use stream-id 1-16, not 1-15.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Handle usb-device resets not triggered from uas_eh_bus_reset_handler(), when
this happens, disable cmd queuing during the reset, and wait for existing
requests to finish in pre_reset.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Fix the uas_eh_bus_reset_handler not properly taking the usbdev lock
before calling usb_device_reset, the usb-core expects this lock to be
taken when usb_device_reset is called.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
I thought it would be a good idea to also test uas with usb-2, and it turns out
it was, as it did not work. The problem is that the uas driver was passing the
bEndpointAddress' direction bit to usb_rcvbulkpipe, the xhci code seems to not
care about this, but with the ehci code this causes usb_submit_urb failure.
With this fixed the uas code works nicely with an uas device plugged into
an ehci port.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The cmd endpoint never has streams, so the stream_id parameter is unused.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
All callers of unlink_data_urbs drop devinfo->lock before calling it, and
then immediately take it again after the call. And the first thing
unlink_data_urbs does is take the lock again, and the last thing it does
is drop it. This commit removes all the unnecessary lock dropping and taking.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
- Rename labels to properly reflect this
- Don't skip free-ing the streams when scsi_init_shared_tag_map fails
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Otherwise they may complete before they get anchored and thus never get
unanchored (as the unanchoring is done by the usb core on completion).
This commit also remove the usb_get_urb / usb_put_urb around cmd submission +
anchoring, since if done in the proper order this is not necessary.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
This patch adds a new list where all requests which are canceled are
added to, so we don't loose them. Then, after killing all inflight
urbs on bus reset (and disconnect) we'll walk over the list and clean
them up.
Without this we can end up with aborted requests lingering around in
case of status pipe transfer errors.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Simplifies locking, we'll protect the list with the device spin lock.
Also plugs races which can happen when two devices operate on the
global list.
While being at it rename the list head from "list" to "work", preparing
for the addition of a second list.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
256 luns is what the sam-4 address method 0 can handle and what
the qemu uas emulation supports. So pick that for now.
[ v2: unlike the other two max_* fields max_channel isn't max+1 ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add new function to unlink and abort requests from the work
list, call it on bus reset and disconnect where we kill all
in-flight urbs. Also reorder calls in disconnect to first
cancel transfers, then remove the scsi hba.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Two changes. First we check whenever the request is linked in the work
list and if so take it out. Second check whenever the command is
actually in flight before asking the device to cancel it via task
management, and in case it isn't just zap the data urbs and finish it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Keep track whenever the request is linked into the work list or not.
Needed for request abort.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
uas_unlink_data_urbs uses this to make sure the the scsi command is
not released while looking at it. This will be needed when we start
calling uas_unlink_data_urbs in the request cancel code paths.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add uas_unlink_data_urbs function to cancel in-flight data urbs.
Moves existing code into a separate function.
[ v2: also drop the locking, just call usb_unlink_urb no matter what,
which is safe because the usb core guarantees the completion
callback is called only once ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Streamline control flow so it is easier for gcc to follow which paths
can be taken and which can't.
Fixes "warning: 'cmdinfo' may be used uninitialized in this function"
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Properly report aborted commands.
Also don't access cmdinfo after kicking task management,
it may not be valid any more once it returns.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Allocate one tag for task management functions and
use it properly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add task management support, wind up in abort and device reset error
handlers. Cancel all in-flight urbs in bus reset handler.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Use separate anchors for data and sense urbs, which
I think will be useful when implementing error handling.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(1) Handle data pipe errors: When the data urb failed we
didn't transfer anything, update scsi_cmnd accordingly.
(2) Cancel data transfers when we got back an error on the
status pipe.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Set state bits after submitting data urbs & command urbs, so we know
what is in flight. Clear data bits when the data urb is finished, clear
command bit when we see the status urb for the command. Finish the scsi
command after running both status and data completion handlers for the
command.
Add a cmd status logging function for debugging purposes. Hook it into
the error handler, so we see in the log what status a command is in
which the scsi layer wants cancel.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stop reusing sense urbs, just allocate a fresh one each time and free it
when done.
Stop storing a sense urb pointer in the scsi request, all you can do
with it is misusing. For example requeuing the sense urb, then f*ck it
up by picking the wrong one in case tagged requests don't finish in the
same order you've submitted them. Also note that (not-yet supported)
task management ops don't have a scsi request in the first place.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit ceb3f91fd5.
IMO the real bug is assigning status urbs to scsi requests. First there
is no such link in the non-stream case. Also there isn't nessesarely a
scsi request in the first place, for example when submitting task
management requests.
This patch just papers over the real bug and introduces different status
urb handling in the stream/non-stream case for no good reason.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit e4d8318a85.
This patch makes uas.c call usb_unlink_urb on data urbs. The data urbs
get freed in the completion callback. This is illegal according to the
usb_unlink_urb documentation.
This patch also makes the code expect the data completion callback
being called before the status completion callback. This isn't
guaranteed to be the case, even though the actual data transfer should
be finished by the time the status is received.
Background: The ehci irq handler for example only know that there are
finished transfers, it then has go check the QHs & TDs to see which
transfers did actually finish. It has no way to figure in which order
the transfers did complete. The xhci driver can call the callbacks in
completion order thanks to the event queue. This does nicely explain
why the driver is solid on a (usb2) xhci port whereas it goes crazy on
ehci in my testing.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Just run into the following:
- new disk arrived in the system
- udev couldn't wait to get its hands on to to run ata_id /dev/sda
- this sent the cdb 0xa1 to the device.
- my UAS-gadget recevied the cdb and had no idea what to do with it. It
decided to send a status URB back with sense set to invalid opcode.
- the host side received it status and completed the scsi command.
- the host sent another scsi with 4kib data buffer
- Now I was confused why the data transfer is only 512 bytes instead of
4kib since the host is always allocating the complete transfer in one
go.
- Finally the system crashed while walking through the sg list.
This patch adds three new flags in order to distinguish between DATA
URB completed and outstanding. If we receive status before data, we
cancel data and let data complete the command.
This solves the problem for IN and OUT transfers but does not work for
BIDI.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The protocol specific structures and defines which are used by UAS are
moved into a header files by this patch so it can be accessed by the UAS
gadget as well.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
The UAS driver requires SG support by the HCD operating the device. This
patch stops UAS from operating on a HCD without sg support and prints a
message to let him know.
The spec says:
|For [USB2] backward compatibility, the device shall present [BOT] as
|alternate interface zero (primary) and [UAS] as alternate interface one
|(secondary). A device which does not need backward compatibility with
|[BOT] shall present [UAS] as alternate interface zero. In [USB2]
|systems, the [BOT] driver or an associated filter driver may need to
|issue a SET INTERFACE request for alternate interface one and then allow
|the [UAS] driver to load.
If the user used usb_modeswitch to switch to UAS then he can go back to
BOT or use a different HCD. In case UAS is the only interface then there
is currently no way out.
In future usb_sg_wait() should be extended to provide a non-blocking
interface so it can work with the UAS driver.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJO8x85AAoJEHuW6BYqjPXRXWgQAI/+xBuTNKwfe/zAcIYxH1I5
Lq3jQaaqZ/TYWMZH2BwHYPXLLayLpHyvYSmub4hJm9okPp/iWJeE6nnYg8Ige8CD
jmpGa8p25pvdP+Rn8GW0EVIA+X0ZVdUV1llz88+21piY4ydobBQOtUtXAIl5jsBv
EVjqCZ6kmn0X7utdutpTHQ421/5k/9x5bh7mHOQTLiMcouXDyA/KVYjet4DVt5PU
Umqrk+uOMUjnygShRZ3C+FLBi/cfJ2jKUQo34dJbhxtD4hZyDe3CXM0UKnvZ5dso
EAykudlN32L29vT000F5KCocEUjQfnqvlBKK+acI7gvdmHCerDn0X/luHx/skSQV
li+pqCqfcfnX6Xg68WWLod9xrt5TtUlD1vAwhvi+ObDIFcVkCqLIdD5lBl+pZz3s
L2j/NgxVkAEVr4VotCNCHCAw17nWYSyle7Px5rLzU1+gfRFTGXiepBxnp52ZPXFf
l+rM+U+OZzrEtuXQq2AEIqh07G4EeovEigWB2v0Eyl77ZmE+SprMHoFVLTtB5Xqc
iau4YMG3nuJdIEyxIHMTrIX91iEgKFfo2Zc030GIe1EH7Gllr8VSYnoQLZf6/tF7
D4NzlqAVQUd6RIDlwQn6XpOGm4FLMF0rJL+Di3QqZ1vk/CRfSmGPSP7mFLbaCNOg
YhMYuzWknxi80kYRMZgy
=GTUe
-----END PGP SIGNATURE-----
Merge tag 'uas_for_sarah' of git://linutronix.de/users/bigeasy/linux into for-uas-next
Merge UAS bug fixes from Sebastian Andrzej Siewior, including some patches of
mine that he signed.
UAS fixes for Sarah
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>
In "usb/uas: use unique tags for all LUNs" we make sure to create unique
tags across all LUNs. This patch uses scsi_host_find_tag() to obtain the
correct command which is associated with the tag.
The following changes are required:
- don't use sdev->current_cmnd anymore
Since we can have devices which don't support command queueing we must
ensure that we can tell the two commands apart. Even if a device
supports comand queuing we send the INQUIRY command "untagged" for
LUN1 while we can send a tagged command to LUN0 at the same time.
devinfo->cmnd is used for stashing the one "untagged" command.
- tag number is altered. If stream support is used then the tag number
must match the stream number. Therefore we can't use tag 0 and must
start at tag 1.
In case we have untagged commands (at least the first command) we must
be able to distinguish between command tag 0 (which becomes 1) and
untagged command (which becomes curently also 1).
The following tag numbers are used:
0: never
1: for untagged commands (devinfo->cmnd)
2+: tagged commands.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Hans de Goede