Update the ARM DMA scatter gather APIs for the scatterlist changes.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This replaces the original cache type decoding printks.  We now
indicate how we're treating the cache which we found, rather
than what we found.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Rather than trying to (inaccurately) decode the cache type from the
registers each time we need to decide what type of cache we have,
use a bitmask initialized early during boot.

Since the setup is a one-off initialization, we can be a little more
clever and take account of the CPU architecture as well.

Note that we continue to achieve the compactness on optimised kernels
by forcing tests to always-false or always-true as appropriate, thereby
allowing the compiler to do build-time code elimination.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The cache type register found in ARMv5 and later CPUs changes format
and meaning depending on the CPU architecture version.  Currently,
this code:
a) doesn't work for everything - Xscale's are identified as
   'unknown 5'.
b) is not able to tell whether the caches are VIVT or VIPT from the
   cache type.
c) prints rubbish on some ARMv6 and ARMv7+ CPUs.

The two solutions to this are:
1. Add yet more code to decode and print the various different register
   formats.
2. Remove the code altogther.

The code only exists to decode and print the cache parameters.
Increasing the complexity of it just for the sake of a few prinks
isn't worth it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

http://armlinux.simtec.co.uk/kautobuild/2.6.27-rc5/iop13xx_defconfig/zimage.log

Occurrences  Warning text
339  arch/arm/include/asm/dma-mapping.h:40: warning: return makes pointer from integer without a cast
203  arch/arm/include/asm/dma-mapping.h:45: warning: return makes integer from pointer without a cast
Acked-by: NDan Williams <dan.j.williams@intel.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This allows assembly files to be crafted to cover all ARM CPU types
rather than erroring out on instructions only in later CPUs.  We
are careful in these files to only execute CPU specific code when
the CPU ID says we can.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

... some of which are now in linux/*.h headers.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This quietens some sparse warnings about phys_initrd_start and
phys_initrd_size.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

pc_pointer() was a function to mask the PC for 26-bit ARMs, which
we no longer support.  Remove it.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

arch/arm/kernel/process.c:270:6: warning: symbol 'show_fpregs' was not declared. Should it be static?

This function isn't used, so can be removed.

arch/arm/kernel/setup.c:532:9: warning: symbol 'len' shadows an earlier one
arch/arm/kernel/setup.c:524:6: originally declared here

A function containing two 'len's.

arch/arm/mm/fault-armv.c:188:13: warning: symbol 'check_writebuffer_bugs' was not declared. Should it be static?
arch/arm/mm/mmap.c:122:5: warning: symbol 'valid_phys_addr_range' was not declared. Should it be static?
arch/arm/mm/mmap.c:137:5: warning: symbol 'valid_mmap_phys_addr_range' was not declared. Should it be static?

Missing includes.

arch/arm/kernel/traps.c:71:77: warning: Using plain integer as NULL pointer
arch/arm/mm/ioremap.c:355:46: error: incompatible types in comparison expression (different address spaces)

Sillies.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Since the other assembly functions do not seem to save the frame
pointer onto the stack, this patch changes the csum_partial_copy_*
functions to behave in the same way.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The post-index immediate value is optional if it is 0 and this patch
removes it. The reason is to allow such instructions to compile to
Thumb-2 where only pre-indexed LDRT/STRT instructions are allowed.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The last strnebt instruction has a post-index of 1 but the address
register is set to 0 in the next instruction, so no need for
post-indexing.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This declaration specifies the "function" type and size for various
assembly functions, mainly needed for generating the correct branch
instructions in Thumb-2.
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch adds a config option (CONFIG_VMSPLIT_*) to allow choosing
between 3:1, 2:2 and 1:3 user:kernel memory splits.
Tested-by: NRiku Voipio <riku.voipio@iki.fi>
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Logic for the p bit was reversed.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When CONFIG_DEBUG_BUGVERBOSE is not set, we get warnings such as:

arch/arm/mm/ioremap.c: In function ‘remap_area_pte’:
arch/arm/mm/ioremap.c:67: warning: control reaches end of non-void function
mm/bootmem.c: In function ‘mark_bootmem’:
mm/bootmem.c:321: warning: control reaches end of non-void function
fs/dcache.c: In function ‘d_materialise_unique’:
fs/dcache.c:1875: warning: control reaches end of non-void function
fs/nfs/client.c: In function ‘nfs_sockaddr_match_ipaddr’:
fs/nfs/client.c:251: warning: control reaches end of non-void function
block/cfq-iosched.c: In function ‘cfq_async_queue_prio’:
block/cfq-iosched.c:1501: warning: control reaches end of non-void function
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Linux/ARM currently doesn't support robust or PI futexes.
The problem is that the kernel wants to perform certain ops
(cmpxchg, set, add, or, andn, xor) atomically on user-space
addresses, and ARM's futex.h doesn't support that.

This patch adds that support, but only for uniprocessor machines.
For UP it's enough to disable preemption to ensure mutual exclusion
with other software agents (futexes don't need to care about other
hardware agents, fortunately).

This patch is based on one posted by Khem Raj on 2007-08-01
<http://marc.info/?l=linux-arm-kernel&m=118599407413016&w=2>.
(That patch is included in the -RT kernel patches.)
My changes since that version include:
* corrected implementation of FUTEX_OP_ANDN (must complement oparg)
* added missing memory clobber to futex_atomic_cmpxchg_inatomic()
* removed spinlock because it's unnecessary for UP and insufficient
  for SMP, instead the code is restricted to UP and relies on the
  fact that pagefault_disable() also disables preemption
* coding style cleanups

Tested on ARMv5 XScales with the glibc-2.6 nptl test suite.
Tested-by: NBruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

As mentioned in commit 79696910,
and because of commit b03a5b75,
the direct calling of kprobe_trap_handler() can be removed.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add Oprofile kernel support for ARMv7.
Tested on OMAP3430 and OMAP3530 chipsets (Cortex-A8).
Signed-off-by: NJean Pihet <jpihet@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Rather than pollute asm/cacheflush.h with the cache type definitions,
move them to asm/cachetype.h, and include this new header where
necessary.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Add asm/cputype.h, moving functions and definitions from asm/system.h
there.  Convert all users of 'processor_id' to the more efficient
read_cpuid_id() function.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This fixes a regression that was indirectly caused by commit
1184dc2f ("x86: modify Kconfig to allow
up to 4096 cpus").

Allowing 4k CPU's is not practical at this time, because we still have a
number of places that have several 'cpumask_t's on the stack, and a
4k-bit cpumask is 512 bytes of stack-space for each such variable.  This
literally caused functions like 'smp_call_function_mask' to have a 2.5kB
stack frame, and several functions to have 2kB stackframes.

With an 8kB stack total, smashing the stack was simply much too likely.
At least bugzilla entry

	http://bugzilla.kernel.org/show_bug.cgi?id=11342

was due to this.

The earlier commit to not inline load_module() into sys_init_module()
fixed the particular symptoms of this that Alan Brunelle saw in that
bugzilla entry, but the huge stack waste by cpumask_t's was the more
direct cause.

Some day we'll have allocation helpers that allocate large CPU masks
dynamically, but in the meantime we simply cannot allow cpumasks this
large.

Cc: Alan D. Brunelle <Alan.Brunelle@hp.com>
Cc: Mike Travis <travis@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The shadow code assigns a pte directly in one place, which is nonatomic on
i386 can can cause random memory references.  Fix by using an atomic setter.
Signed-off-by: NAvi Kivity <avi@qumranet.com>

I noticed that my sched_clock() was slow on a number of machine, so I
started looking at cpufreq.

The below seems to fix the problem for me.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

David Witbrodt tracked down (and bisected) a hpet bootup hang on his
system to the following problem: a BIOS bug made the hpet device
visible as a generic PCI device. If e820 reserved entries happen to
be registered first in the resource tree [which v2.6.26 started doing],
then the PCI code will reallocate that device's BAR to some other
address - breaking timer IRQs and hanging the system.

( Normally hpet devices are hidden by the BIOS from the OS's PCI
  discovery via chipset magic. Sometimes the hpet is not a PCI device
  at all. )

Solve this fundamental fragility by making non-PCI platform drivers
insert resources into the resource tree even if it overlaps the e820
reserved entry, to keep the resource manager from updating the BAR.

Also do these checks for the ioapic and mmconfig addresses, and emit
a warning if this happens.
Bisected-by: NDavid Witbrodt <dawitbro@sbcglobal.net>
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Tested-by: NDavid Witbrodt <dawitbro@sbcglobal.net>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: crash on non-TSC-equipped CPUs

Don't enable the TSC notifier if we *either*:

1. don't have a CPU, or
2. have a CPU with constant TSC.

In either of those cases, the notifier is either damaging (1) or useless(2).

From: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

This patch lets the files using linux/version.h match the files that
#include it.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

During CPU hot-remove the sysfs directory created by
threshold_create_bank(), defined in
arch/x86/kernel/cpu/mcheck/mce_amd_64.c, has to be removed before
its parent directory, created by mce_create_device(), defined in
arch/x86/kernel/cpu/mcheck/mce_64.c .  Moreover, when the CPU in
question is hotplugged again, obviously the latter has to be created
before the former.  At present, the right ordering is not enforced,
because all of these operations are carried out by CPU hotplug
notifiers which are not appropriately ordered with respect to each
other.  This leads to serious problems on systems with two or more
multicore AMD CPUs, among other things during suspend and hibernation.

Fix the problem by placing threshold bank CPU hotplug callbacks in
mce_cpu_callback(), so that they are invoked at the right places,
if defined.  Additionally, use kobject_del() to remove the sysfs
directory associated with the kobject created by
kobject_create_and_add() in threshold_create_bank(), to prevent the
kernel from crashing during CPU hotplug operations on systems with
two or more multicore AMD CPUs.

This patch fixes bug #11337.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NAndi Kleen <andi@firstfloor.org>
Tested-by: NMark Langsdorf <mark.langsdorf@amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Until now, PCI ECS setup was performed at boot time only and for cpus
that are enabled then. This patch fixes this and adds cpu hotplug.

Tests sequence (check if ECS bit is set when bringing cpu online again):

 # ( perl -e 'sysseek(STDIN, 0xC001001F, 0)'; hexdump -n 8 -e '2/4 "%08x " "\n"' )   < /dev/cpu/1/msr
 00000008 00404010
 # ( perl -e 'sysseek(STDOUT, 0xC001001F, 0); print pack "l*", 8, 0x00400010' ) > /dev/cpu/1/msr
 # ( perl -e 'sysseek(STDIN, 0xC001001F, 0)'; hexdump -n 8 -e '2/4 "%08x " "\n"' )   < /dev/cpu/1/msr
 00000008 00400010
 # echo 0 > /sys/devices/system/cpu/cpu1/online
 # echo 1 > /sys/devices/system/cpu/cpu1/online
 # ( perl -e 'sysseek(STDIN, 0xC001001F, 0)'; hexdump -n 8 -e '2/4 "%08x " "\n"' )   < /dev/cpu/1/msr
 00000008 00404010
Reported-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Jan Beulich wrote:

> Even worse - this would even try to access the MSR on non-AMD CPUs
> (currently probably prevented just by the fact that only AMD ones use
> family values of 0x10 or higher).

This patch adds cpu vendor check to the postcore_initcalls.
Reported-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

improve the debug printout:

- make it actually display something
- print it only once

would be nice to have a WARN_ONCE() facility, to feed such things to
kerneloops.org.
Signed-off-by: NIngo Molnar <mingo@elte.hu>

WARNING: vmlinux.o(.cpuinit.text+0x3cc4): Section mismatch in reference from the function uv_cpu_init() to the function .init.text:uv_system_init()
The function __cpuinit uv_cpu_init() references
a function __init uv_system_init().
If uv_system_init is only used by uv_cpu_init then
annotate uv_system_init with a matching annotation.

uv_system_init was ment to be called only once, so do it from codepath
(native_smp_prepare_cpus) which is called once, right before activation
of other cpus (smp_init).

Note: old code relied on uv_node_to_blade being initialized to 0,
but it'a not initialized from anywhere.
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Acked-by: NJack Steiner <steiner@sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>