into ppc970.osdl.org:/home/torvalds/v2.5/linux

From: Andreas Gruenbacher <agruen@suse.de>,
      and me.

Latest gcc cvs is able to detect mismatches between functions which are
tagged asmlinkage and declarations which are missing asmlinkage.  Or vice
versa.

Fix up the fallout from an x86 allyesconfig build.

From: "Randy.Dunlap" <rddunlap@osdl.org>

Add syscalls.h, which contains prototypes for the kernel's system calls.
Replace open-coded declarations all over the place.  This patch found a
couple of prior bugs.  It appears to be more important with -mregparm=3 as we
discover more asmlinkage mismatches.

Some syscalls have arch-dependent arguments, so their prototypes are in the
arch-specific unistd.h.  Maybe it should have been asm/syscalls.h, but there
were already arch-specific syscall prototypes in asm/unistd.h...

Tested on x86, ia64, x86_64, ppc64, s390 and sparc64.  May cause
trivial-to-fix build breakage on other architectures.

into ppc970.osdl.org:/home/torvalds/v2.5/linux

into ppc970.osdl.org:/home/torvalds/v2.5/linux

into intel.com:/home/lenb/src/linux-acpi-test-2.6.4

drivers/acpi/sleep/proc.c:359: warning: initialization from incompatible pointer type
drivers/acpi/sleep/proc.c:367: warning: initialization from incompatible pointer type

drivers/acpi/utils.c: In function `acpi_evaluate_reference':
drivers/acpi/utils.c:353: warning: unsigned int format, different type arg (arg 5)

into intel.com:/home/lenb/src/linux-acpi-test-2.6.4

into nuts.davemloft.net:/disk1/BK/sparc-2.6

into intel.com:/home/lenb/src/linux-acpi-test-2.6.4

From: Pavel Machek <pavel@suse.cz>

swsusp/s3 assembly parts, and parts called from assembly are not properly
marked asmlinkage; that leads to double fault on resume when someone
compiles kernel with regparm.  Thanks go to Stefan Seyfried for discovering
this.

From: James Morris <jmorris@redhat.com>

ENOTSUPP is the wrong value, and should not be returned to userspace.

From: Armin <armin@melware.de>

Pointers to __devexit functions must be wrapped with the __devexit_p()
macro.

From: Ian Wienand <ianw@gelato.unsw.edu.au>

- Fix inline function declarations

- Use #ifdef for CONFIG_*, not #if

From: David Woodhouse <dwmw2@infradead.org>

Don't jump between contexts.

(don't write comprehensible changelogs, either).

From: Albert Cahalan <albert@users.sourceforge.net>

Now that /dev/pts is using the 12:20 dev_t, a new procps is required.

From: Martine Silbermann <Martine.Silbermann@hp.com>

Having spent a non trivial amount of time trying to pull in the code to
enable MSI, I would suggest that a clear indication in Kconfig that MSI
requires CONFIG_PCI_USE_VECTOR would be very helpful.  Also since the MSI
code was integrated into 2.6.1 I've updated the comment that called for
installing the MSI patch.

That check I just added to sys_sysctl() is not needed: do_sysctl() checks as
well.

From: Arjan van de Ven <arjanv@redhat.com>

One of my machines prints the following in dmesg during boot;

CPU: Trace cache: 4K uops<6>CPU: L2 cache: 256K

cause is a missing \n being printed; fix below.

From: Arjan van de Ven <arjanv@redhat.com>

some more hardcoded THREAD_SIZE cleanups.

From: James Bottomley <James.Bottomley@SteelEye.com>

The alder has an intel Extended Express System Support Controller which
presents apparently spurious BARs.  When the pci resource code tries to
reassign these BARs, the second IO-APIC gets disabled (with disastrous
consequences).

The first BAR is the actual IO-APIC, the remaining five bars seem to be
spurious resources, so we forcibly insert the first one into the resource
tree and clear all the others.

From: James Bottomley <James.Bottomley@SteelEye.com>

This is a necessary precursor patch for getting the Intel Alder motherboard
working (it has a PCI device corresponding to the IO-APIC which has to be
forcibly inserted into the machine's reserved memory region).

Eric Biederman was going to come up with a more comprehensive fix, but in
the meantime, this is the minimum necessary to get insert_resource to work
when the covering region is larger than the resource being inserted.

From: Tim Hockin <thockin@sun.com>

Attached is a simple patch to expose NGROUPS_MAX via sysctl.  Nothing
fancy, just a read-only variable.  glibc can use this to sysconf() the
value properly, so apps will stop relying on NGROUPS_MAX as a real
constant.

From: Andi Kleen <ak@suse.de>,
     R. J. Wysocki

Without this make xconfig doesn't find the Qt library on systems using
/lib64 (like x86-64)

From: Jeremy Kerr <jk@ozlabs.org>

This patch is missing a single quote; here's a fix.

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.

into ppc970.osdl.org:/home/torvalds/v2.5/linux