If a spurious OCP IRQ occurs the isr schedules delayed work
but does not disable the IRQ. The delayed work assumes IRQ was
disabled in handler and attempts enabling it again causing
unbalanced enable.
Fixes: 390af53e04114 ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs")
Signed-off-by: Matti Vaittinen <matti.vaittinen@xxxxxxxxxxxxxxxxx>
---
This fix is done purely based on code reading. No testing is done.
I don't have the HW (and even if I did I might have hard time producing
these errors) I have not tested this and I am unsure if my code-reading
is correct => I would _really_ appreciate second opinion and/or testing
drivers/regulator/qcom-labibb-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/qcom-labibb-regulator.c b/drivers/regulator/qcom-labibb-regulator.c
index dbb4511c3c6d..5ac4566f9b7f 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -275,7 +275,7 @@ static irqreturn_t qcom_labibb_ocp_isr(int irq, void *chip)
ret = qcom_labibb_check_ocp_status(vreg);
if (ret == 0) {
vreg->ocp_irq_count = 0;
- goto end;
+ return IRQ_NONE;
}
vreg->ocp_irq_count++;
base-commit: 4288b4ccda966c2a49ec7c67100208378bdb34d2
--
2.25.4
--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND
~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~
Simon says - in Latin please.
~~~ "non cogito me" dixit Rene Descarte, deinde evanescavit ~~~
Thanks to Simon Glass for the translation =]
