From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@nvidia.com>
Cc: "Liam Girdwood (lrg@ti.com)" <lrg@ti.com>,
Chris Ball <cjb@laptop.org>,
Marek Szyprowski <m.szyprowski@samsung.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: sdmmc controllers without vmmc regulator
Date: Sat, 25 Feb 2012 11:57:59 +0000 [thread overview]
Message-ID: <20120225115759.GE3167@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF17BD8BCD8C@HQMAIL01.nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
On Fri, Feb 24, 2012 at 01:35:08PM -0800, Stephen Warren wrote:
> Can we eliminate this warning in of_get_regulator(), and let clients
> Control whether they warn when a regulator isn't found, if they think
> one is mandatory? I think I'd prefer this option; it's consistent with
> the non-DT path in regulator_dev_lookup().
This would be sensible but...
> Or, should I set up dummy regulators in device tree to cover this case,
> such that an SD controller's vmmc-supply always points at a valid phandle.
> In which case, I'd have to add DT support to the dummy regulator.
...you really ought to be doing this anyway (except with the fixed
voltage regulator, the dummy regulator is for stubbing out regulator
support entirely on systems with just one or two software controlled
regulators or where you don't have any information on the board design).
The MMC regulator usage is a bit of a mess for historical reasons, it
shouldn't really be conditional.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-02-25 11:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-24 21:35 sdmmc controllers without vmmc regulator Stephen Warren
2012-02-25 11:57 ` Mark Brown [this message]
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=20120225115759.GE3167@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=cjb@laptop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=lrg@ti.com \
--cc=m.szyprowski@samsung.com \
--cc=swarren@nvidia.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).