- 24 Sep, 2014 40 commits
-
-
Hans de Goede authored
Lately (with the use of uas / bulk-streams) we have been seeing several cases where this error triggers (which should never happen). Add some extra logging to make debugging these errors easier. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
Even though a Set TR deq ptr command operates on a ring, and an endpoint can have multiple rings, we can have only one Set TR deq ptr command pending. When an endpoint with streams halts or is stopped to unlink urbs, there will only be at most one ring active / one td being executed (the td stopped_td points to). So when we reset the endpoint (for a halt), or the stop command completes, we will queue one Set TR deq ptr command at most, cancelled urbs on other stream rings then the one being executed will have there trbs turned to nops, and once the hcd gets around to execute that stream ring they will be simply skipped. So the SET_DEQ_PENDING flag in the endpoint is sufficient protection against starting the endpoing before all stream rings are cleaned up. Signed-off-by:
-
Hans de Goede authored
Even if the stream for which the command was intended has been freed in the mean time. This ensures that things start rolling again after an unlink / halt. Signed-off-by:
-
Hans de Goede authored
xhci_queue_new_dequeue_state is the only caller of queue_set_tr_deq and queue_set_tr_deq checks for SET_DEQ_PENDING, where as xhci_queue_new_dequeue_state sets it which is inconsistent. Simply fold the 2 into one is a nice cleanup and fixes the inconsistency. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Al Cooper authored
V2 - Restart polling (which will restart the timer) for the shared HCD in xhci_resume(). xhci_suspend() will stop the primary HCD's root hub timer, but leaves the shared HCD's timer running. This change adds stopping of the shared HCD timer. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Signed-off-by:
-
Hans de Goede authored
There are multiple reasons for this: 1) This fixes a missing check for xhci_alloc_command failing in xhci_handle_cmd_stop_ep() 2) This adds a warning when we cannot set the new dequeue state because of xhci_alloc_command failing 3) It puts the allocation of the command after the sanity checks in queue_set_tr_deq(), avoiding leaking the command if those fail 4) Since queue_set_tr_deq now owns the command it can free it if queue_command fails 5) It reduces code duplication Signed-off-by:
-
Hans de Goede authored
If something goes wrong in our communication with an uas device we may get a response iu in reaction to a cmnd, rather then a status iu. In this case propagate an error upwards, rather then logging a bogus iu message. Signed-off-by:
-
Hans de Goede authored
Signed-off-by:
-
Hans de Goede authored
Instead of doing: uas_log_cmd_state(cmnd, __func__) scmd_printk(KERN_ERR, cmnd, "error doing foo %d\n", err) On error, resulting in 2 log calls for a single error, make uas_log_cmd_state take a status code, and change calls like the above to: uas_log_cmd_state(cmnd, "error doing foo", err) Also change various sanity checks (which should never trigger) from: "scmd_printk(KERN_ERR, cmnd, "sanity foo failed\n")" to calling the new uas_log_cmd_state(), so that when they do trigger we get more info. Signed-off-by:
-
Hans de Goede authored
We've removed all hack from the driver for pre-production hardware. Signed-off-by:
-
Hans de Goede authored
I've access to a number of different uas devices now, and none of them use old style sense urbs. The only case where these code-paths trigger is with the asm1051 and there they do the wrong thing, as the asm1051 sends 8 bytes status iu-s when it does not have any sense data, but uses new style sense iu-s regardless, as can be seen for scsi cmnds where there is sense data. Signed-off-by:
-
Hans de Goede authored
It was only used to sanity check against completing the same cmnd twice, but that is the case we're likely operating on free-ed memory, and doing sanity checks on free-ed memory is not really helpful. Signed-off-by:
-
Hans de Goede authored
Use scsi_print_command to print commands during errors, rather then printing the rather meaningless pointer to the command. Signed-off-by:
-
Hans de Goede authored
Check for both type of cancellation codes for sense and data urbs. Signed-off-by:
-
Hans de Goede authored
Limit the no-streams case to speeds less then USB_SPEED_SUPER. Signed-off-by:
-
Hans de Goede authored
The purpose of uas_pre_reset is to: 1) Stop any new commands from being submitted while an externally triggered usb-device-reset is running 2) Wait for any pending commands to finish before allowing the usb-device-reset to continue The purpose of uas_suspend is to: 2) Wait for any pending commands to finish before suspending This commit fixes races in both paths: 1) For 1) we use scsi_block_requests, but the scsi midlayer calls queuecommand without holding any locks, so a queuecommand may already past the midlayer scsi_block_requests checks when we call it, add a check to uas_queuecommand to fix this 2) For 2) we were waiting for all sense-urbs to complete, there are 2 problems with this approach: a) data-urbs may complete after the sense urb, so we need to check for those too b) if a sense-urb completes with a iu id of READ/WRITE_READY a command is not yet done. We submit a new sense-urb immediately in this case, but that submit may fail (in which case it will get retried by uas_do_work), if this happens the sense_urbs anchor may become empty while the cmnd is not yet done Also unblock requests on timeout, to avoid things getting stuck in that case. Signed-off-by:
-
Hans de Goede authored
Not all urbs we've allocated are necessarily also submitted, non-submitted urbs will not be free-ed by their completion handler. So we need to free them manually. There are 2 scenarios where this can happen: 1) We have failed to submit some urbs at abort / disconnect 2) When running over usb-2 we may have never tried to submit the data urbs when completing the scsi cmnd, because we never got a READ/WRITE_READY iu Signed-off-by:
-
Hans de Goede authored
Do not keep references around to a cmnd which is under error handling. Signed-off-by:
-
Hans de Goede authored
It is not strictly necessary for the cmd urb to have a reference to the cmnd, and without this reference it becomes easier to drop all references to a cmnd on an abort. Signed-off-by:
-
Hans de Goede authored
We've the same info doubled in both the inflight list and the cmnd array, drop the list. Signed-off-by:
-
Hans de Goede authored
The data urbs are all killed before calling zap_pending, and their completion handler should have cleared their inflight flag. Do not 0 the data inflight flags, and add a check for try_complete succeeding, as it should always succeed when called from zap_pending. Signed-off-by:
-
Hans de Goede authored
Drop the whole dance with first moving cmnds to a dead-list. The resetting flag ensures that no new cmds / urbs will be submitted, and that any urb completions are short-circuited without trying to complete the scsi cmnd. Signed-off-by:
-
Hans de Goede authored
Now that we no longer drop our lock to unlink the data urbs, we can simply free them on completion, making their handling consistent with the other urbs. Signed-off-by:
-
Hans de Goede authored
There is no need for all the trickery with dropping the lock, we can simply reference the urbs while we hold the lock to ensure the urbs don't disappear beneath us, and do the actual unlink (+ unreference) after we've dropped the lock. This also fixes a race where we may loose of cmnd ownership to the scsi midlayer without holding the lock due to the midlayer re-claiming ownership through an abort (which will be handled by a future patch in this series). Signed-off-by:
-
Hans de Goede authored
The status urb should not complete before the command has been submitted, nor should we get a second status urb for the same tag after a IU_ID_STATUS. Data urbs should not complete before the command has been submitted, but may complete after the IU_ID_STATUS. Signed-off-by:
-
Hans de Goede authored
Using scsi_host_find_tag with tags returned by the device is unsafe for multiple reasons: 1) It returns tags->rqs[tag], which may be non NULL even when the cmnd is not owned by us 2) It returns tags->rqs[tag], without holding any locks protecting it 3) It returns tags->rqs[tag], without doing any boundary checking Instead keep our own list which maps tags -> inflight cmnds. Signed-off-by:
-
Hans de Goede authored
Factor out the mapping of scsi-tags -> uas-tags/stream-ids to a helper function so that there is a single place where this "magic" happens. Signed-off-by:
-
Hans de Goede authored
- Make sure we always hold the lock when setting / checking resetting - Check resetting before checking urb->status - Add missing check for resetting to uas_data_cmplt - Add missing check for resetting to uas_do_work Signed-off-by:
-
Hans de Goede authored
There are various bug reports about oopses / hangs with the uas driver, which all point to the abort-command and logical-unit-reset (task-management) error handling paths. Getting these right is very hard, there are quite a few corner cases, and testing is almost impossible since under normal operation these code paths are not used at all. Another problem is that there are also some cases where it simply is not clear what to do at all. E.g. over usb-2 multiple outstanding commands share the same endpoint. What if a command gets aborted while its sense urb is half way through completing (so some data has been transfered but not all). Since the urb is not yet complete we don't know if the sense urb is actually for this command, or for one of the other oustanding commands. If it is for one of the other commands and we cancel it, then we end up in an undefined state. But if it is actually for the command we're aborting, and the abort succeeds, then it may never complete... This exact same problem applies to logical unit resets too, if there are multiple luns, then commands outstanding on both luns share the sense endpoint. If there is only a single lun, then doing a logical unit reset is little better then doing a full usb device reset. So summarizing because: 1) abort / lun-reset is very tricky to get right 2) Not being able to test the tricky code, which means it will have bugs 3) This being a code path which under normal operation will never happen, so being slow / sub-optimal here is not really an issue 4) Under error conditions we will still be able to recover through usb device resets. 5) This may be a bit slower in some cases, but this is actually faster in cases where the bridge ship has locked up, which seems to be the most common error case sofar. This commit removes the abort / lun-reset error handling paths, and also the taks-mgmt code since those are the only 2 task-mgmt users. Leaving only the (tested and testable) usb-device-reset error handling path in place. Note I realize that this is somewhat of a big hammer, but currently people are seeing very hard to debug oopses with uas. First let focus on making uas work reliable, then we can later look into adding more fine grained error handling. Signed-off-by:
-
Hans de Goede authored
As most ASM1051 based devices, this one has unfixable issues with uas too. Cc: stable@vger.kernel.org # 3.16 Signed-off-by:
-
Hans de Goede authored
https://bbs.archlinux.org/viewtopic.php?pid=1457492Signed-off-by:
-
Hans de Goede authored
Besides the ASM1051 (*) needing sdev->no_report_opcodes = 1, it turns out that the JMicron JMS567 also needs it to work properly with uas (usb-storage always sets it). Since some of the scsi devs were not to keen on the idea to outrightly set sdev->no_report_opcodes = 1 for all uas devices, so add a quirk for this, and set it for the JMS567. *) Which has become a non-issue since we've completely blacklisted uas on the ASM1051 for other reasons Cc: stable@vger.kernel.org Reported-and-tested-by:
Claudio Bizzarri <claudio.bizzarri@gmail.com> Signed-off-by:
-
Hans de Goede authored
And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one seems to hang upon receiving an ATA_12 or ATA_16 command. https://bugzilla.kernel.org/show_bug.cgi?id=79511 https://bbs.archlinux.org/viewtopic.php?id=183190 While at it also add missing documentation for the u value for usb-storage quirks. Cc: stable@vger.kernel.org # 3.16, 3.17 Signed-off-by:
-
Sanjeev Sharma authored
on some architecture spin_is_locked() always return false in uniprocessor configuration and therefore it would be advise to replace with lockdep_assert_held(). Signed-off-by:
Sanjeev Sharma <Sanjeev_Sharma@mentor.com> Acked-by:
-
Peter Griffin authored
This patch adds the ehci-st.c and ohci-st.c files for the usb 2.0 & usb1.1 host controller drivers found on stih41x and stih4xx STMicroelectronics SoC's into the STI arch section of the maintainers file. Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Peter Griffin authored
This patch documents the device tree bindings required for the ohci on-chip controller found in ST consumer electronics SoC's. Signed-off-by:
-
Peter Griffin authored
This patch documents the device tree bindings required for the ehci on-chip controller found in ST consumer electronics SoC's. Signed-off-by:
-
Peter Griffin authored
This patch adds the glue code required to ensure the on-chip OHCI controller works on STi consumer electronics SoC's from STMicroelectronics. It mainly manages the setting and enabling of the relevant clocks and manages the reset / power signals to the IP block. Signed-off-by:
-
Peter Griffin authored
This patch adds the glue code required to ensure the on-chip EHCI controller works on STi consumer electronics SoC's from STMicroelectronics. It mainly manages the setting and enabling of the relevant clocks and manages the reset / power signals to the IP block. Signed-off-by:
-
