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.
Suggested-by: Russell King <[email protected]>
Signed-off-by: Fabio Estevam <[email protected]>
---
drivers/mfd/mc13xxx-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
index 06e64b6..9e296c4 100644
--- a/drivers/mfd/mc13xxx-core.c
+++ b/drivers/mfd/mc13xxx-core.c
@@ -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;
--
1.8.3.2
On Tue, Apr 15, 2014 at 07:43:10PM -0300, Fabio Estevam wrote:
> 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.
> 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,
Acked-by: Russell King <[email protected]>
Thanks.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.