Created attachment 86581 [details] Dmesg and other relevant output. Device: 02:01.2 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21) OS: RHEL 6u3 Arch: x86_64 3.0.51 kernel -- o.k. 3.1.10 kernel -- o.k. 3.2.33 kernel -- o.k. 3.3.8 kernel -- first sign of a problem. "sdhci-pci 0000:02:01.2: could not set regulator OCR (-22)". Cards are still accessible. 3.4.18 kernel -- "sdhci-pci 0000:02:01.2: could not set regulator OCR (-22)". Cards are still accessible. 3.5.7 kernel -- "sdhci-pci 0000:02:01.2: could not set regulator OCR (-22)". Cards are still accessible. 3.6.6 kernel -- "mmc0: Hardware doesn't report any support voltages.". Cards are not accessible. For each of the above seven kernels, I have comprehensive logs of the tests performed. The log for the 3.6.6 kernel is attached. Others can be supplied, upon request.
I have the hardware available for testing and can readily build a new kernel. All I would need is a patch and the advice as to which kernel sources it should be applied.
Just to make sure, this report is not forgotten - I have exactly the same problem, but a different distro, so it is not distribution-speciffic. 02:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 18) (prog-if 01)
Bumping the assignee to say that I have the hardware and I have the ability to build/package kernels, however I do not understand the hardware (regulator and/or Ricoh R5C822 Host Adapter) at register/device level. Hence I am unable to de-bug this issue, myself. I am ready and willing to perform tests -- I just need some code. As such, any kernel >= 3.6.6 is useless for me. I am pleased to see comment #2, from Lukasz, for I was feeling rather lonely here!
Thanks to Marek Szyprowski, I've managed to make kernel 3.7.6 work with my reader. I'm still getting these errors (sdhci-pci: could not set regulator OCR (-22)), but I can access my cards. Everything requires the following patch (thanks to Marek): diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index 042c1ff..d07c240 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1872,7 +1872,14 @@ int regulator_count_voltages(struct regulator *regulator) { struct regulator_dev *rdev = regulator->rdev; - return rdev->desc->n_voltages ? : -EINVAL; + if (rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_VOLTAGE) { + if (rdev->desc->n_voltages) + return rdev->desc->n_voltages; + else + return -EINVAL; + } else { + return 1; + } } EXPORT_SYMBOL_GPL(regulator_count_voltages); diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index c7851c0..6f6534e 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -2923,7 +2923,7 @@ int sdhci_add_host(struct sdhci_host *host) regulator_enable(host->vmmc); #ifdef CONFIG_REGULATOR - if (host->vmmc) { + if (host->vmmc && regulator_count_voltages(host->vmmc) > 1) { ret = regulator_is_supported_voltage(host->vmmc, 3300000, 3300000); if ((ret <= 0) || (!(caps[0] & SDHCI_CAN_VDD_330))) --------
Created attachment 92531 [details] Patch which allows the card readers from this report to work again under kernels 3.7.x (tested on 3.7.6).
Here is the original thread on the linux-kernel-mmc list, where one can find this patch (in fact part 2 and 3 are needed, the first part has been applied in the kernel already). http://thread.gmane.org/gmane.linux.kernel.mmc/17643
Bumping this issue, once again, so that it does not get 'forgotten'. The regression appeared in linux-3.3.X and is still present in linux-3.8.X I have the hardware available for testing. I can build a kernel for testing. This issue needs to be assigned to someone capable of understanding the internal workings of the patch(es) introduced in linux-3.3.X that has caused this regression and is prepared to fix the code.
This regression is still present in linux-3.9-rc5 Ignoring it will not make it go away. Any comments? Anybody?
Setting CONFIG_REGULATOR=n will fix your problem, and I think just setting CONFIG_REGULATOR_DUMMY=n would too. If you're using sdhci-pci, I think you're on a system without any regulators. (CONFIG_REGULATOR_DUMMY should only be set if you are developing a regulator driver; if you're using a distribution kernel that has it turned on, please report a bug in your distribution asking for it to be disabled.)
(In reply to comment #9) > Setting CONFIG_REGULATOR=n will fix your problem, and I think just setting > CONFIG_REGULATOR_DUMMY=n would too. If you're using sdhci-pci, I think > you're > on a system without any regulators. YES, it works for me! And no longer all these annoying "could not set regulator OCR (-22)" messages. Now I have to push it into my distro ;-)
(In reply to comment #9) > Setting CONFIG_REGULATOR=n will fix your problem, and I think just setting > CONFIG_REGULATOR_DUMMY=n would too. If you're using sdhci-pci, I think > you're > on a system without any regulators. > > (CONFIG_REGULATOR_DUMMY should only be set if you are developing a regulator > driver; if you're using a distribution kernel that has it turned on, please > report a bug in your distribution asking for it to be disabled.) Thank you for your assistance, Chris. I am always a little wary when someone uses the phrase "I think" but you have "hit the nail on the head". The mischief was created by having CONFIG_REGULATOR_DUMMY being set. Turning it off and building from the linux-3.8.8 tarball resulted in a kernel that: (1) Booted without displaying either the "sdhci-pci: could not set regulator OCR (-22)" or the "mmc0: Hardware doesn't report any support voltages" message. (2) Had a fully functioning card reader/writer. Perhaps the Kconfig file should be updated to clarify the intended usage of the CONFIG_REGULATOR_DUMMY setting?