On Tue, Aug 14, 2012 at 11:06:42AM +0800, Bryan Wu wrote: > On Tue, Aug 14, 2012 at 12:15 AM, Pawel Moll <pawel.moll@xxxxxxx> wrote: > > On Mon, 2012-08-13 at 16:47 +0100, Fabio Baltieri wrote: > >> Delay execution of led_set_brightness() if need to stop soft-blink > >> timer. > >> > >> This allows led_set_brightness to be called in hard-irq context even if > >> soft-blink was activated on that LED. > >> > >> Signed-off-by: Fabio Baltieri <fabio.baltieri@xxxxxxxxx> > >> Cc: Pawel Moll <pawel.moll@xxxxxxx> > >> Cc: Bryan Wu <bryan.wu@xxxxxxxxxxxxx> > > > > I've just tried it on my setup and see nothing wrong going on (at least > > at the first sight ;-), so: > > > > Tested-by: Pawel Moll <pawel.moll@xxxxxxx> Thanks for your time! > Fabio, thanks for this beautiful solution, do we need any cleanup for > this workqueue? I maybe worry too much. Uh - you're totally right, I missed misses a cancel_work_sync in the unregister function. Also, I'm running some other tests and I noticed that the patch introduced a bug in trigger change code, which assumes that soft-blink is stopped instantly to reset default timings on activation. I'm currently passing through the code to double check if delaying that part introduced some other race, and I think it's better to move the stop-blink code in a spearate function to call where appropriate to restore the correct behaviour. Also, I'll try to test it a bit more deeply as it's becoming a little frustrating... that lock-less blink code is nice but quite delicate to change. Do you prefer if I send you a separate patch or an incremental one for other fixes on this problem? Fabio -- To unsubscribe from this list: send the line "unsubscribe linux-leds" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
