Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1286619 > unrolled thread

[PATCH] regulator: add regulator_sync_voltage inline dummy

Back to article view | Back to linux.kernel

Contents

  [PATCH] regulator: add regulator_sync_voltage inline dummy Arnd Bergmann <arnd@arndb.de> - 2015-12-08 16:50 +0100
    Re: [PATCH] regulator: add regulator_sync_voltage inline dummy Mark Brown <broonie@kernel.org> - 2015-12-08 17:40 +0100
      Re: [PATCH] regulator: add regulator_sync_voltage inline dummy Mark Brown <broonie@kernel.org> - 2015-12-08 18:00 +0100
      Re: [PATCH] regulator: add regulator_sync_voltage inline dummy Arnd Bergmann <arnd@arndb.de> - 2015-12-08 18:00 +0100

#1286619 — [PATCH] regulator: add regulator_sync_voltage inline dummy

Only one driver calls regulator_sync_voltage(), but that driver
can currently be built with CONFIG_REGULATOR disabled, producing
this build error:

drivers/cpufreq/tegra124-cpufreq.c: In function 'tegra124_cpu_switch_to_pllx':
drivers/cpufreq/tegra124-cpufreq.c:68:2: error: implicit declaration of function 'regulator_sync_voltage' [-Werror=implicit-function-declaration]
  regulator_sync_voltage(priv->vdd_cpu_reg);

This modifies the API header so we provide a static inline function
with the same prototype as the normal function of this name. This matches
what we do for all other regulator API functions and avoids the build
error.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 include/linux/regulator/consumer.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/include/linux/regulator/consumer.h b/include/linux/regulator/consumer.h
index 48603506f8de..d45e2e99396a 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -458,6 +458,11 @@ static inline int regulator_get_voltage(struct regulator *regulator)
 	return -EINVAL;
 }
 
+static inline int regulator_sync_voltage(struct regulator *regulator)
+{
+	return 0;
+}
+
 static inline int regulator_is_supported_voltage(struct regulator *regulator,
 				   int min_uV, int max_uV)
 {
-- 
2.1.0.rc2


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1286670

[Multipart message — attachments visible in raw view] — view raw

On Tue, Dec 08, 2015 at 04:43:35PM +0100, Arnd Bergmann wrote:

> This modifies the API header so we provide a static inline function
> with the same prototype as the normal function of this name. This matches
> what we do for all other regulator API functions and avoids the build
> error.

We don't do this for *all* regulator API functions - there's some where
using them strongly suggests that there is actually a dependency on the
regulator API.  This does seem like it might be falling into the
specialist category...

[toc] | [prev] | [next] | [standalone]

#1286686

[Multipart message — attachments visible in raw view] — view raw

On Tue, Dec 08, 2015 at 05:49:20PM +0100, Arnd Bergmann wrote:
> On Tuesday 08 December 2015 16:37:39 Mark Brown wrote:
> > On Tue, Dec 08, 2015 at 04:43:35PM +0100, Arnd Bergmann wrote:

> > We don't do this for *all* regulator API functions - there's some where
> > using them strongly suggests that there is actually a dependency on the
> > regulator API.  This does seem like it might be falling into the
> > specialist category...

> Ok, got it.

> I guess we'll want something like the patch below in the cpufreq git, right?

Yes, exactly - though looking at the code I'm pretty unclear on what the
authors think the use of _sync_voltage() is doing in the first place so
it may be even better to just remove the call.  It seems to have been
included in the first commit so there's not changelog explaining things
and there's no comment either.  I'd *expect* it to be a noop as far as I
can see.

[toc] | [prev] | [next] | [standalone]

#1286687

On Tuesday 08 December 2015 16:37:39 Mark Brown wrote:
> On Tue, Dec 08, 2015 at 04:43:35PM +0100, Arnd Bergmann wrote:
> 
> > This modifies the API header so we provide a static inline function
> > with the same prototype as the normal function of this name. This matches
> > what we do for all other regulator API functions and avoids the build
> > error.
> 
> We don't do this for *all* regulator API functions - there's some where
> using them strongly suggests that there is actually a dependency on the
> regulator API.  This does seem like it might be falling into the
> specialist category...
> 

Ok, got it.

I guess we'll want something like the patch below in the cpufreq git, right?

	Arnd

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 235a1ba73d92..b1f8a73e5a94 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -226,7 +226,7 @@ config ARM_TEGRA20_CPUFREQ
 
 config ARM_TEGRA124_CPUFREQ
 	tristate "Tegra124 CPUFreq support"
-	depends on ARCH_TEGRA && CPUFREQ_DT
+	depends on ARCH_TEGRA && CPUFREQ_DT && REGULATOR
 	default y
 	help
 	  This adds the CPUFreq driver support for Tegra124 SOCs.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web