linux-kernel - Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property

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]

Message-ID: <20150115155314.GZ3043@sirena.org.uk>
Date:	Thu, 15 Jan 2015 15:53:14 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Rob Herring <robherring2@...il.com>
Cc:	Jacek Anaszewski <j.anaszewski@...sung.com>,
	linux-leds@...r.kernel.org,
	"linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Pavel Machek <pavel@....cz>, Bryan Wu <cooloney@...il.com>,
	Richard Purdie <rpurdie@...ys.net>, sakari.ailus@....fi,
	Sylwester Nawrocki <s.nawrocki@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Liam Girdwood <lgirdwood@...il.com>
Subject: Re: [PATCH/RFC v10 03/19] DT: leds: Add led-sources property

On Thu, Jan 15, 2015 at 08:24:26AM -0600, Rob Herring wrote:
> On Tue, Jan 13, 2015 at 2:42 AM, Jacek Anaszewski

> > I am aware that it may be tempting to treat LED devices as common
> > regulators, but they have their specific features which gave a
> > reason for introducing LED class for them. Besides, there is already
> > drivers/leds/leds-regulator.c driver for LED devices which support only
> > turning on/off and setting brightness level.
> >
> > In your proposition a separate regulator provider binding would have
> > to be created for each current output and a separate binding for
> > each discrete LED connected to the LED device. It would create
> > unnecessary noise in a dts file.
> >
> > Moreover, using regulator binding implies that we want to treat it
> > as a sheer power supply for our device (which would be a discrete LED
> > element in this case), whereas LED devices provide more features like
> > blinking pattern and for flash LED devices - flash timeout, external
> > strobe and flash faults.

> Okay, fair enough. Please include some of this explanation in the
> binding description.

Right, the other thing here is that these chips are not normally
designed with the goal that the various components be used separately -
I've seen devices where the startup and shutdown procedures involve
interleaved actions to the boost regulator and current sink for example.
Trying to insert an abstraction layer typically just makes life more
complex.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)