[+Olof who had mentioned lock recursion BUG in -next] On Tue, Sep 3, 2013 at 5:10 AM, Linus Walleij <[email protected]> wrote: > On Tue, Sep 3, 2013 at 12:39 PM, Thierry Reding > <[email protected]> wrote: > >> Return an error if neither the ->set() nor the ->set_debounce() function >> is implemented by the chip. Furthermore move locking further down so the >> lock doesn't have to be unlocked on error. This is safe to do because at >> this point the lock doesn't protect anything. >> >> Signed-off-by: Thierry Reding <[email protected]> >> --- >> Linus, >> >> Feel free to squash this into the commit that introduced these: >> >> fc9bbfb: gpio: improve error path in gpiolib > > Hm I fixed part of this bug yesterday, but screwed up and left the dangling > spinlock in there, what is wrong with me :-( > > Anyway, fixed it _finally_ now, thanks to you.
Exiting without unlocking was causing a lock recurision lockup in next-20130903 on exynos5/arndale. I just verified that moving the spinlock down as propsed here fixes the problem in -next. Thanks, Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
