Message-ID: <20150630174619.GA1852@amd>
Date:	Tue, 30 Jun 2015 19:46:19 +0200
From:	Pavel Machek <pavel@....cz>
To:	Jacek Anaszewski <j.anaszewski@...sung.com>
Cc:	linux-leds@...r.kernel.org, linux-kernel@...r.kernel.org,
	Bryan Wu <cooloney@...il.com>,
	Richard Purdie <rpurdie@...ys.net>,
	Stas Sergeev <stsp@...rs.sourceforge.net>,
	Sakari Ailus <sakari.ailus@...ux.intel.com>,
	Andreas Werner <andreas.werner@....de>,
	Andrew Lunn <andrew@...n.ch>,
	Antonio Ospite <ospite@...denti.unina.it>,
	Atsushi Nemoto <anemo@....ocn.ne.jp>,
	Ben Dooks <ben@...tec.co.uk>, Chris Boot <bootc@...tc.net>,
	Dan Murphy <dmurphy@...com>,
	Daniel Jeong <daniel.jeong@...com>,
	Daniel Mack <daniel@...que.org>,
	"David S. Miller" <davem@...emloft.net>,
	Fabio Baltieri <fabio.baltieri@...il.com>,
	Felipe Balbi <balbi@...com>,
	Florian Fainelli <florian@...nwrt.org>,
	"G.Shark Jeong" <gshark.jeong@...il.com>,
	Guennadi Liakhovetski <g.liakhovetski@....de>,
	Ingi Kim <ingi2.kim@...sung.com>,
	Jan-Simon Moeller <dl9pf@....de>,
	Johan Hovold <johan@...nel.org>, John Lenz <lenz@...wisc.edu>,
	Jonas Gorski <jogo@...nwrt.org>,
	Kim Kyuwon <q1.kim@...sung.com>,
	Kristian Kielhofner <kris@...sk.org>,
	Kristoffer Ericson <kristoffer.ericson@...il.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	Michael Hennerich <michael.hennerich@...log.com>,
	Milo Kim <milo.kim@...com>,
	Márton Németh <nm127@...email.hu>,
	Nate Case <ncase@...-inc.com>, NeilBrown <neilb@...e.de>,
	Nick Forbes <nick.forbes@...epta.com>,
	Paul Parsons <lost.distance@...oo.com>,
	Peter Meerwald <p.meerwald@...-electronic.com>,
	Phil Sutter <n0-1@...ewrt.org>,
	Philippe Retornaz <philippe.retornaz@...l.ch>,
	Raphael Assenat <raph@...com>,
	Richard Purdie <rpurdie@...nedhand.com>,
	Rod Whitby <rod@...tby.id.au>, Dave Hansen <dave@...1.net>,
	Rodolfo Giometti <giometti@...ux.it>,
	"Sebastian A. Siewior" <bigeasy@...utronix.de>,
	Shuah Khan <shuahkhan@...il.com>,
	Simon Guinot <sguinot@...ie.com>,
	Álvaro Fernández Rojas <noltari@...il.com>
Subject: Re: [PATCH/RFC RESEND] leds: Use set_brightness_work for
 brightness_set ops that can sleep

On Tue 2015-06-30 15:06:19, Jacek Anaszewski wrote:
> On 06/30/2015 01:58 PM, Pavel Machek wrote:
> >On Tue 2015-06-30 10:01:08, Jacek Anaszewski wrote:
> >>This patch rearranges the core LED subsystem code, so that it
> >>now removes from drivers the responsibility of using work queues
> >>internally in case their brightness_set ops can sleep.
> >>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 allow 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.
> >
> >Are you sure this is good idea?
> >
> >You'll now use single callback for blocking and non-blocking
> >behaviour. I'm pretty sure stuff like lockdep will have some fun with
> >that.
> 
> I enabled "Lock Debugging" options and didn't get any warning.
> Could you describe the use case you are thinking of?

You may get one when one of the sleeping functions uses some lock...

I'm not a lockdep expert, but mixing functions with different
semantics under one function pointer is wrong thing to do. If it does
not produce warnings today, it may start producing them tommorow. Just
don't do it.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/

Powered by blists - more mailing lists