[ARM] Fix SMP initialisation oops

A change to the SMP initialisation caused the following oops:

 CPU1: Booted secondary processor
 CPU1: D VIPT write-back cache
 CPU1: I cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
 CPU1: D cache: 32768 bytes, associativity 4, 32 byte lines, 256 sets
 <7>Calibrating delay loop... 83.14 BogoMIPS (lpj=415744)
 <1>Unable to handle kernel NULL pointer dereference at virtual address 0000001c
 ...
 PC is at enqueue_task+0x1c/0x64
 LR is at activate_task+0xcc/0xe4

SMP initialisation now requires cpu_possible_map to be initialised in
setup_arch().  Move this from smp_prepare_cpus() to smp_init_cpus()
and call it from our setup_arch() if CONFIG_SMP is enabled.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

arch/arm/mach-integrator/platsmp.c

@@ -140,6 +140,18 @@ static void __init poke_milo(void)
 	mb();
 }
 
+/*
+ * Initialise the CPU possible map early - this describes the CPUs
+ * which may be present or become present in the system.
+ */
+void __init smp_init_cpus(void)
+{
+	unsigned int i, ncores = get_core_count();
+
+	for (i = 0; i < ncores; i++)
+		cpu_set(i, cpu_possible_map);
+}
+
 void __init smp_prepare_cpus(unsigned int max_cpus)
 {
 	unsigned int ncores = get_core_count();
@@ -176,14 +188,11 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		max_cpus = ncores;
 
 	/*
-	 * Initialise the possible/present maps.
-	 * cpu_possible_map describes the set of CPUs which may be present
-	 * cpu_present_map describes the set of CPUs populated
+	 * Initialise the present map, which describes the set of CPUs
+	 * actually populated at the present time.
 	 */
-	for (i = 0; i < max_cpus; i++) {
-		cpu_set(i, cpu_possible_map);
+	for (i = 0; i < max_cpus; i++)
 		cpu_set(i, cpu_present_map);
-	}
 
 	/*
 	 * Do we need any more CPUs? If so, then let them know where