linux-kernel - Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator

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]

Date:	Tue, 23 Oct 2012 14:36:35 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Philip Rakity <prakity@...dia.com>
Cc:	Pavan Kunapuli <pkunapuli@...dia.com>,
	"swarren@...dotorg.org" <swarren@...dotorg.org>,
	"cjb@...top.org" <cjb@...top.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH 2/2] mmc: sdhci: Defer probe if regulator_get fails

On Tue, Oct 23, 2012 at 03:21:58PM +0200, Philip Rakity wrote:
> On 23 Oct 2012, at 09:19, Pavan Kunapuli <pkunapuli@...dia.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.)
--
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/