ARM: multi_v7_defconfig, sunxi_defconfig: increase maximum number of CPUs

Hello,

I have recently been reviewing the kernel warnings generated from the kernelci.org boot farm, and have discovered that the HiP04 and a80-optimus boards have more CPUs then the maximum allowed in a few of the ARM defconfigs. This series fixes those warnings by increasing the maximum number of CPUs. I went ahead and boot tested these patches on various boards [1] to insure there are no regressions introduced when increasing the number of CPUs.

Any comments would be appreciated. Perhaps we may want to increase these limits further?

Thanks,

[1] http://kernelci.org/boot/all/job/tbaker/kernel/v3.19-rc4-845-g9f29e39a74a2/

Tyler Baker (2):
ARM: multi_v7_defconfig: increase the number of maximum number of CPUs to

    16

ARM: sunxi_defconfig: increase the number of maximum number of CPUs to 8

 arch/arm/configs/multi_v7_defconfig | 2 +-
 arch/arm/configs/sunxi_defconfig    | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

2.1.4

The HiSilicon HiP04 has 16 CPUs. I propose we increase the maximum number of CPUs to 16 to avoid the following warning identified during automated boot testing [1].

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at ../arch/arm/kernel/devtree.c:144 arm_dt_init_cpu_maps+0x118/0x1e8()
DT /cpu 9 nodes greater than max cores 8, capping them
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-00528-gbdccc4edeb03 #1
Hardware name: Hisilicon HiP04 (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (warn_slowpath_common+0x74/0xb0)
[] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from [] (arm_dt_init_cpu_maps+0x118/0x1e8)
[] (arm_dt_init_cpu_maps) from [] (setup_arch+0x638/0x9a0)
[] (setup_arch) from [] (start_kernel+0x8c/0x3b4)
[] (start_kernel) from [<10208074>] (0x10208074)
---[ end trace cb88537fdc8fa200 ]---

[1] http://storage.kernelci.org/mainline/v3.19-528-gbdccc4edeb03/arm-multi_v7_defconfig/lab-tbaker/boot-hip04-d01.html

---
 arch/arm/configs/multi_v7_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index e8a4c95..ad57306 100644
@@ -86,7 +86,7 @@ CONFIG_PCI_MVEBU=y
 CONFIG_PCI_TEGRA=y
 CONFIG_PCIEPORTBUS=y
 CONFIG_SMP=y
-CONFIG_NR_CPUS=8
+CONFIG_NR_CPUS=16
 CONFIG_HIGHPTE=y
 CONFIG_CMA=y
 CONFIG_ARM_APPENDED_DTB=y

2.1.4

The a80 optimus has 8 CPUs. I propose we increase the maximum number of CPUs to 8 to avoid the following warning identified during automated boot testing [1].

------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at ../arch/arm/kernel/devtree.c:144 arm_dt_init_cpu_maps+0x110/0x1e0()
DT /cpu 5 nodes greater than max cores 4, capping them
CPU: 0 PID: 0 Comm: swapper Not tainted 3.19.0-00528-gbdccc4edeb03 #1
Hardware name: Allwinner sun9i Family
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x74/0x90)
[] (dump_stack) from [] (warn_slowpath_common+0x70/0xac)
[] (warn_slowpath_common) from [] (warn_slowpath_fmt+0x30/0x40)
[] (warn_slowpath_fmt) from [] (arm_dt_init_cpu_maps+0x110/0x1e0)
[] (arm_dt_init_cpu_maps) from [] (setup_arch+0x634/0x8d4)
[] (setup_arch) from [] (start_kernel+0x88/0x3ac)
[] (start_kernel) from [<20008074>] (0x20008074)
---[ end trace cb88537fdc8fa200 ]---

[1] http://storage.kernelci.org/mainline/v3.19-528-gbdccc4edeb03/arm-sunxi_defconfig/lab-tbaker/boot-sun9i-a80-optimus.html

---
 arch/arm/configs/sunxi_defconfig | 1 +
 1 file changed, 1 insertion(+)

index 38840a8..8f6a570 100644
@@ -4,6 +4,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_PERF_EVENTS=y
 CONFIG_ARCH_SUNXI=y
 CONFIG_SMP=y
+CONFIG_NR_CPUS=8
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 CONFIG_HIGHPTE=y

2.1.4

Applied, thanks!

Maxime

Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150216/405acdd9/attachment.sig>

I've applied your version. Increasing the limit more would mainly cause memory to be wasted, so I don't think that's a good idea until we need to support other hardware.

Arnd

That seems sensible to me, thanks for picking this up.

Tyler