- 04 Mar, 2014 40 commits
-
-
Hans de Goede authored
Before this commit the uas driver would keep track of scsi commands which still need to have some urbs submitted to the device, and complete this with an ABORT result code on bus-reset or disconnect, but in flight scsi commands which have all their urbs submitted, and thus are not part of the work list, would never get their done callback called. The problem is killed sense urbs don't have any tag info, so it is impossible to tell which scsi cmd they belong to, so merely making sure all the urbs have completed one way or the other is not enough. This commit fixes this by changing the work list to an inflight list, which keeps tracks of all inflight scsi cmnds, using the IS_IN_WORK_LIST flag to determine if actual work needs to be done in uas_do_work(), and by moving marking all inflight scsi commands as aborted and moving them to the dead list on bus-reset or disconnect. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com>
-
Hans de Goede authored
uas_alloc_data_urb always gets called with a stream_id value of 0 when not using streams. Removing the check makes it consistent with uas_alloc_sense_urb. Signed-off-by:
-
Hans de Goede authored
For USB-2 connections the stream-id must always be 0. Signed-off-by:
-
Hans de Goede authored
Some BIOS-es will hang on reboot when an uas device is attached and left in uas mode on reboot. This commit adds a shutdown handler which on reboot puts the device back into usb-storage mode, fixing the hang on reboot on these systems. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
We can sleep in our own workqueue (which is the whole reason for having it), and scsi error handlers are also always called from a context which may sleep. Signed-off-by:
-
Hans de Goede authored
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 authored
Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
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 authored
No changes, just the move. Signed-off-by:
-
Hans de Goede authored
The loop uses up to 3 bytes of the endpoint extra data. Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for adding better descriptor validation. Signed-off-by:
-
Hans de Goede authored
Falling back from uas to usb-storage requires coordination between uas and usb-storage, so use usb-storage's quirks module parameter, rather then requiring the user to pass a param to 2 different modules. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
uas devices have 2 alternative settings on their usb-storage interface, one for usb-storage and one for uas. Using the uas driver is preferred, so if the uas driver is enabled, and the device has an uas alt setting, don't bind. Signed-off-by:
-
Hans de Goede authored
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 authored
On disconnect USB3 protocol ports transit from U0 to SS.Inactive to Rx.Detect, on a recoverable error, the port stays in SS.Inactive and we recover from it by doing a warm-reset (through usb_device_reset if we have a udev for the port). If this really is a disconnect we may end up trying the warm-reset anyways, since khubd may run before the SS.Inactive to Rx.Detect transition, or it may get skipped if the transition to Rx.Detect happens before khubd gets run. With a loose connector, or in the case which actually led me to debugging this bad ACPI firmware toggling Vbus off and on in quick succession, the port may transition from Rx.Detect to U0 again before khubd gets run. In this case the device state is unknown really, but khubd happily goes into the resuscitate an existing device path, and the device driver never gets notified about the device state being messed up. If the above scenario happens with a streams using device, as soon as an urb is submitted to an endpoint with streams, the following appears in dmesg: ERROR Transfer event for disabled endpoint or incorrect stream ring @0000000036807420 00000000 00000000 04000000 04078000 Notice how the TRB address is all zeros. I've seen this both on Intel Pantherpoint and Nec xhci hosts. Luckily we can detect the U0 to SS.Inactive to Rx.Detect to U0 all having happened before khubd runs case since the C_LINK_STATE bit gets set in the portchange bits on the U0 -> SS.Inactive change. This bit will also be set on suspend / resume, but then it gets cleared by port_hub_init before khubd runs. So if the C_LINK_STATE bit is set and a warm-reset is not needed, iow the port is not still in SS.Inactive, and the port still has a connection, then the device needs to be reset to put it back in a known state. I've verified that doing the device reset also fixes the transfer event with all zeros address issue. Signed-off-by:
-
Hans de Goede authored
If streams are still allocated on device-reset or set-interface then the hcd code implictly frees the streams. Clear host_endpoint->streams in this case so that if a driver later tries to re-allocate them it won't run afoul of the device already having streams check in usb_alloc_streams(). Note normally streams still being allocated at reset / set-intf would be a driver bug, but this can happen without it being a driver bug on reset-resume. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
If we align segment dma pool memory to 64 bytes, then a segment can be located at 0x10000040 - 0x1000043f, and a segment from another ring at 0x10000440 - 0x1000083f. The last trb in the first segment at 0x10000430 will then translate to the same radix tree key as the first trb of the second segment, while they are in different rings! This patches fixes this by changing the alignment of the dma pool to be 1KB rather then 64 bytes. An alternative fix would be to reduce the shift used to calculate the radix tree keys, but that would (slighlty) grow the radix trees so I believe this is the better fix. Note this patch is mostly theoretical since in practice I've not seen the dma_pool actually return not 1KB aligned memory. Signed-off-by:
-
Hans de Goede authored
cmd_ring_reserved_trbs gets decremented by xhci_free_stream_info(), so set it to 0 after freeing all rings, otherwise it wraps around to a very large value when rings with streams are free-ed. Before this patch the wrap-around could be triggered when xhci_resume calls xhci_mem_cleanup if the controller resume fails. Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for teaching usb-storage to not bind to uas devices. Signed-off-by:
-
Hans de Goede authored
This is a preparation patch for teaching usb-storage to not bind to uas devices. Signed-off-by:
-
Hans de Goede authored
If we get ie 16 streams we can use stream-id 1-16, not 1-15. Signed-off-by:
-
Hans de Goede authored
The iu struct definitions are usb packet definitions, so no alignment should happen. Notice that assuming 32 bit alignment this does not make any difference at all. Signed-off-by:
-
Hans de Goede authored
The response iu struct before this patch has a size of 7 bytes (discounting padding), which is weird since all other iu-s are explictly padded to a multiple of 4 bytes. More over submitting a 7 byte bulk transfer to the status endpoint when expecting a response iu results in an USB babble error, as the device actually sends 8 bytes. Up on closer reading of the UAS spec: http://www.t10.org/cgi-bin/ac.pl?t=f&f=uas2r00.pdf The reason for this becomes clear, the 2 entries in "Table 17 — RESPONSE IU" are numbered 4 and 6, looking at other iu definitions in the spec, esp. multi-byte fields, this indicates that the ADDITIONAL RESPONSE INFORMATION field is not a 2 byte field as one might assume at a first look, but is a multi-byte field containing 3 bytes. This also aligns with the SCSI Architecture Model 4 spec, which UAS is based on which states in paragraph "7.1 Task management function procedure calls" that the "Additional Response Information" output argument for a Task management function procedure call is 3 bytes. Last but not least I've verified this by sending a logical unit reset task management call with an invalid lun to an actual uasp device, and received back a response-iu with byte 6 being 0, and byte 7 being 9, which is the responce code for an invalid iu, which confirms that the response code is being reported in byte 7 of the response iu rather then in byte 6. Things were working before despite this error in the response iu struct definition because the additional response info field is normally filled with zeros, and 0 is the response code value for success. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
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 authored
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 authored
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 authored
The cmd endpoint never has streams, so the stream_id parameter is unused. Signed-off-by:
-
Hans de Goede authored
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 authored
- 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 authored
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:
-
Gerd Hoffmann authored
Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Gerd Hoffmann authored
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 authored
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 authored
Signed-off-by:
-
