Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This has the adverse effect of converting many 29bit configs to 32bit
mode, while this is a change that needs to be done manually for each
platform. Turn it off by default in order to cut down on spurious bug
reports.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

While the PMB is available on SH-4A parts, SH4AL-DSP parts exclude it
altogether. As such, explicitly disable PMB support for these parts. If
this changes in the future for newer subtypes, this will have to be made
more fine-grained.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

As CPUs are migrated over to more fully-featured clock frameworks of
their own and off of the legacy CPG code, they no longer have any real
need for defining the PCLK value. The PCLK define in itself is already
fairly misleading, as many boards get their input clocks from different
sources, making this value fairly arbitrary anyways.

Outside of the legacy CPG clock framework, the only place where this
value is used is for deriving CLOCK_TICK_RATE, which we set back to the
legacy PIT value that it was before the PCLK definitions were added in
the first place.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

We can't request the cascade channel before it's been registered, so
move it afterwards.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This fixes a "start_kernel(): bug: interrupts were enabled early".

rtc_cmos now takes care of initializing the ISA RTC and reading the
current time and date from it; there's no need to repeat that here,
thereby causing interrupts to be enabled too early.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

PAGE_KERNEL should not be executable; any area marked executable can
be prefetched into the instruction cache.  We don't want vmalloc areas
to be read in this way.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

With some of the cache rework an address aliasing optimization was added,
but this managed to fail on certain mappings resulting in pages with
PG_dcache_dirty set never writing back their dcache lines. This patch
reverts to the earlier behaviour of simply always writing back when the
dirty bit is set.
Signed-off-by: NMarkus Pietrek <Markus.Pietrek@emtrion.de>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

o remove unused define
o add device name comment
Signed-off-by: NKuninori Morimoto <morimoto.kuninori@renesas.com>
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This reverts commit 9f15226e.  It's just
wrong, and broke resume for Rafael even on a non-AMD CPU.

As Rafael says:
 "... it causes microcode_init_cpu() to be called during resume even for
  CPUs for which there's no microcode to apply.  That, in turn, results
  in executing request_firmware() (on Intel CPUs at least) which doesn't
  work at this stage of resume (we have device interrupts disabled, I/O
  devices are still suspended and so on).

  If I'm not mistaken, the "if (uci->valid)" logic means "if that CPU is
  known to us" , so before commit 9f15226e microcode_resume_cpu() was
  called for all CPUs already in the system during suspend, which was
  the right thing to do.  The commit changed it so that the CPUs without
  microcode to apply are now treated as "unknown", which is not quite
  right.

  The problem this commit attempted to solve has to be handled
  differently."

Bisected-and -requested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It is unpredictable to have the same memory mapped using different
shared bit settings for ARMv6 and ARMv7 CPUs.  Fix this for the CPU
write buffer bug test.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.c: avoid cross-CPU interrupts by using smp_call_function_any()

Presently acpi-cpufreq will perform the MSR read on the first CPU in the
mask.  That's inefficient if that CPU differs from the current CPU.
Because we have to perform a cross-CPU call, but we could have run the
rdmsr on the current CPU.

So switch to using the new smp_call_function_any(), which will perform the
call on the current CPU if that CPU is present in the mask (it is).

Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Jaswinder Singh Rajput <jaswinder@kernel.org>
Cc: Len Brown <len.brown@intel.com>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

Commit f74f7e57 (ARM: use
flush_kernel_dcache_area() for dmabounce) has broken dmabounce build:

  CC      arch/arm/common/dmabounce.o
arch/arm/common/dmabounce.c: In function 'unmap_single':
arch/arm/common/dmabounce.c:315: error: implicit declaration of function '__cpuc_flush_kernel_dcache_area'
make[2]: *** [arch/arm/common/dmabounce.o] Error 1

Fix it.
Signed-off-by: NMike Rapoport <mike@compulab.co.il>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix bug of uart0 platfrom data for nuc900
Signed-off-by: Nlijie <eltshanli@gmail.com>
Signed-off-by: NWan ZongShun <mcuos.com@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

putc support for nuc900
Signed-off-by: Nlijie <eltshanli@gmail.com>
Signed-off-by: NWan ZongShun <mcuos.com@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

fix compiling error for NUC900
Signed-off-by: Nlijie <eltshanli@gmail.com>
Signed-off-by: NWan ZongShun <mcuos.com@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

On Oprofile ARMv7 the PMNC_D bit was set to lower the PMU IRQs
and so to decrease the risk of errata #628216 from appearing.
The effect of setting the PMNC_D bit is that the CCNT counter
is divided by 64, making the program counter events count
inaccurate.
The new OMAP3 r4 cores should have that errata fixed.

The PMNC_D bit should not be set, this patch fixes it.
Signed-off-by: NJean Pihet <jpihet@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The x86 and ia64 implementations of the function in $subject are
exactly the same.

Also, since the arch-specific implementations of setting _PDC have
been completely hollowed out, remove the empty shells.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The only thing arch-specific about calling _PDC is what bits get
set in the input obj_list buffer.

There's no need for several levels of indirection to twiddle those
bits. Additionally, since we're just messing around with a buffer,
we can simplify the interface; no need to pass around the entire
struct acpi_processor * just to get at the buffer.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

Both x86 and ia64 initialize _PDC with mostly common bit settings.

Factor out the common settings and leave the arch-specific ones alone.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The x86 and ia64 implementations of arch_acpi_processor_init_pdc()
are almost exactly the same. The only difference is in what bits
they set in obj_list buffer.

Combine the boilerplate memory management code, and leave the
arch-specific bit twiddling in separate implementations.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

arch dependent helper function that tells us if we should attempt to
evaluate _PDC on this machine or not.

The x86 implementation assumes that the CPUs in the machine must be
homogeneous, and that you cannot mix CPUs of different vendors.

Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NAlex Chiang <achiang@hp.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

We don't actually require this in the cpu_relax() polling case, so just
cuddle these around the sleeping version.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

This fixes up some crashes with IRQs racing the need_resched() test under
QEMU.
Signed-off-by: NPaul Mundt <lethal@linux-sh.org>

Fix the following build failures:

arch/powerpc/platforms/embedded6xx/flipper-pic.c: In function 'flipper_pic_map':
arch/powerpc/platforms/embedded6xx/flipper-pic.c:105: error: implicit declaration of function 'get_irq_desc'

arch/powerpc/platforms/embedded6xx/hlwd-pic.c: In function 'hlwd_pic_map':
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:98: error: implicit declaration of function 'get_irq_desc'

These failures are caused by the changes introduced in commit
"powerpc: Remove get_irq_desc()". The reason these drivers were not
updated is that they weren't merged yet.
Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Fix the following build failures:

arch/powerpc/platforms/embedded6xx/hlwd-pic.c: In function 'hlwd_pic_irq_cascade':
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:135: error: passing argument 1 of 'spin_lock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:137: error: passing argument 1 of 'spin_unlock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:145: error: passing argument 1 of 'spin_lock' from incompatible pointer type
arch/powerpc/platforms/embedded6xx/hlwd-pic.c:149: error: passing argument 1 of 'spin_unlock' from incompatible pointer type

These failures are caused by the changes introduced in commit
"genirq: Convert irq_desc.lock to raw_spinlock". The reason this driver
was not updated is that it wasn't merged yet.
Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Nobody except ptrace itself should use task->ptrace or PT_PTRACED
directly, change arch/s390/kernel/traps.c to use the helper.
Signed-off-by: NOleg Nesterov <oleg@redhat.com>
Acked-by: NRoland McGrath <roland@redhat.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

The elf notes number for the upper register halves is s390 specific.
Change the name of the elf notes to include S390.
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Return the PTR_ERR of the correct pointer.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

26-bit ARM support was removed a long time ago, and this symbol has
been defined to be 'y' ever since.  As it's never disabled anymore,
we can kill it without any side effects.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This avoids races in the VFP code where the dead thread may have
state on another CPU.  By moving this code to exit_thread(), we
will be running as the thread, and therefore be running on the
current CPU.

This means that we can ensure that the only local state is accessed
in the thread notifiers.
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The kbuild's select command doesn't propagate through the config
dependencies.

Hence the current rules of hardware breakpoint's config can't
ensure perf can never be disabled under us.

We have:

config X86
	selects HAVE_HW_BREAKPOINTS

config HAVE_HW_BREAKPOINTS
	select PERF_EVENTS

config PERF_EVENTS
	[...]

x86 will select the breakpoints but that won't propagate to perf
events. The user can still disable the latter, but it is
necessary for the breakpoints.

What we need is:

 - x86 selects HAVE_HW_BREAKPOINTS and PERF_EVENTS
 - HAVE_HW_BREAKPOINTS depends on PERF_EVENTS

so that we ensure PERF_EVENTS is enabled and frozen for x86.

This fixes the following kind of build errors:

 In file included from arch/x86/kernel/hw_breakpoint.c:31:
 include/linux/hw_breakpoint.h: In function 'hw_breakpoint_addr':
 include/linux/hw_breakpoint.h:39: error: 'struct perf_event' has no member named 'attr'

v2: Select also ANON_INODES from x86, required for perf
Reported-by: NCyrill Gorcunov <gorcunov@gmail.com>
Reported-by: NMichal Marek <mmarek@suse.cz>
Reported-by: NAndrew Randrianasulu <randrik_a@yahoo.com>
Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Cc: K.Prasad <prasad@linux.vnet.ibm.com>
LKML-Reference: <1261010034-7786-1-git-send-regression-fweisbec@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Commit 2c9b9c84 added an argument to __cpuc_flush_dcache_page
and renamed it.

Update a caller of the old function to fix this build error:

  CC      arch/arm/mm/copypage-v6.o
arch/arm/mm/copypage-v6.c: In function 'v6_copy_user_highpage_nonaliasing':
arch/arm/mm/copypage-v6.c:51: error: implicit declaration of function '__cpuc_flush_dcache_page'
make[1]: *** [arch/arm/mm/copypage-v6.o] Error 1
make: *** [arch/arm/mm] Error 2
Reported-by: NJinsung Yang <jsgood.yang@samsung.com>
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use the new unreachable() macro instead of for(;;);
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
CC: Richard Henderson <rth@twiddle.net>
CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
CC: linux-alpha@vger.kernel.org
Signed-off-by: NMatt Turner <mattst88@gmail.com>

In the kernel the patch enables configuration of the perf event
option, adds the perf_event_open syscall, and includes a minimal
architecture specific asm/perf_event.h header file.
Signed-off-by: NMichael Cree <mcree@orcon.net.nz>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

This wire up the: fallocate, timerfd_create, timerfd_settime,
timerfd_gettime, signalfd4, eventfd2, epoll_create1, dup3, pipe2,
inotify_init1, preadv, pwritev and rt_tgsigqueueinfo syscalls for
the alpha port.

For umount2, alpha have an "old" and "new" version called: oldumount and
umount; so ignore umount2.

Rebased on top of 6e17e8b9 by Matt
Turner.
Signed-off-by: NDaniele Calore <orkaan@orkaan.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NMatt Turner <mattst88@gmail.com>

John Blackwood reported:
> on an older Dell PowerEdge 6650 system with 8 cpus (4 are hyper-threaded),
> and  32 bit (x86) kernel, once you change the irq smp_affinity of an irq
> to be less than all cpus in the system, you can never change really the
> irq smp_affinity back to be all cpus in the system (0xff) again,
> even though no error status is returned on the "/bin/echo ff >
> /proc/irq/[n]/smp_affinity" operation.
>
> This is due to that fact that BAD_APICID has the same value as
> all cpus (0xff) on 32bit kernels, and thus the value returned from
> set_desc_affinity() via the cpu_mask_to_apicid_and() function is treated
> as a failure in set_ioapic_affinity_irq_desc(), and no affinity changes
> are made.

set_desc_affinity() is already checking if the incoming cpu mask
intersects with the cpu online mask or not. So there is no need
for the apic op cpu_mask_to_apicid_and() to check again
and return BAD_APICID.

Remove the BAD_APICID return value from cpu_mask_to_apicid_and()
and also fix set_desc_affinity() to return -1 instead of using BAD_APICID
to represent error conditions (as cpu_mask_to_apicid_and() can return
logical or physical apicid values and BAD_APICID is really to represent
bad physical apic id).
Reported-by: NJohn Blackwood <john.blackwood@ccur.com>
Root-caused-by: NJohn Blackwood <john.blackwood@ccur.com>
Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
LKML-Reference: <1261103386.2535.409.camel@sbs-t61>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

The retry logic in ug_putc() is broken.

If the TX fifo is not ready and the counter runs out it will have a
value of -1 and no transfer should be attempted. Also, a counter
with a value of 0 means that the TX fifo got ready in the last try
and the transfer should be attempted.
Reported-by: N"Juha Leppanen" <juha_motorsportcom@luukku.com>
Signed-off-by: N"Juha Leppanen" <juha_motorsportcom@luukku.com>
Signed-off-by: NAlbert Herranz <albert_herranz@yahoo.es>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>