Messages in this thread | | | From | "Kim, Milo" <> | Subject | RE: [PATCH 2/4] leds-lp5523: set the brightness to 0 forcely on removing the driver | Date | Wed, 22 Aug 2012 05:46:21 +0000 |
| |
> 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
| |