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

["Kim, Milo" <Milo.Kim@ti.com>]

> 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