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

This patch adds an config switch to determine if we need to build some
workaround helper files.

The staging driver octeon-ethernet references some symbols which are only
built when PCI is enabled. The new config switch enables these symbols in
bothe cases.
Signed-off-by: NAndreas Bießmann <biessmann@corscience.de>
To: linux-kernel@vger.kernel.org
Cc: Andreas Bießmann <biessmann@corscience.de>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1543/Acked-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The 64-bit kernel has already had its atomic64 functions. Except for that,
we use the generic spinlocked version. The atomic64 types and related
functions are needed for the Linux performance counter subsystem.
Signed-off-by: NDeng-Cheng Zhu <dengcheng.zhu@gmail.com>
To: linux-mips@linux-mips.org
Cc: a.p.zijlstra@chello.nl
Cc: paulus@samba.org
Cc: mingo@elte.hu
Cc: acme@redhat.com
Cc: jamie.iles@picochip.com
Patchwork: https://patchwork.linux-mips.org/patch/1361/Acked-by: NDavid Daney <ddaney@caviumnetworks.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRicardo Mendoza <ricmm@gentoo.org>
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1540/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Indent the branch of an if.

The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r disable braces4@
position p1,p2;
statement S1,S2;
@@

(
if (...) { ... }
|
if (...) S1@p1 S2@p2
)

@script:python@
p1 << r.p1;
p2 << r.p2;
@@

if (p1[0].column == p2[0].column):
  cocci.print_main("branch",p1)
  cocci.print_secs("after",p2)
// </smpl>
Signed-off-by: NJulia Lawall <julia@diku.dk>
To: linux-mips@linux-mips.org
To: linux-kernel@vger.kernel.org
To: kernel-janitors@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/1539/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

"Userpace" -> "Userspace"
Signed-off-by: NAndrea Gelmini <andrea.gelmini@gelma.net>
Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Martin Hicks <mort@sgi.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1536/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

flush_icache_range() is given virtual addresses to describe the region.  It
deals with these by attempting to translate them through the current set of
page tables.

This is fine for userspace memory and vmalloc()'d areas as they are governed by
page tables.  However, since the regions above 0x80000000 aren't translated
through the page tables by the MMU, the kernel doesn't bother to set up page
tables for them (see paging_init()).

This means flush_icache_range() as it stands cannot be used to flush regions of
the VM area between 0x80000000 and 0x9fffffff where the kernel resides if the
data cache is operating in WriteBack mode.

To fix this, make flush_icache_range() first check for addresses in the upper
half of VM space and deal with them appropriately, before dealing with any
range in the page table mapped area.

Ordinarily, this is not a problem, but it has the capacity to make kprobes and
kgdb malfunction.  It should not affect gdbstub, signal frame setup or module
loading as gdb has its own flush functions, and the others take place in the
page table mapped area only.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NAkira Takeuchi <takeuchi.akr@jp.panasonic.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the warnings

  arch/m68k/mac/macboing.c: In function 'mac_mksound':
  arch/m68k/mac/macboing.c:189: warning: comparison of distinct pointer types lacks a cast
  arch/m68k/mac/macboing.c:211: warning: comparison of distinct pointer types lacks a cast
  arch/m68k/mac/macboing.c: In function 'mac_quadra_start_bell':
  arch/m68k/mac/macboing.c:241: warning: comparison of distinct pointer types lacks a cast
  arch/m68k/mac/macboing.c:263: warning: comparison of distinct pointer types lacks a cast
  arch/m68k/mac/macboing.c: In function 'mac_quadra_ring_bell':
  arch/m68k/mac/macboing.c:283: warning: comparison of distinct pointer types lacks a cast

Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

create_irq() returns -1 if the interrupt allocation failed, but the
code checks for irq == 0.

Use create_irq_nr() instead.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Venkatesh Pallipadi <venki@google.com>
LKML-Reference: <alpine.LFD.2.00.1009282310360.2416@localhost6.localdomain6>
Cc: stable@kernel.org
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

free_irq_cfg() is not freeing the cpumask_vars in irq_cfg. Fixing this
triggers a use after free caused by the fact that copying struct
irq_cfg is done with memcpy, which copies the pointer not the cpumask.

Fix both places.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
LKML-Reference: <alpine.LFD.2.00.1009282052570.2416@localhost6.localdomain6>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: stable@kernel.org
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Commit c52c2ddc ("alpha: switch osf_sigprocmask() to use of
sigprocmask()") had several problems.  The more obvious compile issues
got fixed in commit 0f44fbd2 ("alpha: fix compile problem in
arch/alpha/kernel/signal.c"), but it also caused a regression.

Since _BLOCKABLE is already the set of signals that can be blocked, the
code should do "newmask & _BLOCKABLE" rather than inverting _BLOCKABLE
before masking.
Reported-by: NMichael Cree <mcree@orcon.net.nz>
Patch-by: NAl Viro <viro@zeniv.linux.org.uk>
Patch-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

cpu_cstate_entry is a percpu pointer
but was missing __percpu markup.
Signed-off-by: NNamhyung Kim <namhyung@gmail.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

When caching is disabled on the MN10300 arch, the sys_cacheflush()
function is removed by conditional stuff in the makefiles, but is still
referred to by the syscall table.

Provide a null version that just returns 0 when caching is disabled (or
-EINVAL if the arguments are silly).
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

After uncapping the CPUID level, we need to also re-run the CPU
feature detection code.

This resolves kernel bugzilla 16322.
Reported-by: Nboris64 <bugzilla.kernel.org@boris64.net>
Cc: <stable@kernel.org> v2.6.29..2.6.35
LKML-Reference: <tip-@git.kernel.org>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Tssk.  Apparently Al hadn't checked commit c52c2ddc ("alpha: switch
osf_sigprocmask() to use of sigprocmask()") at all. It doesn't compile.

Fixed as per suggestions from Michael Cree.
Reported-by: NMichael Cree <mcree@orcon.net.nz>
Cc: Al Viro <viro@ftp.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The configuration choice for the port on which the GDB stub listens has
a default of GDBSTUB_TTYSM0, but this should be GDBSTUB_ON_TTYSM0 to
match the option.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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

It really has no business being there; short of a serious kernel bug
we should already have USER_DS at that point.  It shouldn't have been
done on x86 either...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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

set ->orig_d0 to -1, same as what sigreturn does
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

force_sigsegv() is there for purpose...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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

get rid of a useless wrapper, while we are at it
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The PL310 on the ct-ca9x4 tile for the Versatile Express does not need
to add additional latency when accessing its cache RAMs. Unfortunately,
the boot monitor sets this up for an 8-cycle delay on reads and writes,
resulting in greatly reduced memory performance when the L2 cache is
enabled.

This patch sets the L2 RAM latencies to the correct value of 1 cycle
on the ct-ca9x4 tile before enabling the L2 cache.
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

While debugging bit_spin_lock() hang, it was tracked down to gcc-4.4
misoptimization of non-inlined constant_test_bit() due to non-volatile
addr when 'const volatile unsigned long *addr' cast to 'unsigned long *'
with subsequent unconditional jump to pause (and not to the test) leading
to hang.

Compiling with gcc-4.3 or disabling CONFIG_OPTIMIZE_INLINING yields inlined
constant_test_bit() and correct jump, thus working around the kernel bug.

Other arches than asm-x86 may implement this slightly differently;
2.6.29 mitigates the misoptimization by changing the function prototype
(commit c4295fbb) but probably fixing the issue
itself is better.
Signed-off-by: NAlexander Chumachenko <ledest@gmail.com>
Signed-off-by: NMichael Shigorin <mike@osdn.org.ua>
Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

rdusp() gives us the right value only for the current thread...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We want interrupts disabled on all paths leading to RESTORE_ALL;
otherwise, we are risking an IRQ coming between the updates of
alpha_mv->hae_cache and *alpha_mv->hae_register and set_hae()
within the IRQ getting badly confused.

RESTORE_ALL used to play with disabling IRQ itself, but that got
removed back in 2002, without making sure we had them disabled
on all paths.  It's cheaper to make sure we have them disabled than
to revert to original variant...

Remove the detritus left from that commit back in 2002; we used to
need a reload of $0 and $1 since swpipl would change those, but
doing that had become pointless when we stopped doing swpipl in
there...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

On Davinci SRAM is mapped as MT_DEVICE becasue of the section
mapping pre-requisite instead of intended MT_MEMORY_NONCACHED

Since the section mapping limitation gets fixed with first
patch in this series, the MT_MEMORY_NONCACHED can be used now.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Currently we map 1 MB section while setting up SRAM on OMAPs
Regardless of the actual memory. The physical OCM RAM available
on OMAP SOCs is in order of KBs. This patch maps only available
sram and cleans up some un-necessary cpu_is_xxx checks.

Mapping un-available or non-accessible(secure) memory on the newer ARM
processor is dangerous. Because ARM CPUs can now speculatively prefetch,
we should avoid mapping any no-existing or secure memory.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch populates the L1 entries for MT_MEMORY and MT_MEMORY_NONCACHED
types so that at boot-up, we can map memories outside system memory
at page level granularity

Previously the mapping was limiting to section level, which creates
unnecessary additional mapping for which physical memory may not
present. On the newer ARM with speculation, this is dangerous and can
result in untraceable aborts.
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

When CONFIG_PXA3xx is not selected, cpu_is_pxa3xx() doesn't expand to
zero, which in some places doesn't result in correct optimization.
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>
Reported-and-tested-by: NMarek Vasut <marek.vasut@gmail.com>

Reset vector for pxa168 is 0xffff_0000 not 0x0. This fix allows
reboot to work
Signed-off-by: NMark F. Brown <mark.brown314@gmail.com>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Original idea by: Mike Rapoport <mike@compulab.co.il>
Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>

GPIO 0 is valid, yet this platform doesn't have any power GPIO for MMC.
Signed-off-by: NMarek Vasut <marek.vasut@gmail.com>

This "bpt_code" instruction was killed off in our development line a while
ago (the actual definition of bpt_code that is used is in kernel/traps.c)
but I didn't push it for 2.6.36 because it seemed harmless and I didn't
want to try to push more than absolutely necessary.

However, we recently fixed a bug in our gcc that had been causing
"-gdwarf2" not to be passed to the assembler, and passing this flag causes
an erroneous assembler failure in the presence of code in a data section,
sometimes.  While we'd like to track down the bug in the assembler,
we'd also like to make sure 2.6.36 builds with the current toolchain,
so I'm removing this dead code as well.
Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>

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

It's a userland pointer; worse, an untrustable one since ptrace
has just provided a chance to modify it.

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

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

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