pm24.git/drivers/usb, branch v3.17-rc5

Merge tag 'fixes-for-v3.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus

2014-09-11T22:08:14Z

Felipe writes: usb: fixes for v3.17-rc4 Some late fixes for dwc3 so we have something more stable on v3.17-final. Most bugs have been there for quite a while and nobody noticed, except for TRB completion when multiple TRBs are started. Patches were tested on AM437x SK and J6 EVM and are passing my tests. Signed-of-by: Felipe Balbi

xhci: fix oops when xhci resumes from hibernate with hw lpm capable devices

2014-09-11T21:23:52Z

Resuming from hibernate (S4) will restart and re-initialize xHC. The device contexts are freed and will be re-allocated later during device reset. Usb core will disable link pm in device resume before device reset, which will try to change the max exit latency, accessing the device contexts before they are re-allocated. There is no need to zero (disable) the max exit latency when disabling hw lpm for a freshly re-initialized xHC. So check that device context exists before doing anything. The max exit latency will be set again after device reset when usb core enables the link pm. Reported-by: Imre Deak Tested-by: Imre Deak Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: xhci: Fix OOPS in xhci error handling code

2014-09-11T21:23:52Z

The xhci driver will OOPS on resume from S2/S3 if dma_alloc_coherent() is out of memory. This is a result of two things: 1. xhci_mem_cleanup() in xhci-mem.c free's xhci->lpm_command if it's not NULL, but doesn't set it to NULL after the free. 2. xhci_mem_cleanup() is called twice on resume, once for normal restart and once from xhci_mem_init() if dma_alloc_coherent() fails, resulting in a free of xhci->lpm_command that has already been freed. The fix is to set xhci->lpm_command to NULL after freeing it. Signed-off-by: Al Cooper Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: Fix null pointer dereference if xhci initialization fails

2014-09-11T21:23:52Z

If xhci initialization fails before the roothub bandwidth domains (xhci->rh_bw[i]) are allocated it will oops when trying to access rh_bw members in xhci_mem_cleanup(). Reported-by: Manuel Reimer Cc: stable Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

storage: Add single-LUN quirk for Jaz USB Adapter

2014-09-11T21:22:25Z

The Iomega Jaz USB Adapter is a SCSI-USB converter cable. The hardware seems to be identical to e.g. the Microtech XpressSCSI, using a Shuttle/ SCM chip set. However its firmware restricts it to only work with Jaz drives. On connecting the cable a message like this appears four times in the log: reset full speed USB device number 4 using uhci_hcd That's non-fatal but the US_FL_SINGLE_LUN quirk fixes it. Signed-off-by: Mark Knibbs Cc: stable Signed-off-by: Greg Kroah-Hartman

uas: Add missing le16_to_cpu calls to asm1051 / asm1053 usb-id check

2014-09-11T21:21:43Z

Reported-by: kbuild test robot Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman

usb: chipidea: msm: Initialize PHY on reset event

2014-09-11T00:30:39Z

Initialize USB PHY after every Link controller reset Cc: 3.16+ Cc: Tim Bird Signed-off-by: Peter Chen Signed-off-by: Ivan T. Ivanov Signed-off-by: Greg Kroah-Hartman

usb: chipidea: msm: Use USB PHY API to control PHY state

2014-09-11T00:30:39Z

PHY drivers keep track of the current state of the hardware, so don't change PHY settings under it. Cc: 3.16+ Cc: Tim Bird Signed-off-by: Peter Chen Signed-off-by: Ivan T. Ivanov Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb: hub: take hub->hdev reference when processing from eventlist

2014-09-10T20:32:35Z

During surprise device hotplug removal tests, it was observed that hub_events may try to call usb_lock_device on a device that has already been freed. Protect the usb_device by taking out a reference (under the hub_event_lock) when hub_events pulls it off the list, returning the reference after hub_events is finished using it. Signed-off-by: Joe Lawrence Suggested-by: David Bulkow for using kref Suggested-by: Alan Stern for placement Acked-by: Alan Stern Cc: stable Signed-off-by: Greg Kroah-Hartman

uas: Disable uas on ASM1051 devices

2014-09-10T20:32:35Z

There are a large numbers of issues with ASM1051 devices in uas mode: 1) They do not support REPORT SUPPORTED OPERATION CODES 2) They use out of spec 8 byte status iu-s when they have no sense data, switching to normal 16 byte status iu-s when they do have sense data. 3) They hang / crash when combined with some disks, e.g. a Crucial M500 ssd. 4) They hang / crash when stressed (through e.g. sg_reset --bus) with disks with which then normally do work (once 1 & 2 are worked around). Where as in BOT mode they appear to work fine, so the best way forward with these devices is to just blacklist them for uas usage. Unfortunately this is easier said then done. as older versions of the ASM1053 (which works fine) use the same usb-id as the ASM1051. When connected over USB-3 the 2 can be told apart by the number of streams they support. So this patch adds some less then pretty code to disable uas for the ASM1051. When connected over USB-2, simply disable uas alltogether for devices with the shared usb-id. Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman