lkml.org 
[lkml]   [2012]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH 2/4] leds-lp5523: set the brightness to 0 forcely on removing the driver
On Wed, Aug 22, 2012 at 1:46 PM, Kim, Milo <Milo.Kim@ti.com> wrote:
>> 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().
>

Yeah, I agree here. I made a mistake about your original patch's description.

-Bryan


\
 
 \ /
  Last update: 2012-08-22 10:01    [W:1.327 / U:0.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site