Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

It's cc-option not cc-options.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

tee was already there for some reason for native 64bit, but
sys_sync_file_range was missing. Also add it to the compat layer.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

o Start booting into the capture kernel after an Oops if system is in a
  unrecoverable state. System will boot into the capture kernel, if one is
  pre-loaded by the user, and capture the kernel core dump.

o One of the following conditions should be true to trigger the booting of
  capture kernel.
        - panic_on_oops is set.
        - pid of current thread is 0
        - pid of current thread is 1
        - Oops happened inside interrupt context.
Signed-off-by: NVivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The patch I submitted earlier to fix disabled LAPIC handling in ACPI
was mismerged for some reason I still don't quite understand. Parts
of it was applied to the wrong function.

This patch fixes it up.

Cc: len.brown@intel.com
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We weren't using the recommended sequence for putting the CPU into
nap mode.  When I changed the idle loop, for some reason 7447A cpus
started hanging when we put them into nap mode.  Changing to the
recommended sequence fixes that.

The complexity here is that the recommended sequence is a loop that
keeps putting the cpu back into nap mode.  Clearly we need some way
to break out of the loop when an interrupt (external interrupt,
decrementer, performance monitor) occurs.  Here we use a bit in
the thread_info struct to indicate that we need this, and the exception
entry code notices this and arranges for the exception to return
to the value in the link register, thus breaking out of the loop.
We use a new `local_flags' field in the thread_info which we can
alter without needing to use an atomic update sequence.

The PPC970 has the same recommended sequence, so we do the same thing
there too.

This also fixes a bug in the kernel stack overflow handling code on
32-bit, since it was causing a value that we needed in a register to
get trashed.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

SYM2 driver uses it.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The at91_cf driver got out of sync with certain changes in the PCMCIA
layer, notably getting rid of some duplication of data ... causing the
version merged to kernel.org to fail compiling.

This patch gives the at91_cf platform device a new iomem resource, using
it so this new pcmcia scheme works.  It also cleans up some whitepsace
bugs that have accumulated over time (mostly too-long lines).
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

I use 2.6.15.6 Linux kernel and found some problems. I have about 100
Linux boxes (all with the same (binary the same) kernel). Last time I have
upgraded all those boxes from 2.4.32 to 2.6.15.6 (first 2.6.15.1, next .2,
.4 and .6) and I have found some problems on VIA based PC's. Probably the
reason of this is that some VIA chipsets are unrecognized by IRQ router.

In line 586 there is: /* FIXME: add new ones for 8233/5 */

There were only a few of chipsets ID's there, some of my VIA chipsets were
not present and kernel used default IRQ router.

I have added three entries, so that the code looks like:

        case PCI_DEVICE_ID_VIA_82C596:
        case PCI_DEVICE_ID_VIA_82C686:
        case PCI_DEVICE_ID_VIA_8231:
        case PCI_DEVICE_ID_VIA_8233A:
        case PCI_DEVICE_ID_VIA_8235:
        case PCI_DEVICE_ID_VIA_8237:
        case PCI_DEVICE_ID_VIA_8237_SATA:
                /* FIXME: add new ones for 8233/5 */
                r->name = "VIA";
                r->get = pirq_via_get;
                r->set = pirq_via_set;
                return 1;
        }

The kernel goes fine but I haven't testes it for weeks, I'm just a moment
after reboot :)
One thing is different (better?):
Using previus kernel I had:
PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 0
now I have:
PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 11

Maybe it is good idea to add there some more VIA chipsets?
The ones I have added seem to be OK.

From: Grzegorz Janoszka <Grzegorz@Janoszka.pl>
Acked-by: NMartin Mares <mj@ucw.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

dmi_scan.c is arch-independent and is used by i386, x86_64, and ia64.
Currently all three arches compile it from arch/i386, which means that ia64
and x86_64 depend on things in arch/i386 that they wouldn't otherwise care
about.

This is simply "mv arch/i386/kernel/dmi_scan.c drivers/firmware/" (removing
trailing whitespace) and the associated Makefile changes.  All three
architectures already set CONFIG_DMI in their top-level Kconfig files.
Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
Cc: Andi Kleen <ak@muc.de>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Andrey Panin <pazke@orbita1.ru>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

This patch modifies ia64's show_mem() to walk the vmem_map page tables and
rapidly skip forward across regions where the page tables are missing.
This prevents the pfn_valid() check from causing numerous unnecessary
page faults.

Without this patch on a 512 node 512 cpu system where every node has four
memory holes, the show_mem() call takes 1 hour 18 minutes.  With this
patch, it takes less than 3 seconds.
Signed-off-by: NRobin Holt <holt@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

ia64_wait_for_slaves() was changed in 2.6.17-rc1 to report the slave
state.  It incorrectly assumes that all slaves are for MCA, but
ia64_wait_for_slaves() is also called from the INIT monarch handler.
The existing message is very misleading, so correct it.
Signed-off-by: NKeith Owens <kaos@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

We found that when the 'decrementer' is saved, the PPE saves the current
time 'csa->suspend_time'. When restoring the 'decrementer', (Step 34)
decrementer seems to be adjusted with the number of cycles th= at a spu
thread has not been running.

In that code it is missing a substract ('-') because 'delta_time' is
assigned a not substracted(see bellow).
Acked-by: NMark Nutter <mnutter@us.ibm.com>
Signed-off-by: NArnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Compile the 32bit kernel with -mcpu=powerpc. This reduces the imagesize
when a compiler is used that defaults to -mtune=power4. It inserts lots
of nops to please the 64bit cpu instruction scheduling. But all these nops
are not needed for 32bit kernels.

Example with SLES10 gcc 4.1.0 and arch/powerpc/configs/pmac32_defconfig:

                    vmlinux  vmlinux.strip  vmlinux.gz
 -O2                4980515     4187528      1846829
 -Os                4618801     3827084      1673333
 -O2 -mcpu=powerpc  4738851     3945868      1816253
 -Os -mcpu=powerpc  4532785     3741068      1664688
Signed-off-by: NOlaf Hering <olh@suse.de>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Repeated calls to eeh_remove_device() can result in multiple
(and thus unbalanced) calls to pci_dev_put(). Make sure the
pci_device_put() is called only once (since there was only
one call to the matching pci_device_get()).
Signed-off-by: NLinas Vepstas <linas@austin.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

In e8222502 the detection of machine types
in prom_init broke for some machines. We should be checking /device_type
instead of /model. This should make Power3 and Power4 boot again. Haven't
been able to test this.  We also need to relocate before comparing.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NMichael Neuling <mikey@neuling.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Fixed odd function behavior when dev->bus_id does not contain '.' - it
compared that case 0 characters of the string and hereby reported success and
executed callback. Now bus_id's are compared correctly, extra callback
triggering eliminated.
Signed-off-by: NVitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Fix __initcall return in proc_rtas_init and rtas_init.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Since external and decrementer interrupts set the runlatch on, we need
to ensure its set off again in the idle loop. At the moment we dont turn
it off in the inner loop.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Patch from Ben Dooks

Fix bad spelling of partition
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Ben Dooks

The wrong variable is written back to CLKDIVN
register if the USB PLL speed is above 94MHz
Signed-off-by: NBen Dooks <ben-linux@fluff.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Basically an in-kernel implementation of tee, which uses splice and the
pipe buffers as an intelligent way to pass data around by reference.

Where the user space tee consumes the input and produces a stdout and
file output, this syscall merely duplicates the data inside a pipe to
another pipe. No data is copied, the output just grabs a reference to the
input pipe data.
Signed-off-by: NJens Axboe <axboe@suse.de>

Surprising that it still worked at all with this - yes it was
tested.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Nobody should pass NULL here. Could in theory make it a BUG,
but the NULL pointer oops will do as well.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

It's not actually needed and would break non power of two number
of cores.

Follows similar earlier x86-64 patch.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

As pointed out by Linus it is useless now because entry.S should
handle it correctly in all cases.
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When nolapic was passed or the local APIC was disabled
for another reason ACPI would still parse the IO-APICs
until these were explicitely disabled with noapic.

Usually this resulted in a non booting configuration unless
"nolapic noapic" was used.

I also disabled the local APIC parsing in this case, although
that's only cosmetic (suppresses a few printks)

This hopefully makes nolapic work in all cases.

Cc: Len Brown <len.brown@intel.com>
Signed-off-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>