On 19.08.2015 22:08, Geert Uytterhoeven wrote: > Hi Krzysztof, > > On Wed, Jun 10, 2015 at 8:23 AM, Krzysztof Kozlowski > <k.kozlow...@samsung.com> wrote: >> Add lockdep_assert_held_once() to functions explicitly mentioning that >> rdev or regulator_list mutex must be held. Using WARN_ONCE shouldn't >> pollute the dmesg to much. >> >> The patch (if CONFIG_LOCKDEP enabled) will show warnings in certain >> regulators calling regulator_notifier_call_chain() without rdev->mutex >> held. >> >> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com> >> >> --- >> >> Warnings for missing locks when calling regulator_notifier_call_chain() >> should appear on many regulators except wm8350-regulator.c, e.g.: >> da9055-regulator.c, da9062-regulator.c, da9063-regulator.c, >> da9211-regulator.c, wm831x-dcdc.c and few more. >> >> The question is whether the lock during that call should be held? > > That was a (so far, not counting the "Applied, thanks!") unanswered question? > > For the first time ever, I got: > > drivers/regulator/core.c:3480 > regulator_notifier_call_chain+0x54/0x80() > > due to da9210_irq_handler() not taking the mutex. > > Drivers calling regulator_notifier_call_chain() from a threaded interrupt > handler should be OK calling mutex_lock(). > > Does anyone have plans to fix all affected drivers?
Question is still unanswered. I don't have plans to fix the drivers because I don't have necessary hardware. Blindly fixing such minor issue could do more harm than good. I just polluted the dmesg with WARN hoping that this will wake up someone :) . Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
