[PATCH 0/3] cpufreq: build fixes

[PATCH 0/3] cpufreq: build fixes

[Arnd Bergmann]

These came out of running randconfig build tests on ARM. The three
patches are completely independent, so please apply what looks good.

The two s3c patches are for old bugs and should go through the
cpufreq tree.

The exynos bug only exists in the thermal-soc tree at the moment
and should get picked up by Eduardo with an Ack from the cpufreq
maintainers, or alternatively the bug should get fixed differently
if someone can come up with a better solution.

Arnd Bergmann (3):
  cpufreq: s3c: remove incorrect __init annotations
  cpufreq: s3c: remove last use of resume_clocks callback
  cpufreq: exynos: allow modular build

 drivers/cpufreq/Kconfig.arm          | 14 +++++++++-----
 drivers/cpufreq/exynos-cpufreq.h     |  6 +++---
 drivers/cpufreq/exynos4210-cpufreq.c |  1 +
 drivers/cpufreq/exynos4x12-cpufreq.c |  1 +
 drivers/cpufreq/exynos5250-cpufreq.c |  1 +
 drivers/cpufreq/s3c2416-cpufreq.c    |  4 ++--
 drivers/cpufreq/s3c24xx-cpufreq.c    | 10 +---------
 7 files changed, 18 insertions(+), 19 deletions(-)

-- 
2.1.0.rc2

[PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations

[Arnd Bergmann]

The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register
are marked init but are called from a context that might be run after
the __init sections are discarded, as the compiler points out:

WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init()
WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register()

This removes the __init markings.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: stable at vger.kernel.org
---
 drivers/cpufreq/s3c2416-cpufreq.c | 4 ++--
 drivers/cpufreq/s3c24xx-cpufreq.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
index 2fd53eaaec20..d6d425773fa4 100644
--- a/drivers/cpufreq/s3c2416-cpufreq.c
+++ b/drivers/cpufreq/s3c2416-cpufreq.c
@@ -263,7 +263,7 @@ out:
 }
 
 #ifdef CONFIG_ARM_S3C2416_CPUFREQ_VCORESCALE
-static void __init s3c2416_cpufreq_cfg_regulator(struct s3c2416_data *s3c_freq)
+static void s3c2416_cpufreq_cfg_regulator(struct s3c2416_data *s3c_freq)
 {
 	int count, v, i, found;
 	struct cpufreq_frequency_table *pos;
@@ -333,7 +333,7 @@ static struct notifier_block s3c2416_cpufreq_reboot_notifier = {
 	.notifier_call = s3c2416_cpufreq_reboot_notifier_evt,
 };
 
-static int __init s3c2416_cpufreq_driver_init(struct cpufreq_policy *policy)
+static int s3c2416_cpufreq_driver_init(struct cpufreq_policy *policy)
 {
 	struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
 	struct cpufreq_frequency_table *pos;
diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c b/drivers/cpufreq/s3c24xx-cpufreq.c
index d00f1cee4509..bd340a1ca87d 100644
--- a/drivers/cpufreq/s3c24xx-cpufreq.c
+++ b/drivers/cpufreq/s3c24xx-cpufreq.c
@@ -454,7 +454,7 @@ static struct cpufreq_driver s3c24xx_driver = {
 };
 
 
-int __init s3c_cpufreq_register(struct s3c_cpufreq_info *info)
+int s3c_cpufreq_register(struct s3c_cpufreq_info *info)
 {
 	if (!info || !info->name) {
 		printk(KERN_ERR "%s: failed to pass valid information\n",
-- 
2.1.0.rc2

[PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback

[Arnd Bergmann]

Commit 32726d2d550 ("ARM: SAMSUNG: Remove legacy clock code")
already removed the callback pointer, but there was one remaining
user:

drivers/cpufreq/s3c24xx-cpufreq.c: In function 's3c_cpufreq_resume_clocks':
drivers/cpufreq/s3c24xx-cpufreq.c:149:14: error: 'struct s3c_cpufreq_info' has no member named 'resume_clocks'
  cpu_cur.info->resume_clocks();
              ^

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 32726d2d550 ("ARM: SAMSUNG: Remove legacy clock code")
Cc: stable at vger.kernel.org # v3.17+
---
 drivers/cpufreq/s3c24xx-cpufreq.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c b/drivers/cpufreq/s3c24xx-cpufreq.c
index bd340a1ca87d..733aa5153e74 100644
--- a/drivers/cpufreq/s3c24xx-cpufreq.c
+++ b/drivers/cpufreq/s3c24xx-cpufreq.c
@@ -144,11 +144,6 @@ static void s3c_cpufreq_setfvco(struct s3c_cpufreq_config *cfg)
 	(cfg->info->set_fvco)(cfg);
 }
 
-static inline void s3c_cpufreq_resume_clocks(void)
-{
-	cpu_cur.info->resume_clocks();
-}
-
 static inline void s3c_cpufreq_updateclk(struct clk *clk,
 					 unsigned int freq)
 {
@@ -417,9 +412,6 @@ static int s3c_cpufreq_resume(struct cpufreq_policy *policy)
 
 	last_target = ~0;	/* invalidate last_target setting */
 
-	/* first, find out what speed we resumed at. */
-	s3c_cpufreq_resume_clocks();
-
 	/* whilst we will be called later on, we try and re-set the
 	 * cpu frequencies as soon as possible so that we do not end
 	 * up resuming devices and then immediately having to re-set
-- 
2.1.0.rc2

[PATCH 3/3] cpufreq: exynos: allow modular build

[Arnd Bergmann]

The exynos cpufreq driver code recently gained a dependency on the
cooling code, which may be a loadable module. This breaks an ARM
allmodconfig build:

drivers/built-in.o: In function `exynos_cpufreq_probe':
:(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register'

To avoid this problem, change cpufreq Kconfig to allow the drivers
to be loadable modules as well and enforce a dependency on the
thermal module. Also, export the symbols that are used for communicating
between the three cpu-specific parts of the driver and the main module.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: e725d26c4857 ("cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered")
---
 drivers/cpufreq/Kconfig.arm          | 14 +++++++++-----
 drivers/cpufreq/exynos-cpufreq.h     |  6 +++---
 drivers/cpufreq/exynos4210-cpufreq.c |  1 +
 drivers/cpufreq/exynos4x12-cpufreq.c |  1 +
 drivers/cpufreq/exynos5250-cpufreq.c |  1 +
 5 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0f9a2c3c0e0d..99ac56746ebd 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -26,11 +26,12 @@ config ARM_VEXPRESS_SPC_CPUFREQ
 
 
 config ARM_EXYNOS_CPUFREQ
-	bool
+	tristate
 
 config ARM_EXYNOS4210_CPUFREQ
-	bool "SAMSUNG EXYNOS4210"
+	tristate "SAMSUNG EXYNOS4210"
 	depends on CPU_EXYNOS4210
+	depends on THERMAL
 	default y
 	select ARM_EXYNOS_CPUFREQ
 	help
@@ -40,8 +41,9 @@ config ARM_EXYNOS4210_CPUFREQ
 	  If in doubt, say N.
 
 config ARM_EXYNOS4X12_CPUFREQ
-	bool "SAMSUNG EXYNOS4x12"
+	tristate "SAMSUNG EXYNOS4x12"
 	depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
+	depends on THERMAL
 	default y
 	select ARM_EXYNOS_CPUFREQ
 	help
@@ -51,8 +53,9 @@ config ARM_EXYNOS4X12_CPUFREQ
 	  If in doubt, say N.
 
 config ARM_EXYNOS5250_CPUFREQ
-	bool "SAMSUNG EXYNOS5250"
+	tristate "SAMSUNG EXYNOS5250"
 	depends on SOC_EXYNOS5250
+	depends on THERMAL
 	default y
 	select ARM_EXYNOS_CPUFREQ
 	help
@@ -62,9 +65,10 @@ config ARM_EXYNOS5250_CPUFREQ
 	  If in doubt, say N.
 
 config ARM_EXYNOS5440_CPUFREQ
-	bool "SAMSUNG EXYNOS5440"
+	tristate "SAMSUNG EXYNOS5440"
 	depends on SOC_EXYNOS5440
 	depends on HAVE_CLK && OF
+	depends on THERMAL
 	select PM_OPP
 	default y
 	help
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 9f2062a7cc02..32a895af4961 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -53,7 +53,7 @@ struct exynos_dvfs_info {
 	void __iomem	*cmu_regs;
 };
 
-#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
 extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
@@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
 	return -EOPNOTSUPP;
 }
 #endif
-#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
 extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
@@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
 	return -EOPNOTSUPP;
 }
 #endif
-#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
 extern int exynos5250_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
diff --git a/drivers/cpufreq/exynos4210-cpufreq.c b/drivers/cpufreq/exynos4210-cpufreq.c
index 843ec824fd91..4b5de19f0ea2 100644
--- a/drivers/cpufreq/exynos4210-cpufreq.c
+++ b/drivers/cpufreq/exynos4210-cpufreq.c
@@ -182,3 +182,4 @@ err_moutcore:
 	pr_debug("%s: failed initialization\n", __func__);
 	return -EINVAL;
 }
+EXPORT_SYMBOL_GPL(exynos4210_cpufreq_init);
diff --git a/drivers/cpufreq/exynos4x12-cpufreq.c b/drivers/cpufreq/exynos4x12-cpufreq.c
index 9e78a850e29f..d2924e1bc909 100644
--- a/drivers/cpufreq/exynos4x12-cpufreq.c
+++ b/drivers/cpufreq/exynos4x12-cpufreq.c
@@ -234,3 +234,4 @@ err_moutcore:
 	pr_debug("%s: failed initialization\n", __func__);
 	return -EINVAL;
 }
+EXPORT_SYMBOL_GPL(exynos4x12_cpufreq_init);
diff --git a/drivers/cpufreq/exynos5250-cpufreq.c b/drivers/cpufreq/exynos5250-cpufreq.c
index 3eafdc7ba787..b2810b839331 100644
--- a/drivers/cpufreq/exynos5250-cpufreq.c
+++ b/drivers/cpufreq/exynos5250-cpufreq.c
@@ -208,3 +208,4 @@ err_moutcore:
 	pr_err("%s: failed initialization\n", __func__);
 	return -EINVAL;
 }
+EXPORT_SYMBOL_GPL(exynos5250_cpufreq_init);
-- 
2.1.0.rc2

[PATCH 3/3] cpufreq: exynos: allow modular build

[Eduardo Valentin]

On Wed, Jan 28, 2015 at 02:16:55PM +0100, Arnd Bergmann wrote:
> The exynos cpufreq driver code recently gained a dependency on the
> cooling code, which may be a loadable module. This breaks an ARM
> allmodconfig build:
> 
> drivers/built-in.o: In function `exynos_cpufreq_probe':
> :(.text+0x1748e8): undefined reference to `of_cpufreq_cooling_register'
> 
> To avoid this problem, change cpufreq Kconfig to allow the drivers
> to be loadable modules as well and enforce a dependency on the
> thermal module. Also, export the symbols that are used for communicating
> between the three cpu-specific parts of the driver and the main module.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: e725d26c4857 ("cpufreq: exynos: Use device tree to determine if cpufreq cooling should be registered")
> ---
>  drivers/cpufreq/Kconfig.arm          | 14 +++++++++-----
>  drivers/cpufreq/exynos-cpufreq.h     |  6 +++---
>  drivers/cpufreq/exynos4210-cpufreq.c |  1 +
>  drivers/cpufreq/exynos4x12-cpufreq.c |  1 +
>  drivers/cpufreq/exynos5250-cpufreq.c |  1 +
>  5 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 0f9a2c3c0e0d..99ac56746ebd 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -26,11 +26,12 @@ config ARM_VEXPRESS_SPC_CPUFREQ
>  
>  
>  config ARM_EXYNOS_CPUFREQ
> -	bool
> +	tristate
>  
>  config ARM_EXYNOS4210_CPUFREQ
> -	bool "SAMSUNG EXYNOS4210"
> +	tristate "SAMSUNG EXYNOS4210"
>  	depends on CPU_EXYNOS4210
> +	depends on THERMAL
>  	default y
>  	select ARM_EXYNOS_CPUFREQ
>  	help
> @@ -40,8 +41,9 @@ config ARM_EXYNOS4210_CPUFREQ
>  	  If in doubt, say N.
>  
>  config ARM_EXYNOS4X12_CPUFREQ
> -	bool "SAMSUNG EXYNOS4x12"
> +	tristate "SAMSUNG EXYNOS4x12"
>  	depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
> +	depends on THERMAL
>  	default y
>  	select ARM_EXYNOS_CPUFREQ
>  	help
> @@ -51,8 +53,9 @@ config ARM_EXYNOS4X12_CPUFREQ
>  	  If in doubt, say N.
>  
>  config ARM_EXYNOS5250_CPUFREQ
> -	bool "SAMSUNG EXYNOS5250"
> +	tristate "SAMSUNG EXYNOS5250"
>  	depends on SOC_EXYNOS5250
> +	depends on THERMAL
>  	default y
>  	select ARM_EXYNOS_CPUFREQ
>  	help
> @@ -62,9 +65,10 @@ config ARM_EXYNOS5250_CPUFREQ
>  	  If in doubt, say N.
>  
>  config ARM_EXYNOS5440_CPUFREQ
> -	bool "SAMSUNG EXYNOS5440"
> +	tristate "SAMSUNG EXYNOS5440"
>  	depends on SOC_EXYNOS5440
>  	depends on HAVE_CLK && OF
> +	depends on THERMAL
>  	select PM_OPP
>  	default y
>  	help

Reading the code briefly, looks like the intention is to separate soc
specific code into different files, but they all compose one single
driver. Translating into module, I believe it makes sense to build them
into a single module, instead of having all of them as separate module.

Meaning, only ARM_EXYNOS_CPUFREQ becomes tristate, all the remaining
continues bool. And we add the following Makefile change to your patch

---
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0f9a2c3..c3c3cf5 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -26,13 +26,19 @@ config ARM_VEXPRESS_SPC_CPUFREQ
 
 
 config ARM_EXYNOS_CPUFREQ
-	bool
+	tristate "SAMSUNG EXYNOS CPUfreq Driver"
+	depends on THERMAL
+	default y
+	help
+	  This adds the CPUFreq driver for Samsung EXYNOS platforms
+
+	  If in doubt, say N.
 
 config ARM_EXYNOS4210_CPUFREQ
 	bool "SAMSUNG EXYNOS4210"
 	depends on CPU_EXYNOS4210
+	depends on ARM_EXYNOS_CPUFREQ
 	default y
-	select ARM_EXYNOS_CPUFREQ
 	help
 	  This adds the CPUFreq driver for Samsung EXYNOS4210
 	  SoC (S5PV310 or S5PC210).
@@ -42,8 +48,8 @@ config ARM_EXYNOS4210_CPUFREQ
 config ARM_EXYNOS4X12_CPUFREQ
 	bool "SAMSUNG EXYNOS4x12"
 	depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
+	depends on ARM_EXYNOS_CPUFREQ
 	default y
-	select ARM_EXYNOS_CPUFREQ
 	help
 	  This adds the CPUFreq driver for Samsung EXYNOS4X12
 	  SoC (EXYNOS4212 or EXYNOS4412).
@@ -54,7 +60,7 @@ config ARM_EXYNOS5250_CPUFREQ
 	bool "SAMSUNG EXYNOS5250"
 	depends on SOC_EXYNOS5250
 	default y
-	select ARM_EXYNOS_CPUFREQ
+	depends on ARM_EXYNOS_CPUFREQ
 	help
 	  This adds the CPUFreq driver for Samsung EXYNOS5250
 	  SoC.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index b3ca7b0..b26e2bf 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -51,10 +51,11 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)		+= arm_big_little_dt.o
 
 obj-$(CONFIG_ARCH_DAVINCI)		+= davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500)		+= dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= arm-exynos-cpufreq.o
+arm-exynos-cpufreq-y					:= exynos-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)	+= exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o

> diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
> index 9f2062a7cc02..32a895af4961 100644
> --- a/drivers/cpufreq/exynos-cpufreq.h
> +++ b/drivers/cpufreq/exynos-cpufreq.h
> @@ -53,7 +53,7 @@ struct exynos_dvfs_info {
>  	void __iomem	*cmu_regs;
>  };
>  
> -#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
> +#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
>  extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
>  #else
>  static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
> @@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
>  	return -EOPNOTSUPP;
>  }
>  #endif
> -#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
> +#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
>  extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
>  #else
>  static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
> @@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
>  	return -EOPNOTSUPP;
>  }
>  #endif
> -#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
> +#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
>  extern int exynos5250_cpufreq_init(struct exynos_dvfs_info *);
>  #else
>  static inline int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
> diff --git a/drivers/cpufreq/exynos4210-cpufreq.c b/drivers/cpufreq/exynos4210-cpufreq.c
> index 843ec824fd91..4b5de19f0ea2 100644
> --- a/drivers/cpufreq/exynos4210-cpufreq.c
> +++ b/drivers/cpufreq/exynos4210-cpufreq.c
> @@ -182,3 +182,4 @@ err_moutcore:
>  	pr_debug("%s: failed initialization\n", __func__);
>  	return -EINVAL;
>  }
> +EXPORT_SYMBOL_GPL(exynos4210_cpufreq_init);
> diff --git a/drivers/cpufreq/exynos4x12-cpufreq.c b/drivers/cpufreq/exynos4x12-cpufreq.c
> index 9e78a850e29f..d2924e1bc909 100644
> --- a/drivers/cpufreq/exynos4x12-cpufreq.c
> +++ b/drivers/cpufreq/exynos4x12-cpufreq.c
> @@ -234,3 +234,4 @@ err_moutcore:
>  	pr_debug("%s: failed initialization\n", __func__);
>  	return -EINVAL;
>  }
> +EXPORT_SYMBOL_GPL(exynos4x12_cpufreq_init);
> diff --git a/drivers/cpufreq/exynos5250-cpufreq.c b/drivers/cpufreq/exynos5250-cpufreq.c
> index 3eafdc7ba787..b2810b839331 100644
> --- a/drivers/cpufreq/exynos5250-cpufreq.c
> +++ b/drivers/cpufreq/exynos5250-cpufreq.c
> @@ -208,3 +208,4 @@ err_moutcore:
>  	pr_err("%s: failed initialization\n", __func__);
>  	return -EINVAL;
>  }
> +EXPORT_SYMBOL_GPL(exynos5250_cpufreq_init);

and certainly we would not need to export such functions anymore

> -- 
> 2.1.0.rc2
> 

BR,

Eduardo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/41b0cc10/attachment.sig>

[PATCH 3/3] cpufreq: exynos: allow modular build

[Arnd Bergmann]

On Wednesday 28 January 2015 13:22:11 Eduardo Valentin wrote:
> >  
> >  config ARM_EXYNOS5440_CPUFREQ
> > -	bool "SAMSUNG EXYNOS5440"
> > +	tristate "SAMSUNG EXYNOS5440"
> >  	depends on SOC_EXYNOS5440
> >  	depends on HAVE_CLK && OF
> > +	depends on THERMAL
> >  	select PM_OPP
> >  	default y
> >  	help
> 
> Reading the code briefly, looks like the intention is to separate soc
> specific code into different files, but they all compose one single
> driver. Translating into module, I believe it makes sense to build them
> into a single module, instead of having all of them as separate module.
> 
> Meaning, only ARM_EXYNOS_CPUFREQ becomes tristate, all the remaining
> continues bool. And we add the following Makefile change to your patch

That was my initial thought as well, but the devil is in the details:

> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 0f9a2c3..c3c3cf5 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -26,13 +26,19 @@ config ARM_VEXPRESS_SPC_CPUFREQ
>  
>  
>  config ARM_EXYNOS_CPUFREQ
> -	bool
> +	tristate "SAMSUNG EXYNOS CPUfreq Driver"
> +	depends on THERMAL
> +	default y
> +	help
> +	  This adds the CPUFreq driver for Samsung EXYNOS platforms
> +
> +	  If in doubt, say N.

Now the option shows up on all systems that include Kconfig.arm,
in particular non-exynos machines that might not even be able
to build this.

It's also enabled by default, but if you change the default to 'n',
the entire drivers will be disabled for users with an existing
configuration file.

We could work around these issues by adding extra (silent) Kconfig
symbols that automatically do the right thing, but that would not
be any less ugly than my first patch.

Another possible might be to change the drivers to use the normal
probe ordering and move the module_platform_driver() statement
into the individual drivers, so that e.g. exynos4210_cpufreq_init()
gets turned into exynos4210_cpufreq_probe() and calls the generic
exynos_cpufreq_probe() function. This would let us express the
dependencies more naturally and just export one symbol from the
main module.

	Arnd

[PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations

[Viresh Kumar]

On 28 January 2015 at 18:46, Arnd Bergmann <arnd@arndb.de> wrote:
> The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register
> are marked init but are called from a context that might be run after
> the __init sections are discarded, as the compiler points out:
>
> WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init()
> WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register()
>
> This removes the __init markings.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: stable at vger.kernel.org
> ---
>  drivers/cpufreq/s3c2416-cpufreq.c | 4 ++--
>  drivers/cpufreq/s3c24xx-cpufreq.c | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpufreq/s3c2416-cpufreq.c b/drivers/cpufreq/s3c2416-cpufreq.c
> index 2fd53eaaec20..d6d425773fa4 100644
> --- a/drivers/cpufreq/s3c2416-cpufreq.c
> +++ b/drivers/cpufreq/s3c2416-cpufreq.c
> @@ -263,7 +263,7 @@ out:
>  }
>
>  #ifdef CONFIG_ARM_S3C2416_CPUFREQ_VCORESCALE
> -static void __init s3c2416_cpufreq_cfg_regulator(struct s3c2416_data *s3c_freq)
> +static void s3c2416_cpufreq_cfg_regulator(struct s3c2416_data *s3c_freq)
>  {
>         int count, v, i, found;
>         struct cpufreq_frequency_table *pos;
> @@ -333,7 +333,7 @@ static struct notifier_block s3c2416_cpufreq_reboot_notifier = {
>         .notifier_call = s3c2416_cpufreq_reboot_notifier_evt,
>  };
>
> -static int __init s3c2416_cpufreq_driver_init(struct cpufreq_policy *policy)
> +static int s3c2416_cpufreq_driver_init(struct cpufreq_policy *policy)
>  {
>         struct s3c2416_data *s3c_freq = &s3c2416_cpufreq;
>         struct cpufreq_frequency_table *pos;
> diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c b/drivers/cpufreq/s3c24xx-cpufreq.c
> index d00f1cee4509..bd340a1ca87d 100644
> --- a/drivers/cpufreq/s3c24xx-cpufreq.c
> +++ b/drivers/cpufreq/s3c24xx-cpufreq.c
> @@ -454,7 +454,7 @@ static struct cpufreq_driver s3c24xx_driver = {
>  };
>
>
> -int __init s3c_cpufreq_register(struct s3c_cpufreq_info *info)
> +int s3c_cpufreq_register(struct s3c_cpufreq_info *info)
>  {
>         if (!info || !info->name) {
>                 printk(KERN_ERR "%s: failed to pass valid information\n",

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

[PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback

[Viresh Kumar]

On 28 January 2015 at 18:46, Arnd Bergmann <arnd@arndb.de> wrote:
> Commit 32726d2d550 ("ARM: SAMSUNG: Remove legacy clock code")
> already removed the callback pointer, but there was one remaining
> user:
>
> drivers/cpufreq/s3c24xx-cpufreq.c: In function 's3c_cpufreq_resume_clocks':
> drivers/cpufreq/s3c24xx-cpufreq.c:149:14: error: 'struct s3c_cpufreq_info' has no member named 'resume_clocks'
>   cpu_cur.info->resume_clocks();
>               ^
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Fixes: 32726d2d550 ("ARM: SAMSUNG: Remove legacy clock code")
> Cc: stable at vger.kernel.org # v3.17+
> ---
>  drivers/cpufreq/s3c24xx-cpufreq.c | 8 --------
>  1 file changed, 8 deletions(-)
>
> diff --git a/drivers/cpufreq/s3c24xx-cpufreq.c b/drivers/cpufreq/s3c24xx-cpufreq.c
> index bd340a1ca87d..733aa5153e74 100644
> --- a/drivers/cpufreq/s3c24xx-cpufreq.c
> +++ b/drivers/cpufreq/s3c24xx-cpufreq.c
> @@ -144,11 +144,6 @@ static void s3c_cpufreq_setfvco(struct s3c_cpufreq_config *cfg)
>         (cfg->info->set_fvco)(cfg);
>  }
>
> -static inline void s3c_cpufreq_resume_clocks(void)
> -{
> -       cpu_cur.info->resume_clocks();
> -}
> -
>  static inline void s3c_cpufreq_updateclk(struct clk *clk,
>                                          unsigned int freq)
>  {
> @@ -417,9 +412,6 @@ static int s3c_cpufreq_resume(struct cpufreq_policy *policy)
>
>         last_target = ~0;       /* invalidate last_target setting */
>
> -       /* first, find out what speed we resumed at. */
> -       s3c_cpufreq_resume_clocks();
> -
>         /* whilst we will be called later on, we try and re-set the
>          * cpu frequencies as soon as possible so that we do not end
>          * up resuming devices and then immediately having to re-set

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

[PATCH 3/3] cpufreq: exynos: allow modular build

[Viresh Kumar]

On 29 January 2015 at 01:31, Arnd Bergmann <arnd@arndb.de> wrote:

>>  config ARM_EXYNOS_CPUFREQ
>> -     bool
>> +     tristate "SAMSUNG EXYNOS CPUfreq Driver"
>> +     depends on THERMAL
>> +     default y
>> +     help
>> +       This adds the CPUFreq driver for Samsung EXYNOS platforms
>> +
>> +       If in doubt, say N.
>
> Now the option shows up on all systems that include Kconfig.arm,
> in particular non-exynos machines that might not even be able
> to build this.

I am sure I am wrong here, but want to know what I am missing.
What about:

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index c3c3cf52d2d9..f3ee05067a69 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -27,7 +27,7 @@ config ARM_VEXPRESS_SPC_CPUFREQ

 config ARM_EXYNOS_CPUFREQ
        tristate "SAMSUNG EXYNOS CPUfreq Driver"
-       depends on THERMAL
+       depends on THERMAL && ARCH_EXYNOS
        default y
        help
          This adds the CPUFreq driver for Samsung EXYNOS platforms

[PATCH 3/3] cpufreq: exynos: allow modular build

[Arnd Bergmann]

On Thursday 29 January 2015 09:09:03 Viresh Kumar wrote:
> On 29 January 2015 at 01:31, Arnd Bergmann <arnd@arndb.de> wrote:
> 
> >>  config ARM_EXYNOS_CPUFREQ
> >> -     bool
> >> +     tristate "SAMSUNG EXYNOS CPUfreq Driver"
> >> +     depends on THERMAL
> >> +     default y
> >> +     help
> >> +       This adds the CPUFreq driver for Samsung EXYNOS platforms
> >> +
> >> +       If in doubt, say N.
> >
> > Now the option shows up on all systems that include Kconfig.arm,
> > in particular non-exynos machines that might not even be able
> > to build this.
> 
> I am sure I am wrong here, but want to know what I am missing.
> What about:
> 
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index c3c3cf52d2d9..f3ee05067a69 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -27,7 +27,7 @@ config ARM_VEXPRESS_SPC_CPUFREQ
> 
>  config ARM_EXYNOS_CPUFREQ
>         tristate "SAMSUNG EXYNOS CPUfreq Driver"
> -       depends on THERMAL
> +       depends on THERMAL && ARCH_EXYNOS
>         default y
>         help
>           This adds the CPUFreq driver for Samsung EXYNOS platforms

That might be close enough to what we want. It would by default enable
ARM_EXYNOS_CPUFREQ for exynos based machines that do not use this driver
(e.g. 5440, which has a separate driver, or exynos3/exynos7), but that
can probably just be dealt with by disabling it in the user's defconfig.
If i'm reading exynos_cpufreq_probe right, it would actually compile
into an almost-empty file in this case and only kzalloc a few bytes
of memory and then print a warning message.

	Arnd

[PATCH 3/3] cpufreq: exynos: allow modular build

[Viresh Kumar]

On 29 January 2015 at 15:31, Arnd Bergmann <arnd@arndb.de> wrote:
> That might be close enough to what we want. It would by default enable
> ARM_EXYNOS_CPUFREQ for exynos based machines that do not use this driver
> (e.g. 5440, which has a separate driver, or exynos3/exynos7), but that
> can probably just be dealt with by disabling it in the user's defconfig.
> If i'm reading exynos_cpufreq_probe right, it would actually compile
> into an almost-empty file in this case and only kzalloc a few bytes
> of memory and then print a warning message.

I may be wrong this time around, but I will still try hard :

diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index b3ca7b0b2c33..91747c411d86 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -51,10 +51,9 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)              +=
arm_big_little_dt.o

 obj-$(CONFIG_ARCH_DAVINCI)             += davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500)         += dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)       += exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos-cpufreq.o exynos4210-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos-cpufreq.o exynos4x12-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos-cpufreq.o exynos5250-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)   += exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)     += highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)                += imx6q-cpufreq.o

[PATCH 3/3] cpufreq: exynos: allow modular build

[Arnd Bergmann]

On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
>  obj-$(CONFIG_ARCH_DAVINCI)             += davinci-cpufreq.o
>  obj-$(CONFIG_UX500_SOC_DB8500)         += dbx500-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)       += exynos-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
> -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
> +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos-cpufreq.o exynos4210-cpufreq.o
> +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos-cpufreq.o exynos4x12-cpufreq.o
> +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos-cpufreq.o exynos5250-cpufreq.o
> 

I'd have to try it, but this might fail if one of the three drivers
is built-in and another one is a module.

	Arnd

[PATCH 3/3] cpufreq: exynos: allow modular build

[Eduardo Valentin]

Hello Arnd and Viresh,

On Thu, Jan 29, 2015 at 01:42:32PM +0100, Arnd Bergmann wrote:
> On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
> >  obj-$(CONFIG_ARCH_DAVINCI)             += davinci-cpufreq.o
> >  obj-$(CONFIG_UX500_SOC_DB8500)         += dbx500-cpufreq.o
> > -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)       += exynos-cpufreq.o
> > -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
> > -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
> > -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
> > +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos-cpufreq.o exynos4210-cpufreq.o
> > +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos-cpufreq.o exynos4x12-cpufreq.o
> > +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos-cpufreq.o exynos5250-cpufreq.o
> > 
> 
> I'd have to try it, but this might fail if one of the three drivers
> is built-in and another one is a module.
> 
> 	Arnd

Let me make one step back here. The original issue is, now this exynos
cpufreq driver depends on of thermal; but of thermal can be built as
module, while this cpufreq driver cannot. Original proposal is to allow
module build in the exynos cpufreq driver.

On the original proposal, my concern is that the driver code does not
have separated modules, but one single module platform driver,  which uses functions from
other c files. On top of that, the patch originally allows four
(independent) modules builds. Although the children drivers still
selects the core part, we would still need to change the original patch
to add module dependency too.

So, my proposal was to, in order to allow module builds on this cpufreq
driver, we also need to properly construct the driver into a single
module, instead of several modules. The issue with my patch was the fact
that it was allowing platforms that do not use that driver, to select it
by default. And eventually this may cause a unusable module being loaded
into those systems.

Well, trying harder here in the same approach. The diff bellow is based
on Arnd's original patch and on Viresh's amendment, except that the core
part is now dependent on all the supported platforms, instead of
ARCH_EXYNOS. This way, it wont load in platforms that are not supposed
to be loaded. The user will be able to build the support for all
platforms, or select which platforms he/she wants (as originally),
except that now it can be a module, instead.

I believe now by default it will still keep the driver only on those
configs that expect it to be on. And it won't compile/load on platforms
that it is not supposed to. It brings closer a config that is dependent on this
driver, so it looks better in the menuconfig.

Let me know if I missed something (feel free to amend to your patch):

diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 0f9a2c3..c6e3a6e 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -26,13 +26,21 @@ config ARM_VEXPRESS_SPC_CPUFREQ
 
 
 config ARM_EXYNOS_CPUFREQ
-	bool
+	tristate "SAMSUNG EXYNOS CPUfreq Driver"
+	depends on CPU_EXYNOS4210 || SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250
+	depends on THERMAL
+	help
+	  This adds the CPUFreq driver for Samsung EXYNOS platforms.
+	  Supported SoC versions are:
+	     Exynos4210, Exynos4212, Exynos4412, and Exynos5250.
+
+	  If in doubt, say N.
 
 config ARM_EXYNOS4210_CPUFREQ
 	bool "SAMSUNG EXYNOS4210"
 	depends on CPU_EXYNOS4210
+	depends on ARM_EXYNOS_CPUFREQ
 	default y
-	select ARM_EXYNOS_CPUFREQ
 	help
 	  This adds the CPUFreq driver for Samsung EXYNOS4210
 	  SoC (S5PV310 or S5PC210).
@@ -42,8 +50,8 @@ config ARM_EXYNOS4210_CPUFREQ
 config ARM_EXYNOS4X12_CPUFREQ
 	bool "SAMSUNG EXYNOS4x12"
 	depends on SOC_EXYNOS4212 || SOC_EXYNOS4412
+	depends on ARM_EXYNOS_CPUFREQ
 	default y
-	select ARM_EXYNOS_CPUFREQ
 	help
 	  This adds the CPUFreq driver for Samsung EXYNOS4X12
 	  SoC (EXYNOS4212 or EXYNOS4412).
@@ -53,28 +61,14 @@ config ARM_EXYNOS4X12_CPUFREQ
 config ARM_EXYNOS5250_CPUFREQ
 	bool "SAMSUNG EXYNOS5250"
 	depends on SOC_EXYNOS5250
+	depends on ARM_EXYNOS_CPUFREQ
 	default y
-	select ARM_EXYNOS_CPUFREQ
 	help
 	  This adds the CPUFreq driver for Samsung EXYNOS5250
 	  SoC.
 
 	  If in doubt, say N.
 
-config ARM_EXYNOS5440_CPUFREQ
-	bool "SAMSUNG EXYNOS5440"
-	depends on SOC_EXYNOS5440
-	depends on HAVE_CLK && OF
-	select PM_OPP
-	default y
-	help
-	  This adds the CPUFreq driver for Samsung EXYNOS5440
-	  SoC. The nature of exynos5440 clock controller is
-	  different than previous exynos controllers so not using
-	  the common exynos framework.
-
-	  If in doubt, say N.
-
 config ARM_EXYNOS_CPU_FREQ_BOOST_SW
 	bool "EXYNOS Frequency Overclocking - Software"
 	depends on ARM_EXYNOS_CPUFREQ && THERMAL
@@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
 
 	  If in doubt, say N.
 
+config ARM_EXYNOS5440_CPUFREQ
+	bool "SAMSUNG EXYNOS5440"
+	depends on SOC_EXYNOS5440
+	depends on HAVE_CLK && OF
+	select PM_OPP
+	default y
+	help
+	  This adds the CPUFreq driver for Samsung EXYNOS5440
+	  SoC. The nature of exynos5440 clock controller is
+	  different than previous exynos controllers so not using
+	  the common exynos framework.
+
+	  If in doubt, say N.
+
 config ARM_HIGHBANK_CPUFREQ
 	tristate "Calxeda Highbank-based"
 	depends on ARCH_HIGHBANK && CPUFREQ_DT && REGULATOR
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index b3ca7b0..b26e2bf 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -51,10 +51,11 @@ obj-$(CONFIG_ARM_DT_BL_CPUFREQ)		+= arm_big_little_dt.o
 
 obj-$(CONFIG_ARCH_DAVINCI)		+= davinci-cpufreq.o
 obj-$(CONFIG_UX500_SOC_DB8500)		+= dbx500-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= exynos-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
-obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
+obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)	+= arm-exynos-cpufreq.o
+arm-exynos-cpufreq-y					:= exynos-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)	+= exynos4210-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)	+= exynos4x12-cpufreq.o
+arm-exynos-cpufreq-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)	+= exynos5250-cpufreq.o
 obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ)	+= exynos5440-cpufreq.o
 obj-$(CONFIG_ARM_HIGHBANK_CPUFREQ)	+= highbank-cpufreq.o
 obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)		+= imx6q-cpufreq.o
diff --git a/drivers/cpufreq/exynos-cpufreq.h b/drivers/cpufreq/exynos-cpufreq.h
index 9f2062a..32a895a 100644
--- a/drivers/cpufreq/exynos-cpufreq.h
+++ b/drivers/cpufreq/exynos-cpufreq.h
@@ -53,7 +53,7 @@ struct exynos_dvfs_info {
 	void __iomem	*cmu_regs;
 };
 
-#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
 extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
@@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
 	return -EOPNOTSUPP;
 }
 #endif
-#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
 extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
@@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
 	return -EOPNOTSUPP;
 }
 #endif
-#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
+#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
 extern int exynos5250_cpufreq_init(struct exynos_dvfs_info *);
 #else
 static inline int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)

Eduardo Valentin

[PATCH 0/3] cpufreq: build fixes

[Rafael J. Wysocki]

On Wednesday, January 28, 2015 02:16:52 PM Arnd Bergmann wrote:
> These came out of running randconfig build tests on ARM. The three
> patches are completely independent, so please apply what looks good.
> 
> The two s3c patches are for old bugs and should go through the
> cpufreq tree.
> 
> The exynos bug only exists in the thermal-soc tree at the moment
> and should get picked up by Eduardo with an Ack from the cpufreq
> maintainers, or alternatively the bug should get fixed differently
> if someone can come up with a better solution.
> 
> Arnd Bergmann (3):
>   cpufreq: s3c: remove incorrect __init annotations
>   cpufreq: s3c: remove last use of resume_clocks callback
>   cpufreq: exynos: allow modular build
> 
>  drivers/cpufreq/Kconfig.arm          | 14 +++++++++-----
>  drivers/cpufreq/exynos-cpufreq.h     |  6 +++---
>  drivers/cpufreq/exynos4210-cpufreq.c |  1 +
>  drivers/cpufreq/exynos4x12-cpufreq.c |  1 +
>  drivers/cpufreq/exynos5250-cpufreq.c |  1 +
>  drivers/cpufreq/s3c2416-cpufreq.c    |  4 ++--
>  drivers/cpufreq/s3c24xx-cpufreq.c    | 10 +---------
>  7 files changed, 18 insertions(+), 19 deletions(-)

I'm assuming that this series will go in through the Samsumg tree.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH 3/3] cpufreq: exynos: allow modular build

[Arnd Bergmann]

On Thursday 29 January 2015 18:21:51 Eduardo Valentin wrote:
> Hello Arnd and Viresh,
> 
> On Thu, Jan 29, 2015 at 01:42:32PM +0100, Arnd Bergmann wrote:
> > On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
> > >  obj-$(CONFIG_ARCH_DAVINCI)             += davinci-cpufreq.o
> > >  obj-$(CONFIG_UX500_SOC_DB8500)         += dbx500-cpufreq.o
> > > -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)       += exynos-cpufreq.o
> > > -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
> > > -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
> > > -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
> > > +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos-cpufreq.o exynos4210-cpufreq.o
> > > +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos-cpufreq.o exynos4x12-cpufreq.o
> > > +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos-cpufreq.o exynos5250-cpufreq.o
> > > 
> > 
> > I'd have to try it, but this might fail if one of the three drivers
> > is built-in and another one is a module.
> > 
> > 	Arnd
> 
> Let me make one step back here. The original issue is, now this exynos
> cpufreq driver depends on of thermal; but of thermal can be built as
> module, while this cpufreq driver cannot. Original proposal is to allow
> module build in the exynos cpufreq driver.
> 
> On the original proposal, my concern is that the driver code does not
> have separated modules, but one single module platform driver,  which uses functions from
> other c files. On top of that, the patch originally allows four
> (independent) modules builds. Although the children drivers still
> selects the core part, we would still need to change the original patch
> to add module dependency too.
> 
> So, my proposal was to, in order to allow module builds on this cpufreq
> driver, we also need to properly construct the driver into a single
> module, instead of several modules. The issue with my patch was the fact
> that it was allowing platforms that do not use that driver, to select it
> by default. And eventually this may cause a unusable module being loaded
> into those systems.
> 
> Well, trying harder here in the same approach. The diff bellow is based
> on Arnd's original patch and on Viresh's amendment, except that the core
> part is now dependent on all the supported platforms, instead of
> ARCH_EXYNOS. This way, it wont load in platforms that are not supposed
> to be loaded. The user will be able to build the support for all
> platforms, or select which platforms he/she wants (as originally),
> except that now it can be a module, instead.
> 
> I believe now by default it will still keep the driver only on those
> configs that expect it to be on. And it won't compile/load on platforms
> that it is not supposed to. It brings closer a config that is dependent on this
> driver, so it looks better in the menuconfig.
> 
> Let me know if I missed something (feel free to amend to your patch):

Yes, I think your refined approach works and is better than my
original patch, thanks a lot for giving it more thought!

One tiny problem:

> @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
>  
>  	  If in doubt, say N.
>  
> +config ARM_EXYNOS5440_CPUFREQ
> +	bool "SAMSUNG EXYNOS5440"
> +	depends on SOC_EXYNOS5440
> +	depends on HAVE_CLK && OF
> +	select PM_OPP
> +	default y
> +	help
> +	  This adds the CPUFreq driver for Samsung EXYNOS5440
> +	  SoC. The nature of exynos5440 clock controller is
> +	  different than previous exynos controllers so not using
> +	  the common exynos framework.
> +
> +	  If in doubt, say N.

I believe this one also has to be tristate, for the same reason.

>  
> -#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
> +#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
>  extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
>  #else
>  static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
> @@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
>  	return -EOPNOTSUPP;
>  }
>  #endif
> -#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
> +#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
>  extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
>  #else
>  static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
> @@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
>  	return -EOPNOTSUPP;
>  }
>  #endif
> -#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
> +#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
>  extern int exynos5250_cpufreq_init(struct exynos_dvfs_info *);
>  #else
>  static inline int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)

This change is ok, but not needed, because the three extra symbols are still
bool. I would leave that change out, but I also don't mind it.

With the change to make ARM_EXYNOS5440_CPUFREQ tristate:

Acked-by: Arnd Bergmann <arnd@arndb.de>

[PATCH 3/3] cpufreq: exynos: allow modular build

[Eduardo Valentin]

On Fri, Jan 30, 2015 at 10:24:12PM +0100, Arnd Bergmann wrote:
> On Thursday 29 January 2015 18:21:51 Eduardo Valentin wrote:
> > Hello Arnd and Viresh,
> > 
> > On Thu, Jan 29, 2015 at 01:42:32PM +0100, Arnd Bergmann wrote:
> > > On Thursday 29 January 2015 15:40:15 Viresh Kumar wrote:
> > > >  obj-$(CONFIG_ARCH_DAVINCI)             += davinci-cpufreq.o
> > > >  obj-$(CONFIG_UX500_SOC_DB8500)         += dbx500-cpufreq.o
> > > > -obj-$(CONFIG_ARM_EXYNOS_CPUFREQ)       += exynos-cpufreq.o
> > > > -obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos4210-cpufreq.o
> > > > -obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos4x12-cpufreq.o
> > > > -obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos5250-cpufreq.o
> > > > +obj-$(CONFIG_ARM_EXYNOS4210_CPUFREQ)   += exynos-cpufreq.o exynos4210-cpufreq.o
> > > > +obj-$(CONFIG_ARM_EXYNOS4X12_CPUFREQ)   += exynos-cpufreq.o exynos4x12-cpufreq.o
> > > > +obj-$(CONFIG_ARM_EXYNOS5250_CPUFREQ)   += exynos-cpufreq.o exynos5250-cpufreq.o
> > > > 
> > > 
> > > I'd have to try it, but this might fail if one of the three drivers
> > > is built-in and another one is a module.
> > > 
> > > 	Arnd
> > 
> > Let me make one step back here. The original issue is, now this exynos
> > cpufreq driver depends on of thermal; but of thermal can be built as
> > module, while this cpufreq driver cannot. Original proposal is to allow
> > module build in the exynos cpufreq driver.
> > 
> > On the original proposal, my concern is that the driver code does not
> > have separated modules, but one single module platform driver,  which uses functions from
> > other c files. On top of that, the patch originally allows four
> > (independent) modules builds. Although the children drivers still
> > selects the core part, we would still need to change the original patch
> > to add module dependency too.
> > 
> > So, my proposal was to, in order to allow module builds on this cpufreq
> > driver, we also need to properly construct the driver into a single
> > module, instead of several modules. The issue with my patch was the fact
> > that it was allowing platforms that do not use that driver, to select it
> > by default. And eventually this may cause a unusable module being loaded
> > into those systems.
> > 
> > Well, trying harder here in the same approach. The diff bellow is based
> > on Arnd's original patch and on Viresh's amendment, except that the core
> > part is now dependent on all the supported platforms, instead of
> > ARCH_EXYNOS. This way, it wont load in platforms that are not supposed
> > to be loaded. The user will be able to build the support for all
> > platforms, or select which platforms he/she wants (as originally),
> > except that now it can be a module, instead.
> > 
> > I believe now by default it will still keep the driver only on those
> > configs that expect it to be on. And it won't compile/load on platforms
> > that it is not supposed to. It brings closer a config that is dependent on this
> > driver, so it looks better in the menuconfig.
> > 
> > Let me know if I missed something (feel free to amend to your patch):
> 
> Yes, I think your refined approach works and is better than my
> original patch, thanks a lot for giving it more thought!
> 
> One tiny problem:
> 
> > @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
> >  
> >  	  If in doubt, say N.
> >  
> > +config ARM_EXYNOS5440_CPUFREQ
> > +	bool "SAMSUNG EXYNOS5440"
> > +	depends on SOC_EXYNOS5440
> > +	depends on HAVE_CLK && OF
> > +	select PM_OPP
> > +	default y
> > +	help
> > +	  This adds the CPUFreq driver for Samsung EXYNOS5440
> > +	  SoC. The nature of exynos5440 clock controller is
> > +	  different than previous exynos controllers so not using
> > +	  the common exynos framework.
> > +
> > +	  If in doubt, say N.
> 
> I believe this one also has to be tristate, for the same reason.
> 

I agree with you that it is better if we make it tristate. So, on my
side, I have no concerns changing it to tristate.

However, the exynos5440 cpufreq driver does not depend on of thermal as
of today, and therefore, I did not touch this driver for this matter.
Meaning, if it is not causing troubles, no need to mess with it.

But I can add this change. No issues, on my side.

> >  
> > -#ifdef CONFIG_ARM_EXYNOS4210_CPUFREQ
> > +#if IS_ENABLED(CONFIG_ARM_EXYNOS4210_CPUFREQ)
> >  extern int exynos4210_cpufreq_init(struct exynos_dvfs_info *);
> >  #else
> >  static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
> > @@ -61,7 +61,7 @@ static inline int exynos4210_cpufreq_init(struct exynos_dvfs_info *info)
> >  	return -EOPNOTSUPP;
> >  }
> >  #endif
> > -#ifdef CONFIG_ARM_EXYNOS4X12_CPUFREQ
> > +#if IS_ENABLED(CONFIG_ARM_EXYNOS4X12_CPUFREQ)
> >  extern int exynos4x12_cpufreq_init(struct exynos_dvfs_info *);
> >  #else
> >  static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
> > @@ -69,7 +69,7 @@ static inline int exynos4x12_cpufreq_init(struct exynos_dvfs_info *info)
> >  	return -EOPNOTSUPP;
> >  }
> >  #endif
> > -#ifdef CONFIG_ARM_EXYNOS5250_CPUFREQ
> > +#if IS_ENABLED(CONFIG_ARM_EXYNOS5250_CPUFREQ)
> >  extern int exynos5250_cpufreq_init(struct exynos_dvfs_info *);
> >  #else
> >  static inline int exynos5250_cpufreq_init(struct exynos_dvfs_info *info)
> 
> This change is ok, but not needed, because the three extra symbols are still
> bool. I would leave that change out, but I also don't mind it.

Indeed.

> 
> With the change to make ARM_EXYNOS5440_CPUFREQ tristate:
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>

I will repost this patch with the minor amendments. Now, we only need
an ack from cpufreq folks.

BR,

Eduardo Valentin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150130/5da259c5/attachment.sig>

[PATCH 3/3] cpufreq: exynos: allow modular build

[Arnd Bergmann]

On Friday 30 January 2015 17:51:24 Eduardo Valentin wrote:
> > > @@ -90,6 +84,20 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
> > >  
> > >       If in doubt, say N.
> > >  
> > > +config ARM_EXYNOS5440_CPUFREQ
> > > +   bool "SAMSUNG EXYNOS5440"
> > > +   depends on SOC_EXYNOS5440
> > > +   depends on HAVE_CLK && OF
> > > +   select PM_OPP
> > > +   default y
> > > +   help
> > > +     This adds the CPUFreq driver for Samsung EXYNOS5440
> > > +     SoC. The nature of exynos5440 clock controller is
> > > +     different than previous exynos controllers so not using
> > > +     the common exynos framework.
> > > +
> > > +     If in doubt, say N.
> > 
> > I believe this one also has to be tristate, for the same reason.
> > 
> 
> I agree with you that it is better if we make it tristate. So, on my
> side, I have no concerns changing it to tristate.
> 
> However, the exynos5440 cpufreq driver does not depend on of thermal as
> of today, and therefore, I did not touch this driver for this matter.
> Meaning, if it is not causing troubles, no need to mess with it.
> 
> But I can add this change. No issues, on my side.

Sorry, my mistake. I remembered incorrectly that the problem was
in both modules, but you are right that it does not exist in the exynos5440
one. It is not a mistake to turn this into tristate, but there is no
immediate neeed, so either version is fine.

	Arnd