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 <redacted>
Cc: Kevin Hilman <redacted>
Cc: Lee Jones <redacted>
Cc: Linus Walleij <redacted>
Cc: Santosh Shilimkar <redacted>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <redacted>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Yong Shen <redacted>
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
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 <redacted>
Cc: Shawn Guo <redacted>
Cc: stable at vger.kernel.org
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
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 <redacted>
Cc: Lee Jones <redacted>
---
arch/arm/mach-ux500/Kconfig | 1 -
1 file changed, 1 deletion(-)
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 <redacted>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
---
arch/arm/mach-imx/mach-imx6q.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -71,7 +71,7 @@ soft:/* For imx6q sabrelite board: set KSZ9021RN RGMII pad skew */staticintksz9021rn_phy_fixup(structphy_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);
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 <redacted>
Cc: Shawn Guo <redacted>
Cc: stable at vger.kernel.org
---
arch/arm/mach-imx/Kconfig | 1 +
1 file changed, 1 insertion(+)
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 <redacted>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: stable at vger.kernel.org
---
arch/arm/mach-imx/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
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 <redacted>
Cc: Kevin Hilman <redacted>
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(-)
On Wed, Aug 22, 2012 at 8:43 PM, Arnd Bergmann [off-list ref] 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.
@@ -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_COUPLEDdev->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 ?
On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
quoted hunk
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 ?
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
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 <redacted>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: stable at vger.kernel.org
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 <redacted>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
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.
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 <redacted>
Cc: Shawn Guo <redacted>
Cc: stable at vger.kernel.org
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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
On Wed, Aug 22, 2012 at 10:52 PM, Arnd Bergmann [off-list ref] wrote:
On Wednesday 22 August 2012, Shilimkar, Santosh wrote:
quoted
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 ?
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
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
On Thu, Aug 23, 2012 at 5:42 PM, Arnd Bergmann [off-list ref] wrote:
On Thursday 23 August 2012, Shilimkar, Santosh wrote:
quoted
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 [off-list ref]
On Thursday 23 August 2012, Shilimkar, Santosh wrote:
On Thu, Aug 23, 2012 at 5:42 PM, Arnd Bergmann [off-list ref] wrote:
quoted
On Thursday 23 August 2012, Shilimkar, Santosh wrote:
quoted
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 [off-list ref]
On Wed, Aug 22, 2012 at 05:13:10PM +0200, Arnd Bergmann wrote:
quoted
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 <redacted>
Cc: Shawn Guo <redacted>
Cc: stable at vger.kernel.org
diff --git a/arch/arm/mach-imx/head-v7.S b/arch/arm/mach-imx/headsmp.Ssimilarity index 100%rename from arch/arm/mach-imx/head-v7.Srename to arch/arm/mach-imx/headsmp.S
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 <redacted>
Cc: Lee Jones <redacted>
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 <redacted>
Cc: Lee Jones <redacted>
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 <redacted>
quoted hunk
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 <redacted>
Cc: Shawn Guo <redacted>
Cc: stable at vger.kernel.org
diff --git a/arch/arm/mach-imx/head-v7.S b/arch/arm/mach-imx/headsmp.Ssimilarity index 100%rename from arch/arm/mach-imx/head-v7.Srename to arch/arm/mach-imx/headsmp.S