- 21 5月, 2013 1 次提交
-
-
由 Linus Torvalds 提交于
In commit 78d77df7 ("x86-64, init: Do not set NX bits on non-NX capable hardware") we added the early_pmd_flags that gets the NX bit set when a CPU supports NX. However, the new variable was marked __initdata, because the main _use_ of this is in an __init routine. However, the bit setting happens from secondary_startup_64(), which is called not only at bootup, but on every secondary CPU start. Including resuming from STR and at CPU hotplug time. So the value cannot be __initdata. Reported-bisected-and-tested-by: NMichal Hocko <mhocko@suse.cz> Cc: stable@vger.kernel.org # v3.9 Acked-by: NPeter Anvin <hpa@linux.intel.com> Cc: Fernando Luis Vázquez Cao <fernando@oss.ntt.co.jp> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 18 5月, 2013 11 次提交
-
-
由 Wolfram Sang 提交于
devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Acked-by: NJohn Crispin <blogic@openwrt.org>
-
由 Wolfram Sang 提交于
devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
-
由 Wolfram Sang 提交于
devm_ioremap_resource does sanity checks on the given resource. No need to duplicate this in the driver. Signed-off-by: NWolfram Sang <wsa@the-dreams.de> Acked-by: NStephen Warren <swarren@nvidia.com>
-
由 Matthijs Kooijman 提交于
This sets up the devicetree file for the rt3050 chip series and rt3052 eval board to use the right compatible string for the dwc2 driver. Acked-by: NJohn Crispin <blogic@openwrt.org> Cc: blogic@openwrt.org Cc: linux-mips@linux-mips.org Cc: Matthijs Kooijman <matthijs@stdin.nl> Patchwork: https://patchwork.linux-mips.org/patch/5226/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Tony Wu 提交于
schedule_mfi is supposed to be extracted from schedule(), and is used in thread_saved_pc and get_wchan. But, after optimization, schedule() is reduced to a sibling call to __schedule(), and no real frame info can be extracted. One solution is to compile schedule() with -fno-omit-frame-pointer and -fno-optimize-sibling-calls, but that will incur performance degradation. Another solution is to extract info from the real scheduler, __schedule, and this is the approache adopted here. This patch reads the __schedule address by either following the 'j' call in schedule if KALLSYMS is disabled or by using kallsyms_lookup_name to lookup __schedule if KALLSYMS is available, then, extracts schedule_mfi from __schedule frame info. This patch also fixes the "Can't analyze schedule() prologue" warning at boot time. Signed-off-by: NTony Wu <tung7970@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5237/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Tony Wu 提交于
Given a function, get_frame_info() analyzes its instructions to figure out frame size and return address. get_frame_info() works as follows: 1. analyze up to 128 instructions if the function size is unknown 2. search for 'addiu/daddiu sp,sp,-immed' for frame size 3. search for 'sw ra,offset(sp)' for return address 4. end search when it sees jr/jal/jalr This leads to an issue when the given function is a sibling call, example shown as follows. 801ca110 <schedule>: 801ca110: 8f820000 lw v0,0(gp) 801ca114: 8c420000 lw v0,0(v0) 801ca118: 080726f0 j 801c9bc0 <__schedule> 801ca11c: 00000000 nop 801ca120 <io_schedule>: 801ca120: 27bdffe8 addiu sp,sp,-24 801ca124: 3c028022 lui v0,0x8022 801ca128: afbf0014 sw ra,20(sp) In this case, get_frame_info() cannot properly detect schedule's frame info, and eventually returns io_schedule's instead. This patch adds 'j' to the end search condition to workaround sibling call cases. Signed-off-by: NTony Wu <tung7970@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/5236/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Denis Efremov 提交于
EXPORT_SYMBOL and inline directives are contradictory to each other. The patch fixes this inconsistency. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: NDenis Efremov <yefremov.denis@gmail.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: trivial@kernel.org Cc: ldv-project@linuxtesting.org Patchwork: https://patchwork.linux-mips.org/patch/5227/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 David Daney 提交于
As reported: This problem was discovered when doing BGP traffic with the TCP MD5 option activated, where the following call chain caused a crash: * tcp_v4_rcv * tcp_v4_timewait_ack * tcp_v4_send_ack -> follow stack variable rep.th * tcp_v4_md5_hash_hdr * tcp_md5_hash_header * sg_init_one * sg_set_buf * virt_to_page I noticed that tcp_v4_send_reset uses a similar stack variable and also calls tcp_v4_md5_hash_hdr, so it has the same problem. The networking core can indirectly call virt_to_phys() on stack addresses, if this is done from PID 0, the stack will usually be in CKSEG0, so virt_to_phys() needs to work there as well Signed-off-by: NDavid Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: Jiang Liu <liuj97@gmail.com> Cc: eunb.song@samsung.com Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/5220/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 EunBong Song 提交于
This patch fixes crash_dump.c build error. Build error logs are as follow. arch/mips/kernel/crash_dump.c: In function 'kdump_buf_page_init': arch/mips/kernel/crash_dump.c:67: error: implicit declaration of function 'kmalloc' arch/mips/kernel/crash_dump.c:67: error: assignment makes pointer from integer without a cast Signed-off-by: NEunBong Song <eunb.song@samsung.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/5238/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Libo Chen 提交于
When gptu_r32 fails, we should put clk before returning. Signed-off-by: NLibo Chen <libo.chen@huawei.com> Acked-by: NJohn Crispin <blogic@openwrt.org> Cc: grant.likely@linaro.org Cc: rob.herring@calxeda.com, Cc: linux-mips@linux-mips.org Cc: LKML linux-kernel@vger.kernel.org Cc: Andrew Morton akpm@linux-foundation.org Cc: Li Zefan lizefan@huawei.com Patchwork: https://patchwork.linux-mips.org/patch/5247/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Will Deacon 提交于
When we take an exception at EL1, we only want to enable debug exceptions if we're not currently stepping, otherwise we can easily get stuck in a loop stepping into interrupt handlers. Unfortunately, the current code tests the wrong bit in the mdscr, so fix that. Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
- 17 5月, 2013 2 次提交
-
-
由 David Daney 提交于
This reverts commit d532f3d2. The original commit has several problems: 1) Doesn't work with 64-bit kernels. 2) Calls TLBMISS_HANDLER_SETUP() before the code is generated. 3) Calls TLBMISS_HANDLER_SETUP() twice in per_cpu_trap_init() when only one call is needed. [ralf@linux-mips.org: Also revert the bits of the ASID patch which were hidden in the KVM merge.] Signed-off-by: NDavid Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: "Steven J. Hill" <Steven.Hill@imgtec.com> Cc: David Daney <david.daney@cavium.com> Patchwork: https://patchwork.linux-mips.org/patch/5242/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 David Daney 提交于
This reverts commit f6b06d93. The next revert depends on this one, so this has to go too. Signed-off-by: NDavid Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: "Steven J. Hill" <Steven.Hill@imgtec.com> Cc: David Daney <david.daney@cavium.com> Patchwork: https://patchwork.linux-mips.org/patch/5241/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 15 5月, 2013 1 次提交
-
-
由 John Stultz 提交于
Kay Sievers noted that the ALWAYS_USE_PERSISTENT_CLOCK config, which enables some minor compile time optimization to avoid uncessary code in mostly the suspend/resume path could cause problems for userland. In particular, the dependency for RTC_HCTOSYS on !ALWAYS_USE_PERSISTENT_CLOCK, which avoids setting the time twice and simplifies suspend/resume, has the side effect of causing the /sys/class/rtc/rtcN/hctosys flag to always be zero, and this flag is commonly used by udev to setup the /dev/rtc symlink to /dev/rtcN, which can cause pain for older applications. While the udev rules could use some work to be less fragile, breaking userland should strongly be avoided. Additionally the compile time optimizations are fairly minor, and the code being optimized is likely to be reworked in the future, so lets revert this change. Reported-by: NKay Sievers <kay@vrfy.org> Signed-off-by: NJohn Stultz <john.stultz@linaro.org> Cc: stable <stable@vger.kernel.org> #3.9 Cc: Feng Tang <feng.tang@intel.com> Cc: Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Link: http://lkml.kernel.org/r/1366828376-18124-1-git-send-email-john.stultz@linaro.orgSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 14 5月, 2013 25 次提交
-
-
由 Catalin Marinas 提交于
As per commit 764e0da1 (timers: Fixup the Kconfig consolidation fallout), init/Kconfig already includes kernel/time/Kconfig, so no need to do it explicitly for arm64. Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Sukanto Ghosh 提交于
The format of the lower 32-bits of the 64-bit operand to 'dc cisw' is unchanged from ARMv7 architecture and the upper bits are RES0. This implies that the 'way' field of the operand of 'dc cisw' occupies the bit-positions [31 .. (32-A)]. Due to the use of 64-bit extended operands to 'clz', the existing implementation of __flush_dcache_all is incorrectly placing the 'way' field in the bit-positions [63 .. (64-A)]. Signed-off-by: NSukanto Ghosh <sghosh@apm.com> Tested-by: NAnup Patel <anup.patel@linaro.org> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Cc: stable@vger.kernel.org
-
由 Catalin Marinas 提交于
The of_platform_populate() is currently invoked at device_initcall() level. There are however drivers that use platform_driver_probe() directly and they need the devices to be populated. This patch makes the of_platform_populate() and arch_initcall(). Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Reported-by: NBenoit Lecardonnel <Benoit.Lecardonnel@synopsys.com> Tested-by: NBenoit Lecardonnel <Benoit.Lecardonnel@synopsys.com>
-
由 Benjamin Herrenschmidt 提交于
Just like other architectures Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Neuling 提交于
Currently we only set the "to" address in the branch stack when the CPU explicitly gives us a value. Unfortunately it only does this for XL form branches (eg blr, bctr, bctar) and not I and B form branches (eg b, bc). Fortunately if we read the instruction from memory we can extract the offset of a branch and calculate the target address. This adds a function power_pmu_bhrb_to() to calculate the target/to address of the corresponding I and B form branches. It handles branches in both user and kernel spaces. It also plumbs this into the perf brhb reading code. Signed-off-by: NMichael Neuling <mikey@neuling.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Neuling 提交于
The current Branch History Rolling Buffer (BHRB) code misinterprets the order of entries in the hardware buffer. It assumes that a branch target address will be read _after_ its corresponding branch. In reality the branch target comes before (lower mfbhrb entry) it's corresponding branch. This is a rewrite of the code to take this into account. Signed-off-by: NMichael Neuling <mikey@neuling.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Neuling 提交于
The new Branch History Rolling buffer (BHRB) code is only useful on 64bit processors, so move it into the #ifdef CONFIG_PPC64 region. This avoids code bloat on 32bit systems. Signed-off-by: NMichael Neuling <mikey@neuling.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Li Zhong 提交于
Start context tracking support from pSeries. Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Li Zhong 提交于
This patch corresponds to [PATCH] x86: Use the new schedule_user API on userspace preemption commit 0430499cSigned-off-by: NLi Zhong <zhong@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Li Zhong 提交于
This patch allows RCU usage in do_notify_resume, e.g. signal handling. It corresponds to [PATCH] x86: Exit RCU extended QS on notify resume commit edf55fdaSigned-off-by: NLi Zhong <zhong@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Li Zhong 提交于
This is the exception hooks for context tracking subsystem, including data access, program check, single step, instruction breakpoint, machine check, alignment, fp unavailable, altivec assist, unknown exception, whose handlers might use RCU. This patch corresponds to [PATCH] x86: Exception hooks for userspace RCU extended QS commit 6ba3c97a But after the exception handling moved to generic code, and some changes in following two commits: 56dd9470 context_tracking: Move exception handling to generic code 6c1e0256 context_tracking: Restore correct previous context state on exception exit it is able for exception hooks to use the generic code above instead of a redundant arch implementation. Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Li Zhong 提交于
This is the syscall slow path hooks for context tracking subsystem, corresponding to [PATCH] x86: Syscall hooks for userspace RCU extended QS commit bf5a3c13 TIF_MEMDIE is moved to the second 16-bits (with value 17), as it seems there is no asm code using it. TIF_NOHZ is added to _TIF_SYCALL_T_OR_A, so it is better for it to be in the same 16 bits with others in the group, so in the asm code, andi. with this group could work. Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com> Acked-by: NFrederic Weisbecker <fweisbec@gmail.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Scott Wood 提交于
MSR_DE is not cleared on entry to the kernel, and we don't clear it explicitly outside of debug code. If we have MSR_DE set in prime_debug_regs(), and the new thread has events enabled in DBCR0 (e.g. ICMP is set in thread->dbsr0, even though it was cleared in the real DBCR0 when the thread got scheduled out), we'll end up taking a debug exception in the kernel when DBCR0 is loaded. DSRR0 will not point to an exception vector, and the kernel ends up hanging at kernel_dbg_exc. Fix this by always clearing MSR_DE when we load new debug state. Another observed source of kernel_dbg_exc hangs is with the branch taken event. If this event is active, but we take a non-debug trap (e.g. a TLB miss or an asynchronous interrupt) before the next branch. We end up taking a branch-taken debug exception on the initial branch instruction of the exception vector, but because the debug exception is DBSR_BT rather than DBSR_IC we branch to kernel_dbg_exc before even checking the DSRR0 address. Fix this by checking for DBSR_BT as well as DBSR_IC, which is what 32-bit does and what the comments suggest was intended in the 64-bit code as well. Signed-off-by: NScott Wood <scottwood@freescale.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Alexander Gordeev 提交于
Signed-off-by: NAlexander Gordeev <agordeev@redhat.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 David Woodhouse 提交于
Some versions of GCC apparently expect this to be provided by libgcc. Updates from Mikey to fix 32 bit version and adding "r" to registers. Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com> Signed-off-by: NMichael Neuling <mikey@neuling.org> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
The current code fails to handle kexec on OPALv2. This fixes it and adds code to improve the situation on OPALv3 where we can query the CPU status from the firmware and decide what to do based on that. Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Benjamin Herrenschmidt 提交于
Future firmwares will support that new version Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Li Zhong 提交于
Saw this warning again, and this time from the ret_from_fork path. It seems we could clear the back chain earlier in copy_thread(), which could cover both path, and also fix potential lockdep usage in schedule_tail(), or exception occurred before we clear the back chain. Signed-off-by: NLi Zhong <zhong@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Michael Ellerman 提交于
We are getting build errors with CONFIG_PROC_FS=n: arch/powerpc/kernel/rtas_flash.c In function 'rtas_flash_init': 745:33: error: unused variable 'f' [-Werror=unused-variable] But rtas_flash.c should not be built when CONFIG_PROC_FS=n, beacause all it does is provide a /proc interface to the RTAS flash routines. CONFIG_RTAS_FLASH already depends on CONFIG_RTAS_PROC, to indicate that it depends on the RTAS proc support, but CONFIG_RTAS_PROC does not depend on CONFIG_PROC_FS. So fix that. Signed-off-by: NMichael Ellerman <michael@ellerman.id.au> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Robert Jennings 提交于
This patch brings online all threads which are present but not online prior to migration/hibernation. After migration/hibernation those threads are taken back offline. During migration/hibernation all online CPUs must call H_JOIN, this is required by the hypervisor. Without this patch, threads that are offline (H_CEDE'd) will not be woken to make the H_JOIN call and the OS will be deadlocked (all threads either JOIN'd or CEDE'd). Cc: <stable@kernel.org> Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Vasant Hegde 提交于
ibm,validate-flash-image RTAS call output buffer contains 150 - 200 bytes of data on latest system. Presently we have output buffer size as 64 bytes and we use sprintf to copy data from RTAS buffer to local buffer. This causes kernel oops (see below call trace). This patch increases local buffer size to 256 and also uses snprintf instead of sprintf to copy data from RTAS buffer. Kernel call trace : ------------------- Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=1024 NUMA pSeries Modules linked in: nfs fscache lockd auth_rpcgss nfs_acl sunrpc fuse loop dm_mod ipv6 ipv6_lib usb_storage ehea(X) sr_mod qlge ses cdrom enclosure st be2net sg ext3 jbd mbcache usbhid hid ohci_hcd ehci_hcd usbcore qla2xxx usb_common sd_mod crc_t10dif scsi_dh_hp_sw scsi_dh_rdac scsi_dh_alua scsi_dh_emc scsi_dh lpfc scsi_transport_fc scsi_tgt ipr(X) libata scsi_mod Supported: Yes NIP: 4520323031333130 LR: 4520323031333130 CTR: 0000000000000000 REGS: c0000001b91779b0 TRAP: 0400 Tainted: G X (3.0.13-0.27-ppc64) MSR: 8000000040009032 <EE,ME,IR,DR> CR: 44022488 XER: 20000018 TASK = c0000001bca1aba0[4736] 'cat' THREAD: c0000001b9174000 CPU: 36 GPR00: 4520323031333130 c0000001b9177c30 c000000000f87c98 000000000000009b GPR04: c0000001b9177c4a 000000000000000b 3520323031333130 2032303133313031 GPR08: 3133313031350a4d 000000000000009b 0000000000000000 c0000000003664a4 GPR12: 0000000022022448 c000000003ee6c00 0000000000000002 00000000100e8a90 GPR16: 00000000100cb9d8 0000000010093370 000000001001d310 0000000000000000 GPR20: 0000000000008000 00000000100fae60 000000000000005e 0000000000000000 GPR24: 0000000010129350 46573738302e3030 2046573738302e30 300a4d4720323031 GPR28: 333130313520554e 4b4e4f574e0a4d47 2032303133313031 3520323031333130 NIP [4520323031333130] 0x4520323031333130 LR [4520323031333130] 0x4520323031333130 Call Trace: [c0000001b9177c30] [4520323031333130] 0x4520323031333130 (unreliable) Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Signed-off-by: NVasant Hegde <hegdevasant@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Anton Blanchard 提交于
commit b3f271e8 (powerpc: POWER7 optimised memcpy using VMX and enhanced prefetch) uses VMX when it is safe to do so (ie not in interrupt). It also looks at the task struct to decide if we have to save the current tasks' VMX state. kexec calls memcpy() at a point where the task struct may have been overwritten by the new kexec segments. If it has been overwritten then when memcpy -> enable_altivec looks up current->thread.regs->msr we get a cryptic oops or lockup. I also notice we aren't initialising thread_info->cpu, which means smp_processor_id is broken. Fix that too. Signed-off-by: NAnton Blanchard <anton@samba.org> Cc: <stable@vger.kernel.org> # 3.6+ Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Aneesh Kumar K.V 提交于
Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Aneesh Kumar K.V 提交于
Our pgtable are 2*sizeof(pte_t)*PTRS_PER_PTE which is PTE_FRAG_SIZE. Instead of depending on frag size, mask with PMD_MASKED_BITS. Signed-off-by: NAneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Jaccon Bastiaansen 提交于
The implementation of cmpxchg64() for the ARM v6 and v7 architecture casts parameter 2 and 3 (the old and new 64bit values) to an unsigned long before calling the atomic_cmpxchg64() function. This clears the top 32 bits of the old and new values, resulting in the wrong values being compare-exchanged. Luckily, this only appears to be used for 64-bit sched_clock, which we don't (yet) have on ARM. This bug was introduced by commit 3e0f5a15 ("ARM: 7404/1: cmpxchg64: use atomic64 and local64 routines for cmpxchg64"). Cc: <stable@vger.kernel.org> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NJaccon Bastiaansen <jaccon.bastiaansen@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-