mfd: mc13xxx-core: Initialize the lock prior to using it
PATCH 1/1 mfd: mc13xxx-core: Initialize the lock prior to using it
From: Fabio Estevam <[email protected]>
After request_threaded_irq() is called there is a chance that an interrupt may occur before the 'mc13xxx->lock' is initialized, which will trigger a kernel warning.
In order to prevent that, move the initialization of 'mc13xxx->lock' prior to requesting the interrupts.
--- drivers/mfd/mc13xxx-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/mfd/mc13xxx-core.c +2 -2
@@ -660,13 +660,13 @@ int mc13xxx_common_init(struct device *dev)if (ret)return ret; +mutex_init (&mc13xxx->lock); + ret =request_threaded_irq (mc13xxx->irq,NULL , mc13xxx_irq_thread,IRQF_ONESHOT |IRQF_TRIGGER_HIGH ,"mc13xxx" , mc13xxx);if (ret)return ret; -mutex_init (&mc13xxx->lock); -if (mc13xxx_probe_flags_dt (mc13xxx) <0 && pdata) mc13xxx->flags = pdata->flags;
Signature · 1 line
1.8.3.2
Quoted 5 lines · Fabio Estevam
From: Fabio Estevam <[email protected]>
After
request_threaded_irq()is called there is a chance that an interrupt may occur before the 'mc13xxx->lock' is initialized, which will trigger a kernel warning.
I'd suggest... "which will trigger a kernel oops" because that's what you got - it killed the IRQ thread, which then caused a few other problems along the way.
Quoted 5 lines
In order to prevent that, move the initialization of '
mc13xxx->lock' prior to requesting the interrupts.Suggested-by Russell King <[email protected]>Signed-off-by Fabio Estevam <[email protected]>
Patch looks good, and should fix the reported issue... so with the above description fixed,
Thanks.
Signature · 2 lines
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it.