Re: Regulator supplies when using Device Tree

[Michael Bohan <mbohan@codeaurora.org>]

On 3/28/2012 12:33 PM, Mark Brown wrote:
> On Wed, Mar 28, 2012 at 12:19:45PM -0700, Michael Bohan wrote:
>> Within the regulator driver, we currently have to do an
>> of_get_property(of_node, "foo-supply", NULL) to determine whether
>> the device has a supply, and thus whether we should assign
>> rdesc->supply_name to "foo" or not when calling
>
> No, this would be completely idiotic.  Please think about what I'm
> saying here.  To repeat, supplies of all kinds are always requested with
> the name the chip uses for the supply.  This means that any machine
> binding is *totally* irrelevant to the regulator driver.

I'm not sure we're even talking about the same problem here. I agree 
that the name used for the supply should correspond with the data sheet 
- I just don't know how that's relevant.

Put simply, whose responsibility is it to assign the 
regulator_desc->supply_name pointer before registering a regulator 
device added from Device Tree? And do you agree that if you assign this 
pointer to a name for which there isn't a Device Tree property specified 
in that device_node, then regulator_register() will fail? This happens 
because of_get_regulator() tacks on a "-supply" at the end and then 
calls of_get_property() on the resulting string. That call will fail 
since there is no property specified in the device_node. This is the 
scenario I'm trying to avoid. Thus I add an additional check with 
of_get_property() in my driver to see if the property does exist before 
registering the regulator device, since both cases are reasonable. One 
is a regulator device with a supply, and one is a regulator device 
without a supply.

Are you aware of any other examples of submitted drivers with Device 
Tree support that implement regulator devices that optionally have an 
upstream supply? I looked at your tree recently and couldn't see any 
such cases.

Thanks,
Mike

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.