linux-kernel - Possible regression with commit 52221610d

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

Message-ID: <54584260.8030602@nvidia.com>
Date:	Tue, 4 Nov 2014 12:05:04 +0900
From:	Alexandre Courbot <acourbot@...dia.com>
To:	Tim Kryger <tim.kryger@...il.com>,
	Sachin Kamat <spk.linux@...il.com>,
	Ulf Hansson <ulf.hansson@...aro.org>
CC:	<linux-mmc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Alexandre Courbot <gnurou@...il.com>
Subject: Possible regression with commit 52221610d

Hi guys,

On the NVIDIA shield (tegra114-roth) platform, I have noticed that MMC 
stopped working completely on recent kernels. MMC devices will not show 
up and the message "mmc1: Controller never released inhibit bit(s)." 
shows up repeatedly in the console.

After bisecting I tracked commit 
52221610dd84dc3e9196554f0292ca9e8ab3541d ("mmc: sdhci: Improve external 
VDD regulator support") as the one that introduced this issue, which 
seems somehow surprising to me since it has been around for a while and 
nobody else complained about this AFAICT.

The following diff solves the issue for me, however I don't know whether 
it also reverts the intended purpose of the initial patch:

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ada1a3ea3a87..615701bb8ea3 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1235,13 +1235,6 @@ 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(mmc, mmc->supply.vmmc, vdd);
-               spin_lock_irq(&host->lock);
-               return;
-       }
-
         if (mode != MMC_POWER_OFF) {
                 switch (1 << vdd) {
                 case MMC_VDD_165_195:
@@ -1300,6 +1293,12 @@ 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(mmc, mmc->supply.vmmc, vdd);
+               spin_lock_irq(&host->lock);
+       }
  }

Does this look like the right approach? If not, would you have any 
suggestion as to how to solve this problem?

Thanks,
Alex.
--
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/