From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Michael Bohan <mbohan@codeaurora.org>
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: Fri, 30 Mar 2012 11:36:02 +0100 [thread overview]
Message-ID: <20120330103602.GE21950@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4F7509F4.6010303@codeaurora.org>
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]
On Thu, Mar 29, 2012 at 06:18:44PM -0700, Michael Bohan wrote:
> On 3/29/2012 4:11 AM, Mark Brown wrote:
> >On Wed, Mar 28, 2012 at 05:06:48PM -0700, Michael Bohan wrote:
> >>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.
> >No, pretty much any drivers which optionally have an upstream supply
> >would be buggy and should therefore run into trouble during review.
> Can you please elaborate on why this is a bad design? We have always
> used this model in the past, and the regulator framework is happy to
> support it.
The support for regulator-regulator supplies has always been problematic
and infrequently used -
> We have identical hardware blocks that can be positioned to take a
> supply or not. So are you proposing we copy / paste our driver so
> that in one case rdesc->supply_name is NULL and the other case a
> valid supply name? I'm guessing you aren't implying this, but what
> alternatives do you suggest to support such a model?
Please be more specific about what you're actually trying to physically
accomplish here. It would be *extremely* unusual to see a regulator
which was able to do something useful without any input power and if you
genuinely have this need whatever you're doing probably needs the
framework to actually be aware of what's going on. However...
> I was hoping that we could continue to treat regulator supplies as
> normal supplies, but somehow allow the framework to determine
> whether a regulator supply exists or not in the Device Tree
> configuration so the driver doesn't have to.
...this doesn't really make any sense - the new scheme makes regulator
supplies *more* like normal supplies, not less, since they're now
specified in exactly the same way as other supplies and are just assumed
to be provided by the leaf driver.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-03-30 10:36 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
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 [this message]
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=20120330103602.GE21950@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.com \
--cc=mbohan@codeaurora.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).