linux-kernel - Re: [PATCH] mmc: sdhci: Improve external VDD regulator support

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] [day] [month] [year] [list]

Message-ID: <CAPDyKFr-eG04G39AcX2DyUiBgOTE4AY5MZbw6FXBtq918s2rJQ@mail.gmail.com>
Date:	Wed, 25 Jun 2014 11:49:55 +0200
From:	Ulf Hansson <ulf.hansson@...aro.org>
To:	Tim Kryger <tim.kryger@...il.com>
Cc:	Chris Ball <chris@...ntf.net>, Sachin Kamat <spk.linux@...il.com>,
	linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mmc: sdhci: Improve external VDD regulator support

On 25/06/2014, Tim Kryger <tim.kryger@...il.com> wrote:
> A standard compliant SDHCI can itself supply VDD at 1.8, 3.0, or 3.3v.
> Several vendors ignore this and instead rely upon external regulators
> to supply VDD.  While the external regulators typically can supply one
> of the standard SDHCI voltage levels, there is no real reason for this
> to be a hard requirement.
>
> This patch alters the SDHCI driver such that external VDD regulators
> that provide voltages other than the three mentioned above may be used
> so long as they can supply a voltage that meets the needs of the card.
>
> In the case that an external VDD regulator is provided, it is reasonable
> to ignore the voltage capabilities of the host controller and allow the
> external regulator to set the OCR mask.  Additionally, there is no need
> to convert a VDD voltage request into one of the standard SDHCI voltage
> levels or program it in the host controller's power control register.
>
> Signed-off-by: Tim Kryger <tim.kryger@...il.com>
> Tested-by: Sachin Kamat <spk.linux@...il.com>

Thanks! Applied for next.

Kind regards
Uffe

> ---
>
> This change corrects a regression observed on Exynos platforms that was
> triggered by "mmc: sdhci: Use mmc core regulator infrastucture"
>
> https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg27101.html
>
>  drivers/mmc/host/sdhci.c |   16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index c23a872..07a2426 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1226,6 +1226,13 @@ static void sdhci_set_power(struct sdhci_host *host,
> unsigned char mode,
>  	struct mmc_host *mmc = host->mmc;
>  	u8 pwr = 0;
>
> +	if (!IS_ERR(mmc->supply.vmmc)) {
> +		spin_unlock_irq(&host->lock);
> +		mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
> +		spin_lock_irq(&host->lock);
> +		return;
> +	}
> +
>  	if (mode != MMC_POWER_OFF) {
>  		switch (1 << vdd) {
>  		case MMC_VDD_165_195:
> @@ -1284,12 +1291,6 @@ static void sdhci_set_power(struct sdhci_host *host,
> unsigned char mode,
>  		if (host->quirks & SDHCI_QUIRK_DELAY_AFTER_POWER)
>  			mdelay(10);
>  	}
> -
> -	if (!IS_ERR(mmc->supply.vmmc)) {
> -		spin_unlock_irq(&host->lock);
> -		mmc_regulator_set_ocr(host->mmc, mmc->supply.vmmc, vdd);
> -		spin_lock_irq(&host->lock);
> -	}
>  }
>
> /*****************************************************************************\
> @@ -3092,8 +3093,9 @@ int sdhci_add_host(struct sdhci_host *host)
>  				   SDHCI_MAX_CURRENT_MULTIPLIER;
>  	}
>
> +	/* If OCR set by external regulators, use it instead */
>  	if (mmc->ocr_avail)
> -		ocr_avail &= mmc->ocr_avail;
> +		ocr_avail = mmc->ocr_avail;
>
>  	if (host->ocr_mask)
>  		ocr_avail &= host->ocr_mask;
> --
> 1.7.9.5
>
>
--
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/