| Message ID | 1357537131-8000-1-git-send-email-kliu5@marvell.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Mon, Jan 07, 2013 at 01:38:50PM +0800, Kevin Liu wrote: > Introduce a regulator_is_dummy function to check whether the > regulator is dummy. No, we've been through this repeatedly. Whatever problem you're trying to bodge around is going to be a problem with some real physical regulators too.
2013/1/7 Mark Brown <broonie@opensource.wolfsonmicro.com>: > On Mon, Jan 07, 2013 at 01:38:50PM +0800, Kevin Liu wrote: >> Introduce a regulator_is_dummy function to check whether the >> regulator is dummy. > > No, we've been through this repeatedly. Whatever problem you're trying > to bodge around is going to be a problem with some real physical > regulators too. Then the only way is MUST define the regulator rather than let dummy regulator handle it, right? -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Am 07.01.2013 12:25, schrieb Mark Brown: > On Mon, Jan 07, 2013 at 01:38:50PM +0800, Kevin Liu wrote: >> Introduce a regulator_is_dummy function to check whether the >> regulator is dummy. > > No, we've been through this repeatedly. Whatever problem you're trying > to bodge around is going to be a problem with some real physical > regulators too. Though I don't know the previous discussion, this seems a different case to me. The problem is that *only* a dummy regulator is available which refuses to do any regulation at all. So sdhci/mmc should better behave as no regulator was available at all. This may happen if e.g. in a precompiled kernel of some linux distro regulator support (including dummy) is enabled but the machine running that kernel doesn't have a known hardware regulator. This results in sdhci/mmc failing to enable the SD card reader though it would work well without regulator support in the kernel. Rainer -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Jan 07, 2013 at 06:36:36AM -0500, Kevin Liu wrote: > 2013/1/7 Mark Brown <broonie@opensource.wolfsonmicro.com>: > > No, we've been through this repeatedly. Whatever problem you're trying > > to bodge around is going to be a problem with some real physical > > regulators too. > Then the only way is MUST define the regulator rather than let dummy > regulator handle it, right? To repeat once again, dummy regulators should never be used in production. They are purely a crutch to help get boot going - it is expected that things like this and cpufreq might fail.
On Mon, Jan 07, 2013 at 01:30:54PM +0100, Dr. Rainer Kaluscha wrote: > The problem is that *only* a dummy regulator is available which > refuses to do any regulation at all. > So sdhci/mmc should better behave as no regulator was available at all. > This may happen if e.g. in a precompiled kernel of some linux distro > regulator support (including dummy) is enabled but the machine > running that kernel doesn't have a known hardware regulator. This > results in sdhci/mmc failing to enable the SD card reader though it > would work well without regulator support in the kernel. Production systems should not enable the dummy regulators, it's that simple. They're a crutch to get things booting but they're going to cause problems in production.
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index e872c8b..d2a8bdb 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -1826,6 +1826,23 @@ int regulator_disable_regmap(struct regulator_dev *rdev) } EXPORT_SYMBOL_GPL(regulator_disable_regmap); +/** + * regulator_is_dummy - check if regulator is dummy + * @regulator: regulator source + * + * Returns positive if the regulator is dummy, zero if it's not. + */ +int regulator_is_dummy(struct regulator *regulator) +{ + struct regulator_dev *rdev = regulator->rdev; + + if (!strcmp(rdev_get_name(rdev), "regulator-dummy")) + return 1; + else + return 0; +} +EXPORT_SYMBOL_GPL(regulator_is_dummy); + static int _regulator_is_enabled(struct regulator_dev *rdev) { /* A GPIO control always takes precedence */ diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h index c43cd35..fe549d0 100644 --- a/include/linux/regulator/consumer.h +++ b/include/linux/regulator/consumer.h @@ -164,6 +164,7 @@ int regulator_count_voltages(struct regulator *regulator); int regulator_list_voltage(struct regulator *regulator, unsigned selector); int regulator_is_supported_voltage(struct regulator *regulator, int min_uV, int max_uV); +int regulator_is_dummy(struct regulator *regulator); int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV); int regulator_set_voltage_time(struct regulator *regulator, int old_uV, int new_uV); @@ -249,6 +250,11 @@ static inline int regulator_is_enabled(struct regulator *regulator) return 1; } +static inline int regulator_is_dummy(struct regulator *regulator) +{ + return 0; +} + static inline int regulator_bulk_get(struct device *dev, int num_consumers, struct regulator_bulk_data *consumers)
Introduce a regulator_is_dummy function to check whether the regulator is dummy. Signed-off-by: Kevin Liu <kliu5@marvell.com> --- drivers/regulator/core.c | 17 +++++++++++++++++ include/linux/regulator/consumer.h | 6 ++++++ 2 files changed, 23 insertions(+)