From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails
Date: Tue, 23 Oct 2012 14:36:35 +0100 [thread overview]
Message-ID: <20121023133635.GV21164@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <4F1DF342-A2C4-434A-B878-A11374089E6E@nvidia.com>
On Tue, Oct 23, 2012 at 03:21:58PM +0200, Philip Rakity wrote:
> On 23 Oct 2012, at 09:19, Pavan Kunapuli <pkunapuli@nvidia.com> wrote:
> > - /* If vqmmc regulator and no 1.8V signalling, then there's no UHS */
> > + /*
> > + * If vqmmc regulator and no 1.8V signalling, then there's no UHS.
> > + * vqmmc regulator should be present. If it's not present,
> > + * assume the regulator driver registration is not yet done and
> > + * defer the probe.
> > + */
> > host->vqmmc = regulator_get(mmc_dev(mmc), "vqmmc");
> > if (IS_ERR(host->vqmmc)) {
> > - pr_info("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> > + pr_err("%s: no vqmmc regulator found\n", mmc_hostname(mmc));
> > host->vqmmc = NULL;
> > + return -EPROBE_DEFER;
>
> Some systems exist where vmmc regulator exists and vqmmc regulator does not. The vmmc regular is fixed at 3.3v.
> Deferring the probe will cause issues.
That's one of the issues of deferred probing: you don't know if one of the
_get() functions failed because it just isn't present, or whether it's
failed because it hasn't been registered yet.
The two conditions are indistinguishable from the driver point of view.
The solution to it is to ensure that those drivers where hardware resource
X is optional provide a dummy resource to the driver when the hardware
resource is not available. That means, as far as the driver is concerned,
that it will always expect to get a full set of resources whether or not
the hardware has them.
If drivers care about such stuff, then we should have xxx_is_dummy()
functions (eg, clk_is_dummy(clk)) which return TRUE when the hardware
resource is not available. (which we could use NULL to indicate and
would be in keeping with the specified IS_ERR() usage of these APIs.)
prev parent reply other threads:[~2012-10-23 13:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-23 7:18 [PATCH 0/2] mmc: sdhci: Defer probe if regulators are not registered Pavan Kunapuli
2012-10-23 7:18 ` [PATCH 1/2] ARM: dt: tegra: Add sdhci regulators Pavan Kunapuli
2012-10-23 18:07 ` Marc Dietrich
2012-10-23 18:42 ` Stephen Warren
2012-10-23 19:41 ` Marc Dietrich
2012-10-23 7:19 ` [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails Pavan Kunapuli
2012-10-23 7:57 ` Lucas Stach
2012-10-23 8:16 ` Pavan Kunapuli
2012-10-23 16:29 ` Stephen Warren
2012-10-23 17:07 ` Mark Brown
2012-10-23 13:21 ` Philip Rakity
2012-10-23 13:36 ` Russell King - ARM Linux [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=20121023133635.GV21164@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
/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).