On 10/21/25 8:53 PM, Joel Selvaraj via B4 Relay wrote: > From: Joel Selvaraj <[email protected]> > > In Xiaomi Poco F1 and at least few other devices, the qcom wled driver > triggers unbalanced ovp irq enable warning like the following during > boot up. > > [ 1.151677] ------------[ cut here ]------------ > [ 1.151680] Unbalanced enable for IRQ 176 > [ 1.151693] WARNING: CPU: 0 PID: 160 at kernel/irq/manage.c:774 > __enable_irq+0x50/0x80 > [ 1.151710] Modules linked in: > [ 1.151717] CPU: 0 PID: 160 Comm: kworker/0:11 Not tainted 5.17.0-sdm845 #4 > [ 1.151724] Hardware name: Xiaomi Pocophone F1 (DT) > [ 1.151728] Workqueue: events wled_ovp_work > ...<snip>... > [ 1.151833] Call trace: > [ 1.151836] __enable_irq+0x50/0x80 > [ 1.151841] enable_irq+0x48/0xa0 > [ 1.151846] wled_ovp_work+0x18/0x24 > [ 1.151850] process_one_work+0x1d0/0x350 > [ 1.151858] worker_thread+0x13c/0x460 > [ 1.151862] kthread+0x110/0x114 > [ 1.151868] ret_from_fork+0x10/0x20 > [ 1.151876] ---[ end trace 0000000000000000 ]--- > > Fix it by storing and checking the state of ovp irq before enabling and > disabling it. > > Signed-off-by: Joel Selvaraj <[email protected]> > --- > I was able to debug the issue a little further. This happens mainly because > devm_request_threaded_irq already enables the ovp irq during probe. Then ovp > work gets scheduled when update_status happens and in turn enables the irq > again. > Tracking the status makes it easy to avoid the double irq enable. But I am > open to try a different approach if there is any suggestion.
Would reverting this change and adding (| IRQF_NO_AUTOEN) to that call fix it? Konrad
