[PATCH 2/9] regulator: helper routine to extract regulator_init_data

[Rajendra Nayak]

On Friday 30 September 2011 05:48 PM, Mark Brown wrote:
> On Fri, Sep 30, 2011 at 04:39:02PM +0530, Rajendra Nayak wrote:
>
>> The "regulator-supplies" is used to specific the regulator *parent*.
>> Same as what was earlier passed by using the
>> "supply_regulator" field of regulator_init_data structure.
>> Grant wanted the bindings to support specifying multiple parents
>> and hence I was thinking of either a list of names *or*
>> a list of phandles to specify multiple parents to a regulator.
>
> So, as I'm fairly sure I said last time these are just standard
> supplies.  It just happens to be that the consumer is a regulator.  The
> fact that Linux chooses to have core framework handling for this is an
> implementation detail of Linux (and indeed many devices ignore this for
> their on board regulators).

Yes, the implementation details of linux is what is making me using
these bindings difficult, and maybe you can help me how I can work
around the framework. The binding themselves, I agree should not care
if the consumer is a device/IP or a regulator itself.

So here's my problem:

I use the <name-supply> = <&reg_phandle> binding to define
a device/IP using one/more regulators on one/more rails.

device mmc {
	...
	...
	vmmc-supply = <&vmmc>;
	vpll-supply = <&vpll>;
};

The parsing of the "vmmc-supply" or the "vpll-supply" property
happens only when a mmc drivers makes a call to
regulator_get() passing the supply-name as "vmmc" or "vpll".
For ex:
regulator_get(dev, "vmmc"); or regulator_get(dev, "vpll");

Its easy to just append the "-supply" to a "vmmc" or "vpll"
and derive a property name like "vmm-supply" or "vpll-supply".

Now lets take the case of a regulator as a consumer:

regulator vmmc {
	...
	...
	vin-supply = <&vin>;
};

Now I need to parse the "vin-supply" property during a
regulator_register(), so I could do a set_supply() and
create the parent/child relationship between a vin and
vmmc.
The problem is I don't know if the property in the regulator dt
node is called "vin-supply" or "vxyz-supply" and hence I
can parse the property based on a substring alone, which is
"-supply" because all I know is the property name is expected
to end with a "-supply".

I can always add a new of_find_property_substr() which finds
me property based on a substring value passed rather than the
exact property-name string.
However I don;t know if this is the best way to handle it.
Any thoughts?