On Sun, Jan 20, 2019 at 3:12 PM Jacek Anaszewski
<jacek.anaszewski@xxxxxxxxx> wrote:
> As stated above software blinking implementation in the core
> enforces non-blocking semantics of brightness setting operations.
> Currently we don't have anything similar required for blink
> setting operations.
>
> LED core maintainability is now hindered sufficiently with that
> and also with bad design decision that allowed led_set_brightness()
> to be called from hard irq context
> (d23a22a74fde ("leds: delay led_set_brightness if stopping soft-blink"),
> for which set_brightness_work was introduced initially, and its scope of
> responsibilities was only extended when adding generic support for non
> blocking brightness setting).
>
> Please use in-driver workqueue for calling blink_set().
Aha I see your point clearly now.
I'll create a local delayed work!
Yours,
Linus Walleij
