On Tue, Oct 13, 2015 at 09:08:46AM +0200, Hans de Goede wrote:

On 13-10-15 04:22, Chen-Yu Tsai wrote:

quoted

On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland [off-list ref] wrote:

quoted

On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:

quoted

quoted

quoted

+- num-supplies : The number of regulators used by the framebuffer.
+- vinN-supply : The N-th (from 0) regulator used by the framebuffer.

quoted

quoted

I don't see why you need num-supplies. Why not just try probing
vin${N}-supply until such a property isn't present in the DT?

+1 for this.

Even better would be to just enumerate all the properties on the node
and request anything with a FOO-supply name.  That way we can keep
using standard regulator bindings that name the supplies after their
actual names on the device.

quoted

That's doable. Though I'd add a hard limit on it. Does 16 seem
reasonable?

I would not add a hard limit to the binding, you can use a fixed array in
the code to make the code simpler. I would say 8 should be sufficient, since
the limit will only be in the code we can always bump it when we need
to.

Or just dynamically allocate the array and resize as needed if it starts
to get to be a problem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20151014/5fd830c7/attachment.sig>