phy: rockchip-inno-usb2: fix possibe deadlock
The commit
611ec35fa148 ("phy: rockchip-inno-usb2: fix some
race conditions") use mutex lock to protect charger detect
work, but it will cause the following possible deadlock.
[ INFO: possible circular locking dependency detected ]
4.4.66 #563 Not tainted
-------------------------------------------------------
kworker/3:1/145 is trying to acquire lock:
(&rport->mutex){+.+...}, at: [<
ffffff80083f286c>] rockchip_chg_detect_work+0x6c/0x3d0
but task is already holding lock:
((&(&rport->chg_work)->work)){+.+...}, at: [<
ffffff80080be6e4>] process_one_work+0x1c4/0x6ac
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 ((&(&rport->chg_work)->work)){+.+...}:
[<
ffffff80080fda40>] __lock_acquire+0x15c0/0x195c
[<
ffffff80080fe5e8>] lock_acquire+0x190/0x250
[<
ffffff80080bf534>] flush_work+0x4c/0x274
[<
ffffff80080bf944>] __cancel_work_timer+0x130/0x1c0
[<
ffffff80080bf9fc>] cancel_delayed_work_sync+0x10/0x18
[<
ffffff80083f17a8>] rockchip_usb2phy_exit+0x54/0x6c
[<
ffffff80083f07ac>] phy_exit+0x64/0xb4
[<
ffffff8008772810>] dwc3_core_exit+0x44/0x98
[<
ffffff80087728b0>] dwc3_suspend_common+0x4c/0x5c
[<
ffffff8008772a68>] dwc3_runtime_suspend+0x38/0x5c
[<
ffffff8008571784>] pm_generic_runtime_suspend+0x28/0x38
[<
ffffff8008573464>] __rpm_callback+0x40/0x74
[<
ffffff80085734f4>] rpm_callback+0x5c/0x80
[<
ffffff8008573bc4>] rpm_suspend+0x31c/0x688
[<
ffffff80085751ec>] __pm_runtime_suspend+0x58/0xa4
[<
ffffff800877efc0>] dwc3_rockchip_probe+0x3f8/0x574
[<
ffffff800856bcd0>] platform_drv_probe+0x58/0xa4
[<
ffffff8008569bb0>] driver_probe_device+0x118/0x2b0
[<
ffffff8008569e9c>] __device_attach_driver+0x88/0x98
[<
ffffff8008567f4c>] bus_for_each_drv+0x7c/0xac
[<
ffffff80085699e4>] __device_attach+0xa8/0x128
[<
ffffff800856a00c>] device_initial_probe+0x10/0x18
[<
ffffff8008569000>] bus_probe_device+0x2c/0x90
[<
ffffff800856948c>] deferred_probe_work_func+0x78/0xa8
[<
ffffff80080be858>] process_one_work+0x338/0x6ac
[<
ffffff80080bfd54>] worker_thread+0x300/0x428
[<
ffffff80080c5758>] kthread+0x104/0x10c
[<
ffffff8008083080>] ret_from_fork+0x10/0x50
-> #0 (&rport->mutex){+.+...}:
[<
ffffff80080faacc>] print_circular_bug+0x64/0x2c4
[<
ffffff80080fd70c>] __lock_acquire+0x128c/0x195c
[<
ffffff80080fe5e8>] lock_acquire+0x190/0x250
[<
ffffff8008c67ac0>] mutex_lock_nested+0x80/0x3d0
[<
ffffff80083f286c>] rockchip_chg_detect_work+0x6c/0x3d0
[<
ffffff80080be858>] process_one_work+0x338/0x6ac
[<
ffffff80080bfd54>] worker_thread+0x300/0x428
[<
ffffff80080c5758>] kthread+0x104/0x10c
[<
ffffff8008083080>] ret_from_fork+0x10/0x50
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((&(&rport->chg_work)->work));
lock(&rport->mutex);
lock((&(&rport->chg_work)->work));
lock(&rport->mutex);
*** DEADLOCK ***
2 locks held by kworker/3:1/145:
stack backtrace:
CPU: 3 PID: 145 Comm: kworker/3:1 Not tainted 4.4.66 #563
Hardware name: Rockchip RK3399 Evaluation Board v3 (Android) (DT)
Workqueue: events rockchip_chg_detect_work
Call trace:
[<
ffffff800808a814>] dump_backtrace+0x0/0x1c8
[<
ffffff800808a9f0>] show_stack+0x14/0x1c
[<
ffffff80083c1fa0>] dump_stack+0xb0/0xec
[<
ffffff80080fad10>] print_circular_bug+0x2a8/0x2c4
[<
ffffff80080fd70c>] __lock_acquire+0x128c/0x195c
[<
ffffff80080fe5e8>] lock_acquire+0x190/0x250
[<
ffffff8008c67ac0>] mutex_lock_nested+0x80/0x3d0
[<
ffffff80083f286c>] rockchip_chg_detect_work+0x6c/0x3d0
[<
ffffff80080be858>] process_one_work+0x338/0x6ac
[<
ffffff80080bfd54>] worker_thread+0x300/0x428
[<
ffffff80080c5758>] kthread+0x104/0x10c
[<
ffffff8008083080>] ret_from_fork+0x10/0x50
Change-Id: I4289afb05d334bf79000090f9071cf428817a583
Signed-off-by: William Wu <william.wu@rock-chips.com>