Currently code has an inverted logic: opcode from user memory
is swapped to a proper endianness only in case of read error.
While normally opcode should be swapped only if it was read
correctly from user memory.
Reviewed-by: NVictor Kamensky <victor.kamensky@linaro.org>
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

arch/arm/kernel/perf_event_cpu.c:274:25: warning: incorrect type in assignment (different modifiers)
arch/arm/kernel/perf_event_cpu.c:274:25: expected int ( *init_fn )( ... )
arch/arm/kernel/perf_event_cpu.c:274:25: got void const *const data
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The MPIDR contains specific bitfields(MPIDR.Aff{2..0}) which uniquely
identify a CPU, in addition to some non-identifying information and
reserved bits. The ARM cpu binding defines the 'reg' property to only
contain the affinity bits, and any cpu nodes with other bits set in
their 'reg' entry are skipped.

As such it is not necessary to mask the phys_id with MPIDR_HWID_BITMASK,
and doing so could lead to matching erroneous CPU nodes in the device
tree. This patch removes the masking of the physical identifier.
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The array was missing the final entry for the undefined instruction
exception handler; this commit adds it.

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

Jason Gunthorpe reports a build failure when ARM_PATCH_PHYS_VIRT is
not defined:

In file included from arch/arm/include/asm/page.h:163:0,
                 from include/linux/mm_types.h:16,
                 from include/linux/sched.h:24,
                 from arch/arm/kernel/asm-offsets.c:13:
arch/arm/include/asm/memory.h: In function '__virt_to_phys':
arch/arm/include/asm/memory.h:244:40: error: 'PHYS_OFFSET' undeclared (first use in this function)
arch/arm/include/asm/memory.h:244:40: note: each undeclared identifier is reported only once for each function it appears in
arch/arm/include/asm/memory.h: In function '__phys_to_virt':
arch/arm/include/asm/memory.h:249:13: error: 'PHYS_OFFSET' undeclared (first use in this function)

Fixes: ca5a45c0 ("ARM: mm: use phys_addr_t appropriately in p2v and v2p conversions")
Tested-By: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The __do_cache_op function operates with a 'chunk' size of one page
but fails to limit the size of the final chunk so as to not exceed
the specified memory region. Fix this.

Cc: <stable@vger.kernel.org>
Reported-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Tested-by: NChristian Gmeiner <christian.gmeiner@gmail.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJon Medhurst <tixy@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch fixes corner case when (fp + 4) overflows unsigned long,
for example: fp = 0xFFFFFFFF -> fp + 4 == 3.

Cc: <stable@vger.kernel.org>
Signed-off-by: NKonstantin Khlebnikov <k.khlebnikov@samsung.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

get_wchan() is lockless. Task may wakeup at any time and change its own stack,
thus each next stack frame may be overwritten and filled with random stuff.

/proc/$pid/stack interface had been disabled for non-current tasks, see [1]
But 'wchan' still allows to trigger stack frame unwinding on volatile stack.

This patch fixes oops in unwind_frame() by adding stack pointer validation on
each step (as x86 code do), unwind_frame() already checks frame pointer.

Also I've found another report of this oops on stackoverflow (irony).

Link: http://www.spinics.net/lists/arm-kernel/msg110589.html [1]
Link: http://stackoverflow.com/questions/18479894/unwind-frame-cause-a-kernel-paging-error

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

To get updated __pv_phys_offset, setup_dma_zone() needs to be
called after early_paging_init().

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Copying a function with memcpy() and then trying to execute the
result isn't trivially portable to Thumb.

This patch modifies the kexec soft restart code to copy its
assembler trampoline relocate_new_kernel() using fncpy() instead,
so that relocate_new_kernel can be in the same ISA as the rest of
the kernel without problems.
Signed-off-by: NDave Martin <Dave.Martin@arm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Reported-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org>
Tested-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

After "ARM: signal: sigreturn_codes should be endian neutral to
work in BE8" commit, thumb only platforms, like armv7m, fails to
compile sigreturn_codes.S. The reason is that for such arch
values '.arm' directive and arm opcodes are not allowed.

Fix conditionally enables arm opcodes only if no CONFIG_CPU_THUMBONLY
defined and it uses .org instructions to keep sigreturn_codes
layout.
Suggested-by: NDave Martin <Dave.Martin@arm.com>
Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
Tested-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: NDave Martin <Dave.Martin@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fixes a harmless warning when building for V7M (!MMU):
 arch/arm/kernel/traps.c:859:123: warning: 'kuser_init' defined but not used [-Wunused-function]

By making the stub static inline instead of just static.

Fixes: f6f91b0d ('ARM: allow kuser helpers to be removed from the vector page')
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Fix patching code to convert mov instruction into mvn instruction
in case of CONFIG_ARCH_PHYS_ADDR_T_64BIT and CONFIG_ARM_PATCH_PHYS_VIRT.

In BE case store into r0 proper bits so byte swapped instruction
could be modified correctly.
Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
Reviewed-by: NR Sricharan <r.sricharan@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit "bc41b872 ARM: 7846/1:
Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices"
added read of SCU config register into __fixup_smp function.
Such read should be followed by byteswap, if kernel runs in
BE mode.
Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use more appropriate NUMA_NO_NODE instead of -1 in all archs' module_alloc()
Signed-off-by: NJianguo Wu <wujianguo@huawei.com>
Acked-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If we're running a kernel compiled with SMP_ON_UP=y and the
hardware only supports UP operation there isn't any
smp_cross_call function assigned. Unfortunately, we call
smp_cross_call() unconditionally in arch_irq_work_raise() and
crash the kernel on UP devices. Check to make sure we're running
on an SMP device before calling smp_cross_call() here.

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 80000005 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.12.0-rc6-00018-g8d451442-dirty #16
task: de05b440 ti: de05c000 task.ti: de05c000
PC is at 0x0
LR is at arch_irq_work_raise+0x3c/0x48
pc : [<00000000>]    lr : [<c0019590>]    psr: 60000193
sp : de05dd60  ip : 00000001  fp : 00000000
r10: c085e2f0  r9 : de05c000  r8 : c07be0a4
r7 : de05c000  r6 : de05c000  r5 : c07c5778  r4 : c0824554
r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : c0529a58
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel
Control: 10c5387d  Table: 80004019  DAC: 00000017
Process swapper/0 (pid: 1, stack limit = 0xde05c248)
Stack: (0xde05dd60 to 0xde05e000)
dd60: c07b9dbc c00cb2dc 00000001 c08242c0 c08242c0 60000113 c07be0a8 c00b0590
dd80: de05c000 c085e2f0 c08242c0 c08242c0 c1414c28 c00b07cc de05b440 c1414c28
dda0: c08242c0 c00b0af8 c0862bb0 c0862db0 c1414cd8 de05c028 c0824840 de05ddb8
ddc0: 00000000 00000009 00000001 00000024 c07be0a8 c07be0a4 de05c000 c085e2f0
dde0: 00000000 c004a4b0 00000010 de00d2dc 00000054 00000100 00000024 00000000
de00: de05c028 0000000a ffff8ae7 00200040 00000016 de05c000 60000193 de05c000
de20: 00000054 00000000 00000000 00000000 00000000 c004a704 00000000 de05c008
de40: c07ba254 c004aa1c c07c5778 c0014b70 fa200000 00000054 de05de80 c0861244
de60: 00000000 c0008634 de05b440 c051c778 20000113 ffffffff de05deb4 c051d0a4
de80: 00000001 00000001 00000000 de05b440 c082afac de057ac0 de057ac0 de0443c0
dea0: 00000000 00000000 00000000 00000000 c082afbc de05dec8 c009f2a0 c051c778
dec0: 20000113 ffffffff 00000000 c016edb0 00000000 000002b0 de057ac0 de057ac0
dee0: 00000000 c016ee40 c0875e50 de05df2e de057ac0 00000000 00000013 00000000
df00: 00000000 c016f054 de043600 de0443c0 c008eb38 de004ec0 c0875e50 c008eb44
df20: 00000012 00000000 00000000 3931f0f8 00000000 00000000 00000014 c0822e84
df40: 00000000 c008ed2c 00000000 00000000 00000000 c07b7490 c07b7490 c075ab3c
df60: 00000000 c00701ac 00000002 00000000 c0070160 dffadb73 7bf8edb4 00000000
df80: c051092c 00000000 00000000 00000000 00000000 00000000 00000000 c0510934
dfa0: de05aa40 00000000 c051092c c0013ce8 00000000 00000000 00000000 00000000
dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 07efffe5 4dfac6f5
[<c0019590>] (arch_irq_work_raise+0x3c/0x48) from [<c00cb2dc>] (irq_work_queue+0xe4/0xf8)
[<c00cb2dc>] (irq_work_queue+0xe4/0xf8) from [<c00b0590>] (rcu_accelerate_cbs+0x1d4/0x1d8)
[<c00b0590>] (rcu_accelerate_cbs+0x1d4/0x1d8) from [<c00b07cc>] (rcu_start_gp+0x34/0x48)
[<c00b07cc>] (rcu_start_gp+0x34/0x48) from [<c00b0af8>] (rcu_process_callbacks+0x318/0x608)
[<c00b0af8>] (rcu_process_callbacks+0x318/0x608) from [<c004a4b0>] (__do_softirq+0x114/0x2a0)
[<c004a4b0>] (__do_softirq+0x114/0x2a0) from [<c004a704>] (do_softirq+0x6c/0x74)
[<c004a704>] (do_softirq+0x6c/0x74) from [<c004aa1c>] (irq_exit+0xac/0x100)
[<c004aa1c>] (irq_exit+0xac/0x100) from [<c0014b70>] (handle_IRQ+0x54/0xb4)
[<c0014b70>] (handle_IRQ+0x54/0xb4) from [<c0008634>] (omap3_intc_handle_irq+0x60/0x74)
[<c0008634>] (omap3_intc_handle_irq+0x60/0x74) from [<c051d0a4>] (__irq_svc+0x44/0x5c)
Exception stack(0xde05de80 to 0xde05dec8)
de80: 00000001 00000001 00000000 de05b440 c082afac de057ac0 de057ac0 de0443c0
dea0: 00000000 00000000 00000000 00000000 c082afbc de05dec8 c009f2a0 c051c778
dec0: 20000113 ffffffff
[<c051d0a4>] (__irq_svc+0x44/0x5c) from [<c051c778>] (_raw_spin_unlock_irq+0x28/0x2c)
[<c051c778>] (_raw_spin_unlock_irq+0x28/0x2c) from [<c016edb0>] (proc_alloc_inum+0x30/0xa8)
[<c016edb0>] (proc_alloc_inum+0x30/0xa8) from [<c016ee40>] (proc_register+0x18/0x130)
[<c016ee40>] (proc_register+0x18/0x130) from [<c016f054>] (proc_mkdir_data+0x44/0x6c)
[<c016f054>] (proc_mkdir_data+0x44/0x6c) from [<c008eb44>] (register_irq_proc+0x6c/0x128)
[<c008eb44>] (register_irq_proc+0x6c/0x128) from [<c008ed2c>] (init_irq_proc+0x74/0xb0)
[<c008ed2c>] (init_irq_proc+0x74/0xb0) from [<c075ab3c>] (kernel_init_freeable+0x84/0x1c8)
[<c075ab3c>] (kernel_init_freeable+0x84/0x1c8) from [<c0510934>] (kernel_init+0x8/0x150)
[<c0510934>] (kernel_init+0x8/0x150) from [<c0013ce8>] (ret_from_fork+0x14/0x2c)
Code: bad PC value

Fixes: bf18525f "ARM: 7872/1: Support arch_irq_work_raise() via self IPIs"
Reported-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Tested-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

By default, IRQ work is run from the tick interrupt (see
irq_work_run() in update_process_times()). When we're in full
NOHZ mode, restarting the tick requires the use of IRQ work and
if the only place we run IRQ work is in the tick interrupt we
have an unbreakable cycle. Implement arch_irq_work_raise() via
self IPIs to break this cycle and get the tick started again.
Note that we implement this via IPIs which are only available on
SMP builds. This shouldn't be a problem because full NOHZ is only
supported on SMP builds anyway.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Reviewed-by: NKevin Hilman <khilman@linaro.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The ARM architecture reference specifies that the IT state bits in the
PSR must be all zeros in ARM mode or behavior is unspecified.  On the
Qualcomm Snapdragon S4/Krait architecture CPUs the processor continues
to consider the IT state bits while in ARM mode.  This makes it so
that some instructions are skipped by the CPU.
Signed-off-by: NT.J. Purtell <tj@mobisocial.us>
[rmk+kernel@arm.linux.org.uk: fixed whitespace formatting in patch]
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The exception handling code fails to clear the IT state, potentially
leading to incorrect execution of the fixup if the size of the IT
block is more than one.

Let fixup_exception do the IT sanitizing if a fixup has been found,
and restore CPSR from the stack when returning from a data abort.

Cc: Will Deacon <will.deacon@arm.com>
Cc: stable@vger.kernel.org
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use CONFIG_ARCH_PHYS_ADDR_T_64BIT to determine
if ignoring or truncating of memory banks is
neccessary. This may be needed in the case of
64-bit memory bank addresses but when phys_addr_t
is kept 32-bit.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The DTB and/or the kernel command line may pass
64-bit addresses regardless of kernel configuration,
so update arm_add_memory() to take 64-bit arguments
independently of the phys_addr_t size.

This allows non-wrapping handling of high memory
banks such as the second memory bank of APE6EVM
(at 0x2_0000_0000) in case of 32-bit phys_addr_t.
Signed-off-by: NMagnus Damm <damm@opensource.se>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This is the ARM part of Christoph's patchset cleaning up the various
uses of __get_cpu_var across the tree.

The idea is to convert __get_cpu_var into either an explicit address
calculation using this_cpu_ptr() or into a use of this_cpu operations
that use the offset. Thereby address calculations are avoided and fewer
registers are used when code is generated.

[will: fixed debug ref counting checks and pcpu array accesses]
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NChristoph Lameter <cl@linux.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The work-around for A15 errata 798181 is not needed if appropriate ECO
fixes have been applied to r3p2 and earlier core revisions. This can be
checked by reading REVIDR register bits 4 and 9. If only bit 4 is set,
then the IPI broadcast can be skipped.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit 'f52bb722'
Author: Sricharan R <r.sricharan@ti.com>
    ARM: mm: Correct virt_to_phys patching for 64 bit physical addresses

introduced a __ARMEB__ macro usage in a new place, but missed the second
underscore. So correcting it here.

Also a explicit .align keyword is needed for the label with .long
data-type to be aligned on the 4 byte boundary. Otherwise this can
cause problem for thumb2 build. So adding it here.
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

In case of BE8 kernel data is in BE order whereas code stays in LE
order. Move sigreturn_codes to separate .S file and use proper
assembler mnemonics for these code snippets. In this case compiler
will take care of proper instructions byteswaps for BE8 case.
Change assumes that sufficiently Thumb-capable tools are used to
build kernel.

Problem was discovered during ltp testing of BE system: all rt_sig*
tests failed. Tested against the same tests in both BE and LE modes.
Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org>
Reviewed-by: NDave Martin <Dave.Martin@arm.com>
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>

Currently BUG() uses .word or .hword to create the necessary illegal
instructions. However if we are building BE8 then these get swapped
by the linker into different illegal instructions in the text. This
means that the BUG() macro does not get trapped properly.

Change to using <asm/opcodes.h> to provide the necessary ARM instruction
building as we cannot rely on gcc/gas having the `.inst` instructions
which where added to try and resolve this issue (reported by Dave Martin
<Dave.Martin@arm.com>).
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: NDave Martin <Dave.Martin@arm.com>

When in BE8 mode, our instructions are not in the same ordering as the
data, so use <asm/opcodes.h> to take this into account.

Note, also requires modules to be built --be8
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: NDave Martin <Dave.Martin@arm.com>

The trap handler needs to take into account the endian configuration of
the system when loading instructions. Use <asm/opcodes.h> to provide the
necessary conversion functions.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The smp_scu driver needs to use the relaxed readl/write accessors
to avoid any issues with the endian mode the processor core is in.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>

Ensure the twd driver uses the correct calls to access the hardware
to ensure that we do not end up with data in the wrong endian format.
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>

If we are booting in LE and compiled for BE8, then add code to
set the state to bE8. Since the instruction stream is always LE,
we do not need to do anything special to the instruction.

Also ensure that the secondary processors are started in the same mode.

Note, we do add about 20 bytes to the kernel image, but it seems easier
to do this than adding another configuration to change.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: NDave Martin <Dave.Martin@arm.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

The fixup_pv_table assumes that the instructions are in the same
endian configuration as the data, but when the CPU is running in
BE8 the instructions stay in little-endian format.

Make sure if CONFIG_CPU_ENDIAN_BE8 is set that we do all the
alterations to the instructions taking in to account the LDR/STR
will be swapping the data endian-ness.

Since the code is only modifying a byte, we avoid dual-swapping
the data, and just change the bits we clear and ORR in (in the
case where the code is not thumb2).

For thumb2, we add the necessary rev16 instructions to ensure that
the instructions are processed in the correct format, as it was
easier than re-writing the code to contain a mask and shift.
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Reviewed-by: NDave Martin <Dave.Martin@arm.com>
Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>

Add ARM_BE8() helper to wrap any code conditional on being
compile when CONFIG_ARM_ENDIAN_BE8 is selected and convert
existing places where this is to use it.
Acked-by: NNicolas Pitre <nico@linaro.org>
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>

This patch adds a step in the init sequence, in order to recreate
the kernel code/data page table mappings prior to full paging
initialization.  This is necessary on LPAE systems that run out of
a physical address space outside the 4G limit.  On these systems,
this implementation provides a machine descriptor hook that allows
the PHYS_OFFSET to be overridden in a machine specific fashion.

Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NR Sricharan <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

The current phys_to_virt patching mechanism works only for 32 bit
physical addresses and this patch extends the idea for 64bit physical
addresses.

The 64bit v2p patching mechanism patches the higher 8 bits of physical
address with a constant using 'mov' instruction and lower 32bits are patched
using 'add'. While this is correct, in those platforms where the lowmem addressable
physical memory spawns across 4GB boundary, a carry bit can be produced as a
result of addition of lower 32bits. This has to be taken in to account and added
in to the upper. The patched __pv_offset and va are added in lower 32bits, where
__pv_offset can be in two's complement form when PA_START < VA_START and that can
result in a false carry bit.

e.g
    1) PA = 0x80000000; VA = 0xC0000000
       __pv_offset = PA - VA = 0xC0000000 (2's complement)

    2) PA = 0x2 80000000; VA = 0xC000000
       __pv_offset = PA - VA = 0x1 C0000000

So adding __pv_offset + VA should never result in a true overflow for (1).
So in order to differentiate between a true carry, a __pv_offset is extended
to 64bit and the upper 32bits will have 0xffffffff if __pv_offset is
2's complement. So 'mvn #0' is inserted instead of 'mov' while patching
for the same reason. Since mov, add, sub instruction are to patched
with different constants inside the same stub, the rotation field
of the opcode is using to differentiate between them.

So the above examples for v2p translation becomes for VA=0xC0000000,
    1) PA[63:32] = 0xffffffff
       PA[31:0] = VA + 0xC0000000 --> results in a carry
       PA[63:32] = PA[63:32] + carry

       PA[63:0] = 0x0 80000000

    2) PA[63:32] = 0x1
       PA[31:0] = VA + 0xC0000000 --> results in a carry
       PA[63:32] = PA[63:32] + carry

       PA[63:0] = 0x2 80000000

The above ideas were suggested by Nicolas Pitre <nico@linaro.org> as
part of the review of first and second versions of the subject patch.

There is no corresponding change on the phys_to_virt() side, because
computations on the upper 32-bits would be discarded anyway.

Cc: Russell King <linux@arm.linux.org.uk>
Reviewed-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NSricharan R <r.sricharan@ti.com>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

On some PAE systems (e.g. TI Keystone), memory is above the
32-bit addressable limit, and the interconnect provides an
aliased view of parts of physical memory in the 32-bit addressable
space.  This alias is strictly for boot time usage, and is not
otherwise usable because of coherency limitations. On such systems,
the idmap mechanism needs to take this aliased mapping into account.

This patch introduces virt_to_idmap() and a arch function pointer which
can be populated by platform which needs it. Also populate necessary
idmap spots with now available virt_to_idmap(). Avoided #ifdef approach
to be compatible with multi-platform builds.

Most architecture won't touch it and in that case virt_to_idmap()
fall-back to existing virt_to_phys() macro.

Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>

Convert arm to use the common of_flat_dt_match_machine function.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org

Register with the generic sched_clock framework now that it
supports 64 bits. This fixes two problems with the current
sched_clock support for machines using the architected timers.
First off, we don't subtract the start value from subsequent
sched_clock calls so we can potentially start off with
sched_clock returning gigantic numbers. Second, there is no
support for suspend/resume handling so problems such as discussed
in 6a4dae5e (ARM: 7565/1: sched: stop sched_clock() during
suspend, 2012-10-23) can happen without this patch. Finally, it
allows us to move the sched_clock setup into drivers clocksource
out of the arch ports.

Cc: Christopher Covington <cov@codeaurora.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>

Convert arm to use new early_init_dt_scan function.
Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel@lists.infradead.org

Since software events can always be scheduled, perf allows software and
hardware events to be mixed together in the same event group. There are
two ways in which this can come about:

  (1) A SW event is added to a HW group. This validates using the HW PMU
      of the group leader.

  (2) A HW event is added to a SW group. This inserts the SW events and
      the new HW event into a HW context, but the SW event remains the
      group leader.

When validating the latter case, we would ideally compare the PMU of
each event in the group with the relevant HW PMU. The problem is, in the
face of potentially multiple HW PMUs, we don't have a handle on the
relevant structure. Commit 7b9f72c6 ("ARM: perf: clean up event
group validation") attempting to resolve this issue, but actually made
things *worse* by comparing with the leader PMU. If the leader is a SW
event, then we automatically `pass' all the HW events during validation!

This patch removes the check against the leader PMU. Whilst this will
allow events from multiple HW PMUs to be grouped together, that should
probably be dealt with in perf core as the result of a later patch.
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>