[SPARC64]: Eliminate NR_CPUS limitations.

Cheetah systems can have cpuids as large as 1023, although physical
systems don't have that many cpus.

Only three limitations existed in the kernel preventing arbitrary
NR_CPUS values:

1) dcache dirty cpu state stored in page->flags on
   D-cache aliasing platforms.  With some build time
   calculations and some build-time BUG checks on
   page->flags layout, this one was easily solved.

2) The cheetah XCALL delivery code could only handle
   a cpumask with up to 32 cpus set.  Some simple looping
   logic clears that up too.

3) thread_info->cpu was a u8, easily changed to a u16.

There are a few spots in the kernel that still put NR_CPUS
sized arrays on the kernel stack, but that's not a sparc64
specific problem.

Signed-off-by: David S. Miller <davem@davemloft.net>

1 files changed, 1 insertions, 1 deletions

diff --git a/include/asm-sparc64/cpudata.h b/include/asm-sparc64/cpudata.h
index f321b1d21227..03c385de7619 100644
--- a/include/asm-sparc64/cpudata.h
+++ b/include/asm-sparc64/cpudata.h
@@ -202,7 +202,7 @@ extern struct sun4v_2insn_patch_entry __sun4v_2insn_patch,
  * the calculations done by the macro mid-stream.
  */
 #define LOAD_PER_CPU_BASE(DEST, THR, REG1, REG2, REG3)  \
-        ldub    [THR + TI_CPU], REG1;                   \
+        lduh    [THR + TI_CPU], REG1;                   \
         sethi   %hi(__per_cpu_shift), REG3;             \
         sethi   %hi(__per_cpu_base), REG2;              \
         ldx     [REG3 + %lo(__per_cpu_shift)], REG3;    \