Re: [PATCH] leds: add LED driver for CR0014114 board

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

Hi!

> > Hmm. Well, this works if you can't provide better names. Still "board"
> > is somehow generic, andsomeone else might want to use it. "board" ->
> > "crms"?
> 
> It's specified in device tree by defining label.
> In my examples:
> board@0 {
>        compatible = "ccs,cr0014114";
>        reg = <0>;
>        spi-max-frequency = <50000>;
>        spi-cpha;
>        label = "board0";
> };
> 
> board@1 {
>        compatible = "ccs,cr0014114";
>        reg = <1>;
>        spi-max-frequency = <50000>;
>        spi-cpha;
>        label = "board1";
> };

Ok, makes sense. How does the board look?

> >>>>>> +	while (i--)
> >>>>>> +		led_classdev_unregister(&priv->leds[i].ldev);
> >>>>>
> >>>>> Can devm_* be used to simplify this?
> >>>>
> >>>> I think no, because it will cause race condition.
> >>>
> >>> Please take a look at devm_led_classdev_register() and friends. It
> >>> should be possible to simplify code without races.
> >>
> >> I don't understand how I can call destroy_workqueue() after calling unregister leds.
> > 
> > Do you actually need the workqueues? It should be possible to avoid
> > them, using workqueue support in the core.
> 
> The delay between data sends to SPI board should be at least 10 ms
> I think it will be bad idea to use shared workqueue from kernel,
> so I create separate single threaded work queue :)

If workqueue support in led core can not take 10 msec wait, we should
fix it, not add hacks around...
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]