If we cannot relocate the kernel Image to its preferred offset of base of DRAM
plus TEXT_OFFSET, instead relocate it to the lowest available 2 MB boundary plus
TEXT_OFFSET. We may lose a bit of memory at the low end, but we can still
proceed normally otherwise.
Acked-by: NMark Salter <msalter@redhat.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NLeif Lindholm <leif.lindholm@linaro.org>
Tested-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

The static memory footprint of a kernel Image at boot is larger than the
Image file itself. Things like .bss data and initial page tables are allocated
statically but populated dynamically so their content is not contained in the
Image file.

However, if EFI (or GRUB) has loaded the Image at precisely the desired offset
of base of DRAM + TEXT_OFFSET, the Image will be booted in place, and we have
to make sure that the allocation done by the PE/COFF loader is large enough.

Fix this by growing the PE/COFF .text section to cover the entire static
memory footprint. The part of the section that is not covered by the payload
will be zero initialised by the PE/COFF loader.
Acked-by: NMark Salter <msalter@redhat.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NLeif Lindholm <leif.lindholm@linaro.org>
Tested-by: NLeif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

In certain cases the cpu-release-addr of a CPU may not fall in the
linear mapping (e.g. when the kernel is loaded above this address due to
the presence of other images in memory). This is problematic for the
spin-table code as it assumes that it can trivially convert a
cpu-release-addr to a valid VA in the linear map.

This patch modifies the spin-table code to use a temporary cached
mapping to write to a given cpu-release-addr, enabling us to support
addresses regardless of whether they are covered by the linear mapping.
Acked-by: NLeif Lindholm <leif.lindholm@linaro.org>
Tested-by: NLeif Lindholm <leif.lindholm@linaro.org>
Tested-by: NMark Salter <msalter@redhat.com>
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
[ardb: added (__force void *) cast]
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

VIPT caches are non-aliasing if the index is derived from address bits that
are always equal between VA and PA. Classifying these as aliasing results in
unnecessary flushing which may hurt performance.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

This adds helper functions and #defines to <asm/cachetype.h> to read the
line size and the number of sets from the level 1 instruction cache.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

The atmel,clk-divisors property is taking 4 divisors, if less are
provided, the clock registration will fail.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Actually register clocks from device tree when using the common clock
framework.
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
[nicolas.ferre@atmel.com: add at91 to function name]
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

The at91sam9g20 SOC uses its own pllb implementation which is different
from the one inherited from at91sam9260 SOC.
Signed-off-by: NGaël PORTAY <gael.portay@gmail.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

DRA7 evm REV G and later boards uses a vtt regulator for DDR3
termination and this is controlled by gpio7_11. This gpio is
configured in boot loader. gpio7_11, which is only available only on
Pad A22, in previous boards, is connected only to an unused pad on
expansion connector EXP_P3 and is safe to be muxed as GPIO on all
DRA7-evm versions (without a need to spin off another dts file).

Since gpio7_11 is used to control VTT and should not be reset or kept
in idle state during boot up else VTT will be disconnected and DDR
gets corrupted. So, as part of this change, mark gpio7 as no-reset and
no-idle on init.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

While auditing the various pin ctrl configurations using the following
command:
grep PIN_ arch/arm/boot/dts/dra7-evm.dts|(while read line;
do
	v=`echo "$line" | sed -e "s/\s\s*/|/g" | cut -d '|' -f1 |
		cut -d 'x' -f2|tr [a-z] [A-Z]`;
	HEX=`echo "obase=16;ibase=16;4A003400+$v"| bc`;
	echo "$HEX ===> $line";
done)
against DRA75x/74x NDA TRM revision S(SPRUHI2S August 2014),
documentation errors were found for spi1 pinctrl. Fix the same.

Fixes: 6e58b8f1 ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board")
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Both QSPI and GPMC-NAND share the same Pin (A8) from the SoC for Chip Select
functionality. So both can't be enabled simultaneously.

Disable QSPI node to prevent the pin conflict as well as
be similar to 3.12 release.

CC: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

For NAND read & write wait pin monitoring must be kept disabled as the
wait pin is only used to indicate NAND device ready status and not to
extend each read/write cycle.

So don't print a warning if wait pin is specified while read/write
monitoring is not in the device tree.

Sanity check wait pin number irrespective if read/write monitoring is
set or not.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

NAND uses wait pin only to indicate device readiness after
a block/page operation. It is not use to extend individual
read/write cycle and so read/write wait pin monitoring must
be disabled for NAND.

Add gpmc wait pin information as the NAND uses wait pin 0
for device ready indication.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

NAND uses wait pin only to indicate device readiness after
a block/page operation. It is not use to extend individual
read/write cycle and so read/write wait pin monitoring must
be disabled for NAND.

This patch also gets rid of the below warning when NAND is
accessed for the first time.

omap_l3_noc 44000000.ocp: L3 application error: target 13 mod:1 (unclearable)
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

am437x-gp-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.

For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

am43x-epos-evm uses a NAND chip with page size 4096 bytes
and spare area of 225 bytes per page.

For such a setup it is preferrable to use BCH16 ECC scheme over
BCH8. This also makes it compatible with ROM code ECC scheme so
we can boot with NAND after flashing from kernel.
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Reviewed-by: NPekon Gupta <pekon@pek-sem.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Size should be 64KiB instead of 92KiB.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

On the GP EVM, the ambient light sensor is limited to 100KHz on the
I2C bus.

So use 100kHz for I2C on the GP EVM due to this limitation on the
ambient light sensor.
Reported-by: NAparna Balasubramanian <aparnab@ti.com>
Signed-off-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The 8th NAND partition should be named "NAND.u-boot-env.backup1"
instead of "NAND.u-boot-env". This is to be consistent with other
TI boards as well as u-boot.

CC: Pekon Gupta <pekon@pek-sem.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NSekhar Nori <nsekhar@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The I2C3 pins are taken from pads E21 (GPIO6_14) and
F20 (GPIO6_15). Use the right pinmux register and mode.

Also set the I2C3 bus frequency to a safer 400KHz than
3.4Mhz.

CC: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Structure name and variable name were erroneously interchanged
Signed-off-by: NNoam Camus <noamc@ezchip.com>
Acked-by: NVineet Gupta <vgupta@synopsys.com>
[ Also removed pointless cast from "void *".  - Linus ]
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

fc95ca72 introduces a memset in
kvmppc_alloc_hpt since the general CMA doesn't clear the memory it
allocates.

However, the size argument passed to memset is computed from a signed value
and its signed bit is extended by the cast the compiler is doing. This lead
to extremely large size value when dealing with order value >= 31, and
almost all the memory following the allocated space is cleaned. As a
consequence, the system is panicing and may even fail spawning the kdump
kernel.

This fix makes use of an unsigned value for the memset's size argument to
avoid sign extension. Among this fix, another shift operation which may
lead to signed extended value too is also fixed.

Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NLaurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Analogous to commit 8858d88a
that fixed commit 70b41abc
"ARM: ux500: move MSP pin control to the device tree"
accidentally activated MSP2, giving rise to a boot scroll
scream as the kernel attempts to probe a driver for it and
fails to obtain DMA channel 14.

For some reason I forgot to fix this on the Snowball. Fix
this up by marking the node disabled again.

Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

commit 0944fe3f ("s390/mm: implement software referenced bits")
triggered another paging/storage key corruption. There is an
unhandled invalid->valid pte change where we have to set the real
storage key from the pgste.
When doing paging a guest page might be swapcache or swap and when
faulted in it might be read-only and due to a parallel scan old.
An do_wp_page will make it writeable and young. Due to software
reference tracking this page was invalid and now becomes valid.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Cc: stable@vger.kernel.org # v3.12+

Since 3.12 or more precisely  commit 0944fe3f ("s390/mm:
implement software referenced bits") guest storage keys get
corrupted during paging. This commit added another valid->invalid
translation for page tables - namely ptep_test_and_clear_young.
We have to transfer the storage key into the pgste in that case.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
Cc: stable@vger.kernel.org # v3.12+

It turns out that vendors are relying on the format of /proc/cpuinfo,
and we've even spotted out-of-tree hacks attempting to make it look
identical to the format used by arch/arm/. That means we can't afford to
churn this interface in mainline, so revert the recent reformatting of
the file for arm64 pending discussions on the list to find out what
people actually want.

This reverts commit d7a49086.
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Now arm64 defers reloading FPSIMD state, but this optimization also
introduces the bug after cpu resume back from low power mode.

The reason is after the cpu has been powered off, s/w need set the
cpu's fpsimd_last_state to NULL so that it will force to reload
FPSIMD state for the thread, otherwise there has the chance to meet
the condition for both the task's fpsimd_state.cpu field contains the
id of the current cpu, and the cpu's fpsimd_last_state per-cpu variable
points to the task's fpsimd_state, so finally kernel will skip to reload
the context during it return back to userland.
Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NLeo Yan <leoy@marvell.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>

unicore32 builds fail with

  arch/unicore32/kernel/signal.c: In function ‘setup_frame’:
  arch/unicore32/kernel/signal.c:257: error: ‘usig’ undeclared (first use in this function)
  arch/unicore32/kernel/signal.c:279: error: ‘usig’ undeclared (first use in this function)
  arch/unicore32/kernel/signal.c: In function ‘handle_signal’:
  arch/unicore32/kernel/signal.c:306: warning: unused variable ‘tsk’
  arch/unicore32/kernel/signal.c: In function ‘do_signal’:
  arch/unicore32/kernel/signal.c:376: error: implicit declaration of function ‘get_signsl’
  make[1]: *** [arch/unicore32/kernel/signal.o] Error 1
  make: *** [arch/unicore32/kernel/signal.o] Error 2

Bisect points to commit 649671c9 ("unicore32: Use get_signal()
signal_setup_done()").

This code never even compiled.  Reverting the patch does not work, since
previously used functions no longer exist, so try to fix it up.  Compile
tested only.

Fixes: 649671c9 ("unicore32: Use get_signal() signal_setup_done()")
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With ARCH_VEXPRESS_SPC option, kernel build has the following
warning:

arch/arm/mach-vexpress/spc.c: In function ‘ve_spc_clk_init’:
arch/arm/mach-vexpress/spc.c:431:38: warning: array subscript is below array bounds [-Warray-bounds]
  struct ve_spc_opp *opps = info->opps[cluster];
                                      ^
since 'cluster' maybe '-1' in UP system. This patch does a active
checking to fix this issue.
Signed-off-by: NAlex Shi <alex.shi@linaro.org>
Acked-by: NPawel Moll <pawel.moll@arm.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Without this patch the kexec-purgatory.c and purgatory.ro files are not
removed after make mrproper.
Signed-off-by: NMichael Welling <mwelling@ieee.org>
Acked-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix building errors occuring due to a missing export of
flush_icache_range() in

kisskb.ellerman.id.au/kisskb/buildresult/11677809/

ERROR: "flush_icache_range" [drivers/misc/lkdtm.ko] undefined!
Signed-off-by: NPranith Kumar <bobby.prani@gmail.com>
Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Vineet Gupta <vgupta@synopsys.com>	[arc]
Acked-by: Richard Kuo <rkuo@codeaurora.org>	[hexagon]
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Chris Zankel <chris@zankel.net>
Acked-by: Max Filippov <jcmvbkbc@gmail.com>	[xtensa]
Cc: Noam Camus <noamc@ezchip.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Acked-by: Zhigang Lu <zlu@tilera.com>		[tile]
Cc: Kirill Tkhai <tkhai@yandex.ru>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Thomas reported that build of x86_64 kernel was failing for him.  He is
using 32bit tool chain.

Problem is that while compiling purgatory, I have not specified -m64
flag.  And 32bit tool chain must be assuming -m32 by default.

Following is error message.

(mini) [~/work/linux-2.6] make
scripts/kconfig/conf --silentoldconfig Kconfig
  CHK     include/config/kernel.release
  UPD     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  UPD     include/generated/utsrelease.h
  CC      arch/x86/purgatory/purgatory.o
arch/x86/purgatory/purgatory.c:1:0: error: code model 'large' not supported in
the 32 bit mode

Fix it by explicitly passing appropriate -m64/-m32 build flag for
purgatory.
Reported-by: NThomas Glanzmann <thomas@glanzmann.de>
Tested-by: NThomas Glanzmann <thomas@glanzmann.de>
Suggested-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

New system call depends on crypto.  As it did not have a separate config
option, CONFIG_KEXEC was modified to select CRYPTO and CRYPTO_SHA256.

But now previous patch introduced a new config option for new syscall.
So CONFIG_KEXEC does not require crypto.  Remove that dependency.
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently new system call kexec_file_load() and all the associated code
compiles if CONFIG_KEXEC=y.  But new syscall also compiles purgatory
code which currently uses gcc option -mcmodel=large.  This option seems
to be available only gcc 4.4 onwards.

Hiding new functionality behind a new config option will not break
existing users of old gcc.  Those who wish to enable new functionality
will require new gcc.  Having said that, I am trying to figure out how
can I move away from using -mcmodel=large but that can take a while.

I think there are other advantages of introducing this new config
option.  As this option will be enabled only on x86_64, other arches
don't have to compile generic kexec code which will never be used.  This
new code selects CRYPTO=y and CRYPTO_SHA256=y.  And all other arches had
to do this for CONFIG_KEXEC.  Now with introduction of new config
option, we can remove crypto dependency from other arches.

Now CONFIG_KEXEC_FILE is available only on x86_64.  So whereever I had
CONFIG_X86_64 defined, I got rid of that.

For CONFIG_KEXEC_FILE, instead of doing select CRYPTO=y, I changed it to
"depends on CRYPTO=y".  This should be safer as "select" is not
recursive.
Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Tested-by: NShaun Ruffell <sruffell@digium.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sasha Levin has shown oopses on ffffea0003480048 and ffffea0003480008 at
mm/memory.c:1132, running Trinity on different 3.16-rc-next kernels:
where zap_pte_range() checks page->mapping to see if PageAnon(page).

Those addresses fit struct pages for pfns d2001 and d2000, and in each
dump a register or a stack slot showed d2001730 or d2000730: pte flags
0x730 are PCD ACCESSED PROTNONE SPECIAL IOMAP; and Sasha's e820 map has
a hole between cfffffff and 100000000, which would need special access.

Commit c46a7c81 ("x86: define _PAGE_NUMA by reusing software bits on
the PMD and PTE levels") has broken vm_normal_page(): a PROTNONE SPECIAL
pte no longer passes the pte_special() test, so zap_pte_range() goes on
to try to access a non-existent struct page.

Fix this by refining pte_special() (SPECIAL with PRESENT or PROTNONE) to
complement pte_numa() (SPECIAL with neither PRESENT nor PROTNONE).  A
hint that this was a problem was that c46a7c81 added pte_numa() test
to vm_normal_page(), and moved its is_zero_pfn() test from slow to fast
path: This was papering over a pte_special() snag when the zero page was
encountered during zap.  This patch reverts vm_normal_page() to how it
was before, relying on pte_special().

It still appears that this patch may be incomplete: aren't there other
places which need to be handling PROTNONE along with PRESENT?  For
example, pte_mknuma() clears _PAGE_PRESENT and sets _PAGE_NUMA, but on a
PROT_NONE area, that would make it pte_special().  This is side-stepped
by the fact that NUMA hinting faults skipped PROT_NONE VMAs and there
are no grounds where a NUMA hinting fault on a PROT_NONE VMA would be
interesting.

Fixes: c46a7c81 ("x86: define _PAGE_NUMA by reusing software bits on the PMD and PTE levels")
Reported-by: NSasha Levin <sasha.levin@oracle.com>
Tested-by: NSasha Levin <sasha.levin@oracle.com>
Signed-off-by: NHugh Dickins <hughd@google.com>
Signed-off-by: NMel Gorman <mgorman@suse.de>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: <stable@vger.kernel.org>	[3.16]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

write{b,w,l,q}_relaxed are implemented by some architectures in order to
permit memory-mapped I/O writes with weaker barrier semantics than the
non-relaxed variants.

This patch implements these write macros for Alpha, in the same vein as
the relaxed read macros, which are already implemented.
Acked-by: NRichard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NMichael Cree <mcree@orcon.net.nz>
Signed-off-by: NMatt Turner <mattst88@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The KSTK_ESP macro is used to determine the user stack pointer for a
given task. In particular, this is used to to report the '[stack]' VMA
in /proc/self/maps, which is used by Android to determine the stack
location for children of the main thread.

This patch fixes the macro to use user_stack_pointer instead of directly
returning sp. This means that we report w13 instead of sp, since the
former is used as the stack pointer when executing in AArch32 state.

Cc: <stable@vger.kernel.org>
Reported-by: NSerban Constantinescu <Serban.Constantinescu@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>