kernel.git/drivers/usb/musb, branch linux-4.10.y

usb: musb: fix possible spinlock deadlock

2017-03-31T08:33:43Z

commit bc1e2154542071e3cfe1734b143af9b8bdacf8bd upstream. The DSPS glue calls del_timer_sync() in its musb_platform_disable() implementation, which requires the caller to not hold a lock. But musb_remove() calls musb_platform_disable() will musb->lock held. This could causes spinlock deadlock. So change musb_remove() to call musb_platform_disable() without holds musb->lock. This doesn't impact the musb_platform_disable implementation in other glue drivers. root@am335x-evm:~# modprobe -r musb-dsps [ 126.134879] musb-hdrc musb-hdrc.1: remove, state 1 [ 126.140465] usb usb2: USB disconnect, device number 1 [ 126.146178] usb 2-1: USB disconnect, device number 2 [ 126.416985] musb-hdrc musb-hdrc.1: USB bus 2 deregistered [ 126.423943] [ 126.425525] ====================================================== [ 126.431997] [ INFO: possible circular locking dependency detected ] [ 126.438564] 4.11.0-rc1-00003-g1557f13bca04-dirty #77 Not tainted [ 126.444852] ------------------------------------------------------- [ 126.451414] modprobe/778 is trying to acquire lock: [ 126.456523] (((&glue->timer))){+.-...}, at: [] del_timer_sync+0x0/0xd0 [ 126.464403] [ 126.464403] but task is already holding lock: [ 126.470511] (&(&musb->lock)->rlock){-.-...}, at: [] musb_remove+0x50/0x1 30 [musb_hdrc] [ 126.479965] [ 126.479965] which lock already depends on the new lock. [ 126.479965] [ 126.488531] [ 126.488531] the existing dependency chain (in reverse order) is: [ 126.496368] [ 126.496368] -> #1 (&(&musb->lock)->rlock){-.-...}: [ 126.502968] otg_timer+0x80/0xec [musb_dsps] [ 126.507990] call_timer_fn+0xb4/0x390 [ 126.512372] expire_timers+0xf0/0x1fc [ 126.516754] run_timer_softirq+0x80/0x178 [ 126.521511] __do_softirq+0xc4/0x554 [ 126.525802] irq_exit+0xe8/0x158 [ 126.529735] __handle_domain_irq+0x58/0xb8 [ 126.534583] __irq_usr+0x54/0x80 [ 126.538507] [ 126.538507] -> #0 (((&glue->timer))){+.-...}: [ 126.544636] del_timer_sync+0x40/0xd0 [ 126.549066] musb_remove+0x6c/0x130 [musb_hdrc] [ 126.554370] platform_drv_remove+0x24/0x3c [ 126.559206] device_release_driver_internal+0x14c/0x1e0 [ 126.565225] bus_remove_device+0xd8/0x108 [ 126.569970] device_del+0x1e4/0x308 [ 126.574170] platform_device_del+0x24/0x8c [ 126.579006] platform_device_unregister+0xc/0x20 [ 126.584394] dsps_remove+0x14/0x30 [musb_dsps] [ 126.589595] platform_drv_remove+0x24/0x3c [ 126.594432] device_release_driver_internal+0x14c/0x1e0 [ 126.600450] driver_detach+0x38/0x6c [ 126.604740] bus_remove_driver+0x4c/0xa0 [ 126.609407] SyS_delete_module+0x11c/0x1e4 [ 126.614252] __sys_trace_return+0x0/0x10 Fixes: ea2f35c01d5ea ("usb: musb: Fix sleeping function called from invalid context for hdrc glue") Acked-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

usb: musb: cppi41: don't check early-TX-interrupt for Isoch transfer

2017-03-30T07:44:05Z

commit 0090114d336a9604aa2d90bc83f20f7cd121b76c upstream. The CPPI 4.1 driver polls register to workaround the premature TX interrupt issue, but it causes audio playback underrun when triggered in Isoch transfers. Isoch doesn't do back-to-back transfers, the TX should be done by the time the next transfer is scheduled. So skip this polling workaround for Isoch transfer. Fixes: a655f481d83d6 ("usb: musb: musb_cppi41: handle pre-mature TX complete interrupt") Reported-by: Alexandre Bailon Acked-by: Sebastian Andrzej Siewior Tested-by: Alexandre Bailon Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

usb: musb: da8xx: Remove CPPI 3.0 quirk and methods

2017-03-12T05:44:16Z

commit a994ce2d7e66008381a0b184c73be9ae9b72eb5c upstream. DA8xx driver is registering and using the CPPI 3.0 DMA controller but actually, the DA8xx has a CPPI 4.1 DMA controller. Remove the CPPI 3.0 quirk and methods. Fixes: f8e9f34f80a2 ("usb: musb: Fix up DMA related macros") Fixes: 7f6283ed6fe8 ("usb: musb: Set up function pointers for DMA") Signed-off-by: Alexandre Bailon Acked-by: Sergei Shtylyov Acked-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix external abort on non-linefetch for musb_irq_work()

2017-01-25T10:02:29Z

While testing musb host mode cable plugging on a BeagleBone, I came across this error: Unhandled fault: external abort on non-linefetch (0x1008) at 0xd1dcfc60 ... [] (musb_default_readb [musb_hdrc]) from [] (musb_irq_work+0x1c/0x180 [musb_hdrc]) [] (musb_irq_work [musb_hdrc]) from [] (process_one_work+0x2b4/0x808) [] (process_one_work) from [] (worker_thread+0x3c/0x550) [] (worker_thread) from [] (kthread+0x104/0x148) [] (kthread) from [] (ret_from_fork+0x14/0x24) Signed-off-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix host mode error -71 regression

2017-01-25T10:02:29Z

Commit 467d5c980709 ("usb: musb: Implement session bit based runtime PM for musb-core") started implementing musb generic runtime PM support by introducing devctl register session bit based state control. This caused a regression where if a USB mass storage device is connected to a USB hub, we can get: usb 1-1: reset high-speed USB device number 2 using musb-hdrc usb 1-1: device descriptor read/64, error -71 usb 1-1.1: new high-speed USB device number 4 using musb-hdrc This is because before the USB storage device is connected, musb is in OTG_STATE_A_SUSPEND. And we currently only set need_finish_resume in musb_stage0_irq() and the related code calling finish_resume_work in musb_resume() and musb_runtime_resume() never gets called. To fix the issue, we can call schedule_delayed_work() directly in musb_stage0_irq() to have finish_resume_work run. And we should no longer never get interrupts when when suspended. We have changed musb to no longer need pm_runtime_irqsafe(). The need_finish_resume flag was added in commit 9298b4aad37e ("usb: musb: fix device hotplug behind hub") and no longer applies as far as I can tell. So let's just remove the earlier code that no longer is needed. Fixes: 467d5c980709 ("usb: musb: Implement session bit based runtime PM for musb-core") Reported-by: Bin Liu Signed-off-by: Tony Lindgren Signed-off-by: Bin Liu Cc: stable Signed-off-by: Greg Kroah-Hartman

usb: musb: fix runtime PM in debugfs

2017-01-10T17:26:19Z

MUSB driver now has runtime PM support, but the debugfs driver misses the PM _get/_put() calls, which could cause MUSB register access failure. Cc: stable@vger.kernel.org # 4.9+ Acked-by: Tony Lindgren Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

usb: musb: blackfin: add bfin_fifo_offset in bfin_ops

2017-01-05T18:18:05Z

The function bfin_fifo_offset is defined but not used: drivers/usb/musb/blackfin.c:36:12: warning: ‘bfin_fifo_offset’ defined but not used [-Wunused-function] static u32 bfin_fifo_offset(u8 epnum) ^~~~~~~~~~~~~~~~ Adding bfin_fifo_offset to bfin_ops fixes this warning and allows musb core to call this function instead of default_fifo_offset. Fixes: cc92f6818f6e ("usb: musb: Populate new IO functions for blackfin") Signed-off-by: Jérémy Lefaure Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

usb: musb: fix compilation warning on unused function

2017-01-05T18:18:05Z

The function musb_run_resume_work is called only when CONFIG_PM is enabled. So this function should not be defined when CONFIG_PM is disabled. Otherwise the compiler issues a warning: drivers/usb/musb/musb_core.c:2057:12: error: ‘musb_run_resume_work’ defined but not used [-Werror=unused-function] static int musb_run_resume_work(struct musb *musb) ^~~~~~~~~~~~~~~~~~~~ Signed-off-by: Jérémy Lefaure Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

usb: musb: Fix trying to free already-free IRQ 4

2017-01-05T18:18:05Z

When unloading omap2430, we can get the following splat: WARNING: CPU: 1 PID: 295 at kernel/irq/manage.c:1478 __free_irq+0xa8/0x2c8 Trying to free already-free IRQ 4 ... [] (free_irq) from [] (musbhs_dma_controller_destroy+0x28/0xb0 [musb_hdrc]) [] (musbhs_dma_controller_destroy [musb_hdrc]) from [] (musb_remove+0xf0/0x12c [musb_hdrc]) [] (musb_remove [musb_hdrc]) from [] (platform_drv_remove+0x24/0x3c) ... This is because the irq number in use is 260 nowadays, and the dma controller is using u8 instead of int. Fixes: 6995eb68aab7 ("USB: musb: enable low level DMA operation for Blackfin") Signed-off-by: Tony Lindgren [b-liu@ti.com: added Fixes tag] Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman

usb: musb: dsps: implement clear_ep_rxintr() callback

2017-01-05T18:18:05Z

During dma teardown for dequque urb, if musb load is high, musb might generate bogus rx ep interrupt even when the rx fifo is flushed. In such case any of the follow log messages could happen. musb_host_rx 1853: BOGUS RX2 ready, csr 0000, count 0 musb_host_rx 1936: RX3 dma busy, csr 2020 As mentioned in the current inline comment, clearing ep interrupt in the teardown path avoids the bogus interrupt, so implement clear_ep_rxintr() callback. This bug seems to be existing since the initial driver for musb support, but I only validated the fix back to v4.1, so only cc stable for v4.1+. cc: stable@vger.kernel.org # 4.1+ Signed-off-by: Bin Liu Signed-off-by: Greg Kroah-Hartman