- 24 Sep, 2014 36 commits
-
-
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 <hdegoede@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
-
Tobias Klauser authored
Use devm_ioremap_resource to simplify error handling in the probe function and to get rid of some boilerplate in the remove function. Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Signed-off-by:
-
Peter Chen authored
Adds chipidea to the list of DT vendor prefixes. Signed-off-by:
Peter Chen <peter.chen@freescale.com> Signed-off-by:
-
Peter Chen authored
Some kernel-doc style comment are not satisfied for format, fix them. Signed-off-by:
-
Peter Chen authored
We have only needed to enable otg initialization when both of below conditions are satisfied: - The controller is otg capable - The gadget function is enabled If the controller is otg capable, but is host-only configuration, we do not need to access register otgsc and do any otg operations (eg, create otg workqueue). Signed-off-by:
-
Stefan Agner authored
This adds Vybrid VF610 SoC support. The IP is very similar to i.MX6, however, the non-core registers are spread in two different register areas. Hence we support multiple instances of the USB misc driver and add the driver instance to the imx_usbmisc_data structure. Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Peter Chen authored
TPL (Targeted Peripheral List) is needed for targets host (OTG and Embedded Hosts) for usb certification and other vendor specific requirements. Signed-off-by:
-
Peter Chen authored
For OTG and Embedded hosts, they may need TPL (Targeted Peripheral List) for usb certification and other vender specific requirements, the platform can tell chipidea core driver if it supports tpl through DT or platform data. Signed-off-by:
-
Peter Chen authored
The TPL (Targeted Peripheral List) is used for targeted hosts (non-PC hosts), and it can be used at USB OTG & EH certification and some specific products which need white list. Signed-off-by:
-
Peter Chen authored
Update configuration for USB_OTG_WHITELIST, any targeted hosts (non PC-hosts) can have TPL (Targered Peripheral List). Signed-off-by:
-
Peter Chen authored
According to On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification, the targeted hosts (non-PC hosts) include both embedded hosts and otg, and each targeted host product defines the set of supported peripherals on a TPL (Targeted Peripheral List). So, TPL should apply for both OTG and embedded host, and the otg support is not a must for embedded host. The TPL support feature will only be effect when CONFIG_USB_OTG_WHITELIST has been chosen and hcd->tpl_support flag is set, it can avoid the enumeration fails problem for the user who chooses CONFIG_USB_OTG_WHITELIST wrongly. Signed-off-by:
-
Peter Chen authored
The targeted hosts (non-PC hosts) need to have TPL (Targeted Peripheral List) for USB OTG & EH certification and other vendor specific requirements. The platform who needs TPL feature should set this flag at usb host controller driver. Signed-off-by:
-
Johan Hovold authored
Enable device-qualifier quirk for Elan Touchscreen, which often fails to handle requests for the device_descriptor. Note that the device sometimes do respond properly with a Request Error (three times as USB core retries), but usually fails to respond at all. When this happens any further descriptor requests also fails, for example: [ 1528.688934] usb 2-7: new full-speed USB device number 4 using xhci_hcd [ 1530.945588] usb 2-7: unable to read config index 0 descriptor/start: -71 [ 1530.945592] usb 2-7: can't read configurations, error -71 This has been observed repeating for over a minute before eventual successful enumeration. Reported-by:
Drew Von Spreecken <drewvs@gmail.com> Reported-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Johan Hovold authored
Add new quirk for devices that cannot handle requests for the device_qualifier descriptor. A USB-2.0 compliant device must respond to requests for the device_qualifier descriptor (even if it's with a request error), but at least one device is known to misbehave after such a request. Suggested-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
- 23 Sep, 2014 1 commit
-
-
Felipe Balbi authored
This reverts commit f2267089. That commit causes more problem than fixes. Firstly, kfree() should be called after usb_ep_dequeue() and secondly, the way things are, we will try to dequeue a request that has already completed much more frequently than one which is pending. Cc: Li Jun <b47624@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Cc: stable <stable@vger.kernel.org> # 3.17 Signed-off-by:
-
- 22 Sep, 2014 2 commits
-
-
Greg Kroah-Hartman authored
We want the USB fixes in this branch as well. Signed-off-by: -
Greg Kroah-Hartman authored
Merge tag 'usb-serial-3.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB-serial updates for v3.18-rc1 These changes add two new "simple" drivers, while removing the redundant zte_ev driver (PIDs moved to option). Included are also some minor clean ups to the xsens_mt driver, and the enabling of further baud rates for pl2303 devices. Signed-off-by:
-
- 21 Sep, 2014 1 commit
-
-
Linus Torvalds authored
-
