Patch from Gen FUKATSU

Invalidate BTB entry instruction flushes two instruction
at a time. Therefore this instruction should be done four
times after invalidate instruction cache line.

Signed-off-by: Gen Fukatsu
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Catalin Marinas

The warning is caused by the gic_set_cpu() function being defined but not
used if CONFIG_SMP is not defined.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Catalin Marinas

When CONFIG_CPU_CACHE_VIPT is defined, the flush_pfn_alias() function is
implicitely declared and it later conflicts with its actual definition.
This patch moves the function definition to the beginning of the file.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It's pointless to include mach-types.h if you're not going to use
anything from it.  These references were removed as a result of:

grep -lr 'asm/mach-types\.h' . | xargs grep -L 'machine_is_\|MACH_TYPE_\|MACHINE_START\|machine_type'
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Since asm/hardware.h's only reason for existing is to include
asm/arch/hardware.h, it's completely pointless to include both.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix
 arch/arm/mach-pxa/generic.c:242: warning: 'struct i2c_pxa_platform_data' declared inside parameter list
caused by missing asm/arch/i2c.h include.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

My previous patch fixing invalidation of huge PTEs wasn't good enough, we
still had an issue if a PTE invalidation batch contained both small and
large pages.  This patch fixes this by making sure the batch is flushed if
the page size fed to it changes.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Mikey and I were testing kexec and hit a lockup.  It turns out gcc 4.0
optimises the kexec_prepare_cpus loop so we avoid reloading paca.hw_cpu_id.
 A gcc barrier() fixes the problem.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This should resolve the issue seen in bugme bug #5105, where it is assumed
that dualcore x86_64 systems have synced TSCs.  This is not the case, and
alternate timesources should be used instead.

For more details, see:
http://bugzilla.kernel.org/show_bug.cgi?id=5105

Andi's earlier concerns that the TSCs should be synced on dualcore systems
have been resolved by confirmation from AMD folks that they can be
unsynced.
Acked-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I did something stupid in my oprofile fix, here's the obvious fix:
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

	arm maketools needs include/asm-arm in place in the build tree.
On normal builds it's always there, of course, but on O= it's created
(by generic code) too late - when we get to asm-offset.h.

	We used to get away with that by accident - creation of
include/asm-arm/arch symlink creates include/asm-arm and it happened
to go before maketools.  However, we did not have such dependency,
so that luck didn't last - now maketools is picked first and we are screwed.

	Both the symlink and maketools are prerequisites of the same
target (archprepare).  This fix is obvious - make the latter explicitly
depend on the former and be done with that.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

We do _not_ need "sparse" in sparse arguments ;-)

What we do need is __BIG_ENDIAN__; right now unconditional, when m32r
starts using CPU_LITTLE_ENDIAN, we'll need to adjust.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

	Most of these guys are simply not needed (pulled by other stuff
via asm-i386/hardirq.h).  One that is not entirely useless is hilarious -
arch/i386/oprofile/nmi_timer_int.c includes linux/irq.h... as a way to
get linux/errno.h
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

In order to do it correctly on UltraSPARC-III+ and later we'd
need to add some complicated code to set the TAG access extension
register before loading the TLB.

Since this optimization gives questionable gains, it's best to
just remove it for now instead of adding the fix for Ultra-III+
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It tries to batch up the tag loads and comparisons, and
then the stores.  And this is just complicated instead
of efficient.

Also, make the symbol of the Cheetah version more grepable.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Patch from Vincent Sanders

A recent patch which made IXP4xx mach_desc's depend on config options
had the effect of not building the kernel for several machines it
possibly could be, this patch updates the default config to ensure all
possible machines are built for by default.
Signed-off-by: NVincent Sanders <vince@arm.linux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from David Vrabel
Signed-off-by: NDavid Vrabel <dvrabel@arcom.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

At boot time, determine the D-cache, I-cache and E-cache size and
line-size.  Use them in cache flushes when appropriate.

This change was motivated by discovering that the D-cache on
UltraSparc-IIIi and later are 64K not 32K, and the flushes done by the
Cheetah error handlers were assuming a 32K size.

There are still some pieces of code that are hard coding things and
will need to be fixed up at some point.

While we're here, fix the D-cache and I-cache parity error handlers
to run with interrupts disabled, and when the trap occurs at trap
level > 1 log the event via a counter displayed in /proc/cpuinfo.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The trick is that we do the kernel linear mapping TLB miss starting
with an instruction sequence like this:

	ba,pt		%xcc, kvmap_load
	 xor		%g2, %g4, %g5

succeeded by an instruction sequence which performs a full page table
walk starting at swapper_pg_dir.

We first take over the trap table from the firmware.  Then, using this
constant PTE generation for the linear mapping area above, we build
the kernel page tables for the linear mapping.

After this is setup, we patch that branch above into a "nop", which
will cause TLB misses to fall through to the full page table walk.

With this, the page unmapping for CONFIG_DEBUG_PAGEALLOC is trivial.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

"1" needs to be "1UL", this is a 64-bit mask we're creating.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add 'volatile' to the __iomem pointers for these functions as
per x86.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

We accidentally corrupted the TLS value when clearing out the ARMv6
exclusive monitor.  Avoid doing so.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Current kernel has a couple of sneaky bugs in the ppc64 hugetlb code that
cause huge pages to be potentially left stale in the hash table and TLBs
(improperly invalidated), with all the nasty consequences that can have.

One is that we forgot to set the "secondary" bit in the hash PTEs when
hashing a huge page in the secondary bucket (fortunately very rare).

The other one is on non-LPAR machines (like Apple G5s), flush_hash_range()
which is used to flush a batch of PTEs simply did not work for huge pages.
Historically, our huge page code didn't batch, but this was changed without
fixing this routine.  This patch fixes both.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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

'highest_paddr' is set, but never actually used.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Remove io_remap_page_range() from all of Linux 2.6.x (as requested and
suggested by Randy Dunlap) and minor clean-ups.
Signed-off-by: NChris Zankel <chris@zankel.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

User get *a lot* confused when consoles don't work but we don't report
anything.  And, as reported in the comment, using printk to report "your
console doesn't work" isn't likely to go that far.

Fix the problem on the base of this: stack consumption by host printf().  Use
kernel sprintf() and os_write_file, using a wild guess that one page will be
enough for the message, to preallocate the buffer with kmalloc().
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

setup_initial_poll is only called with sigio_lock() held, so use appropriate
allocation.

Also, parse_chan() can also be called when holding a spinlock (see line_open()
 -> parse_chan_pair()).

I have sporadic problems (spinlock taken twice, with spinlock debugging on UP)
which could be caused by a sequence like "take spinlock, alloc and go to
sleep, take again the spinlock in the other thread".
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

GFP_ATOMIC | GFP_KERNEL is meaningless and won't work.  Actually it never
worked, even in 2.4.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Following i386, we should maybe refuse trying to fault in pages when we're
doing atomic operations, because to handle the fault we could need to take
already taken spinlocks.

Also, if we're doing an atomic operation (in the sense of in_atomic()) we're
surely in kernel mode and we're surely going to handle adequately the failed
fault, so it's safe to behave this way.

Currently, on UML SMP is rarely used, and we don't support PREEMPT, so this is
unlikely to create problems right now, but it might in the future.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Things are breaking horribly with sysrq called in interrupt context.  I want
to try to fix it, but probably this is simpler.  To tell the truth, sysrq is
normally run in interrupt context, so there shouldn't be any problem.

There's also a warning from the fault handler because it's run in atomic
context (I have a patch for that, only I deferred it).  This is why I'm doing
this.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Avoid setting w = 0 twice.  Spotted this (trivial) thing which is needed for
another patch.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The current code doesn't handle well general protection faults on the host -
it thinks that cr2 is always the address of a page fault.  While actually, on
general protection faults, that address is not accessible, so we'd better
assume we couldn't satisfy the fault.  Currently instead we think we've fixed
it, so we go back, retry the instruction and fault again endlessly.

This leads to the kernel hanging when doing copy_from_user(dest, -1, ...) in
TT mode, since reading *(-1) causes a GFP, and we don't support kernel
preemption.

Thanks to Luo Xin for testing UML with LTP and reporting the failures he got.

Cc: Luo Xin <luothing@sina.com>
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Simplify the code by using strlcat() instead of strncat() and manual
appending.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Only remove the UML pidfile and management socket if we created them.
Currently in case two UMLs are started with the same umid, the second will
remove the first's ones.

Probably we should also panic() at that point, not sure however.
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The SMU is the "system controller" chip used by Apple recent G5 machines
including the iMac G5.  It drives things like fans, i2c busses, real time
clock, etc...

The current kernel contains a very crude driver that doesn't do much more
than reading the real time clock synchronously.  This is a completely
rewritten driver that provides interrupt based command queuing, a userland
interface, and an i2c/smbus driver for accessing the devices hanging off
the SMU i2c busses like temperature sensors.  This driver is a basic block
for upcoming work on thermal control for those machines, among others.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Jean Delvare <khali@linux-fr.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix my stupid bug in the 64bit version of PTRACE_SET_DEBUGREG.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix build when iommu debug is enabled.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The recent iommu fix broke booting on some POWER4 and POWER5 LPAR boxes.

It looks like we have been calling the non LPAR iommu_dev_setup on LPAR
machines for a while. The recent iommu fix caused that code path to
fail.

It looks like we just need to hook up the devices iommu_table to the
parents one, so do that instead of calling iommu_dev_setup_pSeries and
crossing the streams.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>