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: <54B7B39C.7080204@samsung.com>
Date:	Thu, 15 Jan 2015 13:33:32 +0100
From:	Sylwester Nawrocki <s.nawrocki@...sung.com>
To:	Mark Brown <broonie@...nel.org>,
	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,
	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 12/01/15 18:06, Mark Brown wrote:
> On Mon, Jan 12, 2015 at 10:55:29AM -0600, Rob Herring wrote:
>> > On Mon, Jan 12, 2015 at 10:10 AM, Jacek Anaszewski
>>> > > There are however devices that don't fall into this category, i.e. they
>>> > > have many outputs, that can be connected to a single LED or to many LEDs
>>> > > and the driver has to know what is the actual arrangement.
>> >
>> > We may need to extend the regulator binding slightly and allow for
>> > multiple phandles on a supply property, but wouldn't something like
>> > this work:
>> > led-supply = <&led-reg0>, <&led-reg1>, <&led-reg2>, <&led-reg3>;
>> > The shared source is already supported by the regulator binding.
>
> What is the reasoning for this?  If a single supply is being supplied by
> multiple regulators then in general those regulators will all know about
> each other at a hardware level and so from a functional and software
> point of view will effectively be one regulator.  If they don't/aren't
> then they tend to interfere with each other.

For LED current regulators like this one [1] we want to be able to 
communicate to the software the hardware wiring, e.g. if a single LED is 
connected to only one or both the current regulators.  The device needs 
to be programmed differently for each configuration, as shown on page 36 
of the datasheet [2].

Now, the LED DT binding describes the LEDs (current consumers) as child
nodes of the LED driver IC (current supplier), e.g. (from [3]):

pca9632@62 {
        compatible = "nxp,pca9632";
        #address-cells = <1>;
        #size-cells = <0>;
        reg = <0x62>;

        red@0 {
                label = "red";
                reg = <0>;
                linux,default-trigger = "none";
        };
        green@1 {
                label = "green";
                reg = <1>;
                linux,default-trigger = "none";
        };
	...
};

What is missing in this binding is the ability to tell that a single LED
is connected to more than one current source.

We could, for example adopt the multiple phandle in the supply property
scheme, but not use the kernel regulator API, e.g.

flash-led {
         compatible = "maxim,max77387";

         current-reg1 { // FLED1
                 led-output-id = <0>;
         };

         current-reg2 { // FLED2
                 led-output-id = <1>;
         };

         red_led {
                 led-supply = <&current-reg1>, <&current-reg2>;
         };
};

However my feeling is that it is unnecessarily complicated that way.

Perhaps we could use the 'reg' property to describe actual connections,
I'm not sure if it's better than a LED specific property, e.g.

max77387@52 {
        compatible = "nxp,max77387";
        #address-cells = <2>;
        #size-cells = <0>;
        reg = <0x52>;

	flash_led {
		reg = <1 1>;	
		...
	};	
};

[1] http://www.maximintegrated.com/en/products/power/led-drivers/MAX77387.html
[2] http://datasheets.maximintegrated.com/en/ds/MAX77387.pdf
[3] Documentation/devicetree/bindings/leds/pca963x.txt
--
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/