[PATCH 0/6] ARM: randconfig bugs

[PATCH 0/6] ARM: randconfig bugs

[Arnd Bergmann]

Hi everyone,

Here are some more patches for bugs I found using
'make randconfig' in v3.6-rc+multiplatform. I can
to merge them through the arm-soc tree, but please
have a look and provide Acks.

	Arnd

---
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Yong Shen <yong.shen@linaro.org>


Arnd Bergmann (6):
  ARM: ux500: don't select LEDS_GPIO for snowball
  ARM: omap: allow building omap44xx without SMP
  ARM: imx: build pm-imx5 code only when PM is enabled
  ARM: imx: fix ksz9021rn_phy_fixup
  ARM: imx: select CPU_FREQ_TABLE when needed
  ARM: imx: select ARM_CPU_SUSPEND when necessary

 arch/arm/Kconfig                  |    1 +
 arch/arm/mach-imx/Kconfig         |    1 +
 arch/arm/mach-imx/Makefile        |    3 ++-
 arch/arm/mach-imx/mach-imx6q.c    |    4 ++--
 arch/arm/mach-omap2/Kconfig       |    2 +-
 arch/arm/mach-omap2/cpuidle44xx.c |    3 ++-
 arch/arm/mach-ux500/Kconfig       |    1 -
 include/linux/cpuidle.h           |    4 ++++
 8 files changed, 13 insertions(+), 6 deletions(-)

-- 
1.7.10

[PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball

[Arnd Bergmann]

The gpio leds driver can only be built if the generic LED code is
also enabled. Snowball selects LEDS_GPIO for an unknown reason
but it does not select LEDS_CLASS and also does not really require
the LED support at all, so we can just drop this dependency.

Without this patch, building without LEDS_CLASS esults in:

drivers/built-in.o: In function `create_gpio_led.part.2':
governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `gpio_led_remove':
governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'

This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
support for Snowball", which was not completely thought through.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>
---
 arch/arm/mach-ux500/Kconfig |    1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index c013bbf..53d3d46 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -41,7 +41,6 @@ config MACH_HREFV60
 config MACH_SNOWBALL
 	bool "U8500 Snowball platform"
 	select MACH_MOP500
-	select LEDS_GPIO
 	help
 	  Include support for the snowball development platform.
 
-- 
1.7.10

[PATCH 2/6] ARM: omap: allow building omap44xx without SMP

[Arnd Bergmann]

The new omap4 cpuidle implementation currently requires
ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.

This patch makes it possible to build a non-SMP kernel
for that platform. This is not normally desired for
end-users but can be useful for testing.

Without this patch, building rand-0y2jSKT results in:

drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]

It's not clear if this patch is the best solution for
the problem at hand. I have made sure that we can now
build the kernel in all configurations, but that does
not mean it will actually work on an OMAP44xx.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/Kconfig       |    2 +-
 arch/arm/mach-omap2/cpuidle44xx.c |    3 ++-
 include/linux/cpuidle.h           |    4 ++++
 3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd2db02..66a8be3 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -62,7 +62,7 @@ config ARCH_OMAP4
 	select PM_OPP if PM
 	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 	select ARM_CPU_SUSPEND if PM
-	select ARCH_NEEDS_CPU_IDLE_COUPLED
+	select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
 
 config SOC_OMAP5
 	bool "TI OMAP5"
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index ee05e19..288bee6 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -238,8 +238,9 @@ int __init omap4_idle_init(void)
 	for_each_cpu(cpu_id, cpu_online_mask) {
 		dev = &per_cpu(omap4_idle_dev, cpu_id);
 		dev->cpu = cpu_id;
+#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
 		dev->coupled_cpus = *cpu_online_mask;
-
+#endif
 		cpuidle_register_driver(&omap4_idle_driver);
 
 		if (cpuidle_register_device(dev)) {
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index 040b13b..279b1ea 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -194,6 +194,10 @@ static inline int cpuidle_play_dead(void) {return -ENODEV; }
 
 #ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
 void cpuidle_coupled_parallel_barrier(struct cpuidle_device *dev, atomic_t *a);
+#else
+static inline void cpuidle_coupled_parallel_barrier(struct cpuidle_device *dev, atomic_t *a)
+{
+}
 #endif
 
 /******************************
-- 
1.7.10

[PATCH 3/6] ARM: imx: build pm-imx5 code only when PM is enabled

[Arnd Bergmann]

This moves the imx5 pm code out of the list of unconditionally
compiled files for imx5, mirroring what we already do for imx6
and how it was done before the code was move from mach-mx5 to
mach-imx in v3.3.

Without this patch, building with CONFIG_PM disabled results in:

arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init'
arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here
arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init'
arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: stable@vger.kernel.org
---
 arch/arm/mach-imx/Makefile |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 07f7c22..e08adb7 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -9,7 +9,8 @@ obj-$(CONFIG_SOC_IMX27) += clk-imx27.o mm-imx27.o ehci-imx27.o
 obj-$(CONFIG_SOC_IMX31) += mm-imx3.o cpu-imx31.o clk-imx31.o iomux-imx31.o ehci-imx31.o pm-imx3.o
 obj-$(CONFIG_SOC_IMX35) += mm-imx3.o cpu-imx35.o clk-imx35.o ehci-imx35.o pm-imx3.o
 
-obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o pm-imx5.o cpu_op-mx51.o
+imx5-pm-$(CONFIG_PM) += pm-imx5.o
+obj-$(CONFIG_SOC_IMX5) += cpu-imx5.o mm-imx5.o clk-imx51-imx53.o ehci-imx5.o $(imx5-pm-y) cpu_op-mx51.o
 
 obj-$(CONFIG_COMMON_CLK) += clk-pllv1.o clk-pllv2.o clk-pllv3.o clk-gate2.o \
 			    clk-pfd.o clk-busy.o
-- 
1.7.10

[PATCH 4/6] ARM: imx: fix ksz9021rn_phy_fixup

[Arnd Bergmann]

The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to
set up an ethernet phy if they can. They do check whether
phylib is enabled, but unfortunately the functions can only
be called from platform code if phylib is builtin, not
if it is a module

Without this patch, building with a modular phylib results in:

arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init':
arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared (first use in this function)
arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is reported only once for each function it appears in

The bug was originally reported by Artem Bityutskiy but only
partially fixed in ef441806 "ARM: imx6q: register phy fixup only when
CONFIG_PHYLIB is enabled".

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/mach-imx6q.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index 5ec0608..045b3f6 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -71,7 +71,7 @@ soft:
 /* For imx6q sabrelite board: set KSZ9021RN RGMII pad skew */
 static int ksz9021rn_phy_fixup(struct phy_device *phydev)
 {
-	if (IS_ENABLED(CONFIG_PHYLIB)) {
+	if (IS_BUILTIN(CONFIG_PHYLIB)) {
 		/* min rx data delay */
 		phy_write(phydev, 0x0b, 0x8105);
 		phy_write(phydev, 0x0c, 0x0000);
@@ -112,7 +112,7 @@ put_clk:
 
 static void __init imx6q_sabrelite_init(void)
 {
-	if (IS_ENABLED(CONFIG_PHYLIB))
+	if (IS_BUILTIN(CONFIG_PHYLIB))
 		phy_register_fixup_for_uid(PHY_ID_KSZ9021, MICREL_PHY_ID_MASK,
 				ksz9021rn_phy_fixup);
 	imx6q_sabrelite_cko1_setup();
-- 
1.7.10

[PATCH 5/6] ARM: imx: select CPU_FREQ_TABLE when needed

[Arnd Bergmann]

The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
so it needs to select that code to be built. This problem has
apparently existed since the i.MX cpufreq code was first merged
in v3.6.37.

Building IMX without CPU_FREQ_TABLE results in:

arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Yong Shen <yong.shen@linaro.org>
Cc: Shawn Guo <shawn.guo@freescale.com>
Cc: stable@vger.kernel.org
---
 arch/arm/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..84b5a0c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -2150,6 +2150,7 @@ source "drivers/cpufreq/Kconfig"
 config CPU_FREQ_IMX
 	tristate "CPUfreq driver for i.MX CPUs"
 	depends on ARCH_MXC && CPU_FREQ
+	select CPU_FREQ_TABLE
 	help
 	  This enables the CPUfreq driver for i.MX CPUs.
 
-- 
1.7.10

[PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary

[Arnd Bergmann]

On i.MX6, we select ARM_CPU_SUSPEND when building with power management
support, but for some reason this was omitted on i.MX5. Normally we
build kernels for both together so the error only showed up in
randconfig tests.

Without this patch, building imx5 standalone results in:

arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: stable@vger.kernel.org
---
 arch/arm/mach-imx/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index afd542a..8e96573 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -89,6 +89,7 @@ config SOC_IMX5
 	select ARCH_MXC_IOMUX_V3
 	select ARCH_HAS_CPUFREQ
 	select ARCH_MX5
+	select ARM_CPU_SUSPEND if PM
 	bool
 
 config SOC_IMX50
-- 
1.7.10

Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP

[Shilimkar, Santosh]

On Wed, Aug 22, 2012 at 8:43 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The new omap4 cpuidle implementation currently requires
> ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP.
>
> This patch makes it possible to build a non-SMP kernel
> for that platform. This is not normally desired for
> end-users but can be useful for testing.
>
> Without this patch, building rand-0y2jSKT results in:
>
> drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke':
> drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration]
>
> It's not clear if this patch is the best solution for
> the problem at hand. I have made sure that we can now
> build the kernel in all configurations, but that does
> not mean it will actually work on an OMAP44xx.
>
Am not sure either about the subject patch.

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Kevin Hilman <khilman@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/mach-omap2/Kconfig       |    2 +-
>  arch/arm/mach-omap2/cpuidle44xx.c |    3 ++-
>  include/linux/cpuidle.h           |    4 ++++
>  3 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index dd2db02..66a8be3 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -62,7 +62,7 @@ config ARCH_OMAP4
>         select PM_OPP if PM
>         select USB_ARCH_HAS_EHCI if USB_SUPPORT
>         select ARM_CPU_SUSPEND if PM
> -       select ARCH_NEEDS_CPU_IDLE_COUPLED
> +       select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP
>
>  config SOC_OMAP5
>         bool "TI OMAP5"
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index ee05e19..288bee6 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -238,8 +238,9 @@ int __init omap4_idle_init(void)
>         for_each_cpu(cpu_id, cpu_online_mask) {
>                 dev = &per_cpu(omap4_idle_dev, cpu_id);
>                 dev->cpu = cpu_id;
> +#ifdef CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED
>                 dev->coupled_cpus = *cpu_online_mask;
> -
> +#endif

Was just thinking whether we should just take care of it at
core cpuidle level itself. Will below be enough to kill the build
error what you mentioned in the change log ?

diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
index 2c9bf26..df34534 100644
--- a/drivers/cpuidle/coupled.c
+++ b/drivers/cpuidle/coupled.c
@@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
        struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);

        if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
+#ifdef CONFIG_SMP
                __smp_call_function_single(cpu, csd, 0);
+#endif
 }

 /**

Regards
Santosh

Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP

[Arnd Bergmann]

On Wednesday 22 August 2012, Shilimkar, Santosh wrote:

> Was just thinking whether we should just take care of it at
> core cpuidle level itself. Will below be enough to kill the build
> error what you mentioned in the change log ?
> 
> diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> index 2c9bf26..df34534 100644
> --- a/drivers/cpuidle/coupled.c
> +++ b/drivers/cpuidle/coupled.c
> @@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
>         struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb, cpu);
> 
>         if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> +#ifdef CONFIG_SMP
>                 __smp_call_function_single(cpu, csd, 0);
> +#endif
>  }
> 

That would work, but isn't the entire concept of the cpuidle-coupled driver
dependent on SMP? If this driver makes no sense on UP, I think we should
not attempt to build it.

	Arnd

Re: [PATCH 3/6] ARM: imx: build pm-imx5 code only when PM is enabled

[Shawn Guo]

On Wed, Aug 22, 2012 at 05:13:07PM +0200, Arnd Bergmann wrote:
> This moves the imx5 pm code out of the list of unconditionally
> compiled files for imx5, mirroring what we already do for imx6
> and how it was done before the code was move from mach-mx5 to
> mach-imx in v3.3.
> 
> Without this patch, building with CONFIG_PM disabled results in:
> 
> arch/arm/mach-imx/pm-imx5.c:202:116: error: redefinition of 'imx51_pm_init'
> arch/arm/mach-imx/include/mach-imx/common.h:154:91: note: previous definition of 'imx51_pm_init' was here
> arch/arm/mach-imx/pm-imx5.c:209:116: error: redefinition of 'imx53_pm_init'
> arch/arm/mach-imx/include/mach-imx/common.h:155:91: note: previous definition of 'imx53_pm_init' was here
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: stable@vger.kernel.org

Acked-by: Shawn Guo <shawn.guo@linaro.org>

Re: [PATCH 4/6] ARM: imx: fix ksz9021rn_phy_fixup

[Shawn Guo]

On Wed, Aug 22, 2012 at 05:13:08PM +0200, Arnd Bergmann wrote:
> The ksz9021rn_phy_fixup and mx6q_sabrelite functions try to
> set up an ethernet phy if they can. They do check whether
> phylib is enabled, but unfortunately the functions can only
> be called from platform code if phylib is builtin, not
> if it is a module
> 
> Without this patch, building with a modular phylib results in:
> 
> arch/arm/mach-imx/mach-imx6q.c: In function 'imx6q_sabrelite_init':
> arch/arm/mach-imx/mach-imx6q.c:120:5: error: 'ksz9021rn_phy_fixup' undeclared (first use in this function)
> arch/arm/mach-imx/mach-imx6q.c:120:5: note: each undeclared identifier is reported only once for each function it appears in
> 
> The bug was originally reported by Artem Bityutskiy but only
> partially fixed in ef441806 "ARM: imx6q: register phy fixup only when
> CONFIG_PHYLIB is enabled".
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Artem Bityutskiy <dedekind1@gmail.com>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>

Acked-by: Shawn Guo <shawn.guo@linaro.org>

Re: [PATCH 5/6] ARM: imx: select CPU_FREQ_TABLE when needed

[Shawn Guo]

On Wed, Aug 22, 2012 at 05:13:09PM +0200, Arnd Bergmann wrote:
> The i.MX cpufreq implementation uses the CPU_FREQ_TABLE helpers,
> so it needs to select that code to be built. This problem has
> apparently existed since the i.MX cpufreq code was first merged
> in v3.6.37.
> 
s/v3.6.37/v2.6.37?

Otherwise,

Acked-by: Shawn Guo <shawn.guo@linaro.org>

> Building IMX without CPU_FREQ_TABLE results in:
> 
> arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_exit':
> arch/arm/plat-mxc/cpufreq.c:173: undefined reference to `cpufreq_frequency_table_put_attr'
> arch/arm/plat-mxc/built-in.o: In function `mxc_set_target':
> arch/arm/plat-mxc/cpufreq.c:84: undefined reference to `cpufreq_frequency_table_target'
> arch/arm/plat-mxc/built-in.o: In function `mxc_verify_speed':
> arch/arm/plat-mxc/cpufreq.c:65: undefined reference to `cpufreq_frequency_table_verify'
> arch/arm/plat-mxc/built-in.o: In function `mxc_cpufreq_init':
> arch/arm/plat-mxc/cpufreq.c:154: undefined reference to `cpufreq_frequency_table_cpuinfo'
> arch/arm/plat-mxc/cpufreq.c:162: undefined reference to `cpufreq_frequency_table_get_attr'
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Yong Shen <yong.shen@linaro.org>
> Cc: Shawn Guo <shawn.guo@freescale.com>
> Cc: stable@vger.kernel.org
> ---
>  arch/arm/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index e91c7cd..84b5a0c 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -2150,6 +2150,7 @@ source "drivers/cpufreq/Kconfig"
>  config CPU_FREQ_IMX
>  	tristate "CPUfreq driver for i.MX CPUs"
>  	depends on ARCH_MXC && CPU_FREQ
> +	select CPU_FREQ_TABLE
>  	help
>  	  This enables the CPUfreq driver for i.MX CPUs.
>  
> -- 
> 1.7.10
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary

[Shawn Guo]

On Wed, Aug 22, 2012 at 05:13:10PM +0200, Arnd Bergmann wrote:
> On i.MX6, we select ARM_CPU_SUSPEND when building with power management
> support, but for some reason this was omitted on i.MX5. Normally we
> build kernels for both together so the error only showed up in
> randconfig tests.
> 
> Without this patch, building imx5 standalone results in:
> 
> arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
> 
So far, none of the functions in head-v7.S is used on imx5.  Also
since imx5 SoCs implement State Retention Power Gating in hardware,
ARM_CPU_SUSPEND support will never be used on imx5.

Maybe we should make head-v7.S only compile for imx6?

Regards,
Shawn

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Miao <eric.miao@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: stable@vger.kernel.org
> ---
>  arch/arm/mach-imx/Kconfig |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index afd542a..8e96573 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -89,6 +89,7 @@ config SOC_IMX5
>  	select ARCH_MXC_IOMUX_V3
>  	select ARCH_HAS_CPUFREQ
>  	select ARCH_MX5
> +	select ARM_CPU_SUSPEND if PM
>  	bool
>  
>  config SOC_IMX50
> -- 
> 1.7.10
> 

Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP

[Shilimkar, Santosh]

On Wed, Aug 22, 2012 at 10:52 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
>
> > Was just thinking whether we should just take care of it at
> > core cpuidle level itself. Will below be enough to kill the build
> > error what you mentioned in the change log ?
> >
> > diff --git a/drivers/cpuidle/coupled.c b/drivers/cpuidle/coupled.c
> > index 2c9bf26..df34534 100644
> > --- a/drivers/cpuidle/coupled.c
> > +++ b/drivers/cpuidle/coupled.c
> > @@ -314,7 +314,9 @@ static void cpuidle_coupled_poke(int cpu)
> >         struct call_single_data *csd = &per_cpu(cpuidle_coupled_poke_cb,
> > cpu);
> >
> >         if (!cpumask_test_and_set_cpu(cpu, &cpuidle_coupled_poked_mask))
> > +#ifdef CONFIG_SMP
> >                 __smp_call_function_single(cpu, csd, 0);
> > +#endif
> >  }
> >
>
> That would work, but isn't the entire concept of the cpuidle-coupled
> driver
> dependent on SMP? If this driver makes no sense on UP, I think we should
> not attempt to build it.
>
I see your point but alternate patch is pushing down the fix to the low
level driver and that means you end up patching more drivers when they
use COUPLE idle infrastructure. That was the only reason I was thinking
of suppressing the error at the source.

Since it is just for the random builds and actually doesn't impact the real
functionality as such, I am fine with your proposed patch too.

Regards
santosh

Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP

[Arnd Bergmann]

On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> I see your point but alternate patch is pushing down the fix to the low
> level driver and that means you end up patching more drivers when they
> use COUPLE idle infrastructure. That was the only reason I was thinking
> of suppressing the error at the source.
> 
> Since it is just for the random builds and actually doesn't impact the real
> functionality as such, I am fine with your proposed patch too.

Ok. It would be nice of course to test if this actually works on uniprocessor
configurations.

	Arnd

Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP

[Shilimkar, Santosh]

On Thu, Aug 23, 2012 at 5:42 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> > I see your point but alternate patch is pushing down the fix to the low
> > level driver and that means you end up patching more drivers when they
> > use COUPLE idle infrastructure. That was the only reason I was thinking
> > of suppressing the error at the source.
> >
> > Since it is just for the random builds and actually doesn't impact the
> > real
> > functionality as such, I am fine with your proposed patch too.
>
> Ok. It would be nice of course to test if this actually works on
> uniprocessor
> configurations.
>
Have tested the patch and it does boot with UP build on OMAP.

Acked-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Re: [PATCH 2/6] ARM: omap: allow building omap44xx without SMP

[Arnd Bergmann]

On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> 
> On Thu, Aug 23, 2012 at 5:42 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Thursday 23 August 2012, Shilimkar, Santosh wrote:
> > > I see your point but alternate patch is pushing down the fix to the low
> > > level driver and that means you end up patching more drivers when they
> > > use COUPLE idle infrastructure. That was the only reason I was thinking
> > > of suppressing the error at the source.
> > >
> > > Since it is just for the random builds and actually doesn't impact the
> > > real
> > > functionality as such, I am fine with your proposed patch too.
> >
> > Ok. It would be nice of course to test if this actually works on
> > uniprocessor
> > configurations.
> >
> Have tested the patch and it does boot with UP build on OMAP.
> 
> Acked-tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

Ok, thanks a lot!

	Arnd

Re: [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary

[Arnd Bergmann]

On Thursday 23 August 2012, Shawn Guo wrote:
> On Wed, Aug 22, 2012 at 05:13:10PM +0200, Arnd Bergmann wrote:
> > On i.MX6, we select ARM_CPU_SUSPEND when building with power management
> > support, but for some reason this was omitted on i.MX5. Normally we
> > build kernels for both together so the error only showed up in
> > randconfig tests.
> > 
> > Without this patch, building imx5 standalone results in:
> > 
> > arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> > arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
> > 
> So far, none of the functions in head-v7.S is used on imx5.  Also
> since imx5 SoCs implement State Retention Power Gating in hardware,
> ARM_CPU_SUSPEND support will never be used on imx5.
> 
> Maybe we should make head-v7.S only compile for imx6?

In tegra and shmobile, the respective file is called headsmp.S, so
I would suggest we rename it to the same here and only build it when
CONFIG_SMP is set, which comes down to imx6 at the moment.

How is this version?

	Arnd

>From 4036e8f292887e7b1abc8eacec7d619abd608178 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Fri, 17 Aug 2012 00:16:08 +0000
Subject: [PATCH] ARM: imx: build i.MX6 functions only when needed

The head-v7.S contains a call to the generic cpu_suspend function,
which is only available when selected by the i.MX6 code. As
pointed out by Shawn Guo, i.MX does not actually use any
functions defined in head-v7.S. It is also needed only for
the i.MX6 power management code and for the SMP code, so
we can restrict building this file to situations in which
at least one of those two is present.

Finally, other platforms with a similar file call it headsmp.S,
so we can rename it to the same for consistency.

Without this patch, building imx5 standalone results in:

arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Eric Miao <eric.miao@linaro.org>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: stable@vger.kernel.org

diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index e08adb7..d004d37 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -71,14 +71,13 @@ obj-$(CONFIG_DEBUG_LL) += lluart.o
 obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
 obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
 obj-$(CONFIG_HAVE_IMX_SRC) += src.o
-obj-$(CONFIG_CPU_V7) += head-v7.o
-AFLAGS_head-v7.o :=-Wa,-march=armv7-a
-obj-$(CONFIG_SMP) += platsmp.o
+AFLAGS_headsmp.o :=-Wa,-march=armv7-a
+obj-$(CONFIG_SMP) += headsmp.o platsmp.o
 obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
 obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
 
 ifeq ($(CONFIG_PM),y)
-obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o
+obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
 endif
 
 # i.MX5 based machines
diff --git a/arch/arm/mach-imx/head-v7.S b/arch/arm/mach-imx/headsmp.S
similarity index 100%
rename from arch/arm/mach-imx/head-v7.S
rename to arch/arm/mach-imx/headsmp.S

Re: [PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball

[Arnd Bergmann]

On Wednesday 22 August 2012, Arnd Bergmann wrote:
> The gpio leds driver can only be built if the generic LED code is
> also enabled. Snowball selects LEDS_GPIO for an unknown reason
> but it does not select LEDS_CLASS and also does not really require
> the LED support at all, so we can just drop this dependency.
> 
> Without this patch, building without LEDS_CLASS esults in:
> 
> drivers/built-in.o: In function `create_gpio_led.part.2':
> governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
> drivers/built-in.o: In function `gpio_led_remove':
> governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'
> 
> This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
> support for Snowball", which was not completely thought through.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Lee Jones <lee.jones@linaro.org>

I discussed this with Lee on IRC, he really wants to keep the LED enabled for snowball
for his own convenience. How is this version instead?

	Arnd

>From 53c4e002b7ebd70ad9dcfa7a97c0ae58e874e643 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Wed, 15 Aug 2012 20:34:48 +0000
Subject: [PATCH] ARM: ux500: don't select LEDS_GPIO for snowball

The gpio leds driver can only be built if the generic LED code is
also enabled. Snowball selects LEDS_GPIO for an unknown reason
but it does not select LEDS_CLASS and also does not really require
the LED support at all, so we can just drop this dependency.

Without this patch, building without LEDS_CLASS esults in:

drivers/built-in.o: In function `create_gpio_led.part.2':
governor_userspace.c:(.devinit.text+0x5a58): undefined reference to `led_classdev_register'
drivers/built-in.o: In function `gpio_led_remove':
governor_userspace.c:(.devexit.text+0x6b8): undefined reference to `led_classdev_unregister'

This reverts 8733f53c6 "ARM: ux500: Kconfig: Compile in leds-gpio
support for Snowball", which was not completely thought through.

In order to leave the GPIO LED code still present in normal
builds, this also enables the symbol in u8500_defconfig, in addition
to the other LED drivers that are already selected there.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Lee Jones <lee.jones@linaro.org>

diff --git a/arch/arm/configs/u8500_defconfig b/arch/arm/configs/u8500_defconfig
index 2d4f661..da68454 100644
--- a/arch/arm/configs/u8500_defconfig
+++ b/arch/arm/configs/u8500_defconfig
@@ -86,6 +86,7 @@ CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_LM3530=y
 CONFIG_LEDS_LP5521=y
+CONFIG_LEDS_GPIO=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_AB8500=y
 CONFIG_RTC_DRV_PL031=y
diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
index c013bbf..53d3d46 100644
--- a/arch/arm/mach-ux500/Kconfig
+++ b/arch/arm/mach-ux500/Kconfig
@@ -41,7 +41,6 @@ config MACH_HREFV60
 config MACH_SNOWBALL
 	bool "U8500 Snowball platform"
 	select MACH_MOP500
-	select LEDS_GPIO
 	help
 	  Include support for the snowball development platform.
 

Re: [PATCH 6/6] ARM: imx: select ARM_CPU_SUSPEND when necessary

[Shawn Guo]

On Thu, Aug 23, 2012 at 02:20:50PM +0000, Arnd Bergmann wrote:
> From 4036e8f292887e7b1abc8eacec7d619abd608178 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Fri, 17 Aug 2012 00:16:08 +0000
> Subject: [PATCH] ARM: imx: build i.MX6 functions only when needed
> 
> The head-v7.S contains a call to the generic cpu_suspend function,
> which is only available when selected by the i.MX6 code. As
> pointed out by Shawn Guo, i.MX does not actually use any

s/i.MX/i.MX5

Acked-by: Shawn Guo <shawn.guo@linaro.org>

> functions defined in head-v7.S. It is also needed only for
> the i.MX6 power management code and for the SMP code, so
> we can restrict building this file to situations in which
> at least one of those two is present.
> 
> Finally, other platforms with a similar file call it headsmp.S,
> so we can rename it to the same for consistency.
> 
> Without this patch, building imx5 standalone results in:
> 
> arch/arm/mach-imx/built-in.o: In function `v7_cpu_resume':
> arch/arm/mach-imx/head-v7.S:104: undefined reference to `cpu_resume'
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Eric Miao <eric.miao@linaro.org>
> Cc: Shawn Guo <shawn.guo@linaro.org>
> Cc: stable@vger.kernel.org
> 
> diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
> index e08adb7..d004d37 100644
> --- a/arch/arm/mach-imx/Makefile
> +++ b/arch/arm/mach-imx/Makefile
> @@ -71,14 +71,13 @@ obj-$(CONFIG_DEBUG_LL) += lluart.o
>  obj-$(CONFIG_HAVE_IMX_GPC) += gpc.o
>  obj-$(CONFIG_HAVE_IMX_MMDC) += mmdc.o
>  obj-$(CONFIG_HAVE_IMX_SRC) += src.o
> -obj-$(CONFIG_CPU_V7) += head-v7.o
> -AFLAGS_head-v7.o :=-Wa,-march=armv7-a
> -obj-$(CONFIG_SMP) += platsmp.o
> +AFLAGS_headsmp.o :=-Wa,-march=armv7-a
> +obj-$(CONFIG_SMP) += headsmp.o platsmp.o
>  obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
>  obj-$(CONFIG_SOC_IMX6Q) += clk-imx6q.o mach-imx6q.o
>  
>  ifeq ($(CONFIG_PM),y)
> -obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o
> +obj-$(CONFIG_SOC_IMX6Q) += pm-imx6q.o headsmp.o
>  endif
>  
>  # i.MX5 based machines
> diff --git a/arch/arm/mach-imx/head-v7.S b/arch/arm/mach-imx/headsmp.S
> similarity index 100%
> rename from arch/arm/mach-imx/head-v7.S
> rename to arch/arm/mach-imx/headsmp.S

-- 
Regards,
Shawn

Re: [PATCH 1/6] ARM: ux500: don't select LEDS_GPIO for snowball

[Linus Walleij]

On Thu, Aug 23, 2012 at 7:26 AM, Arnd Bergmann <arnd@arndb.de> wrote:

> I discussed this with Lee on IRC, he really wants to keep the LED enabled for snowball
> for his own convenience. How is this version instead?

Sure, I guess you already merged it though?

Acked-by.

Yours,
Linus Walleij