(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>
I observed that on a device with multiple LUNs UAS was re-using the same
tag number for requests which were issued at the same time to both LUNs.
This patch uses scsi_init_shared_tag_map() to use unique tags for all
LUNs. With this patch I haven't seen the same tag number during the init
sequence anymore. Tag 1 is used for devices which do not adverise
command queueing.
This patch initilizes the queue before adding the scsi host like the
other two user in tree.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
In the UAS status URB completion handler, we need to free the URB, no
matter what happens. Fix a bug where we would leak the URB (and its
buffer) if we couldn't find a SCSI command that is associated with this
status phase.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
UAS can work with either USB 3.0 devices that support bulk streams, or
USB 2.0 devices that do not support bulk streams. When we're working
with a non-streams device, we need to be able to uniquely identify a
SCSI command with a tag in the IU. Devices will barf and abort all
queued commands if they find a duplicate tag.
uas_queuecommand_lck() sets cmdinfo->stream to zero if the device
doesn't support streams, which is later passed into uas_alloc_cmd_urb()
as the variable stream. This means the UAS driver was setting the tag
in all commands to zero for non-stream devices. So the UAS driver won't
currently work with USB 2.0 devices.
Use the SCSI command tag instead of the stream ID for the command IU
tag. We have to add one to the SCSI command tag because SCSI tags are
zero-based, but stream IDs are one-based, and the command tag must match
the stream ID that we're queueing the data IUs for. Untagged SCSI
commands use stream ID 1.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
If the original submission (or allocation) of the URBs for a SCSI
command fails, the UAS driver sticks the command structure in a
workqueue and schedules uas_do_work() to run. That function removes the
entire queue before walking across it and attempting to resubmit.
Unfortunately, if the second submission fails, we will leak memory
(because an allocated URB was not submitted) and possibly leave the SCSI
command partially enqueued on some of the stream rings. Fix this by
checking whether the second submission failed and re-queueing the
command to the UAS workqueue and scheduling it.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
This converts the drivers in drivers/usb/* to use the
module_usb_driver() macro which makes the code smaller and a bit
simpler.
Added bonus is that it removes some unneeded kernel log messages about
drivers loading and/or unloading.
Cc: Simon Arlott <cxacru@fire.lp0.eu>
Cc: Duncan Sands <duncan.sands@free.fr>
Cc: Matthieu CASTET <castet.matthieu@free.fr>
Cc: Stanislaw Gruszka <stf_xl@wp.pl>
Cc: Pete Zaitcev <zaitcev@redhat.com>
Cc: Oliver Neukum <oliver@neukum.name>
Cc: Juergen Stuber <starblue@users.sourceforge.net>
Cc: Cesar Miquel <miquel@df.uba.ar>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Cc: Matthew Wilcox <willy@linux.intel.com>
Cc: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Cc: Michael Hund <mhund@ld-didactic.de>
Cc: Zack Parsons <k3bacon@gmail.com>
Cc: Melchior FRANZ <mfranz@aon.at>
Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The situation up to this point meant that module.h was pretty
much everywhere, regardless of whether you asked for it or not.
We are fixing that, so give the USB folks who want it an actual
include of it.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* usb-next: (132 commits)
USB: uas: Use GFP_NOIO instead of GFP_KERNEL in I/O submission path
USB: uas: Ensure we only bind to a UAS interface
USB: uas: Rename sense pipe and sense urb to status pipe and status urb
USB: uas: Use kzalloc instead of kmalloc
USB: uas: Fix up the Sense IU
usb: musb: core: kill unneeded #include's
DA8xx: assign name to MUSB IRQ resource
usb: gadget: g_ncm added
usb: gadget: f_ncm.c added
usb: gadget: u_ether: prepare for NCM
usb: pch_udc: Fix setup transfers with data out
usb: pch_udc: Fix compile error, warnings and checkpatch warnings
usb: add ab8500 usb transceiver driver
USB: gadget: Implement runtime PM for MSM bus glue driver
USB: gadget: Implement runtime PM for ci13xxx gadget
USB: gadget: Add USB controller driver for MSM SoC
USB: gadget: Introduce ci13xxx_udc_driver struct
USB: gadget: Initialize ci13xxx gadget device's coherent DMA mask
USB: gadget: Fix "scheduling while atomic" bugs in ci13xxx_udc
USB: gadget: Separate out PCI bus code from ci13xxx_udc
...
If swap is on a UAS device, we could recurse into the driver by using
GFP_KERNEL. Using GFP_NOIO ensures we won't.
Reported-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
While all existing UAS devices use alternate interface 1, this is not
guaranteed, and it has caused confusion with people trying to bind the
uas driver to non-uas devices.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The spec calls this the status pipe. While it is used to receive sense IUs,
it is also used to receive other IUs, so this can be confusing.
Reported-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The IUs are not being fully initialised by the driver (due to the reserved
space). Since we should be zeroing reserved fields, use kzalloc to do
it for us.
Reported-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add a comment to the Sense IU data structure that it's also used for Read
Ready and Write Ready. Remove the 'service response' element since it's
gone from the current draft (04).
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Move the mid-layer's ->queuecommand() invocation from being locked
with the host lock to being unlocked to facilitate speeding up the
critical path for drivers who don't need this lock taken anyway.
The patch below presents a simple SCSI host lock push-down as an
equivalent transformation. No locking or other behavior should change
with this patch. All existing bugs and locking orders are preserved.
Additionally, add one parameter to queuecommand,
struct Scsi_Host *
and remove one parameter from queuecommand,
void (*done)(struct scsi_cmnd *)
Scsi_Host* is a convenient pointer that most host drivers need anyway,
and 'done' is redundant to struct scsi_cmnd->scsi_done.
Minimal code disturbance was attempted with this change. Most drivers
needed only two one-line modifications for their host lock push-down.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Acked-by: James Bottomley <James.Bottomley@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
REQ_HARDBARRIER is dead now, so remove the leftovers. What's left
at this point is:
- various checks inside the block layer.
- sanity checks in bio based drivers.
- now unused bio_empty_barrier helper.
- Xen blockfront use of BLKIF_OP_WRITE_BARRIER - it's dead for a while,
but Xen really needs to sort out it's barrier situaton.
- setting of ordered tags in uas - dead code copied from old scsi
drivers.
- scsi different retry for barriers - it's dead and should have been
removed when flushes were converted to FS requests.
- blktrace handling of barriers - removed. Someone who knows blktrace
better should add support for REQ_FLUSH and REQ_FUA, though.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
USB Attached SCSI is a new protocol specified jointly by the SCSI T10
committee and the USB Implementors Forum.
Signed-off-by: Matthew Wilcox <willy@linux.intel.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
[mina86@mina86.com: updated to use new USB_ prefix]
Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>