[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140826200208.GA11247@kria>
Date: Tue, 26 Aug 2014 22:02:08 +0200
From: Sabrina Dubroca <sd@...asysnail.net>
To: Valdis.Kletnieks@...edu
Cc: Samuel Thibault <samuel.thibault@...-lyon.org>,
Hugh Dickins <hughd@...gle.com>, akpm@...ux-foundation.org,
Vincent Donnefort <vdonnefort@...il.com>,
Bryan Wu <cooloney@...il.com>, linux-leds@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: [PATCH][input-led] Defer input led work to workqueue
2014-08-26, 14:49:18 -0400, Valdis.Kletnieks@...edu wrote:
> On Tue, 26 Aug 2014 03:54:53 +0200, Samuel Thibault said:
> > This changeset defers the second led_trigger_event call into a
> > workqueue, which avoids the nested locking altogether. This does
> > not prevent the user from shooting himself in the foot by creating a
> > vt::capsl <-> vt-capsl loop, but the only consequence is the workqueue
> > threads eating some CPU until the user breaks the loop, which is not too
> > bad.
> >
> > Signed-off-by: Samuel Thibault <samuel.thibault@...-lyon.org>
> >
> > --- a/drivers/input/leds.c
> > +++ b/drivers/input/leds.c
> > @@ -100,13 +100,25 @@ static unsigned long vt_led_registered[B
>
> I admit having zero understanding of the code, but I can confirm that
> next-20140825 still throws the lockdep whine I was seeing, but the same
> tree with this patch on top of it boots without warning. Soo...
>
> Tested-By: Valdis Kletnieks <valdis.kletnieks@...edu>
Same for me.
Tested-by: Sabrina Dubroca <sd@...asysnail.net>
Thanks,
--
Sabrina
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists