linux-kernel - Re: [PATCH/RFC v2 1/5] leds: Use set_brightness_work for 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 01 Jul 2015 11:52:11 +0200
From:	Jacek Anaszewski <j.anaszewski@...sung.com>
To:	Sakari Ailus <sakari.ailus@....fi>
Cc:	linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
	cooloney@...il.com, rpurdie@...ys.net, stsp@...rs.sourceforge.net,
	pavel@....cz, sakari.ailus@...ux.intel.com, andreas.werner@....de,
	andrew@...n.ch, ospite@...denti.unina.it, anemo@....ocn.ne.jp,
	ben@...tec.co.uk, bootc@...tc.net, dmurphy@...com,
	daniel.jeong@...com, daniel@...que.org, davem@...emloft.net,
	fabio.baltieri@...il.com, balbi@...com, florian@...nwrt.org,
	gshark.jeong@...il.com, g.liakhovetski@....de,
	ingi2.kim@...sung.com, dl9pf@....de, johan@...nel.org,
	lenz@...wisc.edu, jogo@...nwrt.org, q1.kim@...sung.com,
	kris@...sk.org, kristoffer.ericson@...il.com,
	linus.walleij@...aro.org, broonie@...nel.org,
	michael.hennerich@...log.com, milo.kim@...com, nm127@...email.hu,
	ncase@...-inc.com, neilb@...e.de, nick.forbes@...epta.com,
	lost.distance@...oo.com, p.meerwald@...-electronic.com,
	n0-1@...ewrt.org, philippe.retornaz@...l.ch, raph@...com,
	rpurdie@...nedhand.com, rod@...tby.id.au, dave@...1.net,
	giometti@...ux.it, bigeasy@...utronix.de, shuahkhan@...il.com,
	sguinot@...ie.com
Subject: Re: [PATCH/RFC v2 1/5] leds: Use set_brightness_work for
 brightness_set ops that can sleep

Hi Sakari,

On 07/01/2015 12:24 AM, Sakari Ailus wrote:
> Hi Jacek,
>
> On Tue, Jun 30, 2015 at 03:59:26PM +0200, Jacek Anaszewski wrote:
>> This patch rearranges the core LED subsystem code, so that it
>> now shifts the responsibility for using work queues from drivers,
>> in case their brightness_set ops can sleep, onto the LED core
>> Addition of two flags: LED_BRIGHTNESS_FAST and LED_BLINK_DISABLE
>> as well as new_brightness_value property to the struct led_classdev
>> allows for employing existing set_brightness_work to do the job.
>> The modifications allows also to get rid of brightness_set_sync op,
>> as flash LED devices can now be handled properly only basing on the
>> SET_BRIGHTNESS_SYNC flag.
>
> Nice patch! Thanks!
>
> Looks like this is the favourite topic nowadays. ;-)

Yeah, this allows to believe that we will manage to tackle the issue
finally :)

> The documentation should be improved to tell how the API is expected to be
> have, e.g. which functions may block. I think this is out of scope for this
> patch though.

Yes, I planned to cover this after the patch is accepted.

> I think all the existing drivers that implement the set_brightness()
> callback have a fast (and non-blocking) implementation, and some of these
> drivers use a work queue. In order to avoid modifying those drivers right
> now, how about adding a flag for slow devices instead? "Slow" handlers
> should be those that do at least one of the following: 1) sleep and 2) take
> excessive amount of time to run.

As Andrew Lunn mentioned, he was also working on this issue and he did
the vast majority of work [1] needed to remove work queues from existing
drivers. Only new flags would have to be added.

> How about splitting the patch as follows:
>
> - set_brightness()/set_brightness_sync() -> set_brightness() +
>    LED_BRIGHTNESS_FAST + slow handlers in a work queue,
> - add LED_BLINK_DISABLE flag,
> - fix the heartbeat trigger (it's sleeping in a timer if LED_BRIGHTNESS_SYNC
>    is set).

With my solution heartbeat trigger is not sleeping even if
LED_BRIGHTNESS_SYNC is set as all triggers use the new function -
led_set_brightness_nosleep.

> I'd propose to drop led_set_brightness_async() and just make
> led_set_brightness() asynchronous (or non-blocking if you wish) as it was
> before the LED flash class patches. Considering the nature and tradition of
> the framework, that's probably how most users want it to be. One can always
> use led_set_brightness_sync() if needed.
>
> The caller should indeed decide whether the operation is synchronous or not,
> that's not really a property of the LED. I requested that for the V4L2
> framework due to the very different use cases that are typical for the LED
> class devices.
>
> I have some patches along these lines, but I probably won't have much time
> to work on them, and I can rebase mine on yours later on. If you're
> interested in taking a peek they're here:
>
> <URL:http://salottisipuli.retiisi.org.uk/cgi-bin/gitweb.cgi?p=~sailus/linux.git;a=shortlog;h=refs/heads/leds-as3645a>

I've skimmed through the patches and I find them valuable.
Could you elaborate on the patch
"leds: Serialise access to LED framework data and drivers",
what problem does it solve?

>
> As the result the as3645a driver is quite a bit smaller than the V4L2
> sub-device one, which is a good sign. :-)
>

[1] https://github.com/lunn/linux.git 3.19-rc4-led-devel-workqueue

-- 
Best Regards,
Jacek Anaszewski
--
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/