If we are context switched whilst copying into a thread's
vfp_hard_struct then the partial copy may be corrupted by the VFP
context switching code (see "ARM: vfp: flush thread hwstate before
restoring context from sigframe").

This patch updates the ptrace VFP set code so that the thread state is
flushed before the copy, therefore disabling VFP and preventing
corruption from occurring.

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

In a preemptible kernel, vfp_set() can be preempted, causing the
hardware VFP context to be switched while the thread vfp state is
being read and modified.  This leads to a race condition which can
cause the thread vfp state to become corrupted if lazy VFP context
save occurs due to preemption in between the time thread->vfpstate
is read and the time the modified state is written back.

This may occur if preemption occurs during the execution of a
ptrace() call which modifies the VFP register state of a thread.
Such instances should be very rare in most realistic scenarios --
none has been reported, so far as I am aware.  Only uniprocessor
systems should be affected, since VFP context save is not currently
lazy in SMP kernels.

The problem was introduced by my earlier patch migrating to use
regsets to implement ptrace.

This patch does a vfp_sync_hwstate() before reading
thread->vfpstate, to make sure that the thread's VFP state is not
live in the hardware registers while the registers are modified.

Thanks to Will Deacon for spotting this.

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Following execution of a signal handler, we currently restore the VFP
context from the ucontext in the signal frame. This involves copying
from the user stack into the current thread's vfp_hard_struct and then
flushing the new data out to the hardware registers.

This is problematic when using a preemptible kernel because we could be
context switched whilst updating the vfp_hard_struct. If the current
thread has made use of VFP since the last context switch, the VFP
notifier will copy from the hardware registers into the vfp_hard_struct,
overwriting any data that had been partially copied by the signal code.

Disabling preemption across copy_from_user calls is a terrible idea, so
instead we move the VFP thread flush *before* we update the
vfp_hard_struct. Since the flushing is performed lazily, this has the
effect of disabling VFP and clearing the CPU's VFP state pointer,
therefore preventing the thread from being updated with stale data on
the next context switch.

Cc: stable <stable@vger.kernel.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This reverts commit 3c424f35.

Joachim Eastwood reports:
| "ARM: 7304/1: ioremap: fix boundary check when reusing static mapping"
| Commit: 3c424f35 in Linus master
|
| Breaks booting on my custom AT91RM9200 board.
| There isn't any error messages or anything that indicates what goes
| wrong it just stops after; Uncompressing Linux... done, booting the
| kernel.
|
| Reverting it makes my board boot again.

and further debugging reveals:

ioremap: pfn=fffff phys=fffff000 offset=400 size=1000
ioremap: area c3ffdfc0: phys_addr=200000 pfn=200 size=4000
ioremap: found: addr fef74000 => fed73000 => fed73400

Clearly, an area for pfn 0x200, 16K can't ever satisfy a request for pfn
0xfffff.  This happens because the changed if statement becomes:

                if (0x00200 > 0xfffff ||
                    0xfffff000 + 0x400 + 0x1000-1 > 0x00200000 + 0x4000-1)
and therefore:
                if (0x00200 > 0xfffff ||
                    0x000003ff > 0x00203fff)

The if condition fails, and so we _believe_ that the SRAM mapping fits
our request.  Clearly that's totally bogus.

Moreover, the original premise of the 'fix' patch was wrong:
|    The condition checking boundaries of the requested and existing
|    mappings didn't take in-page offset into consideration though,
|    which lead to obscure and hard to debug problems when requested
|    mapping crossed end of the static one.

as the code immediately above this loop does:

        size = PAGE_ALIGN(offset + size);

so 'size' already contains the requested offset into the page.

So, revert the broken 'fix'.
Acked-by: Nicolas Pitre <nico@linaro.org>

Since commit 576d2f25 "ARM: add
generic ioremap optimization by reusing static mappings" ioremap()
is trying to reuse existing static mapping when possible.

The condition checking boundaries of the requested and existing
mappings didn't take in-page offset into consideration though,
which lead to obscure and hard to debug problems when requested
mapping crossed end of the static one.
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This macro is used to generate unprivileged accesses (LDRT/STRT) to user
space.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The dynamic ftrace ops startup test currently fails on Thumb-2 kernels:

 Testing tracer function: PASSED
 Testing dynamic ftrace: PASSED
 Testing dynamic ftrace ops #1: (0 0 0 0 0) FAILED!

This is because while the addresses in the mcount records do not have
the zero bit set, the IP reported by the mcount call does have it set
(because it is copied from the LR).  This mismatch causes the ops
filtering in ftrace_ops_list_func() to not call the relevant tracers.

Fix this by clearing the zero bit before adjusting the LR for the mcount
instruction size.  Also, combine the mov+sub into a single sub
instruction.
Acked-by: Dave Martin <dave.martin@linaro.org>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Since commit 0536bdf3 (ARM: move iotable mappings within
the vmalloc region), the RealView PB11MP cannot boot anymore.

This is caused by the way the mappings are described on this
platform (define replaced by hex values for clarity):

{	/* GIC CPU interface mapping */
        .virtual        = IO_ADDRESS(0x1F000100),
        .pfn            = __phys_to_pfn(0x1F000100),
        .length         = SZ_4K,
        .type           = MT_DEVICE,
}, {	/* GIC distributor mapping */
        .virtual        = IO_ADDRESS(0x1F001000),
        .pfn            = __phys_to_pfn(0x1F001000),
        .length         = SZ_4K,
        .type           = MT_DEVICE,
}

The first mapping ends up reserving two pages, and clashes with
the second one, which triggers a BUG_ON in vm_area_add_early().

In order to solve this problem, treat the MPCore private memory
region (containing the SCU, the GIC and the TWD) as a single region,
as described in the TRM:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/CACGDJJC.html

The EB11MP is converted the same way, even if it manages to avoid
the problem.

Tested on both PB11MP and EB11MP.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The sa1111 socket driver oopses when removed:

Unable to handle kernel NULL pointer dereference at virtual address 000003b0
pgd = c1b40000
[000003b0] *pgd=00000000
Internal error: Oops: 41b43005 [#1]
Modules linked in:
CPU: 0    Not tainted  (3.3.0-rc1+ #744)
PC is at pcmcia_remove+0x3c/0x60
LR is at pcmcia_remove+0x34/0x60

This is because we try to dereference a NULL 's' to obtain the next
pointer.  Fix this.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The Jornada SSP driver is supposed to be initialized by a
module_init() call, but it was missed at some merge point. Since
the driver mostly pass calls through it magically works anyway,
but needs to be rectified.

Cc: Kristoffer Ericson <kristoffer.ericson@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

On secondary CPUs, the Timer Control Register is not reset
to a sane value before the timer is registered, and the TRM
doesn't seem to indicate any reset value either. In some cases,
the kernel will take an interrupt too early, depending on what
junk was present in the registers at reset time.

The fix is to set the Timer Control Register to 0 before
registering the clock_event_device and enabling the interrupt.

Problem seen on VE (Cortex A5) and Tegra.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

On v7, we use the same cache maintenance instructions for data lines
as for unified lines. This was not the case for v6, where HARVARD_CACHE
was defined to indicate the L1 cache topology.

This patch removes the erroneous compile-time check for HARVARD_CACHE in
proc-v7.S, ensuring that we perform I-side invalidation at boot.
Reported-and-Acked-by: Shawn Guo <shawn.guo@linaro.org>

Cc: stable <stable@vger.kernel.org>
Acked-by: Catalin Marinas <Catalin.Marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The merging of commits 1b6ba46b ("ARM: LPAE: MMU setup for the 3-level
page table format") and b4244738 ("ARM: 7202/1: Add Cortex-A7 proc info")
during the merge window ended up putting the Cortex-A7 proc_info into a
code block guarded by !CONFIG_ARM_LPAE. This makes Cortex-A7 platforms
unbootable when LPAE is enabled.

This patch moves the proc_info structure for Cortex-A7 outside of the
guarded block.

Cc: Pawel Moll <pawel.moll@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

It turns out that the logical CPU mapping is useful even when !CONFIG_SMP
for manipulation of devices like interrupt and power controllers when
running a UP kernel on a CPU other than 0. This can happen when kexecing
a UP image from an SMP kernel.

In the future, multi-cluster systems running AMP configurations will
require something similar for mapping cluster IDs, so it makes sense to
decouple this logic in preparation for this support.
Acked-by: Yang Bai <hamo.by@gmail.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reported-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

To ensure correct alignment of cacheline-aligned data, the maximum
cacheline size needs to be known at compile time.

Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely
that there will be future ARMv7 implementations with the same line size)
then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline
size. For CPUs with smaller caches, this will result in some harmless
padding but will help with single zImage work and avoid hitting subtle
bugs with misaligned data structures.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The exception fixup table is currently aligned to a 32-byte boundary.
Whilst this won't cause any problems, the exception_table_entry
structures contain only a pair of unsigned longs, so 4-byte alignment
is all that is required. If the table was walked from start to end,
cacheline alignment may bring some performance benefits, but since a
binary search is used, the access pattern is random and will not benefit
from a stricter alignment.
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The linker script assumes a cacheline size of 32 bytes when aligning
the .data..cacheline_aligned and .data..percpu sections.

This patch updates the script to use L1_CACHE_BYTES, which should be set
to 64 on platforms that require it.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

If the ucb1x00 touchscreen is resumed while the touchscreen is being
touched, the main thread stops responding.  This occurs because two
things happen:

1. When we suspended, we were woken up, and executed the loop.
   Finding that the touchscreen was not pressed, we prepare to
   schedule for a maximum timeout, before being stopped in
   try_to_freeze().

2. an irq occurs, we disable the irq, and mark it as disabled,
   and wake the thread.  This wake occurs while the thread is
   still within __refrigerator()

3. The thread is unfrozen, and __refrigerator() sets the threads
   state back to INTERRUPTIBLE.

We then drop into schedule_timeout() with an infinite timeout and the
IRQ disabled.  This prevents any further screen touches activating
the thread.

Fix this by using kthread_freezable_should_stop() which handles the
freezing issues for us outside of the hotspot where the task state
matters.  Include a flag to ignore the touchscreen until it is
released to avoid sending unintended data to the application.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

gpiolib drivers should first set the output data before setting the
direction to avoid putting glitches on an output signal.  As an
additional bonus, we tweak the code to avoid unnecessary register
writes to the output and direction registers if they have no need
to be updated.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

We were not restoring the UCB1x00 gpio output data on resume, resulting
in incorrect GPIO output data after a resume.  Add the missing register
write.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

mcp_priv() does unexpected things when passed a void pointer.  Make it
a typed inline function, which ensures that it works correctly in
these cases.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

The genirq layer complains if an interrupt handler returns with
interrupts enabled.  The UCB1x00 handler does just this, because
ucb1x00_enable() calls mcp_enable(), which uses spin_lock_irq()
rather than spin_lock_irqsave().  Convert this, and the divisor
setting functions to use spin_lock_irqsave().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

This reverts commit 5dd7bf59.

Conflicts:

	scripts/mod/file2alias.c

This change is wrong on many levels.  First and foremost, it causes a
regression.  On boot on Assabet, which this patch gives a codec id of
'ucb1x00', it gives:

	ucb1x00 ID not found: 1005

0x1005 is a valid ID for the UCB1300 device.

Secondly, this patch is way over the top in terms of complexity.  The
only device which has been seen to be connected with this MCP code is
the UCB1x00 (UCB1200, UCB1300 etc) devices, and they all use the same
driver.  Adding a match table, requiring the codec string to match the
hardware ID read out of the ID register, etc is completely over the top
when we can just read the hardware ID register.

This reverts commit af9081ae.

This revert is necessary to revert 5dd7bf59.

Merge branches 'sched-urgent-for-linus', 'perf-urgent-for-linus' and 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/accounting, proc: Fix /proc/stat interrupts sum

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  tracepoints/module: Fix disabling tracepoints with taint CRAP or OOT
  x86/kprobes: Add arch/x86/tools/insn_sanity to .gitignore
  x86/kprobes: Fix typo transferred from Intel manual

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, syscall: Need __ARCH_WANT_SYS_IPC for 32 bits
  x86, tsc: Fix SMI induced variation in quick_pit_calibrate()
  x86, opcode: ANDN and Group 17 in x86-opcode-map.txt
  x86/kconfig: Move the ZONE_DMA entry under a menu
  x86/UV2: Add accounting for BAU strong nacks
  x86/UV2: Ack BAU interrupt earlier
  x86/UV2: Remove stale no-resources test for UV2 BAU
  x86/UV2: Work around BAU bug
  x86/UV2: Fix BAU destination timeout initialization
  x86/UV2: Fix new UV2 hardware by using native UV2 broadcast mode
  x86: Get rid of dubious one-bit signed bitfield

gpio bug fixes for v3.3

* tag 'gpio-for-linus' of git://git.secretlab.ca/git/linux-2.6:
  gpio: tps65910: Use correct offset for gpio initialization
  gpio/it8761e: Restrict it8761e gpio driver to x86.
  gpio-ml-ioh: cleanup __iomem annotation usage
  gpio-ml-ioh: cleanup NULL pointer checking
  gpio-pch: cleanup __iomem annotation usage
  gpio-pch: cleanup NULL pointer checking

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  qnx4: don't leak ->BitMap on late failure exits
  qnx4: reduce the insane nesting in qnx4_checkroot()
  qnx4: di_fname is an array, for crying out loud...
  vfs: remove printk from set_nlink()
  wake up s_wait_unfrozen when ->freeze_fs fails

In checkin

  303395ac x86: Generate system call tables and unistd_*.h from tables

the feature macros in <asm/unistd.h> were unified between 32 and 64
bits.  Unfortunately 32 bits requires __ARCH_WANT_SYS_IPC and this was
inadvertently dropped.
Reported-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Link: http://lkml.kernel.org/r/CALLzPKbeXN5gdngo8uYYU8mAow=XhrwBFBhKfG811f37BubQOg@mail.gmail.com

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  KEYS: Permit key_serial() to be called with a const key pointer
  keys: fix user_defined key sparse messages
  ima: fix cred sparse warning
  MPILIB: Add a missing ENOMEM check

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

(struct qnx4_inode_entry *)(bh->b_data + some_offset)->di_fname
is not going to be NULL, TYVM...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Fix the following build warning:

  CC      arch/arm/kernel/setup.o
In file included from arch/arm/kernel/setup.c:39:
arch/arm/include/asm/elf.h:102:1: warning: "vmcore_elf64_check_arch" redefined
In file included from arch/arm/kernel/setup.c:24:
include/linux/crash_dump.h:30:1: warning: this is the location of the previous definition

Since commit 93a72052 (crash_dump: export is_kdump_kernel to modules, consolidate elfcorehdr_addr, setup_elfcorehdr and saved_max_pfn)
the inclusion of <linux/crash_dump.h> is no longer needed.

Remove the inclusion of <linux/crash_dump.h> and the build warning is fixed.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

All other ports use "Kernel code" to identify the Kernel text segment
in /proc/iomem. Change the ARM resources to do the same.
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

We can stall RCU processing on SMP platforms if a CPU sits in its idle
loop for a long time.  This happens because we don't call irq_enter()
and irq_exit() around generic_smp_call_function_interrupt() and
friends.  Add the necessary calls, and remove the one from within
ipi_timer(), so that they're all in a common place.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

WARNING: vmlinux.o(.text+0x1bc9c): Section mismatch in reference from the function ct_ca9x4_init_cpu_map() to the function .init.text:scu_get_core_count()
The function ct_ca9x4_init_cpu_map() references
the function __init scu_get_core_count().

WARNING: vmlinux.o(.text+0x1bce8): Section mismatch in reference from the function ct_ca9x4_init_cpu_map() to the function .init.text:set_smp_cross_call()
The function ct_ca9x4_init_cpu_map() references
the function __init set_smp_cross_call().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Commit 716a3dc2 (ARM: Add arm_memblock_steal() to allocate memory
away from the kernel) added a function which calls memblock_alloc().
This causes a section conflict:

WARNING: vmlinux.o(.text+0xc614): Section mismatch in reference from the function arm_memblock_steal() to the function .init.text:memblock_alloc()
The function arm_memblock_steal() references
the function __init memblock_alloc().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>