kernel/linux.git/drivers/usb/host, branch v3.4.55

usb: host: xhci-plat: release mem region while removing module

2013-07-22T01:19:01+00:00

commit 5388a3a5faba8dfa69e5f06c3a415d373c1a4316 upstream. Do a release_mem_region of the hcd resource. Without this the subsequent insertion of module fails in request_mem_region. Signed-off-by: George Cherian Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

xhci: check for failed dma pool allocation

2013-07-22T01:19:01+00:00

commit 025f880cb2e4d7218d0422d4b07bea1a68959c38 upstream. Fail and free the container context in case dma_pool_alloc() can't allocate the raw context data part of it This patch should be backported to kernels as old as 2.6.31, that contain the commit d115b04818e57bdbc7ccde4d0660b15e33013dc8 "USB: xhci: Support for 64-byte contexts". Signed-off-by: Mathias Nyman Signed-off-by: Sarah Sharp Cc: John Youn Signed-off-by: Greg Kroah-Hartman

USB: revert periodic scheduling bugfix

2013-06-13T16:44:57+00:00

commit fdc03438f53a00294ed9939eb3a1f6db6f3d8963 upstream. This patch reverts commit 3e619d04159be54b3daa0b7036b0ce9e067f4b5d (USB: EHCI: fix bug in scheduling periodic split transfers). The commit was valid -- it fixed a real bug -- but the periodic scheduler in ehci-hcd is in such bad shape (especially the part that handles split transactions) that fixing one bug is very likely to cause another to surface. That's what happened in this case; the result was choppy and noisy playback on certain 24-bit audio devices. The only real fix will be to rewrite this entire section of code. My next project... This fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1136110. Thanks to Tim Richardson for extra testing and feedback, and to Joseph Salisbury and Tyson Tan for tracking down the original source of the problem. Signed-off-by: Alan Stern CC: Joseph Salisbury CC: Tim Richardson Signed-off-by: Greg Kroah-Hartman

xhci: fix list access before init

2013-06-13T16:44:51+00:00

commit 88696ae432ce7321540ac53d9caab3de9118b094 upstream. If for whatever reason we fall into fail path in xhci_mem_init() before bw table gets initialized we may access the uninitialized lists in xhci_mem_cleanup(). Check for bw table before traversing lists in cleanup routine. This patch should be backported to kernels as old as 3.2, that contain the commit 839c817ce67178ca3c7c7ad534c571bba1e69ebe "xhci: Store information about roothubs and TTs." Reported-by: Sergey Dyasly Tested-by: Sergey Dyasly Signed-off-by: Vladimir Murzin Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

xhci-mem: init list heads at the beginning of init

2013-06-13T16:44:50+00:00

commit 331de00a64e5027365145bdf51da27b9ce15dfd5 upstream. It is possible that we fail on xhci_mem_init, just before doing the INIT_LIST_HEAD, and calling xhci_mem_cleanup. Problem is that, the list_for_each_entry_safe macro, assumes list heads are initialized (not NULL), and dereferences their 'next' pointer, causing a kernel panic if this is not yet initialized. Let's protect from that by moving inits to the beginning. This patch should be backported to kernels as old as 3.2, that contain the commit 9574323c39d1f8359a04843075d89c9f32d8b7e6 "xHCI: test USB2 software LPM". Signed-off-by: Sergio Aguirre Acked-by: David Cohen Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

xhci - correct comp_mode_recovery_timer on return from hibernate

2013-06-13T16:44:50+00:00

commit 77df9e0b799b03e1d5d9c68062709af5f637e834 upstream. Commit 71c731a2 (usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware) was a workaround for systems using the SN65LVPE502CP, controller, but it introduced a bug in resume from hibernate. The fix created a timer, comp_mode_recovery_timer, which is deleted from a timer list when xhci_suspend() is called. However, the hibernate image, including the timer list containing the comp_mode_recovery_timer, had already been saved before the timer was deleted. Upon resume from hibernate, the list containing the comp_mode_recovery_timer is restored from the image saved to disk, and xhci_resume(), assuming that the timer had been deleted by xhci_suspend(), makes a call to compliance_mode_recoery_timer_init(), which creates a new instance of the comp_mode_recovery_timer and attempts to place it into the same list in which it is already active, thus corrupting the list during the list_add() call. At this point, a call trace is emitted indicating the list corruption. Soon afterward, the system locks up, the watchdog times out, and the ensuing NMI crashes the system. The problem did not occur when resuming from suspend. In suspend, the image in RAM remains exactly as it was when xhci_suspend() deleted the comp_mode_recovery_timer, so there is no problem when xhci_resume() creates a new instance of this timer and places it in the still empty list. This patch avoids the problem by deleting the timer in xhci_resume() when resuming from hibernate. Now xhci_resume() can safely make the call to create a new instance of this timer, whether returning from suspend or hibernate. Thanks to Alan Stern for his help with understanding the problem. [Sarah reworked this patch to cover the case where the xHCI restore register operation fails, and (temp & STS_SRE) is true (and we re-init the host, including re-init for the compliance mode), but hibernate is false. The original patch would have caused list corruption in this case.] This patch should be backported to kernels as old as 3.2, that contain the commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 "usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware" Signed-off-by: Tony Camuso Tested-by: Tony Camuso Acked-by: Don Zickus Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman

USB: UHCI: fix for suspend of virtual HP controller

2013-06-07T19:49:12+00:00

commit 997ff893603c6455da4c5e26ba1d0f81adfecdfc upstream. HP's virtual UHCI host controller takes a long time to suspend (several hundred microseconds), even when no devices are attached. This provokes a warning message from uhci-hcd in the auto-stop case. To prevent this from happening, this patch adds a test to avoid performing an auto-stop when the wait_for_hp quirk flag is set. The controller will still suspend through the normal runtime PM mechanism. And since that pathway includes a 1-ms delay, the slowness of the virtual hardware won't matter. Signed-off-by: Alan Stern Reported-and-tested-by: ZhenHua Signed-off-by: Greg Kroah-Hartman

USB: xHCI: override bogus bulk wMaxPacketSize values

2013-06-07T19:49:12+00:00

commit e4f47e3675e6f1f40906b785b934ce963e9f2eb3 upstream. This patch shortens the logic in xhci_endpoint_init() by moving common calculations involving max_packet and max_burst outside the switch statement, rather than repeating the same code in multiple case-specific statements. It also replaces two usages of max_packet which were clearly intended to be max_burst all along. More importantly, it compensates for a common bug in high-speed bulk endpoint descriptors. In many devices there is a bulk endpoint having a wMaxPacketSize value smaller than 512, which is forbidden by the USB spec. Some xHCI controllers can't handle this and refuse to accept the endpoint. This patch changes the max_packet value to 512, which allows the controller to use the endpoint properly. In practice the bogus maxpacket size doesn't matter, because none of the transfers sent via these endpoints are longer than the maxpacket value anyway. Signed-off-by: Alan Stern Reported-and-tested-by: "Aurélien Leblond" Signed-off-by: Greg Kroah-Hartman

xhci: Don't warn on empty ring for suspended devices.

2013-05-11T20:48:08+00:00

commit a83d6755814e4614ba77e15d82796af0f695c6b8 upstream. When a device attached to the roothub is suspended, the endpoint rings are stopped. The host may generate a completion event with the completion code set to 'Stopped' or 'Stopped Invalid' when the ring is halted. The current xHCI code prints a warning in that case, which can be really annoying if the USB device is coming into and out of suspend. Remove the unnecessary warning. Signed-off-by: Sarah Sharp Tested-by: Stephen Hemminger Cc: Luis Henriques Signed-off-by: Greg Kroah-Hartman

usb: xhci: Fix TRB transfer length macro used for Event TRB.

2013-04-05T17:04:34+00:00

commit 1c11a172cb30492f5f6a82c6e118fdcd9946c34f upstream. Use proper macro while extracting TRB transfer length from Transfer event TRBs. Adding a macro EVENT_TRB_LEN (bits 0:23) for the same, and use it instead of TRB_LEN (bits 0:16) in case of event TRBs. This patch should be backported to kernels as old as 2.6.31, that contain the commit b10de142119a676552df3f0d2e3a9d647036c26a "USB: xhci: Bulk transfer support". This patch will have issues applying to older kernels. Signed-off-by: Vivek gautam Signed-off-by: Sarah Sharp Signed-off-by: Greg Kroah-Hartman