RE: [PATCH 2/4] leds-lp5523: set the brightness to 0 forcely onremoving the driver

From: Kim, Milo
Date: Wed Aug 22 2012 - 01:47:12 EST


> Hmmm, I think we still should use cancel_work() here based on your
> idea. Please find the patch from Tejun and add him to this loop
> [PATCH 4/6] workqueue: deprecate flush[_delayed]_work_sync()
> ---
> Before this patchset,
>
> flush_work()
>
> flush the last queued instance of the work item. If it got
> queued on multple CPUs, it only considers the last queued
> instance. The work item could still be executing on other
> CPUs and the flush might become noop if there are competing
> queueing operation on another CPU.
>
> flush_work_sync()
>
> flush_work() + wait for executing instances on all CPUs. The
> flush_work() part may still become noop if there's competing
> queueing operation.
>
> cancel_work()
>
> Dequeue the work item if it's pending. Doesn't care about
> whether it's executing or not.
>
> cancel_work_sync()
>
> cancel_work() + flush_work_sync().
>
>
> After this patchset,
>
> flush_work()
>
> flush the work item. Any queueing happened previously is
> guaranteed to have finished execution on return. If no
> further queueing happened after flush started, the work item
> is guaranteed to be idle on return.
>
> cancel_work()
>
> Same as before.
>
> cancel_work_sync()
>
> cancel_work() followed by flush_work(). The same semantics as
> del_timer_sync().
> ---
>
> cancel_work_sync() won't execute the work item at all just cancel
> them, but flush will execute them and return.
>

Thanks a lot for the updates!

Then, I think flush_work() should be used for executing remaining brightness work
rather than cancel_work_sync().

Best Regards,
Milo



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/