linux-kernel - Re: [PATCH RFT] leds: blinkm: Don't init a workqueue per brightness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 30 Oct 2012 21:52:20 -0700
From:	Bryan Wu <cooloney@...il.com>
To:	Axel Lin <axel.lin@...ics.com>
Cc:	Jan-Simon Moeller <jansimon.moeller@....de>,
	Richard Purdie <rpurdie@...ys.net>, linux-leds@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFT] leds: blinkm: Don't init a workqueue per
 brightness_set call

On Tue, Oct 30, 2012 at 8:49 PM, Axel Lin <axel.lin@...ics.com> wrote:
>
>
> 2012/10/29 Axel Lin <axel.lin@...ics.com>
>>
>> Calling INIT_WORK in blinkm_led_common_set() means we init a workqueue
>> every time
>> when brightness_set callback is called.
>> Move INIT_WORK to blinkm_probe() so we only need to init the workqueue
>> once.
>>
>> So we only need to init a workqueue per blinkm led rather than init a
>> workqueue
>> per brightness_set call.
>
>
> Ah. the commit log and subject line is wrong.
> We are using the global workqueue.
> What the patch does is to avoid init work rather than workqueue per
> brightness_set call.
> We just need to call INIT_WORK once for the first time that structure is set
> up.
>
> There should be no functional change with this patch.
>
> Regards,
> Axel

Right, I think I did same review when this driver posted on the list firstly.
Probably it is a hardware issue. So let Jan-Simon give us some updates.

If the hardware requires this specific handling, I suggest we add some
comments or documents to clarify that.

Thanks,
-Bryan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/