On Mon, Aug 13, 2012 at 11:46 PM, Fabio Baltieri
<fabio.baltieri@xxxxxxxxx> wrote:
> On Mon, Aug 13, 2012 at 02:38:06PM +0800, Bryan Wu wrote:
>> Thanks I applied to my fixes-for-3.6 and will push to Linus soon.
>
> Thanks Bryan, that was fast... hope you did not get too many mails for
> that bug, sorry about that!
>
> Anyway, I was able to work a bit more on the problem in the meantime so
> I'm posting another patch for you to consider.
>
> That restores back the call to led_set_brightness() as the original
> patch, but changes led_set_brightness() code to delay the setting to a
> delayed_work if a soft-blink trigger was enabled.
>
> The check uses blink_delay_{on,off} variables to decide if
> del_timer_sync() has to be called before setting new brightness value,
> that should be ok as those two variables are only wrote by
> led_set_software_blink (and the timer is going to do nothing if those
> are zero anyway).
>
> So, this version falls back to calling __led_set_brightness directly in
> the "normal" case and always runs a delayed_work to stop soft-blink AND
> call __led_set_brightness if the trigger mixes set and set-blink calls.
> That should make it hard-irq proof.
>
> That was tested on an UP x86 with CONFIG_SMP=y and using a mix of
> led_trigger_blink_oneshot() and led_trigger_event() from hard-irq
> context.
>
> Do you think this fix is acceptable?
>
Thanks Fabio, I think this solution is good and I merged your patch
before I saw this email.
-Bryan
--
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
