On 01/20/2015 06:40 PM, Pavel Machek wrote:
On Tue 2015-01-20 11:29:16, Rob Herring wrote:
On Tue, Jan 20, 2015 at 10:09 AM, Jacek Anaszewski
<j.anaszewski@xxxxxxxxxxx> wrote:
On 01/16/2015 04:52 PM, Jacek Anaszewski wrote:
On 01/16/2015 02:48 PM, Rob Herring wrote:
[...]
You may want to add something like led-output-cnt or led-driver-cnt in
the parent so you know the max list size.
Why should we need this? The number of current outputs exposed by the
device is fixed and can be specified in a LED device bindings
documentation.
OK. The led-output-cnt property should be put in each sub-node, as the
number of the current outputs each LED can be connected to is variable.
Sorry, I meant this for the parent node meaning how many outputs the
driver IC has. I did say maybe because you may always know this. It
can make it easier to allocate memory for led-sources knowing the max
size up front.
Umm. Not sure if that kind of "help" should go to the device
tree.
Pavel
I agree. I think that led-sources-cnt is redundant. A list property
can be read using of_prop_next_u32 function. I missed that and thus
proposed putting led-sources-cnt in each sub-node to be able to read
led-sources list with of_property_read_u32_array.
Effectively, I propose to avoid adding led-sources-cnt property.
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
