* [PATCH 0/3] cpufreq: build fixes
@ 2015-01-28 13:16 Arnd Bergmann
2015-01-28 13:16 ` [PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations Arnd Bergmann
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: Arnd Bergmann @ 2015-01-28 13:16 UTC (permalink / raw)
To: linux-pm
Cc: linux-samsung-soc, Viresh Kumar, Rafael J. Wysocki,
Eduardo Valentin, Kukjin Kim, Zhang Rui, linux-arm-kernel
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations 2015-01-28 13:16 [PATCH 0/3] cpufreq: build fixes Arnd Bergmann @ 2015-01-28 13:16 ` Arnd Bergmann 2015-01-29 3:23 ` Viresh Kumar 2015-01-28 13:16 ` [PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback Arnd Bergmann ` (2 subsequent siblings) 3 siblings, 1 reply; 17+ messages in thread From: Arnd Bergmann @ 2015-01-28 13:16 UTC (permalink / raw) To: linux-pm Cc: linux-samsung-soc, Viresh Kumar, Rafael J. Wysocki, Eduardo Valentin, Kukjin Kim, Zhang Rui, linux-arm-kernel 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@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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations 2015-01-28 13:16 ` [PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations Arnd Bergmann @ 2015-01-29 3:23 ` Viresh Kumar 0 siblings, 0 replies; 17+ messages in thread From: Viresh Kumar @ 2015-01-29 3:23 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-pm@vger.kernel.org, Rafael J. Wysocki, linux-samsung-soc, linux-arm-kernel@lists.infradead.org, Kukjin Kim, Zhang Rui, Eduardo Valentin 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@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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback 2015-01-28 13:16 [PATCH 0/3] cpufreq: build fixes Arnd Bergmann 2015-01-28 13:16 ` [PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations Arnd Bergmann @ 2015-01-28 13:16 ` Arnd Bergmann 2015-01-29 3:23 ` Viresh Kumar 2015-01-28 13:16 ` [PATCH 3/3] cpufreq: exynos: allow modular build Arnd Bergmann 2015-01-30 0:58 ` [PATCH 0/3] cpufreq: build fixes Rafael J. Wysocki 3 siblings, 1 reply; 17+ messages in thread From: Arnd Bergmann @ 2015-01-28 13:16 UTC (permalink / raw) To: linux-pm Cc: linux-samsung-soc, Viresh Kumar, Rafael J. Wysocki, Eduardo Valentin, Kukjin Kim, Zhang Rui, linux-arm-kernel 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@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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback 2015-01-28 13:16 ` [PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback Arnd Bergmann @ 2015-01-29 3:23 ` Viresh Kumar 0 siblings, 0 replies; 17+ messages in thread From: Viresh Kumar @ 2015-01-29 3:23 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-pm@vger.kernel.org, Rafael J. Wysocki, linux-samsung-soc, linux-arm-kernel@lists.infradead.org, Kukjin Kim, Zhang Rui, Eduardo Valentin 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@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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-28 13:16 [PATCH 0/3] cpufreq: build fixes Arnd Bergmann 2015-01-28 13:16 ` [PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations Arnd Bergmann 2015-01-28 13:16 ` [PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback Arnd Bergmann @ 2015-01-28 13:16 ` Arnd Bergmann 2015-01-28 17:22 ` Eduardo Valentin 2015-01-30 0:58 ` [PATCH 0/3] cpufreq: build fixes Rafael J. Wysocki 3 siblings, 1 reply; 17+ messages in thread From: Arnd Bergmann @ 2015-01-28 13:16 UTC (permalink / raw) To: linux-pm Cc: linux-samsung-soc, Viresh Kumar, Rafael J. Wysocki, Eduardo Valentin, Kukjin Kim, Zhang Rui, linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-28 13:16 ` [PATCH 3/3] cpufreq: exynos: allow modular build Arnd Bergmann @ 2015-01-28 17:22 ` Eduardo Valentin 2015-01-28 20:01 ` Arnd Bergmann 0 siblings, 1 reply; 17+ messages in thread From: Eduardo Valentin @ 2015-01-28 17:22 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-samsung-soc, linux-pm, Viresh Kumar, Rafael J. Wysocki, Kukjin Kim, Zhang Rui, linux-arm-kernel [-- Attachment #1.1: Type: text/plain, Size: 8037 bytes --] 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 [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-28 17:22 ` Eduardo Valentin @ 2015-01-28 20:01 ` Arnd Bergmann 2015-01-29 3:39 ` Viresh Kumar 0 siblings, 1 reply; 17+ messages in thread From: Arnd Bergmann @ 2015-01-28 20:01 UTC (permalink / raw) To: linux-arm-kernel Cc: linux-samsung-soc, linux-pm, Viresh Kumar, Rafael J. Wysocki, Eduardo Valentin, Kukjin Kim, Zhang Rui 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-28 20:01 ` Arnd Bergmann @ 2015-01-29 3:39 ` Viresh Kumar 2015-01-29 10:01 ` Arnd Bergmann 0 siblings, 1 reply; 17+ messages in thread From: Viresh Kumar @ 2015-01-29 3:39 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org, Eduardo Valentin, linux-samsung-soc, linux-pm@vger.kernel.org, Rafael J. Wysocki, Kukjin Kim, Zhang Rui 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-29 3:39 ` Viresh Kumar @ 2015-01-29 10:01 ` Arnd Bergmann 2015-01-29 10:10 ` Viresh Kumar 0 siblings, 1 reply; 17+ messages in thread From: Arnd Bergmann @ 2015-01-29 10:01 UTC (permalink / raw) To: Viresh Kumar Cc: linux-arm-kernel@lists.infradead.org, Eduardo Valentin, linux-samsung-soc, linux-pm@vger.kernel.org, Rafael J. Wysocki, Kukjin Kim, Zhang Rui 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-29 10:01 ` Arnd Bergmann @ 2015-01-29 10:10 ` Viresh Kumar 2015-01-29 12:42 ` Arnd Bergmann 0 siblings, 1 reply; 17+ messages in thread From: Viresh Kumar @ 2015-01-29 10:10 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-samsung-soc, linux-pm@vger.kernel.org, Rafael J. Wysocki, Eduardo Valentin, Kukjin Kim, Zhang Rui, linux-arm-kernel@lists.infradead.org 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-29 10:10 ` Viresh Kumar @ 2015-01-29 12:42 ` Arnd Bergmann 2015-01-29 22:21 ` Eduardo Valentin 0 siblings, 1 reply; 17+ messages in thread From: Arnd Bergmann @ 2015-01-29 12:42 UTC (permalink / raw) To: Viresh Kumar Cc: linux-arm-kernel@lists.infradead.org, Eduardo Valentin, linux-samsung-soc, linux-pm@vger.kernel.org, Rafael J. Wysocki, Kukjin Kim, Zhang Rui 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-29 12:42 ` Arnd Bergmann @ 2015-01-29 22:21 ` Eduardo Valentin 2015-01-30 21:24 ` Arnd Bergmann 0 siblings, 1 reply; 17+ messages in thread From: Eduardo Valentin @ 2015-01-29 22:21 UTC (permalink / raw) To: Arnd Bergmann Cc: Viresh Kumar, linux-arm-kernel@lists.infradead.org, linux-samsung-soc, linux-pm@vger.kernel.org, Rafael J. Wysocki, Kukjin Kim, Zhang Rui 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 ^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-29 22:21 ` Eduardo Valentin @ 2015-01-30 21:24 ` Arnd Bergmann 2015-01-30 21:51 ` Eduardo Valentin 0 siblings, 1 reply; 17+ messages in thread From: Arnd Bergmann @ 2015-01-30 21:24 UTC (permalink / raw) To: linux-arm-kernel Cc: Eduardo Valentin, linux-samsung-soc, linux-pm@vger.kernel.org, Viresh Kumar, Rafael J. Wysocki, Kukjin Kim, Zhang Rui 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-30 21:24 ` Arnd Bergmann @ 2015-01-30 21:51 ` Eduardo Valentin 2015-01-31 22:37 ` Arnd Bergmann 0 siblings, 1 reply; 17+ messages in thread From: Eduardo Valentin @ 2015-01-30 21:51 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-arm-kernel, linux-samsung-soc, linux-pm@vger.kernel.org, Viresh Kumar, Rafael J. Wysocki, Kukjin Kim, Zhang Rui [-- Attachment #1: Type: text/plain, Size: 5784 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 473 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 3/3] cpufreq: exynos: allow modular build 2015-01-30 21:51 ` Eduardo Valentin @ 2015-01-31 22:37 ` Arnd Bergmann 0 siblings, 0 replies; 17+ messages in thread From: Arnd Bergmann @ 2015-01-31 22:37 UTC (permalink / raw) To: linux-arm-kernel Cc: Eduardo Valentin, linux-samsung-soc, linux-pm@vger.kernel.org, Viresh Kumar, Rafael J. Wysocki, Kukjin Kim, Zhang Rui 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH 0/3] cpufreq: build fixes 2015-01-28 13:16 [PATCH 0/3] cpufreq: build fixes Arnd Bergmann ` (2 preceding siblings ...) 2015-01-28 13:16 ` [PATCH 3/3] cpufreq: exynos: allow modular build Arnd Bergmann @ 2015-01-30 0:58 ` Rafael J. Wysocki 3 siblings, 0 replies; 17+ messages in thread From: Rafael J. Wysocki @ 2015-01-30 0:58 UTC (permalink / raw) To: Arnd Bergmann Cc: linux-pm, Viresh Kumar, linux-samsung-soc, linux-arm-kernel, Kukjin Kim, Zhang Rui, Eduardo Valentin 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-01-31 22:37 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-01-28 13:16 [PATCH 0/3] cpufreq: build fixes Arnd Bergmann 2015-01-28 13:16 ` [PATCH 1/3] cpufreq: s3c: remove incorrect __init annotations Arnd Bergmann 2015-01-29 3:23 ` Viresh Kumar 2015-01-28 13:16 ` [PATCH 2/3] cpufreq: s3c: remove last use of resume_clocks callback Arnd Bergmann 2015-01-29 3:23 ` Viresh Kumar 2015-01-28 13:16 ` [PATCH 3/3] cpufreq: exynos: allow modular build Arnd Bergmann 2015-01-28 17:22 ` Eduardo Valentin 2015-01-28 20:01 ` Arnd Bergmann 2015-01-29 3:39 ` Viresh Kumar 2015-01-29 10:01 ` Arnd Bergmann 2015-01-29 10:10 ` Viresh Kumar 2015-01-29 12:42 ` Arnd Bergmann 2015-01-29 22:21 ` Eduardo Valentin 2015-01-30 21:24 ` Arnd Bergmann 2015-01-30 21:51 ` Eduardo Valentin 2015-01-31 22:37 ` Arnd Bergmann 2015-01-30 0:58 ` [PATCH 0/3] cpufreq: build fixes Rafael J. Wysocki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).