aboutsummaryrefslogtreecommitdiffstats
path: root/arch (follow)
AgeCommit message (Collapse)AuthorFilesLines
2015-02-19s390/spinlock: disabled compare-and-delay by defaultMartin Schwidefsky1-5/+7
Until we have hard performance data about the effects of CAD in the spinlock loop disable the instruction by default. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-02-19Merge branch 'mipsr6-for-3.20' of git://git.linux-mips.org/pub/scm/mchandras/linux into mips-for-linux-nextRalf Baechle65-415/+4405
2015-02-19MIPS: Export MSA functions used by lose_fpu(1) for KVMJames Hogan1-0/+4
Export the _save_msa asm function used by the lose_fpu(1) macro to GPL modules so that KVM can make use of it when it is built as a module. This fixes the following build error when CONFIG_KVM=m and CONFIG_CPU_HAS_MSA=y due to commit f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"): ERROR: "_save_msa" [arch/mips/kvm/kvm.ko] undefined! Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest) Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.15+ Patchwork: https://patchwork.linux-mips.org/patch/9261/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-02-19MIPS: Export FP functions used by lose_fpu(1) for KVMJames Hogan1-0/+6
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL modules so that KVM can make use of it when it is built as a module. This fixes the following build error when CONFIG_KVM=m due to commit f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"): ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined! Signed-off-by: James Hogan <james.hogan@imgtec.com> Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest) Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: kvm@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.10+ Patchwork: https://patchwork.linux-mips.org/patch/9260/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-02-19MIPS: BCM3384: Fix outdated use of mips_cpu_intc_init()Kevin Cernekee1-1/+1
This function was renamed to mips_cpu_irq_of_init(), so fix it to avoid a compile error. Signed-off-by: Kevin Cernekee <cernekee@gmail.com> Cc: f.fainelli@gmail.com Cc: jaedon.shin@gmail.com Cc: abrestic@chromium.org Cc: tglx@linutronix.de Cc: jason@lakedaemon.net Cc: jogo@openwrt.org Cc: arnd@arndb.de Cc: computersforpeace@gmail.com Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8834/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-02-19MIPS: Provide correct siginfo_t.si_stimePetr Malat2-37/+3
Provide correct siginfo_t.si_stime on MIPS64 Bug description: MIPS version of copy_siginfo() is not aware of alignment on platforms with 64-bit long integers, which leads to an incorrect si_stime passed to signal handlers, because the last element (si_stime) of _sifields._sigchld is not copied. If _MIPS_SZLONG is 64, then the _sifields starts at the offset of 4 * sizeof(int). Patch description: Use the generic copy_siginfo, which doesn't have this problem. Signed-off-by: Petr Malat <oss@malat.biz> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8671/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-02-19MIPS: Makefile: Move the ASEs checks after setting the core's CFLAGSMarkos Chandras1-18/+17
We need to check the ASEs support against the core's CFLAGS instead of depending to the default -march option from the toolchain. Signed-off-by: Markos Chandras <markos.chandras@imgtec.com> Cc: Maciej W. Rozycki <macro@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9180/ Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-02-19MIPS: Makefile: Pass -march option on Loongson3A coresRalf Baechle1-0/+10
The loongson 3A cores do not select a suitable -march option so the build system uses the default one from the toolchain. This may or may not be suitable for a loongson 3A build. In order to avoid that, we explicitly set a suitable -march option for that core. Furthermore, some very old compilers don't support -march= at all and there is the possibility of toolchain combinations such as GCC 4.9 and binutils 2.24 for which -march=loongson3a will result in MIPS64 R2 code being generated but then rejected by GAS. So treat the Longsoon 3A as an R2 CPU. Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2015-02-19Merge tag 'microcode_fixes_for-3.21' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp into x86/urgentIngo Molnar2-1/+10
Pull microcode fixes from Borislav Petkov: - Two fixes hardening microcode data handling. (Quentin Casasnovas) Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-19x86/microcode/intel: Handle truncated microcode images more robustlyQuentin Casasnovas2-0/+9
We do not check the input data bounds containing the microcode before copying a struct microcode_intel_header from it. A specially crafted microcode could cause the kernel to read invalid memory and lead to a denial-of-service. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Link: http://lkml.kernel.org/r/1422964824-22056-3-git-send-email-quentin.casasnovas@oracle.com [ Made error message differ from the next one and flipped comparison. ] Signed-off-by: Borislav Petkov <bp@suse.de>
2015-02-19x86/microcode/intel: Guard against stack overflow in the loaderQuentin Casasnovas1-1/+1
mc_saved_tmp is a static array allocated on the stack, we need to make sure mc_saved_count stays within its bounds, otherwise we're overflowing the stack in _save_mc(). A specially crafted microcode header could lead to a kernel crash or potentially kernel execution. Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Link: http://lkml.kernel.org/r/1422964824-22056-1-git-send-email-quentin.casasnovas@oracle.com Signed-off-by: Borislav Petkov <bp@suse.de>
2015-02-19Merge branch 'tip-x86-kaslr' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp into x86/urgentIngo Molnar8-20/+66
Pull ASLR and kASLR fixes from Borislav Petkov: - Add a global flag announcing KASLR state so that relevant code can do informed decisions based on its setting. (Jiri Kosina) - Fix a stack randomization entropy decrease bug. (Hector Marco-Gisbert) Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-19x86, mm/ASLR: Fix stack randomization on 64-bit systemsHector Marco-Gisbert1-3/+3
The issue is that the stack for processes is not properly randomized on 64 bit architectures due to an integer overflow. The affected function is randomize_stack_top() in file "fs/binfmt_elf.c": static unsigned long randomize_stack_top(unsigned long stack_top) { unsigned int random_variable = 0; if ((current->flags & PF_RANDOMIZE) && !(current->personality & ADDR_NO_RANDOMIZE)) { random_variable = get_random_int() & STACK_RND_MASK; random_variable <<= PAGE_SHIFT; } return PAGE_ALIGN(stack_top) + random_variable; return PAGE_ALIGN(stack_top) - random_variable; } Note that, it declares the "random_variable" variable as "unsigned int". Since the result of the shifting operation between STACK_RND_MASK (which is 0x3fffff on x86_64, 22 bits) and PAGE_SHIFT (which is 12 on x86_64): random_variable <<= PAGE_SHIFT; then the two leftmost bits are dropped when storing the result in the "random_variable". This variable shall be at least 34 bits long to hold the (22+12) result. These two dropped bits have an impact on the entropy of process stack. Concretely, the total stack entropy is reduced by four: from 2^28 to 2^30 (One fourth of expected entropy). This patch restores back the entropy by correcting the types involved in the operations in the functions randomize_stack_top() and stack_maxrandom_size(). The successful fix can be tested with: $ for i in `seq 1 10`; do cat /proc/self/maps | grep stack; done 7ffeda566000-7ffeda587000 rw-p 00000000 00:00 0 [stack] 7fff5a332000-7fff5a353000 rw-p 00000000 00:00 0 [stack] 7ffcdb7a1000-7ffcdb7c2000 rw-p 00000000 00:00 0 [stack] 7ffd5e2c4000-7ffd5e2e5000 rw-p 00000000 00:00 0 [stack] ... Once corrected, the leading bytes should be between 7ffc and 7fff, rather than always being 7fff. Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es> Signed-off-by: Ismael Ripoll <iripoll@upv.es> [ Rebased, fixed 80 char bugs, cleaned up commit message, added test example and CVE ] Signed-off-by: Kees Cook <keescook@chromium.org> Cc: <stable@vger.kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Fixes: CVE-2015-1593 Link: http://lkml.kernel.org/r/20150214173350.GA18393@www.outflux.net Signed-off-by: Borislav Petkov <bp@suse.de>
2015-02-19Merge branch 'tip-x86-mm' of git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp into x86/urgentIngo Molnar1-2/+26
Pull boot printout fix from Borislav Petkov. Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-19x86/mm/init: Fix incorrect page size in init_memory_mapping() printksDave Hansen1-2/+26
With 32-bit non-PAE kernels, we have 2 page sizes available (at most): 4k and 4M. Enabling PAE replaces that 4M size with a 2M one (which 64-bit systems use too). But, when booting a 32-bit non-PAE kernel, in one of our early-boot printouts, we say: init_memory_mapping: [mem 0x00000000-0x000fffff] [mem 0x00000000-0x000fffff] page 4k init_memory_mapping: [mem 0x37000000-0x373fffff] [mem 0x37000000-0x373fffff] page 2M init_memory_mapping: [mem 0x00100000-0x36ffffff] [mem 0x00100000-0x003fffff] page 4k [mem 0x00400000-0x36ffffff] page 2M init_memory_mapping: [mem 0x37400000-0x377fdfff] [mem 0x37400000-0x377fdfff] page 4k Which is obviously wrong. There is no 2M page available. This is probably because of a badly-named variable: in the map_range code: PG_LEVEL_2M. Instead of renaming all the PG_LEVEL_2M's. This patch just fixes the printout: init_memory_mapping: [mem 0x00000000-0x000fffff] [mem 0x00000000-0x000fffff] page 4k init_memory_mapping: [mem 0x37000000-0x373fffff] [mem 0x37000000-0x373fffff] page 4M init_memory_mapping: [mem 0x00100000-0x36ffffff] [mem 0x00100000-0x003fffff] page 4k [mem 0x00400000-0x36ffffff] page 4M init_memory_mapping: [mem 0x37400000-0x377fdfff] [mem 0x37400000-0x377fdfff] page 4k BRK [0x03206000, 0x03206fff] PGTABLE Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Cc: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/20150210212030.665EC267@viggo.jf.intel.com Signed-off-by: Borislav Petkov <bp@suse.de>
2015-02-19x86/mm/ASLR: Propagate base load address calculationJiri Kosina7-17/+63
Commit: e2b32e678513 ("x86, kaslr: randomize module base load address") makes the base address for module to be unconditionally randomized in case when CONFIG_RANDOMIZE_BASE is defined and "nokaslr" option isn't present on the commandline. This is not consistent with how choose_kernel_location() decides whether it will randomize kernel load base. Namely, CONFIG_HIBERNATION disables kASLR (unless "kaslr" option is explicitly specified on kernel commandline), which makes the state space larger than what module loader is looking at. IOW CONFIG_HIBERNATION && CONFIG_RANDOMIZE_BASE is a valid config option, kASLR wouldn't be applied by default in that case, but module loader is not aware of that. Instead of fixing the logic in module.c, this patch takes more generic aproach. It introduces a new bootparam setup data_type SETUP_KASLR and uses that to pass the information whether kaslr has been applied during kernel decompression, and sets a global 'kaslr_enabled' variable accordingly, so that any kernel code (module loading, livepatching, ...) can make decisions based on its value. x86 module loader is converted to make use of this flag. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Acked-by: Kees Cook <keescook@chromium.org> Cc: "H. Peter Anvin" <hpa@linux.intel.com> Link: https://lkml.kernel.org/r/alpine.LNX.2.00.1502101411280.10719@pobox.suse.cz [ Always dump correct kaslr status when panicking ] Signed-off-by: Borislav Petkov <bp@suse.de>
2015-02-19s390/mm: align 64-bit PIE binaries to 4GBMartin Schwidefsky1-1/+4
The base address (STACK_TOP / 3 * 2) for a 64-bit program is two thirds into the 4GB segment at 0x2aa00000000. The randomization added on z13 can eat another 1GB of the remaining 1.33GB to the next 4GB boundary. In the worst case 300MB are left for the executable + bss which may cross into the next 4GB segment. This is bad for branch prediction, therefore align the base address to 4GB to give the program more room before it crosses the 4GB boundary. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2015-02-19x86/intel/quark: Fix simple_return.cocci warningsFengguang Wu1-5/+1
arch/x86/platform/intel-quark/imr.c:129:1-4: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Andy Shevchenko <andy.schevchenko@gmail.com> Cc: Ong, Boon Leong <boon.leong.ong@intel.com> Cc: Bryan O'Donoghue <pure.logic@nexus-software.ie> Cc: Darren Hart <dvhart@linux.intel.com> Cc: kbuild-all@01.org Link: http://lkml.kernel.org/r/20150219081432.GA21996@waimea Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-19x86/intel/quark: Fix ptr_ret.cocci warningsFengguang Wu1-4/+1
arch/x86/platform/intel-quark/imr.c:280:1-3: WARNING: PTR_ERR_OR_ZERO can be used Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR Generated by: scripts/coccinelle/api/ptr_ret.cocci Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Andy Shevchenko <andy.schevchenko@gmail.com> Cc: Ong, Boon Leong <boon.leong.ong@intel.com> Cc: Bryan O'Donoghue <pure.logic@nexus-software.ie> Cc: Darren Hart <dvhart@linux.intel.com> Cc: kbuild-all@01.org Link: http://lkml.kernel.org/r/20150219081432.GA21983@waimea Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-19ARM: make of_device_ids constUwe Kleine-König15-16/+16
of_device_ids (i.e. compatible strings and the respective data) are not supposed to change at runtime. All functions working with of_device_ids provided by <linux/of.h> work with const of_device_ids. So mark the non-const structs in arch/arm as const, too. While at it also add some __initconst annotations. Acked-by: Jason Cooper <jason@lakedameon.net> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-02-19ARM: make arrays containing machine compatible strings constUwe Kleine-König11-16/+16
The definition static const char *axxia_dt_match[] __initconst = { ... defines a changable array of constant strings. That is you must not do: *axxia_dt_match[0] = 'k'; but axxia_dt_match[0] = "different string"; is fine. So the annotation __initconst is wrong and yields a compiler error when other really const variables are added with __initconst. As the struct machine_desc member dt_compat is declared as const char *const *dt_compat; making the arrays const is the better alternative over changing all annotations to __initdata. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-02-19lguest: update help text.Rusty Russell1-1/+1
We now add about 10k, not 6k, when lguest support is compiled in. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-02-19lguest: now depends on PCIRusty Russell1-1/+1
Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2015-02-18x86/intel/quark: Add Intel Quark platform supportBryan O'Donoghue2-0/+17
Add Intel Quark platform support. Quark needs to pull down all unlocked IMRs to ensure agreement with the EFI memory map post boot. This patch adds an entry in Kconfig for Quark as a platform and makes IMR support mandatory if selected. Suggested-by: Thomas Gleixner <tglx@linutronix.de> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Ong, Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Andy Shevchenko <andy.schevchenko@gmail.com> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Ong, Boon Leong <boon.leong.ong@intel.com> Cc: dvhart@infradead.org Link: http://lkml.kernel.org/r/1422635379-12476-3-git-send-email-pure.logic@nexus-software.ie Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18x86/intel/quark: Add Isolated Memory Regions for Quark X1000Bryan O'Donoghue5-0/+872
Intel's Quark X1000 SoC contains a set of registers called Isolated Memory Regions. IMRs are accessed over the IOSF mailbox interface. IMRs are areas carved out of memory that define read/write access rights to the various system agents within the Quark system. For a given agent in the system it is possible to specify if that agent may read or write an area of memory defined by an IMR with a granularity of 1 KiB. Quark_SecureBootPRM_330234_001.pdf section 4.5 details the concept of IMRs quark-x1000-datasheet.pdf section 12.7.4 details the implementation of IMRs in silicon. eSRAM flush, CPU Snoop write-only, CPU SMM Mode, CPU non-SMM mode, RMU and PCIe Virtual Channels (VC0 and VC1) can have individual read/write access masks applied to them for a given memory region in Quark X1000. This enables IMRs to treat each memory transaction type listed above on an individual basis and to filter appropriately based on the IMR access mask for the memory region. Quark supports eight IMRs. Since all of the DMA capable SoC components in the X1000 are mapped to VC0 it is possible to define sections of memory as invalid for DMA write operations originating from Ethernet, USB, SD and any other DMA capable south-cluster component on VC0. Similarly it is possible to mark kernel memory as non-SMM mode read/write only or to mark BIOS runtime memory as SMM mode accessible only depending on the particular memory footprint on a given system. On an IMR violation Quark SoC X1000 systems are configured to reset the system, so ensuring that the IMR memory map is consistent with the EFI provided memory map is critical to ensure no IMR violations reset the system. The API for accessing IMRs is based on MTRR code but doesn't provide a /proc or /sys interface to manipulate IMRs. Defining the size and extent of IMRs is exclusively the domain of in-kernel code. Quark firmware sets up a series of locked IMRs around pieces of memory that firmware owns such as ACPI runtime data. During boot a series of unlocked IMRs are placed around items in memory to guarantee no DMA modification of those items can take place. Grub also places an unlocked IMR around the kernel boot params data structure and compressed kernel image. It is necessary for the kernel to tear down all unlocked IMRs in order to ensure that the kernel's view of memory passed via the EFI memory map is consistent with the IMR memory map. Without tearing down all unlocked IMRs on boot transitory IMRs such as those used to protect the compressed kernel image will cause IMR violations and system reboots. The IMR init code tears down all unlocked IMRs and sets a protective IMR around the kernel .text and .rodata as one contiguous block. This sanitizes the IMR memory map with respect to the EFI memory map and protects the read-only portions of the kernel from unwarranted DMA access. Tested-by: Ong, Boon Leong <boon.leong.ong@intel.com> Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Reviewed-by: Andy Shevchenko <andy.schevchenko@gmail.com> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Ong, Boon Leong <boon.leong.ong@intel.com> Cc: andy.shevchenko@gmail.com Cc: dvhart@infradead.org Link: http://lkml.kernel.org/r/1422635379-12476-2-git-send-email-pure.logic@nexus-software.ie Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18x86/apic: Fix the devicetree build in certain configsRicardo Ribalda Delgado1-0/+8
Without this patch: LD init/built-in.o arch/x86/built-in.o: In function `dtb_lapic_setup': kernel/devicetree.c:155: undefined reference to `apic_force_enable' Makefile:923: recipe for target 'vmlinux' failed make: *** [vmlinux] Error 1 Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Reviewed-by: Maciej W. Rozycki <macro@linux-mips.org> Cc: David Rientjes <rientjes@google.com> Cc: Jan Beulich <JBeulich@suse.com> Link: http://lkml.kernel.org/r/1422905231-16067-1-git-send-email-ricardo.ribalda@gmail.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18kprobes/x86: Mark 2 bytes NOP as boostableWang Nan1-1/+1
Currently, x86 kprobes is unable to boost 2 bytes nop like: nopl 0x0(%rax,%rax,1) which is 0x0f 0x1f 0x44 0x00 0x00. Such nops have exactly 5 bytes to hold a relative jmp instruction. Boosting them should be obviously safe. This patch enable boosting such nops by simply updating twobyte_is_boostable[] array. Signed-off-by: Wang Nan <wangnan0@huawei.com> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: <lizefan@huawei.com> Link: http://lkml.kernel.org/r/1423532045-41049-1-git-send-email-wangnan0@huawei.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18uprobes/x86: Fix 2-byte opcode tableDenys Vlasenko1-35/+17
Enabled probing of lar, lsl, popcnt, lddqu, prefetch insns. They should be safe to probe, they throw no exceptions. Enabled probing of 3-byte opcodes 0f 38-3f xx - these are vector isns, so should be safe. Enabled probing of many currently undefined 0f xx insns. At the rate new vector instructions are getting added, we don't want to constantly enable more bits. We want to only occasionally *disable* ones which for some reason can't be probed. This includes 0f 24,26 opcodes, which are undefined since Pentium. On 486, they were "mov to/from test register". Explained more fully what 0f 78,79 opcodes are. Explained what 0f ae opcode is. (It's unclear why we don't allow probing it, but let's not change it for now). Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Jim Keniston <jkenisto@us.ibm.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1423768732-32194-3-git-send-email-dvlasenk@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18uprobes/x86: Fix 1-byte opcode tablesDenys Vlasenko1-48/+18
This change fixes 1-byte opcode tables so that only insns for which we have real reasons to disallow probing are marked with unset bits. To that end: Set bits for all prefix bytes. Their setting is ignored anyway - we check the bitmap against OPCODE1(insn), not against first byte. Keeping them set to 0 only confuses code reader with "why we don't support that opcode" question. Thus: enable bytes c4,c5 in 64-bit mode (VEX prefixes). Byte 62 (EVEX prefix) is not yet enabled since insn decoder does not support that yet. For 32-bit mode, enable probing of opcodes 63 (arpl) and d6 (salc). They don't require any special handling. For 64-bit mode, disable 9a and ea - these undefined opcodes were mistakenly left enabled. Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Jim Keniston <jkenisto@us.ibm.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1423768732-32194-2-git-send-email-dvlasenk@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18uprobes/x86: Add comment with insn opcodes, mnemonics and why we dont support themDenys Vlasenko1-19/+134
After adding these, it's clear we have some awkward choices there. Some valid instructions are prohibited from uprobing while several invalid ones are allowed. Hopefully future edits to the good-opcode tables will fix wrong bits or explain why those bits are not wrong. No actual code changes. Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Jim Keniston <jkenisto@us.ibm.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Link: http://lkml.kernel.org/r/1423768732-32194-1-git-send-email-dvlasenk@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18Merge tag 'asm-generic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-genericLinus Torvalds19-499/+582
Pull asm-generic uaccess.h cleanup from Arnd Bergmann: "Like in 3.19, I once more have a multi-stage cleanup for one asm-generic header file, this time the work was done by Michael Tsirkin and cleans up the uaccess.h file in asm-generic, as well as all architectures for which the respective maintainers did not pick up his patches directly" * tag 'asm-generic-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: (37 commits) sparc32: nocheck uaccess coding style tweaks sparc64: nocheck uaccess coding style tweaks xtensa: macro whitespace fixes sh: macro whitespace fixes parisc: macro whitespace fixes m68k: macro whitespace fixes m32r: macro whitespace fixes frv: macro whitespace fixes cris: macro whitespace fixes avr32: macro whitespace fixes arm64: macro whitespace fixes arm: macro whitespace fixes alpha: macro whitespace fixes blackfin: macro whitespace fixes sparc64: uaccess_64 macro whitespace fixes sparc32: uaccess_32 macro whitespace fixes avr32: whitespace fix sh: fix put_user sparse errors metag: fix put_user sparse errors ia64: fix put_user sparse errors ...
2015-02-18powerpc/corenet: Enable CLK_QORIQEmil Medve2-0/+2
Change-Id: I1a80ad7b9f6854791bd270b746f93a91439155a6 Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-02-18MIPS: Alchemy: Remove bogus args from alchemy_clk_fgcs_detrTomeu Vizoso1-2/+0
They were added to this function by mistake when they were added to the clk_ops.determine_rate callback. Fixes: 1c8e600440c7 ("clk: Add rate constraints to clocks") Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-02-18Merge tag 'virtio-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linuxLinus Torvalds5-63/+181
Pull virtio updates from Rusty Russell: "OK, this has the big virtio 1.0 implementation, as specified by OASIS. On top of tht is the major rework of lguest, to use PCI and virtio 1.0, to double-check the implementation. Then comes the inevitable fixes and cleanups from that work" * tag 'virtio-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (80 commits) virtio: don't set VIRTIO_CONFIG_S_DRIVER_OK twice. virtio_net: unconditionally define struct virtio_net_hdr_v1. tools/lguest: don't use legacy definitions for net device in example launcher. virtio: Don't expose legacy net features when VIRTIO_NET_NO_LEGACY defined. tools/lguest: use common error macros in the example launcher. tools/lguest: give virtqueues names for better error messages tools/lguest: more documentation and checking of virtio 1.0 compliance. lguest: don't look in console features to find emerg_wr. tools/lguest: don't start devices until DRIVER_OK status set. tools/lguest: handle indirect partway through chain. tools/lguest: insert driver references from the 1.0 spec (4.1 Virtio Over PCI) tools/lguest: insert device references from the 1.0 spec (4.1 Virtio Over PCI) tools/lguest: rename virtio_pci_cfg_cap field to match spec. tools/lguest: fix features_accepted logic in example launcher. tools/lguest: handle device reset correctly in example launcher. virtual: Documentation: simplify and generalize paravirt_ops.txt lguest: remove NOTIFY call and eventfd facility. lguest: remove NOTIFY facility from demonstration launcher. lguest: use the PCI console device's emerg_wr for early boot messages. lguest: always put console in PCI slot #1. ...
2015-02-18Merge branch 'for-linus' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds3-4/+4
Pull dmaengine updates from Vinod Koul: "This update brings: - the big cleanup up by Maxime for device control and slave capabilities. This makes the API much cleaner. - new IMG MDC driver by Andrew - new Renesas R-Car Gen2 DMA Controller driver by Laurent along with bunch of fixes on rcar drivers - odd fixes and updates spread over driver" * 'for-linus' of git://git.infradead.org/users/vkoul/slave-dma: (130 commits) dmaengine: pl330: add DMA_PAUSE feature dmaengine: pl330: improve pl330_tx_status() function dmaengine: rcar-dmac: Disable channel 0 when using IOMMU dmaengine: rcar-dmac: Work around descriptor mode IOMMU errata dmaengine: rcar-dmac: Allocate hardware descriptors with DMAC device dmaengine: rcar-dmac: Fix oops due to unintialized list in error ISR dmaengine: rcar-dmac: Fix spinlock issues in interrupt dmaenegine: edma: fix sparse warnings dmaengine: rcar-dmac: Fix uninitialized variable usage dmaengine: shdmac: extend PM methods dmaengine: shdmac: use SET_RUNTIME_PM_OPS() dmaengine: pl330: fix bug that cause start the same descs in cyclic dmaengine: at_xdmac: allow muliple dwidths when doing slave transfers dmaengine: at_xdmac: simplify channel configuration stuff dmaengine: at_xdmac: introduce save_cc field dmaengine: at_xdmac: wait for in-progress transaction to complete after pausing a channel ioat: fail self-test if wait_for_completion times out dmaengine: dw: define DW_DMA_MAX_NR_MASTERS dmaengine: dw: amend description of dma_dev field dmatest: move src_off, dst_off, len inside loop ...
2015-02-18Merge tag 'for-linus-20150216' of git://git.infradead.org/linux-mtdLinus Torvalds2-3/+10
Pull MTD updates from Brian Norris: "NAND: - Add new Hisilicon NAND driver for Hip04 - Add default reboot handler, to ensure all outstanding erase transactions complete in time - jz4740: convert to use GPIO descriptor API - Atmel: add support for sama5d4 - Change default bitflip threshold to 75% of correction strength - Miscellaneous cleanups and bugfixes SPI NOR: - Freescale QuadSPI: - Fix a few probe() and remove() issues - Add a MAINTAINERS entry for this driver - Tweak transfer size to increase read performance - Add suspend/resume support - Add Micron quad I/O support - ST FSM SPI: miscellaneous fixes JFFS2: - gracefully handle corrupted 'offset' field found on flash Other: - bcm47xxpart: add tweaks for a few new devices - mtdconcat: set return lengths properly for mtd_write_oob() - map_ram: enable use with mtdoops - maps: support fallback to ROM/UBI for write-protected NOR flash" * tag 'for-linus-20150216' of git://git.infradead.org/linux-mtd: (46 commits) mtd: hisilicon: && vs & typo jffs2: fix handling of corrupted summary length mtd: hisilicon: add device tree binding documentation mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc mtd: avoid registering reboot notifier twice mtd: concat: set the return lengths properly mtd: kconfig: replace PPC_OF with PPC mtd: denali: remove unnecessary stubs mtd: nand: remove redundant local variable MAINTAINERS: add maintainer entry for FREESCALE QUAD SPI driver mtd: fsl-quadspi: improve read performance by increase AHB transfer size mtd: fsl-quadspi: Remove unnecessary 'map_failed' label mtd: fsl-quadspi: Remove unneeded success/error messages mtd: fsl-quadspi: Fix the error paths mtd: nand: omap: drop condition with no effect mtd: nand: jz4740: Convert to GPIO descriptor API mtd: nand: Request strength instead of bytes for soft BCH mtd: nand: default bitflip-reporting threshold to 75% of correction strength mtd: atmel_nand: introduce a new compatible string for sama5d4 chip mtd: atmel_nand: return max bitflips in all sectors in pmecc_correction() ...
2015-02-18x86/irq: Check for valid irq descriptor in check_irq_vectors_for_cpu_disable()Joerg Roedel1-0/+3
When an interrupt is migrated away from a cpu it will stay in its vector_irq array until smp_irq_move_cleanup_interrupt succeeded. The cfg->move_in_progress flag is cleared already when the IPI was sent. When the interrupt is destroyed after migration its 'struct irq_desc' is freed and the vector_irq arrays are cleaned up. But since cfg->move_in_progress is already 0 the references at cpus before the last migration will not be cleared. So this would leave a reference to an already destroyed irq alive. When the cpu is taken down at this point, the check_irq_vectors_for_cpu_disable() function finds a valid irq number in the vector_irq array, but gets NULL for its descriptor and dereferences it, causing a kernel panic. This has been observed on real systems at shutdown. Add a check to check_irq_vectors_for_cpu_disable() for a valid 'struct irq_desc' to prevent this issue. Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Jiang Liu <jiang.liu@linux.intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jan Beulich <JBeulich@suse.com> Cc: K. Y. Srinivasan <kys@microsoft.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Yinghai Lu <yinghai@kernel.org> Cc: alnovak@suse.com Cc: joro@8bytes.org Link: http://lkml.kernel.org/r/20150204132754.GA10078@suse.de Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18x86/irq: Fix regression caused by commit b568b8601f05Jiang Liu1-0/+5
Commit b568b8601f05 ("Treat SCI interrupt as normal GSI interrupt") accidently removes support of legacy PIC interrupt when fixing a regression for Xen, which causes a nasty regression on HP/Compaq nc6000 where we fail to register the ACPI interrupt, and thus lose eg. thermal notifications leading a potentially overheated machine. So reintroduce support of legacy PIC based ACPI SCI interrupt. Reported-by: Ville Syrjälä <syrjala@sci.fi> Tested-by: Ville Syrjälä <syrjala@sci.fi> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: <stable@vger.kernel.org> # 3.19+ Cc: H. Peter Anvin <hpa@zytor.com> Cc: Len Brown <len.brown@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Rafael J. Wysocki <rjw@rjwysocki.net> Cc: Sander Eikelenboom <linux@eikelenboom.it> Cc: linux-pm@vger.kernel.org Link: http://lkml.kernel.org/r/1424052673-22974-1-git-send-email-jiang.liu@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18x86/spinlocks/paravirt: Fix memory corruption on unlockRaghavendra K T3-56/+64
Paravirt spinlock clears slowpath flag after doing unlock. As explained by Linus currently it does: prev = *lock; add_smp(&lock->tickets.head, TICKET_LOCK_INC); /* add_smp() is a full mb() */ if (unlikely(lock->tickets.tail & TICKET_SLOWPATH_FLAG)) __ticket_unlock_slowpath(lock, prev); which is *exactly* the kind of things you cannot do with spinlocks, because after you've done the "add_smp()" and released the spinlock for the fast-path, you can't access the spinlock any more. Exactly because a fast-path lock might come in, and release the whole data structure. Linus suggested that we should not do any writes to lock after unlock(), and we can move slowpath clearing to fastpath lock. So this patch implements the fix with: 1. Moving slowpath flag to head (Oleg): Unlocked locks don't care about the slowpath flag; therefore we can keep it set after the last unlock, and clear it again on the first (try)lock. -- this removes the write after unlock. note that keeping slowpath flag would result in unnecessary kicks. By moving the slowpath flag from the tail to the head ticket we also avoid the need to access both the head and tail tickets on unlock. 2. use xadd to avoid read/write after unlock that checks the need for unlock_kick (Linus): We further avoid the need for a read-after-release by using xadd; the prev head value will include the slowpath flag and indicate if we need to do PV kicking of suspended spinners -- on modern chips xadd isn't (much) more expensive than an add + load. Result: setup: 16core (32 cpu +ht sandy bridge 8GB 16vcpu guest) benchmark overcommit %improve kernbench 1x -0.13 kernbench 2x 0.02 dbench 1x -1.77 dbench 2x -0.63 [Jeremy: Hinted missing TICKET_LOCK_INC for kick] [Oleg: Moved slowpath flag to head, ticket_equals idea] [PeterZ: Added detailed changelog] Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Sasha Levin <sasha.levin@oracle.com> Tested-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Cc: Andrew Jones <drjones@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: Christoph Lameter <cl@linux.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Dave Jones <davej@redhat.com> Cc: David Vrabel <david.vrabel@citrix.com> Cc: Fernando Luis Vázquez Cao <fernando_b1@lab.ntt.co.jp> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Ulrich Obergfell <uobergfe@redhat.com> Cc: Waiman Long <Waiman.Long@hp.com> Cc: a.ryabinin@samsung.com Cc: dave@stgolabs.net Cc: hpa@zytor.com Cc: jasowang@redhat.com Cc: jeremy@goop.org Cc: paul.gortmaker@windriver.com Cc: riel@redhat.com Cc: tglx@linutronix.de Cc: waiman.long@hp.com Cc: xen-devel@lists.xenproject.org Link: http://lkml.kernel.org/r/20150215173043.GA7471@linux.vnet.ibm.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into x86/urgentIngo Molnar5-203/+301
Pull EFI fixes from Matt Fleming: " - Leave a valid 64-bit IDT installed during runtime EFI mixed mode calls to avoid triple faults if an NMI/MCE is received. - Revert Ard's change to the libstub get_memory_map() that went into the v3.20 merge window because it causes boot regressions on Qemu and Xen. " Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-02-18ARM: mm: Remove Kconfig symbol CACHE_PL310Paul Bolle2-8/+0
Commit 20e783e39e55 ("ARM: 8296/1: cache-l2x0: clean up aurora cache handling") removed the only user of the Kconfig symbol CACHE_PL310. Setting CACHE_PL310 is now pointless. Remove its Kconfig entry, and one select of this symbol. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-02-18Merge tag 'arm-soc/for-3.20/dts' of http://github.com/broadcom/stblinux into fixesArnd Bergmann2-2/+23
This pull request contains the following Broadcom SoCs Device Tree changes: - Ray adds support for the Cygnus i2c Device Tree controller on Cygnus SoCs - Fixes to the BCM63138 dtsi file for the L2 cache controller properties * tag 'arm-soc/for-3.20/dts' of http://github.com/broadcom/stblinux: ARM: dts: add I2C device nodes for Broadcom Cygnus ARM: dts: BCM63xx: fix L2 cache properties
2015-02-18ARM: rockchip: force built-in regulator support for PMArnd Bergmann1-0/+1
The rockchips suspend/resume code requires regulators to work, and gives a compile-time error if they are not available: arch/arm/mach-rockchip/built-in.o: In function `rk3288_suspend_finish': :(.text+0x146): undefined reference to `regulator_suspend_finish' arch/arm/mach-rockchip/built-in.o: In function `rk3288_suspend_prepare': :(.text+0x18e): undefined reference to `regulator_suspend_prepare' To solve this, we now enable regulators whenever they are needed, which is what we do on a lot of other platforms as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2015-02-18ARM: mvebu: build armada375-smp code conditionallyArnd Bergmann1-1/+1
mvebu_armada375_smp_wa_init is only used on armada 375 but is defined for all mvebu machines. As it calls a function that is only provided sometimes, this can result in a link error: arch/arm/mach-mvebu/built-in.o: In function `mvebu_armada375_smp_wa_init': :(.text+0x228): undefined reference to `mvebu_setup_boot_addr_wa' To solve this, we can just change the existing #ifdef around the function to also check for Armada375 SMP platforms. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 305969fb6292 ("ARM: mvebu: use the common function for Armada 375 SMP workaround") Cc: Andrew Lunn <andrew@lunn.ch> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Gregory Clement <gregory.clement@free-electrons.com>
2015-02-18ARM: sti: always enable RESET_CONTROLLERArnd Bergmann1-0/+1
A lot of the sti device drivers require reset controller support, but do not all have individual 'depends on RESET_CONTROLLER' statements. Using 'select' here once avoids a lot of build errors resulting from this. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Maxime Coquelin <maxime.coquelin@st.com> Acked-by: Patrice Chotard <patrice.chotard@st.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@gmail.com>
2015-02-18ARM: rockchip: make rockchip_suspend_init conditionalArnd Bergmann1-0/+6
If CONFIG_PM_SLEEP is disabled, we get a build error for rockchips: arch/arm/mach-rockchip/built-in.o: In function `rockchip_dt_init': :(.init.text+0x1c): undefined reference to `rockchip_suspend_init' This adds an inline alternative for that case. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Cc: linux-rockchip@lists.infradead.org
2015-02-18ARM: ixp4xx: fix {in,out}s{bwl} data typesArnd Bergmann1-6/+13
Most platforms use void pointer arguments in these functions, but ixp4xx does not, which triggers lots of warnings in device drivers like: net/ethernet/8390/ne2k-pci.c: In function 'ne2k_pci_get_8390_hdr': net/ethernet/8390/ne2k-pci.c:503:3: warning: passing argument 2 of 'insw' from incompatible pointer type insw(NE_BASE + NE_DATAPORT, hdr, sizeof(struct e8390_pkt_hdr)>>1); ^ In file included from include/asm/io.h:214:0, from /git/arm-soc/include/linux/io.h:22, from /git/arm-soc/include/linux/pci.h:31, from net/ethernet/8390/ne2k-pci.c:48: mach-ixp4xx/include/mach/io.h:316:91: note: expected 'u16 *' but argument is of type 'struct e8390_pkt_hdr *' static inline void insw(u32 io_addr, u16 *vaddr, u32 count) Fixing the drivers seems hopeless, so this changes the ixp4xx code to do the same as the others to avoid the warnings. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Krzysztof Halasa <khalasa@piap.pl> Cc: Imre Kaloz <kaloz@openwrt.org>
2015-02-18ARM: prima2: do not select SMP_ON_UPArnd Bergmann1-1/+0
The new Atlas7 platform implicitly selects 'CONFIG_SMP_ON_UP', which leads to problems if we enable building the platform without MMU, as that combination is not allowed and causes a link error: arch/arm/kernel/built-in.o: In function `c_show': :(.text+0x1872): undefined reference to `smp_on_up' :(.text+0x1876): undefined reference to `smp_on_up' arch/arm/kernel/built-in.o: In function `arch_irq_work_raise': :(.text+0x3d48): undefined reference to `smp_on_up' :(.text+0x3d4c): undefined reference to `smp_on_up' arch/arm/kernel/built-in.o: In function `smp_setup_processor_id': :(.init.text+0x180): undefined reference to `smp_on_up' This removes the 'select' statement. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 4cba058526a7 ("ARM: sirf: add Atlas7 machine support") Acked-by: Barry Song <Baohua.Song@csr.com> Cc: Zhiwu Song <Zhiwu.Song@csr.com>
2015-02-18ARM: at91: fix pm declarationsArnd Bergmann1-4/+4
In a recent rearrangement of the at91 pm initialization code, a broken set of declarations was added for the !CONFIG_PM-case, leading to this link error: arch/arm/mach-at91/board-dt-sama5.o: In function `at91_rm9200_pm_init': arch/arm/mach-at91/generic.h:40: multiple definition of `at91_rm9200_pm_init' arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:40: first defined here arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9260_pm_init': arch/arm/mach-at91/generic.h:41: multiple definition of `at91_sam9260_pm_init' arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:41: first defined here arch/arm/mach-at91/board-dt-sama5.o: In function `at91_sam9g45_pm_init': arch/arm/mach-at91/generic.h:42: multiple definition of `at91_sam9g45_pm_init' arch/arm/mach-at91/setup.o:arch/arm/mach-at91/generic.h:42: first defined here This adds the missing 'static inline' to the declarations to avoid creating a copy of the functions in each file that includes the header. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 4db0ba22da9 ("ARM: at91: pm: prepare for multiplatform") Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com> Cc: Alexandre Belloni <alexandre.belloni@free-electrons.com>
2015-02-18ARM: davinci: multi-soc kernels require AUTO_ZRELADDRArnd Bergmann1-0/+2
The davinci DA8xx and DMx families have incompatible zreladdr settings, and attempting to build a kernel with both enabled results in an error unless AUTO_ZRELADDR is set: multiple zreladdrs: 0xc0008000 0x80008000 This needs CONFIG_AUTO_ZRELADDR to be set This patch changes Kconfig to make the two families mutually exclusive when this is unset. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Sekhar Nori <nsekhar@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>