Verified using the below proglet.. before:

[root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 0
remote write

 Performance counter stats for './numa 0':

         2,101,554 node-stores
         2,096,931 node-store-misses

       5.021546079 seconds time elapsed

[root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 1
local write

 Performance counter stats for './numa 1':

           501,137 node-stores
               199 node-store-misses

       5.124451068 seconds time elapsed

After:

[root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 0
remote write

 Performance counter stats for './numa 0':

         2,107,516 node-stores
         2,097,187 node-store-misses

       5.012755149 seconds time elapsed

[root@westmere ~]# perf stat -e node-stores -e node-store-misses ./numa 1
local write

 Performance counter stats for './numa 1':

         2,063,355 node-stores
               165 node-store-misses

       5.082091494 seconds time elapsed

#define _GNU_SOURCE

#include <sched.h>
#include <stdio.h>
#include <errno.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <dirent.h>
#include <signal.h>
#include <unistd.h>
#include <numaif.h>
#include <stdlib.h>

#define SIZE (32*1024*1024)

volatile int done;

void sig_done(int sig)
{
	done = 1;
}

int main(int argc, char **argv)
{
	cpu_set_t *mask, *mask2;
	size_t size;
	int i, err, t;
	int nrcpus = 1024;
	char *mem;
	unsigned long nodemask = 0x01; /* node 0 */
	DIR *node;
	struct dirent *de;
	int read = 0;
	int local = 0;

	if (argc < 2) {
		printf("usage: %s [0-3]\n", argv[0]);
		printf("  bit0 - local/remote\n");
		printf("  bit1 - read/write\n");
		exit(0);
	}

	switch (atoi(argv[1])) {
	case 0:
		printf("remote write\n");
		break;
	case 1:
		printf("local write\n");
		local = 1;
		break;
	case 2:
		printf("remote read\n");
		read = 1;
		break;
	case 3:
		printf("local read\n");
		local = 1;
		read = 1;
		break;
	}

	mask = CPU_ALLOC(nrcpus);
	size = CPU_ALLOC_SIZE(nrcpus);
	CPU_ZERO_S(size, mask);

	node = opendir("/sys/devices/system/node/node0/");
	if (!node)
		perror("opendir");
	while ((de = readdir(node))) {
		int cpu;

		if (sscanf(de->d_name, "cpu%d", &cpu) == 1)
			CPU_SET_S(cpu, size, mask);
	}
	closedir(node);

	mask2 = CPU_ALLOC(nrcpus);
	CPU_ZERO_S(size, mask2);
	for (i = 0; i < size; i++)
		CPU_SET_S(i, size, mask2);
	CPU_XOR_S(size, mask2, mask2, mask); // invert

	if (!local)
		mask = mask2;

	err = sched_setaffinity(0, size, mask);
	if (err)
		perror("sched_setaffinity");

	mem = mmap(0, SIZE, PROT_READ|PROT_WRITE,
			MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
	err = mbind(mem, SIZE, MPOL_BIND, &nodemask, 8*sizeof(nodemask), MPOL_MF_MOVE);
	if (err)
		perror("mbind");

	signal(SIGALRM, sig_done);
	alarm(5);

	if (!read) {
		while (!done) {
			for (i = 0; i < SIZE; i++)
				mem[i] = 0x01;
		}
	} else {
		while (!done) {
			for (i = 0; i < SIZE; i++)
				t += *(volatile char *)(mem + i);
		}
	}

	return 0;
}
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Stephane Eranian <eranian@google.com>
Cc: <stable@kernel.org>
Link: http://lkml.kernel.org/n/tip-tq73sxus35xmqpojf7ootxgs@git.kernel.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>

Commit f0fbf0ab ("x86: integrate delay functions") converted
delay_tsc() into a random delay generator for 64 bit.  The reason is
that it merged the mostly identical versions of delay_32.c and
delay_64.c.  Though the subtle difference of the result was:

 static void delay_tsc(unsigned long loops)
 {
-	unsigned bclock, now;
+	unsigned long bclock, now;

Now the function uses rdtscl() which returns the lower 32bit of the
TSC. On 32bit that's not problematic as unsigned long is 32bit. On 64
bit this fails when the lower 32bit are close to wrap around when
bclock is read, because the following check

       if ((now - bclock) >= loops)
       	  	break;

evaluated to true on 64bit for e.g. bclock = 0xffffffff and now = 0
because the unsigned long (now - bclock) of these values results in
0xffffffff00000001 which is definitely larger than the loops
value. That explains Tvortkos observation:

"Because I am seeing udelay(500) (_occasionally_) being short, and
 that by delaying for some duration between 0us (yep) and 491us."

Make those variables explicitely u32 again, so this works for both 32
and 64 bit.
Reported-by: NTvrtko Ursulin <tvrtko.ursulin@onelan.co.uk>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org # >= 2.6.27
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fixed following:
arch/arm/mach-s3c2440/s3c244x.c: In function 's3c244x_restart':
arch/arm/mach-s3c2440/s3c244x.c:209: error: expected declaration or statement at end of input
make[1]: *** [arch/arm/mach-s3c24xx/s3c244x.o] Error 1
make: *** [arch/arm/mach-s3c24xx] Error 2
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

There was a latent typo in the C6X KSTK_EIP and KSTK_ESP macros which
caused a problem with a new patch which used them. The broken definitions
were of the form:

  #define KSTK_FOO(tsk) (task_pt_regs(task)->foo)

Note the use of task vs tsk. This actually worked before because the
only place in the kernel which used these macros passed in a local
pointer named task.
Signed-off-by: NMark Salter <msalter@redhat.com>

When a CPU is taken out of reset, either cold booted or hotplugged in,
some of its PMU registers can contain UNKNOWN values.

This patch adds a hotplug notifier to ARM core perf code so that upon
CPU restart the PMU unit is reset and becomes ready to use again.
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

xscale2 PMUs indicate overflow not via the PMU control register, but by
a separate overflow FLAG register instead.

This patch fixes the xscale2 PMU code to use this register to detect
to overflow and ensures that we clear any pending overflow when
disabling a counter.

Cc: <stable@vger.kernel.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The PMU IRQ handlers in perf assume that if a counter has overflowed
then perf must be responsible. In the paranoid world of crazy hardware,
this could be false, so check that we do have a valid event before
attempting to dereference NULL in the interrupt path.

Cc: <stable@vger.kernel.org>
Signed-off-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

When disabling a counter on an ARMv7 PMU, we should also clear the
overflow flag in case an overflow occurred whilst stopping the counter.
This prevents a spurious overflow being picked up later and leading to
either false accounting or a NULL dereference.

Cc: <stable@vger.kernel.org>
Reported-by: NMing Lei <tom.leiming@gmail.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

On ARM, the PMU does not stop counting after an overflow and therefore
IRQ latency affects the new counter value read by the kernel. This is
significant for non-sampling runs where it is possible for the new value
to overtake the previous one, causing the delta to be out by up to
max_period events.

Commit a737823d ("ARM: 6835/1: perf: ensure overflows aren't missed due
to IRQ latency") attempted to fix this problem by allowing interrupt
handlers to pass an overflow flag to the event update function, causing
the overflow calculation to assume that the counter passed through zero
when going from prev to new. Unfortunately, this doesn't work when
overflow occurs on the perf_task_tick path because we have the flag
cleared and end up computing a large negative delta.

This patch removes the overflow flag from armpmu_event_update and
instead limits the sample_period to half of the max_period for
non-sampling profiling runs.

Cc: <stable@vger.kernel.org>
Signed-off-by: NMing Lei <ming.lei@canonical.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It turns out that test-compiling this file on x86-64 doesn't really
help, because much of it is x86-32-specific.  And so I hadn't noticed
the slightly over-eager removal of the 'r' from 'addr' variable despite
thinking I had tested it.
Signed-off-by: NLinus "oopsie" Torvalds <torvalds@linux-foundation.org>

Several users of "find_vma_prev()" were not in fact interested in the
previous vma if there was no primary vma to be found either.  And in
those cases, we're much better off just using the regular "find_vma()",
and then "prev" can be looked up by just checking vma->vm_prev.

The find_vma_prev() semantics are fairly subtle (see Mikulas' recent
commit 83cd904d: "mm: fix find_vma_prev"), and the whole "return
prev by reference" means that it generates worse code too.

Thus this "let's avoid using this inconvenient and clearly too subtle
interface when we don't really have to" patch.

Cc: Mikulas Patocka <mpatocka@redhat.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

As done for the other ep93xx machines in:

commit 9a6879bd
ARM: ep93xx: convert to MULTI_IRQ_HANDLER

Now that there is a generic IRQ handler for multiple VIC devices use it
for vision_ep9307 to help building multi platform kernels.
Signed-off-by: NHartley Sweeten <hsweeten@visionengravers.com>
Acked-by: NRyan Mallon <rmallon@gmail.com>
Reviewed-by: NJamie Iles <jamie@jamieiles.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Fixes atmel_mxt_ts freeze on Universal C210.
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Split out optprobe related code to arch/x86/kernel/kprobes-opt.c
for maintenanceability.
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Suggested-by: NIngo Molnar <mingo@elte.hu>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: yrl.pp-manager.tt@hitachi.com
Cc: systemtap@sourceware.org
Cc: anderson@redhat.com
Link: http://lkml.kernel.org/r/20120305133222.5982.54794.stgit@localhost.localdomain
[ Tidied up the code a tiny bit ]
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Fix a bug in kprobes which can modify kernel code
permanently at run-time. In the result, kernel can
crash when it executes the modified code.

This bug can happen when we put two probes enough near
and the first probe is optimized. When the second probe
is set up, it copies a byte which is already modified
by the first probe, and executes it when the probe is hit.
Even worse, the first probe and the second probe are removed
respectively, the second probe writes back the copied
(modified) instruction.

To fix this bug, kprobes always recovers the original
code and copies the first byte from recovered instruction.
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: yrl.pp-manager.tt@hitachi.com
Cc: systemtap@sourceware.org
Cc: anderson@redhat.com
Link: http://lkml.kernel.org/r/20120305133215.5982.31991.stgit@localhost.localdomainSigned-off-by: NIngo Molnar <mingo@elte.hu>

Current probed-instruction recovery expects that only breakpoint
instruction modifies instruction. However, since kprobes jump
optimization can replace original instructions with a jump,
that expectation is not enough. And it may cause instruction
decoding failure on the function where an optimized probe
already exists.

This bug can reproduce easily as below:

1) find a target function address (any kprobe-able function is OK)

 $ grep __secure_computing /proc/kallsyms
   ffffffff810c19d0 T __secure_computing

2) decode the function
   $ objdump -d vmlinux --start-address=0xffffffff810c19d0 --stop-address=0xffffffff810c19eb

  vmlinux:     file format elf64-x86-64

Disassembly of section .text:

ffffffff810c19d0 <__secure_computing>:
ffffffff810c19d0:       55                      push   %rbp
ffffffff810c19d1:       48 89 e5                mov    %rsp,%rbp
ffffffff810c19d4:       e8 67 8f 72 00          callq
ffffffff817ea940 <mcount>
ffffffff810c19d9:       65 48 8b 04 25 40 b8    mov    %gs:0xb840,%rax
ffffffff810c19e0:       00 00
ffffffff810c19e2:       83 b8 88 05 00 00 01    cmpl $0x1,0x588(%rax)
ffffffff810c19e9:       74 05                   je     ffffffff810c19f0 <__secure_computing+0x20>

3) put a kprobe-event at an optimize-able place, where no
 call/jump places within the 5 bytes.
 $ su -
 # cd /sys/kernel/debug/tracing
 # echo p __secure_computing+0x9 > kprobe_events

4) enable it and check it is optimized.
 # echo 1 > events/kprobes/p___secure_computing_9/enable
 # cat ../kprobes/list
 ffffffff810c19d9  k  __secure_computing+0x9    [OPTIMIZED]

5) put another kprobe on an instruction after previous probe in
  the same function.
 # echo p __secure_computing+0x12 >> kprobe_events
 bash: echo: write error: Invalid argument
 # dmesg | tail -n 1
 [ 1666.500016] Probing address(0xffffffff810c19e2) is not an instruction boundary.

6) however, if the kprobes optimization is disabled, it works.
 # echo 0 > /proc/sys/debug/kprobes-optimization
 # cat ../kprobes/list
 ffffffff810c19d9  k  __secure_computing+0x9
 # echo p __secure_computing+0x12 >> kprobe_events
 (no error)

This is because kprobes doesn't recover the instruction
which is overwritten with a relative jump by another kprobe
when finding instruction boundary.
It only recovers the breakpoint instruction.

This patch fixes kprobes to recover such instructions.

With this fix:

 # echo p __secure_computing+0x9 > kprobe_events
 # echo 1 > events/kprobes/p___secure_computing_9/enable
 # cat ../kprobes/list
 ffffffff810c1aa9  k  __secure_computing+0x9    [OPTIMIZED]
 # echo p __secure_computing+0x12 >> kprobe_events
 # cat ../kprobes/list
 ffffffff810c1aa9  k  __secure_computing+0x9    [OPTIMIZED]
 ffffffff810c1ab2  k  __secure_computing+0x12    [DISABLED]

Changes in v4:
 - Fix a bug to ensure optimized probe is really optimized
   by jump.
 - Remove kprobe_optready() dependency.
 - Cleanup code for preparing optprobe separation.

Changes in v3:
 - Fix a build error when CONFIG_OPTPROBE=n. (Thanks, Ingo!)
   To fix the error, split optprobe instruction recovering
   path from kprobes path.
 - Cleanup comments/styles.

Changes in v2:
 - Fix a bug to recover original instruction address in
   RIP-relative instruction fixup.
 - Moved on tip/master.
Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: yrl.pp-manager.tt@hitachi.com
Cc: systemtap@sourceware.org
Cc: anderson@redhat.com
Link: http://lkml.kernel.org/r/20120305133209.5982.36568.stgit@localhost.localdomainSigned-off-by: NIngo Molnar <mingo@elte.hu>

Failure is reported on hx4700 with kernel v3.3-rc1.

__mfp_validate: GPIO20 is invalid pin
__mfp_validate: GPIO21 is invalid pin
__mfp_validate: GPIO15 is invalid pin
__mfp_validate: GPIO78 is invalid pin
__mfp_validate: GPIO79 is invalid pin
__mfp_validate: GPIO80 is invalid pin
__mfp_validate: GPIO33 is invalid pin
__mfp_validate: GPIO48 is invalid pin
__mfp_validate: GPIO49 is invalid pin
__mfp_validate: GPIO50 is invalid pin

Since pxa_last_gpio is used in mfp-pxa2xx driver. But it's only
updated in pxa-gpio driver that run after mfp-pxa2xx driver.

So update the pxa_last_gpio first in mfp-pxa2xx driver.
Reported-by: NPaul Parsons <lost.distance@yahoo.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>

Both reboot (via reboot(RB_AUTOBOOT)) and suspend freeze on hx4700.

Registration of pxa_gpio_syscore_ops is moved into pxa-gpio driver,
but it still exists in arch-pxa directory. It resulsts failure on
reboot and suspend.

Now remove the registration code in arch-pxa.
Reported-by: NPaul Parsons <lost.distance@yahoo.com>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@gmail.com>

gpio-pxa driver is shared among arch-pxa and arch-mmp. Clock is the
essential component on pxa3xx/pxa95x and arch-mmp. So we need to
define dummy clock in pxa25x/pxa27x instead.

This regression was introduced by the commit "ARM: pxa: add dummy
clock for sa1100-rtc", id a55b5ada.
Reported-by: NJonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: NPaul Parsons <lost.distance@yahoo.com>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NHaojian Zhuang <haojian.zhuang@marvell.com>

Michael Cree said:

: : I have noticed some user space problems (pulseaudio crashes in pthread
: : code, glibc/nptl test suite failures, java compiler freezes on SMP alpha
: : systems) that arise when using a 2.6.39 or later kernel on Alpha.
: : Bisecting between 2.6.38 and 2.6.39 (using glibc/nptl test suite as
: : criterion for good/bad kernel) eventually leads to:
: :
: : 8d7718aa is the first bad commit
: : commit 8d7718aa
: : Author: Michel Lespinasse <walken@google.com>
: : Date:   Thu Mar 10 18:50:58 2011 -0800
: :
: :     futex: Sanitize futex ops argument types
: :
: :     Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic
: :     prototypes to use u32 types for the futex as this is the data type the
: :     futex core code uses all over the place.
: :
: : Looking at the commit I see there is a change of the uaddr argument in
: : the Alpha architecture specific code for futexes from int to u32, but I
: : don't see why this should cause a problem.

Richard Henderson said:

: futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
:                               u32 oldval, u32 newval)
: ...
:         :       "r"(uaddr), "r"((long)oldval), "r"(newval)
:
:
: There is no 32-bit compare instruction.  These are implemented by
: consistently extending the values to a 64-bit type.  Since the
: load instruction sign-extends, we want to sign-extend the other
: quantity as well (despite the fact it's logically unsigned).
:
: So:
:
: -        :       "r"(uaddr), "r"((long)oldval), "r"(newval)
: +        :       "r"(uaddr), "r"((long)(int)oldval), "r"(newval)
:
: should do the trick.

Michael said:

: This fixes the glibc test suite failures and the pulseaudio related
: crashes, but it does not fix the java compiiler lockups that I was (and
: are still) observing.  That is some other problem.
Reported-by: NMichael Cree <mcree@orcon.net.nz>
Tested-by: NMichael Cree <mcree@orcon.net.nz>
Acked-by: NPhil Carmody <ext-phil.2.carmody@nokia.com>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Michel Lespinasse <walken@google.com>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Reviewed-by: NMatt Turner <mattst88@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Our TLB ops want to check the vma vm_flags to find out whether the
mapping is executable.  However, we leave this uninitialized in
ecard.c.  Initialize it with an appropriate value.
Reported-by: NAl Viro <viro@ftp.linux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

While building modules with randconfig the below errors are observed.

ERROR: "omap_bus_sync" [drivers/watchdog/sp805_wdt.ko] undefined!
ERROR: "omap_bus_sync" [drivers/watchdog/dw_wdt.ko] undefined!
ERROR: "omap_bus_sync" [drivers/virtio/virtio_ring.ko] undefined!
ERROR: "omap_bus_sync" [drivers/video/sm501fb.ko] undefined!
ERROR: "omap_bus_sync" [drivers/usb/mon/usbmon.ko] undefined!
ERROR: "omap_bus_sync" [drivers/usb/host/sl811-hcd.ko] undefined!
ERROR: "omap_bus_sync" [drivers/usb/host/ohci-hcd.ko] undefined!
ERROR: "omap_bus_sync" [drivers/usb/host/isp1760.ko] undefined!
ERROR: "omap_bus_sync" [drivers/usb/host/isp1362-hcd.ko] undefined!
ERROR: "omap_bus_sync" [drivers/usb/host/isp116x-hcd.ko] undefined!
ERROR: "omap_bus_sync" [drivers/usb/core/usbcore.ko] undefined!
ERROR: "omap_bus_sync" [drivers/tty/serial/altera_uart.ko] undefined!
ERROR: "omap_bus_sync" [drivers/tty/serial/altera_jtaguart.ko] undefined!
ERROR: "omap_bus_sync" [drivers/tty/serial/8250/8250_dw.ko] undefined!
ERROR: "omap_bus_sync" [drivers/ssb/ssb.ko] undefined!
ERROR: "omap_bus_sync" [drivers/rtc/rtc-cmos.ko] undefined!
ERROR: "omap_bus_sync" [drivers/rtc/rtc-bq4802.ko] undefined!
ERROR: "omap_bus_sync" [drivers/mtd/nand/tmio_nand.ko] undefined!
ERROR: "omap_bus_sync" [drivers/mtd/nand/omap2.ko] undefined!
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

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

For some weird (freudian?) reason, commit 435792d9 "ARM: OMAP: make
iommu subsys_initcall to fix builtin omap3isp" unintentionally changed
the mailbox's initcall instead of the iommu's.

Fix that.
Reported-by: NFernando Guzman Lugo <fernando.lugo@ti.com>
Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>

s3c2410_dma_suspend suspends channels from 0 to dma_channels.
s3c2410_dma_resume resumes channels in reverse order. So
pointer should be decremented instead of being incremented.
Signed-off-by: NGusakov Andrey <dron0gus@gmail.com>
Reviewed-by: NHeiko Stuebner <heiko@sntech.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

It turned out that a performance counter on AMD does not
count at all when the GO or HO bit is set in the control
register and SVM is disabled in EFER.

This patch works around this issue by masking out the HO bit
in the performance counter control register when SVM is not
enabled.

The GO bit is not touched because it is only set when the
user wants to count in guest-mode only. So when SVM is
disabled the counter should not run at all and the
not-counting is the intended behaviour.
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Avi Kivity <avi@redhat.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Gleb Natapov <gleb@redhat.com>
Cc: Robert Richter <robert.richter@amd.com>
Cc: stable@vger.kernel.org # v3.2
Link: http://lkml.kernel.org/r/1330523852-19566-1-git-send-email-joerg.roedel@amd.comSigned-off-by: NIngo Molnar <mingo@elte.hu>

Carlos was getting

	WARNING: at drivers/pci/pci.c:118 pci_ioremap_bar+0x24/0x52()

when probing his sound card, and sound did not work.  After adding
pci=use_crs to the kernel command line, no more trouble.

Ok, we can add a quirk.  dmidecode output reveals that this is an MSI
MS-7253, for which we already have a quirk, but the short-sighted
author tied the quirk to a single BIOS version, making it not kick in
on Carlos's machine with BIOS V1.2.  If a later BIOS update makes it
no longer necessary to look at the _CRS info it will still be
harmless, so let's stop trying to guess which versions have and don't
have accurate _CRS tables.

Addresses https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5533
Also see <https://bugzilla.kernel.org/show_bug.cgi?id=42619>.
Reported-by: NCarlos Luna <caralu74@gmail.com>
Reviewed-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

Commit b27b0727 (ARM: 7265/1: restart: S3C24XX: use new restart hook)
introduced the new restart hook also for the S3C244x cpus, but it
was only defined in the S3C2440 scope, i.e. when CPU_S3C2440 was
selected. Devices using the S3C2442 like the GTA02 normally don't select
this CPU which leads to compilation errors like:
    LD      .tmp_vmlinux1
  arch/arm/mach-s3c2440/built-in.o:(.arch.info.init+0x3c): undefined reference
to `s3c2440_restart'
  make: *** [.tmp_vmlinux1] Error 1

Therefore move the s3c2440_restart function to s3c244x.c which is
common to both cpus and also fix the naming to reflect this.
Reported-and-tested-by: NDenis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The device link core registers for hsotg is base + 0000h
~ base + 11000h.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
[Rebased on the newest git/kgene/linux-samsung #for-next]
Signed-off-by: NLukasz Majewski <l.majewski@samsung.com>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

Add missing break statement in the function omap3xxx_check_revision.

The commit id 4390f5b2 [ARM: OMAP: TI814X: Add cpu type macros
and detection support], removed the 'break' statement from the function
omap3xxx_check_revision(), resulting into wrong omap/cpu_revision
initialization for AM335x devices.
Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com>
[tony@atomide.com: refreshed to apply after changes to cpu_rev]
Signed-off-by: NTony Lindgren <tony@atomide.com>

Device tree support on at91sam9g45 family SoC. Only call
platform_device_register() if no dma-controller node is
found in device tree.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>

DMA controller can deduce its configuration data from
the platform. Remove the platform data and match device
types with the compatible ones.
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>

VUSB is a fixed regulator, so get rid of the apply_uV constraint
for it, which fixes the following error seen at boot on omap4
SDP and PANDA boards.

machine_constraints_voltage: VUSB: failed to apply 3300000uV constraint
twl_reg twl_reg.46: can't register VUSB, -22
twl_reg: probe of twl_reg.46 failed with error -22
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The following commit: 2f31b516
Author: Tero Kristo <t-kristo@ti.com>
Date:   Fri Dec 16 14:37:00 2011 -0700

    ARM: OMAP4: PRM: use PRCM interrupt handler

introduced the PRCM interrupt handler and thus the need
for 64 more interrupts. Since SPARSE_IRQ is still not fully
functional on OMAP, the NR_IRQS needs to be updated to avoid
the failure that happen during irq_alloc_descs call inside
the PRCM driver:

[    0.208221] PRCM: failed to allocate irq descs: -12

Later the mux framework is then unable to request an IRQ from
the PRCM interrupt handler.

[    1.802795] mux: Failed to setup hwmod io irq -22

Fix that by adding 64 more interrupts for OMAP2PLUS config.
Signed-off-by: NBenoit Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

In the spirit of commit 29cf7a30 ("x86/PCI: use host bridge _CRS
info on ASUS M2V-MX SE"), this DMI quirk turns on "pci_use_crs" by
default on a board that needs it.

This fixes boot failures and oopses introduced in 3e3da00c
("x86/pci: AMD one chain system to use pci read out res").  The quirk
is quite targetted (to a specific board and BIOS version) for two
reasons:

 (1) to emphasize that this method of tackling the problem one quirk
     at a time is a little insane

 (2) to give BIOS vendors an opportunity to use simpler tables and
     allow us to return to generic behavior (whatever that happens to
     be) with a later BIOS update

In other words, I am not at all happy with having quirks like this.
But it is even worse for the kernel not to work out of the box on
these machines, so...

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42619Reported-by: NSvante Signell <svante.signell@telia.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>

The user may wish to set their own value (for real cross compiles).  Since the
top level Makefile initialises CROSS_COMPILE to empty by default, we must
check it for being empty (rather than for being defined) before we override.
Reported-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

This patch fixes a wrong loop limit on UART init.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Cc: stable@vger.kernel.org

This patch fixes a HW bug by flushing RX FIFOs of the UARTs on init. It was
ported from NXP's git.lpclinux.com tree.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Cc: stable@vger.kernel.org

This patch fixes the wakeup disable function by clearing latched events.
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Cc: stable@vger.kernel.org

This patch fixes the initialization of the interrupt controller of the LPC32xx
by correctly setting up SIC1 and SIC2 instead of (wrongly) using the same value
as for the Main Interrupt Controller (MIC).
Signed-off-by: NRoland Stigge <stigge@antcom.de>
Cc: stable@vger.kernel.org