The lockdep mechanism reveals an unbalanced unlocking on MT8186:
[ 2.993966] WARNING: bad unlock balance detected! [ 2.993971] 5.15.46-421fef3b44d7-lockdep #16 Not tainted [ 2.993978] ------------------------------------- [ 2.993983] kworker/u16:1/10 is trying to release lock (gpio_request_mutex) at: [ 2.993994] [<ffffffdcd9adebf8>] mt8186_afe_gpio_request+0xf8/0x210 [ 2.994012] but there are no more locks to release! [ 2.994017] [ 2.994017] other info that might help us debug this: [ 2.994022] 3 locks held by kworker/u16:1/10: [ 2.994028] #0: ffffff80c004a148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1a8/0x364 [ 2.994054] #1: ffffffc0080d3d58 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1d0/0x364 [ 2.994074] #2: ffffff80c12ab9a0 (&dev->mutex){....}-{3:3}, at: __device_attach+0x44/0x150 [ 2.994096] [ 2.994096] stack backtrace: [ 2.994102] CPU: 6 PID: 10 Comm: kworker/u16:1 Not tainted 5.15.46-421fef3b44d7-lockdep #16 a2af0e2c6b3eeab6799b5aa8091c1d05d3a7bbb1 [ 2.994113] Hardware name: Google Kingler board (DT) [ 2.994120] Workqueue: events_unbound deferred_probe_work_func [ 2.994130] Call trace: [ 2.994135] dump_backtrace+0x0/0x1d4 [ 2.994144] show_stack+0x20/0x2c [ 2.994152] dump_stack_lvl+0x78/0x9c [ 2.994163] dump_stack+0x18/0x44 [ 2.994172] print_unlock_imbalance_bug+0xf0/0xf4 [ 2.994184] lock_release+0x150/0x388 [ 2.994193] __mutex_unlock_slowpath+0x4c/0x1bc [ 2.994202] mutex_unlock+0x44/0x50 [ 2.994210] mt8186_afe_gpio_request+0xf8/0x210 [ 2.994220] mt8186_afe_gpio_init+0xcc/0x134 [ 2.994230] mt8186_mt6366_rt1019_rt5682s_dev_probe+0x14c/0x220 [ 2.994238] platform_probe+0xb0/0xd0 [ 2.994247] really_probe+0xcc/0x2c8 [ 2.994253] __driver_probe_device+0xbc/0xe8 [ 2.994264] driver_probe_device+0x48/0xf0 [ 2.994271] __device_attach_driver+0xa0/0xc8 [ 2.994278] bus_for_each_drv+0x8c/0xd8 [ 2.994288] __device_attach+0xc4/0x150 [ 2.994298] device_initial_probe+0x1c/0x28 [ 2.994308] bus_probe_device+0x3c/0xa0 [ 2.994318] deferred_probe_work_func+0xa0/0xe0 [ 2.994325] process_one_work+0x208/0x364 [ 2.994334] worker_thread+0x288/0x3fc [ 2.994343] kthread+0x140/0x160 [ 2.994351] ret_from_fork+0x10/0x20
The cause is that the mutex will be double unlocked if dai is unknown during GPIO selection, and this patch fixes it.
Fixes: cfa9a966f12a ("ASoC: mediatek: mt8186: support gpio control in platform driver")
Signed-off-by: Fei Shao fshao@chromium.org ---
sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 1 - 1 file changed, 1 deletion(-)
diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c index 255ffba637d3..274c0c8ec2f2 100644 --- a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c +++ b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c @@ -230,7 +230,6 @@ int mt8186_afe_gpio_request(struct device *dev, bool enable, sel = enable ? MT8186_AFE_GPIO_PCM_ON : MT8186_AFE_GPIO_PCM_OFF; break; default: - mutex_unlock(&gpio_request_mutex); dev_err(dev, "%s(), invalid dai %d\n", __func__, dai); goto unlock; }