Re: introduce delayed-leds.h to reduce code duplication

[Richard Purdie]

On Tue, 2009-01-20 at 10:04 -0200, Henrique de Moraes Holschuh wrote:
> I don't like the loss of functionality of the private workqueue.  I kicked
> the thinkpad led handling to a private workqueue in order to never tie up
> the system-wide one with crap spinning around in the ACPI layer, etc.  In
> fact, all thinkpad-acpi deferred work is in the private workqueue for this
> reason.
> 
> This is easy enough to fix, you just need to provide both versions of the
> interface (standard workqueue, and private workqueue).  OTOH, if nowadays
> the system-wide workqueue runs tasks in parallel and there is no risk of a
> task blocking others from completely unrelated subsystems, I can ditch the
> private workqueue.
> 
> Also, if it is going to be generic, I'd suggest the usual "void *data"
> opaque type to carry information for the driver, instead of a "led number".
> 
> I didn't see any comments from Richard, but your comment about a flag seems
> to imply there was a private one?  IMHO enhancing the led class would be the
> best way to go about it, although deferred leds are simple enough that it
> doesn't matter much.

I think the best approach is to get this header working and then see how
many people can really share it. If its common enough we can add to the
core but lets see if its a useful abstraction first?

Cheers,

Richard

-- 
Richard Purdie
Intel Open Source Technology Centre

--
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/