All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Bohan <mbohan@codeaurora.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: rnayak@ti.com, lrg@ti.com, LKML <linux-kernel@vger.kernel.org>,
	linux-arm-msm@vger.kernel.org
Subject: Re: Regulator supplies when using Device Tree
Date: Wed, 28 Mar 2012 12:19:45 -0700	[thread overview]
Message-ID: <4F736451.8020900@codeaurora.org> (raw)
In-Reply-To: <20120328100957.GD3232@opensource.wolfsonmicro.com>

On 3/28/2012 3:09 AM, Mark Brown wrote:
> On Tue, Mar 27, 2012 at 06:38:30PM -0700, Michael Bohan wrote:
>> the answer is that we should invent another binding to portray the
>> name of the supply the driver should be checking against. But then
>> it would seem silly to have two bindings that pertain to supply
>> names.
>
> Absolutely not, that would be broken.  The whole point here is that
> supplies of all kinds are always requested with the name the chip uses
> for the supply.

Let's consider an example with two regulators:

regulator@0 {
   compatible = "ldo_driver";
   foo-supply = <&smps1>;
};

regulator@1 {
   compatible = "ldo_driver";
};

How do we write a single regulator driver that supports both of these 
regulator devices?

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 regulator_register(). Is 
there a better way to do this? If we don't do this check for the case 
where a device does not have a supply specified in the Device Tree, then 
regulator_register() will fail.

Before Device Tree, regulators could get their supply names directly 
from the board file like so:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/power/regulator/machine.txt;h=ce63af0a8e35ecab32e2f326d13a9a2b33b62909;hb=refs/heads/master#l67

Thus the regulator driver was never concerned about the specifics of a 
supply name. And if the supply name was not specified, then the 
regulator_register() would happily succeed without any checks in the 
driver.

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.

  reply	other threads:[~2012-03-28 19:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-23  1:17 Regulator supplies when using Device Tree Michael Bohan
2012-03-26 13:00 ` Mark Brown
2012-03-28  1:38   ` Michael Bohan
2012-03-28 10:09     ` Mark Brown
2012-03-28 19:19       ` Michael Bohan [this message]
2012-03-28 19:33         ` Mark Brown
2012-03-29  0:06           ` Michael Bohan
2012-03-29  4:44             ` Rajendra Nayak
2012-03-29 11:08               ` Mark Brown
2012-03-29 11:11             ` Mark Brown
2012-03-30  1:18               ` Michael Bohan
2012-03-30 10:36                 ` Mark Brown
2012-04-02 17:35                   ` Michael Bohan
2012-04-02 21:22                     ` Mark Brown
2012-04-03  1:53                       ` Michael Bohan
2012-04-03 12:25                         ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F736451.8020900@codeaurora.org \
    --to=mbohan@codeaurora.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lrg@ti.com \
    --cc=rnayak@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.