All of lore.kernel.org
 help / color / mirror / Atom feed
From: Georgi Djakov <gdjakov@mm-sol.com>
To: Mike Looijmans <mike.looijmans@topic.nl>,
	cjb@laptop.org, linux-mmc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, git@xilinx.com
Subject: Re: [PATCH] sdhci: Forward EPROBE_DEFER on vmmc and vqmmc regulators
Date: Thu, 27 Mar 2014 23:13:40 +0200	[thread overview]
Message-ID: <53349484.5050100@mm-sol.com> (raw)
In-Reply-To: <5334644A.3010201@topic.nl>

On 27.03.14, 19:47, Mike Looijmans wrote:
> On 26-3-2014 16:09, Georgi Djakov wrote:
>> On 03/07/2014 04:18 PM, Mike Looijmans wrote:
>>> If vmmc or vqmmc regulators are controlled by an I2C device, the
>>> request for the regulator is likely to fail because the I2C bus has
>>> not been probed yet. The sdhci then incorrectly assumes that the user
>>> never wanted to use a regulator anyway and continues without ever
>>> enabling or configuring the required regulator.
>>>
>>> To solve this, when a required voltage regulator returns
>>> EPROBE_DEFER, signalling that the regulator exists but is not
>>> available yet, forward this error to the probe method instead
>>> of simply assuming that the user never wanted to use a regulator
>>> anyway.
>>>
>>> Tested on a custom board that has an I2C regulator for one of the sdhcis
>>> and no regulators at all for the other. This patch enables such a system
>>> to work correctly.
>>> ---
>>>   drivers/mmc/host/sdhci.c |    8 ++++++--
>>>   1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>>> index 34aef81..43b90c1 100644
>>> --- a/drivers/mmc/host/sdhci.c
>>> +++ b/drivers/mmc/host/sdhci.c
>>> @@ -2972,6 +2972,8 @@ int sdhci_add_host(struct sdhci_host *host)
>>>       host->vqmmc = regulator_get_optional(mmc_dev(mmc), "vqmmc");
>>>       if (IS_ERR_OR_NULL(host->vqmmc)) {
>>>           if (PTR_ERR(host->vqmmc) < 0) {
>>> +            if (PTR_ERR(host->vqmmc) == -EPROBE_DEFER)
>>> +                return -EPROBE_DEFER;
>>>               pr_info("%s: no vqmmc regulator found\n",
>>>                   mmc_hostname(mmc));
>>>               host->vqmmc = NULL;
>>> @@ -3048,8 +3050,10 @@ int sdhci_add_host(struct sdhci_host *host)
>>>       host->vmmc = regulator_get_optional(mmc_dev(mmc), "vmmc");
>>>       if (IS_ERR_OR_NULL(host->vmmc)) {
>>>           if (PTR_ERR(host->vmmc) < 0) {
>>> -            pr_info("%s: no vmmc regulator found\n",
>>> -                mmc_hostname(mmc));
>>> +            if (PTR_ERR(host->vmmc) == -EPROBE_DEFER)
>>> +                return -EPROBE_DEFER;
>>> +            pr_info("%s: no vmmc regulator found (%d)\n",
>>
>> I suggest using %ld here. The rest looks fine to me! Thanks!
> 
> Does this mean you're waiting for a patch v2 that I should submit?
> 

Yes, please submit v2 and hope to get some more feedback from the community.

Thanks,
Georgi

>>
>>> +                mmc_hostname(mmc), PTR_ERR(host->vmmc));
>>>               host->vmmc = NULL;
>>>           }
>>>       }
>>>
>>
>> BR,
>> Georgi
>>

  reply	other threads:[~2014-03-27 21:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-07 14:18 [PATCH] sdhci: Forward EPROBE_DEFER on vmmc and vqmmc regulators Mike Looijmans
2014-03-26 15:09 ` Georgi Djakov
2014-03-27 17:47   ` Mike Looijmans
2014-03-27 21:13     ` Georgi Djakov [this message]
2014-03-28  7:30 ` Mike Looijmans
2014-03-28 10:20   ` Ulf Hansson
2014-04-07  6:38   ` Mike Looijmans
2014-04-07  6:45     ` Mike Looijmans
2014-04-07  8:11     ` Arnd Bergmann
2014-04-07 12:09       ` Mike Looijmans
2014-04-07 12:09         ` Mike Looijmans
2014-04-07 12:16         ` Ben Dooks
2014-04-07 12:18           ` Ben Dooks
2014-04-07 12:25             ` Arnd Bergmann
2014-04-07 12:32               ` Mike Looijmans
2014-04-07 12:32                 ` Mike Looijmans
2014-04-07 12:51                 ` Arnd Bergmann
2014-04-07 13:11                   ` Mike Looijmans
2014-04-07 13:11                     ` Mike Looijmans
2014-04-16 20:15                     ` Andrew Bresticker
2014-04-16 20:47                       ` 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=53349484.5050100@mm-sol.com \
    --to=gdjakov@mm-sol.com \
    --cc=cjb@laptop.org \
    --cc=git@xilinx.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mike.looijmans@topic.nl \
    /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.