Re: [PATCH/RFC v6 05/36] leds: Improve setting brightness in a non sleeping way

[Jacek Anaszewski]

On 08/21/2015 10:42 PM, Andrew Lunn wrote:
> > This work queue from led-class.c is used for setting brightness, when
> > blink timer is on. Blinking is the functionality from the LED core,
> > so the work queue should also belong to the core. It should be moved
> > there along with led_timer_function, for consistency reasons. In view
> > of the above, using it for setting brightness by blocking drivers
> > would be correct from the architectural point of view.
>
> So lets assume we are not doing all the changes in a single patch
> set. Its too complex. You say the work queue should be in the
> core. Lets put a work queue in the core to handle the blocking op, and
> strip it out of the drivers. That allows you to get a lot of driver
> patches merged.

Moving the work queue to the core is rather a cosmetic change and it is
not required for adapting it to setting brightness for blocking drivers.
I think that we could postpone the cosmetic changes to the moment when
other essential patches are merged.

Like I explained in the previous message, patches from 1 to 4 are
the minimum of the changes required for removing work queues from
drivers. I am aware that the changes may be hard to analyze, but the
things are entangled together and changes must be done in a few places
simultaneously. Those crucial changes are gathered in the patch [1].
I tried to explain them in the commit messages. Maybe my explanations
weren't comprehensive enough, if so, I'd be glad if you could indicate
what could be added/modified in the description to make it more clear.

> You can then work on moving led_timer_function into the core, etc,
> with a much smaller patch set, and hopefully in a number of small
> steps which are easy to review.
>
>        Andrew

[1] https://lkml.org/lkml/2015/8/11/191
--
Best Regards,
Jacek Anaszewski
--
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/