linux-kernel - Re: Regulator supplies when using Device Tree

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: <4F73A798.6030607@codeaurora.org>
Date:	Wed, 28 Mar 2012 17:06:48 -0700
From:	Michael Bohan <mbohan@...eaurora.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
CC:	rnayak@...com, lrg@...com, LKML <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org
Subject: Re: Regulator supplies when using Device Tree

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.
--
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/