user/sven/linux.git/drivers/usb, branch v3.4.89

USB: pl2303: add ids for Hewlett-Packard HP POS pole displays

2014-05-06T14:51:46Z

commit b16c02fbfb963fa2941b7517ebf1f8a21946775e upstream. Add device ids to pl2303 for the Hewlett-Packard HP POS pole displays: LD960: 03f0:0B39 LCM220: 03f0:3139 LCM960: 03f0:3239 [ Johan: fix indentation and sort PIDs numerically ] Signed-off-by: Aaron Sanders Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman

USB: unbind all interfaces before rebinding any

2014-05-06T14:51:45Z

commit 6aec044cc2f5670cf3b143c151c8be846499bd15 upstream. When a driver doesn't have pre_reset, post_reset, or reset_resume methods, the USB core unbinds that driver when its device undergoes a reset or a reset-resume, and then rebinds it afterward. The existing straightforward implementation can lead to problems, because each interface gets unbound and rebound before the next interface is handled. If a driver claims additional interfaces, the claim may fail because the old binding instance may still own the additional interface when the new instance tries to claim it. This patch fixes the problem by first unbinding all the interfaces that are marked (i.e., their needs_binding flag is set) and then rebinding all of them. The patch also makes the helper functions in driver.c a little more uniform and adjusts some out-of-date comments. Signed-off-by: Alan Stern Reported-and-tested-by: "Poulain, Loic" Signed-off-by: Greg Kroah-Hartman

usb: dwc3: fix wrong bit mask in dwc3_event_devt

2014-05-06T14:51:44Z

commit 06f9b6e59661cee510b04513b13ea7927727d758 upstream. Around DWC USB3 2.30a release another bit has been added to the Device-Specific Event (DEVT) Event Information (EvtInfo) bitfield. Because of that, what used to be 8 bits long, has become 9 bits long. Per dwc3 2.30a+ spec in the Device-Specific Event (DEVT), the field of Event Information Bits(EvtInfo) uses [24:16] bits, and it has 9 bits not 8 bits. And the following reserved field uses [31:25] bits not [31:24] bits, and it has 7 bits. So in dwc3_event_devt, the bit mask should be: event_info [24:16] 9 bits reserved31_25 [31:25] 7 bits This patch makes sure that newer core releases will work fine with Linux and that we will decode the event information properly on new core releases. [ balbi@ti.com : improve commit log a bit ] Signed-off-by: Huang Rui Signed-off-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

2014-05-06T14:51:44Z

commit 01bb59ebffdec314da8da66266edf29529372f9b upstream. When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this warning: drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined but not used [-Wunused-function] Instead of creating nested #ifdefs, this patch fixes it by defining the xHCI PCI stubs as inline. This warning has been in since 3.2 kernel and was caused by commit 421aa841a134f6a743111cf44d0c6d3b45e3cf8c "usb/xhci: hide MSI code behind PCI bars", but wasn't noticed until 3.13 when a configuration with these options was tried Signed-off-by: David Cohen Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

xhci: extend quirk for Renesas cards

2014-05-06T14:51:44Z

commit 6db249ebefc6bf5c39f35dfaacc046d8ad3ffd70 upstream. After suspend another Renesas PCI-X USB 3.0 card doesn't work. [root@fedora-20 ~]# lspci -vmnnd 1912: Device: 03:00.0 Class: USB controller [0c03] Vendor: Renesas Technology Corp. [1912] Device: uPD720202 USB 3.0 Host Controller [0015] SVendor: Renesas Technology Corp. [1912] SDevice: uPD720202 USB 3.0 Host Controller [0015] Rev: 02 ProgIf: 30 This patch should be applied to stable kernel 3.14 that contain the commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d "xhci: Fix resume issues on Renesas chips in Samsung laptops" Reported-and-tested-by: Anatoly Kharchenko Reference: http://redmine.russianfedora.pro/issues/1315 Signed-off-by: Igor Gnatenko Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman

usb: musb: set TXMAXP and AUTOSET for full speed bulk in device mode

2014-05-06T14:51:44Z

commit bb3a2ef2eb8cfaea335dcb3426350df7f3d48069 upstream. The TXMAXP register is not set correctly for full speed bulk case when the can_bulk_split() is used. Without this PIO transfers will not take place correctly The "mult" factor needs to be updated correctly for the can_bulk_split() case The AUTOSET bit in the TXCSR is not being set if the "mult" factor is greater than 0 for the High Bandwidth ISO case. But the "mult" factor is also greater than 0 in case of Full speed bulk transfers with the packet splitting in TXMAXP register Without the AUTOSET the DMA transfers will not progress in mode1 [ balbi@ti.com : add braces to both branches ] Signed-off-by: supriya karanth Signed-off-by: Praveena NADAHALLY Acked-by: Linus Walleij Signed-off-by: Felipe Balbi Cc: ian coolidge Signed-off-by: Greg Kroah-Hartman

USB: fix crash during hotplug of PCI USB controller card

2014-05-06T14:51:42Z

commit a2ff864b53eac9a0e9b05bfe9d1781ccd6c2af71 upstream. The code in hcd-pci.c that matches up EHCI controllers with their companion UHCI or OHCI controllers assumes that the private drvdata fields don't get set too early. However, it turns out that this field gets set by usb_create_hcd(), before hcd-pci expects it, and this can result in a crash when two controllers are probed in parallel (as can happen when a new controller card is hotplugged). The companions_rwsem lock was supposed to prevent this sort of thing, but usb_create_hcd() is called outside the scope of the rwsem. A simple solution is to check that the root-hub pointer has been initialized as well as the drvdata field. This doesn't happen until usb_add_hcd() is called; that call and the check are both protected by the rwsem. This patch should be applied to stable kernels from 3.10 onward. Signed-off-by: Alan Stern Reported-by: Stefani Seibold Tested-by: Stefani Seibold Signed-off-by: Greg Kroah-Hartman

xhci: Limit the spurious wakeup fix only to HP machines

2014-04-14T13:44:29Z

commit 6962d914f317b119e0db7189199b21ec77a4b3e0 upstream. We've got regression reports that my previous fix for spurious wakeups after S5 on HP Haswell machines leads to the automatic reboot at shutdown on some machines. It turned out that the fix for one side triggers another BIOS bug in other side. So, it's exclusive. Since the original S5 wakeups have been confirmed only on HP machines, it'd be safer to apply it only to limited machines. As a wild guess, limiting to machines with HP PCI SSID should suffice. This patch should be backported to kernels as old as 3.12, that contain the commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 "xhci: Fix spurious wakeups after S5 on Haswell". Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171 Signed-off-by: Takashi Iwai Signed-off-by: Sarah Sharp Tested-by: Reported-by: Niklas Schnelle Reported-by: Giorgos Reported-by: Signed-off-by: Ben Hutchings Cc: Yang Yingliang Signed-off-by: Greg Kroah-Hartman

xhci: Fix spurious wakeups after S5 on Haswell

2014-04-14T13:44:29Z

commit 638298dc66ea36623dbc2757a24fc2c4ab41b016 upstream. Haswell LynxPoint and LynxPoint-LP with the recent Intel BIOS show mysterious wakeups after shutdown occasionally. After discussing with BIOS engineers, they explained that the new BIOS expects that the wakeup sources are cleared and set to D3 for all wakeup devices when the system is going to sleep or power off, but the current xhci driver doesn't do this properly (partly intentionally). This patch introduces a new quirk, XHCI_SPURIOUS_WAKEUP, for fixing the spurious wakeups at S5 by calling xhci_reset() in the xhci shutdown ops as done in xhci_stop(), and setting the device to PCI D3 at shutdown and remove ops. The PCI D3 call is based on the initial fix patch by Oliver Neukum. [Note: Sarah changed the quirk name from XHCI_HSW_SPURIOUS_WAKEUP to XHCI_SPURIOUS_WAKEUP, since none of the other quirks have system names in them. Sarah also fixed a collision with a quirk submitted around the same time, by changing the xhci->quirks bit from 17 to 18.] This patch should be backported to kernels as old as 3.0, that contain the commit 1c12443ab8eba71a658fae4572147e56d1f84f66 "xhci: Add Lynx Point to list of Intel switchable hosts." Cc: Oliver Neukum Signed-off-by: Takashi Iwai Signed-off-by: Sarah Sharp [bwh: Backported to 3.2: adjust context] Signed-off-by: Ben Hutchings Cc: Yang Yingliang Signed-off-by: Greg Kroah-Hartman

xhci: quirk for extra long delay for S4

2014-04-14T13:44:29Z

commit 455f58925247e8a1a1941e159f3636ad6ee4c90b upstream. It has been reported that this chipset really cannot sleep without this extraordinary delay. This patch should be backported, in order to ensure this host functions under stable kernels. The last quirk for Fresco Logic hosts (commit bba18e33f25072ebf70fd8f7f0cdbf8cdb59a746 "xhci: Extend Fresco Logic MSI quirk.") was backported to stable kernels as old as 2.6.36. Signed-off-by: Oliver Neukum Signed-off-by: Sarah Sharp [bwh: Backported to 3.2: - Adjust context - Use xhci_dbg() instead of xhci_dbg_trace()] Signed-off-by: Ben Hutchings [yangyl: Backported to 3.4: Adjust context] Signed-off-by: Yang Yingliang Signed-off-by: Greg Kroah-Hartman