On the larger ppc64 machines we remap the interrupt numbers used by
the hardware/firmware to virtual IRQ numbers < NR_IRQS.  Up until now
we have used an array for the "real" (hardware) -> virtual IRQ number
mapping, but with new machines coming out that will have 24-bit
hardware IRQ numbers, this will break.  However, in fact it is only
the XICS interrupt controller which cares about this mapping.  This
patch moves that side of the mapping (real -> virtual) into the XICS
code and makes it use a radix tree.

On iSeries we have a similar issue, where the "real" IRQ numbers that
we need are in fact an encoding of the bus/device/function address of
the device.  This patch fixes iSeries to use the virt->real IRQ
mapping, allowing us to support larger iSeries machines.  This patch
also gets rid of the temporary hack that Stephen Rothwell submitted.

On machines with OpenPIC (including the G5) the mapping is explicitly
1-1, and that hasn't changed.  For other machines this patch cleans up
and simplifies the code that sets up the virtual->real mapping.

I have tested this code and verified that G5, pSeries and iSeries boot
and run correctly with this patch.

From: Rusty Russell <rusty@rustcorp.com.au>

1) Check for cpuids >= NR_CPUS in prom_hold_cpus: we previously
   overflowed arrays when this happened, and checking it here ensures
   that it doesn't happen elsewhere.  Still move processors to
   secondary_hold (out of OF), but we won't release them.

2) smp_iSeries_message_pass and smp_xics_message_pass don't need to
   iterate if given a specific CPU: cleanup and fix.

3) kick_cpu variants don't need to check cpu range (caller is screwed
   anyway if this happened): replaced with BUG_ON for now.

4) smp_openpic_probe and smp_xics_probe can use cpus_weight(): it's
   faster and simpler.

5) User for_each_cpu/for_each_online_cpu as appropriate.

Theres still more to do here, but at least the ifdef mess is gone. No
more checking for NULL before calling functions, that was playing with
fire. Oh yeah and lots more deletions :)

Clean up the debugger hooks, it was way too easy to screw up.
And we did. And Linus hit it.

- create CONFIG_DEBUGGER so we can enable kernel debugging options but not
  have any trace of debugger gunk.
- remove a bunch of xmon prototypes so no one gets the urge to call them
- Use die() instead of panic in a number of places, it gives us much better
  debug information.
- Get rid of the ifdef madness

From: Anton Blanchard <anton@samba.org>

And SMT processor support & move back to a logical cpu numbering
in support of DLPAR work.

From: Anton Blanchard <anton@samba.org>

Attached is a patch which replaces all the uses of the old device tree API in
arch/ppc64.  Patch is against 2.6.0-test5 (cset 1.1328) from ameslab bk, plus
the patch from my previous message.  I've tested this on a pSeries LPAR.

From: William Lee Irwin III <wli@holomorphy.com>

Contributions from:
	Jan Dittmer <jdittmer@sfhq.hn.org>
	Arnd Bergmann <arnd@arndb.de>
	"Bryan O'Sullivan" <bos@serpentine.com>
	"David S. Miller" <davem@redhat.com>
	Badari Pulavarty <pbadari@us.ibm.com>
	"Martin J. Bligh" <mbligh@aracnet.com>
	Zwane Mwaikambo <zwane@linuxpower.ca>

It has ben tested on x86, sparc64, x86_64, ia64 (I think), ppc and ppc64.

cpumask_t enables systems with NR_CPUS > BITS_PER_LONG to utilize all their
cpus by creating an abstract data type dedicated to representing cpu
bitmasks, similar to fd sets from userspace, and sweeping the appropriate
code to update callers to the access API.  The fd set-like structure is
according to Linus' own suggestion; the macro calling convention to ambiguate
representations with minimal code impact is my own invention.

Specifically, a new set of inline functions for manipulating arbitrary-width
bitmaps is introduced with a relatively simple implementation, in tandem with
a new data type representing bitmaps of width NR_CPUS, cpumask_t, whose
accessor functions are defined in terms of the bitmap manipulation inlines.
This bitmap ADT found an additional use in i386 arch code handling sparse
physical APIC ID's, which was convenient to use in this case as the
accounting structure was required to be wider to accommodate the physids
consumed by larger numbers of cpus.

For the sake of simplicity and low code impact, these cpu bitmasks are passed
primarily by value; however, an additional set of accessors along with an
auxiliary data type with const call-by-reference semantics is provided to
address performance concerns raised in connection with very large systems,
such as SGI's larger models, where copying and call-by-value overhead would
be prohibitive.  Few (if any) users of the call-by-reference API are
immediately introduced.

Also, in order to avoid calling convention overhead on architectures where
structures are required to be passed by value, NR_CPUS <= BITS_PER_LONG is
special-cased so that cpumask_t falls back to an unsigned long and the
accessors perform the usual bit twiddling on unsigned longs as opposed to
arrays thereof.  Audits were done with the structure overhead in-place,
restoring this special-casing only afterward so as to ensure a more complete
API conversion while undergoing the majority of its end-user exposure in -mm.
 More -mm's were shipped after its restoration to be sure that was tested,
too.

The immediate users of this functionality are Sun sparc64 systems, SGI mips64
and ia64 systems, and IBM ia32, ppc64, and s390 systems.  Of these, only the
ppc64 machines needing the functionality have yet to be released; all others
have had systems requiring it for full functionality for at least 6 months,
and in some cases, since the initial Linux port to the affected architecture.

From: David Gibson <david@gibson.dropbear.id.au>

xics.c uses ppc64_boot_msg() without prototype, this fixes it by inclding
<asm/machdep.h>.

PPC64 irq return fix

iSeries (AS/400).

There are no changes outside of include/asm-ppc64 and arch/ppc64
in this changeset.