m68knommu: Correct page_to_phys when PAGE_OFFSET is non-zero.

The definition of page_to_phys for nommu produces an incorrect value when
PAGE_OFFSET is non-zero.  The nommu version of page_to_pfn works correctly
for non-zero PAGE_OFFSET, so use that instead.

Signed-off-by: Steven King <sfking@fdwdc.com>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
m68knommu: Remove unnecessary prototype for kobjsize()

The prototype for kobjsize() is already defined in linux/mm.h which is
included where kobjsize() is used.

Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
ARM: nommu: don't limit TASK_SIZE

With TASK_SIZE set to the maximal RAM address booting in some XIP
configurations fails (e.g. on efm32 DK3750). The problem is that
strncpy_from_user et al. check for the address not being above TASK_SIZE
(since 8c56cc8be5b3 (ARM: 7449/1: use generic strnlen_user and
strncpy_from_user functions)) and this makes booting fail if the XIP
flash is above the RAM address space.

This change is in line with blackfin, frv and m68k which also use
0xffffffff for TASK_SIZE with !MMU.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
ARM: make user_addr_max more robust

With CONFIG_MMU=y get_fs() returns current_thread_info()->addr_limit
which is initialized as USER_DS (which in turn is defined to TASK_SIZE)
for userspace processes. At least theoretically
current_thread_info()->addr_limit is changable by set_fs() to a
different limit, so checking for KERNEL_DS is more robust.

With !CONFIG_MMU get_fs returns KERNEL_DS. To see what the old variant
did you'd have to find out that USER_DS == KERNEL_DS which isn't needed
any more with the variant this patch introduces. So it's a bit easier to
understand, too.

Also if the limit was changed this limit should be returned, not
TASK_SIZE.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
ARM: OMAP: add deprecation message for legacy OMAP DMA API

The legacy OMAP DMA API is now deprecated; all remaining users should
now convert over ASAP to using the DMA engine API instead of the OMAP
private API.

Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 8067/1: zImage: ensure header in LE format for BE8 kernels

All known BE8-capable systems have LE bootloaders, so we need to ensure
that the magic number and image start/end values are in little endian
format.

[ben.dooks@codethink.co.uk: from nico's original email on this subject]
[taras.kondratiuk@linaro.org: removed lds.S->lds rule, added target to extra-y]

Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: simplify generation of compressed vmlinux.lds file

As we are now using the C preprocessor, we do not need to use sed to
edit constants in this file, and then pass the resulting file through
the C preprocessor.  Instead, rely solely on the C preprocessor to
rewrite TEXT_START and BSS_ADDR.

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size

Changing kernel stack size on arm is not as simple as it should be:
1) THREAD_SIZE macro doesn't respect PAGE_SIZE and THREAD_SIZE_ORDER
2) stack size is hardcoded in get_thread_info macro

This patch fixes it by calculating THREAD_SIZE and thread_info address
taking into account PAGE_SIZE and THREAD_SIZE_ORDER.

Now changing stack size becomes simply changing THREAD_SIZE_ORDER.

Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
arm: perf: move event map macros to pmu.h

A few PMU-related macros are now looking a little lonely in
asm/perf_event.h now that all other PMU-specific structs, function
prototypes and macros live in pmu.h.

So as to make their placement consistent and to make it easier to build
atop of the current PMU functionality, let's reunite the entire family in
pmu.h

Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm: perf: add macros for empty event mappings

We currently map from userspace-ABI standard event numbers to
hardware-specific IDs by use of two arrays, *_perf_map and
*_perf_cache_map. While we use designated initializers to initialize the
events we care about, zero is typically a valid hardware event number,
and thus we have to explicitly initialize unsupported event mappings to a
nonzero value ({HW,CACHE}_OP_UNSUPPORTED).

In the case of the *_cache_map, this requires initialising almost every
entry in a 3-dimensional array to CACHE_OP_UNSUPPORTED, requiring over a
hundred lines to add eleven supported events in the case of Cortex A9.

So as to take up less space and make the tables easier to deal with,
this patch adds two new macros to initialize every entry in these tables
to the *_UNSUPPORTED values. Supported events can be overridden
individually through the use of designated initializers.

Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm: perf: armv7: condense event maps

Now that we have macros for declaring fully invalid event maps, put them
to work for all the ARMv7 PMU event maps. While this necessitates
repeating common indices, we no longer need to refer to *_UNSUPPORTED
events at all, and it makes it possible for the even maps to fit on a
single page on a reasonably sized monitor.

Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm: perf: armv6: condense event maps

Now that we have macros for declaring fully invalid event maps, put them
to work for all the ARMv6 PMU event maps. While this necessitates
repeating common indices, we no longer need to refer to *_UNSUPPORTED
events at all, and it makes it possible for the even maps to fit on a
single page on a reasonably sized monitor.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm: perf: xscale: condense event maps

Now that we have macros for declaring fully invalid event maps, put them
to work for the XScale PMU event maps. While this necessitates repeating
common indices, we no longer need to refer to *_UNSUPPORTED events at
all, and it makes it possible for the even maps to fit on a single page
on a reasonably sized monitor.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm: perf: clean up PMU names

The perf userspace tools can't handle dashes or spaces in PMU names,
which conflicts with the current naming scheme in the arm perf backend.
This prevents these PMUs from being accessed by name from the perf
tools. Additionally the ARMv6 pmus are named "v6", which does not fully
distinguish them in the sys/bus/event_source namespace.

This patch renames the PMUs consistently to a lower case form with
underscores, e.g. "armv6_1176", "armv7_cortex_a9". This is both readily
accepted by today's perf tool, and far easier to type than the
(apparently unused) convention in use previously. The OProfile name
conversion code is updated to handle this.

Due to a copy-paste error involving two "xscale1" entries, "xscale2" has
never been matched by the name OProfile name mapping. While we're
updating names, this is corrected.

Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
[sachin: fixed missing semicolons in armv6 backend]
Signed-off-by: Sachin Kamat <sachin.kamat@samsung.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm: perf: add more specific platform device IDs

When described in DT, PMUs are given specific compatible strings
(e.g. "arm,cortex-a15-pmu") which makes it very easy to reorganise the
way individual PMUs are handled (i.e. we can easily split them into
separate drivers). The same is not true of PMUs described in board
files, which are all use the platform_device_id "arm-pmu" and must all
be handled by the same driver.

To enable splitting the ARMv6, ARMv7, and XScale PMU drivers we need
board files to identify which variant they provide. As a first step,
this patch adds new platform_device_id values: "armv6-pmu", "armv7-pmu,
and "xscale-pmu".

Once board files are moved over and all existing uses of "arm-pmu" are
gone, we can split the existing driver apart.

Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
arm: perf: krait: stop using singleton PMU

Currently the krait_pmu_{enable,disable}_event functions use the global
cpu_pmu variable while all the other pmu enable/disable functions
derive this from the event argument.

This patch brings the Krait functions into line with the rest of the PMU
backends by deriving the address of the pmu from the event argument.

Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: perf: Check that current->mm is alive before getting user callchain

An event may occur when an mm is already released.

As per commit 20afc60f892d285fde179ead4b24e6a7938c2f1b
 'x86, perf: Check that current->mm is alive before getting user callchain'

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: perf: disable the pagefault handler when reading from user space

Under perf, the fp unwinding scheme requires access to user space memory
and can provoke a pagefault via call to __copy_from_user_inatomic from
user_backtrace. This unwinding can take place in response to an interrupt
(__perf_event_overflow). This is undesirable as we may already have
mmap_sem held for write. One example being a process that calls mprotect
just as a the PMU counters overflow.

An example that can provoke this behaviour:
perf record -e event:tocapture --call-graph fp ./application_to_test

This patch addresses this issue by disabling pagefaults briefly in
user_backtrace (as is done in the other architectures: ARM64, x86, Sparc etc.).

Without the patch a deadlock occurs when __perf_event_overflow is called
while reading the data from the user space:

 [ INFO: possible recursive locking detected ]
 3.16.0-rc2-00038-g0ed7ff6 #46 Not tainted
 ---------------------------------------------
 stress/1634 is trying to acquire lock:
 (&mm->mmap_sem){++++++}, at: [<c001dc04>] do_page_fault+0xa8/0x428

 but task is already holding lock:
 (&mm->mmap_sem){++++++}, at: [<c00f4098>] SyS_mprotect+0xa8/0x1c8

 other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&mm->mmap_sem);
  lock(&mm->mmap_sem);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

 2 locks held by stress/1634:
 #0:  (&mm->mmap_sem){++++++}, at: [<c00f4098>] SyS_mprotect+0xa8/0x1c8
 #1:  (rcu_read_lock){......}, at: [<c00c29dc>] __perf_event_overflow+0x120/0x294

 stack backtrace:
 CPU: 1 PID: 1634 Comm: stress Not tainted 3.16.0-rc2-00038-g0ed7ff6 #46
 [<c0017c8c>] (unwind_backtrace) from [<c0012eec>] (show_stack+0x20/0x24)
 [<c0012eec>] (show_stack) from [<c04de914>] (dump_stack+0x7c/0x98)
 [<c04de914>] (dump_stack) from [<c006a360>] (__lock_acquire+0x1484/0x1cf0)
 [<c006a360>] (__lock_acquire) from [<c006b14c>] (lock_acquire+0xa4/0x11c)
 [<c006b14c>] (lock_acquire) from [<c04e3880>] (down_read+0x40/0x7c)
 [<c04e3880>] (down_read) from [<c001dc04>] (do_page_fault+0xa8/0x428)
 [<c001dc04>] (do_page_fault) from [<c00084ec>] (do_DataAbort+0x44/0xa8)
 [<c00084ec>] (do_DataAbort) from [<c0013a1c>] (__dabt_svc+0x3c/0x60)
 Exception stack(0xed7c5ae0 to 0xed7c5b28)
 5ae0: ed7c5b5c b6dadff4 ffffffec 00000000 b6dadff4 ebc08000 00000000 ebc08000
 5b00: 0000007e 00000000 ed7c4000 ed7c5b94 00000014 ed7c5b2c c001a438 c0236c60
 5b20: 00000013 ffffffff
 [<c0013a1c>] (__dabt_svc) from [<c0236c60>] (__copy_from_user+0xa4/0x3a4)

Acked-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
ARM: 8101/1: mach-iop13xx: fix possible build failure

After applying patch:
	"ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size"

following build failure happens on iop13xx platform:

   In file included from include/linux/srcu.h:33:0,
                    from include/linux/notifier.h:15,
                    from include/linux/reboot.h:5,
                    from arch/arm/mach-iop13xx/include/mach/iop13xx.h:6,
                    from arch/arm/mach-iop13xx/include/mach/hardware.h:14,
                    from arch/arm/mach-iop13xx/include/mach/memory.h:4,
                    from arch/arm/include/asm/memory.h:24,
                    from arch/arm/include/asm/page.h:163,
                    from arch/arm/include/asm/thread_info.h:17,
                    from include/linux/thread_info.h:54,
                    from include/asm-generic/preempt.h:4,
                    from arch/arm/include/generated/asm/preempt.h:1,
                    from include/linux/preempt.h:18,
                    from include/linux/spinlock.h:50,
                    from include/linux/seqlock.h:35,
                    from include/linux/time.h:5,
                    from include/uapi/linux/timex.h:56,
                    from include/linux/timex.h:56,
                    from include/linux/sched.h:19,
                    from arch/arm/kernel/asm-offsets.c:13:
   include/linux/rcupdate.h: In function '__rcu_read_lock':
>> include/linux/rcupdate.h:220:2: error: implicit declaration of function 'preempt_disable' [-Werror=implicit-function-declaration]
     preempt_disable();

The problem here is recursive header inclusion which could be avoided by
removing linux/reboot.h from mach/iop13xxx.h.
linux/reboot.h in include/mach/iop13xx.h is needed only for enum reboot_mode,
so header it could be replaced with a enum declaration.

Whatever patch "ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size"
does, I think it's good to avoid unnecessary header inclusion here in any case.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrey Ryabinin <a.ryabinin@samsung.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 8081/1: MCPM: provide infrastructure to allow for MCPM loopback

The kernel already has the responsibility to handle resources such as the

CCI when hotplugging CPUs, during the booting of secondary CPUs, and when
resuming from suspend/idle.  It would be more coherent and less confusing
if the CCI for the boot CPU (or cluster)  was also initialized by the
kernel rather than expecting the firmware/bootloader to do it and only in
that case. After all, the kernel has all the necessary code already and
the bootloader shouldn't have to care at all.

The CCI may be turned on only when the cache is off. Leveraging the CPU
suspend code to loop back through the low-level MCPM entry point is all
that is needed to properly turn on the CCI from the kernel by using the
same code as during secondary boot.

Let's provide a generic MCPM loopback function that can be invoked by
backend initialization code to set things (CCI or similar) on the boot
CPU just as it is done for the other CPUs.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>