summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2013-04-27Merge tag 'fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fix from Olof Johansson: "A late-arriving fix for musb on OMAP4, resolving an issue where the musb IP won't be clocked and thus not functional. Small in scope, most of the lines changed is a longish comment." * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock
2013-04-26Merge tag 'omap-for-v3.9-rc6/fixes-signed' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes From Tony Lindgren: One MUSB regression fix that I forgot to send earlier. Without this MUSB no longer works on omap4 based devices. * tag 'omap-for-v3.9-rc6/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: ARM: OMAP4: hwmod data: make 'ocp2scp_usb_phy_phy_48m" as the main clock Signed-off-by: Olof Johansson <olof@lixom.net>
2013-04-26Merge branch 'fixes-3.9-late' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull late parisc fixes from Helge Deller: "I know it's *very* late in the 3.9 release cycle, but since there aren't that many people testing the parisc linux kernel, a few (for our port) critical issues just showed up a few days back for the first time. What's in it? - add missing __ucmpdi2 symbol, which is required for btrfs on 32bit kernel. - change kunmap() macro to static inline function. This fixes a debian/gcc-4.4 build error. - add locking when doing PTE updates. This fixes random userspace crashes. - disable (optional) -mlong-calls compiler option for modules, else modules can't be loaded at runtime. - a smart patch by Will Deacon which fixes 64bit put_user() warnings on 32bit kernel." * 'fixes-3.9-late' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: use spin_lock_irqsave/spin_unlock_irqrestore for PTE updates parisc: disable -mlong-calls compiler option for kernel modules parisc: uaccess: fix compiler warnings caused by __put_user casting parisc: Change kunmap macro to static inline function parisc: Provide __ucmpdi2 to resolve undefined references in 32 bit builds.
2013-04-25Merge tag 'efi-urgent' into x86/urgentH. Peter Anvin
* The EFI variable anti-bricking algorithm merged in -rc8 broke booting on some Apple machines because they implement EFI spec 1.10, which doesn't provide a QueryVariableInfo() runtime function and the logic used to check for the existence of that function was insufficient. Fix from Josh Boyer. * The anti-bricking algorithm also introduced a compiler warning on 32-bit. Fix from Borislav Petkov. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-04-25parisc: use spin_lock_irqsave/spin_unlock_irqrestore for PTE updatesJohn David Anglin
User applications running on SMP kernels have long suffered from instability and random segmentation faults. This patch improves the situation although there is more work to be done. One of the problems is the various routines in pgtable.h that update page table entries use different locking mechanisms, or no lock at all (set_pte_at). This change modifies the routines to all use the same lock pa_dbit_lock. This lock is used for dirty bit updates in the interruption code. The patch also purges the TLB entries associated with the PTE to ensure that inconsistent values are not used after the page table entry is updated. The UP and SMP code are now identical. The change also includes a minor update to the purge_tlb_entries function in cache.c to improve its efficiency. Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de>
2013-04-25parisc: disable -mlong-calls compiler option for kernel modulesHelge Deller
CONFIG_MLONGCALLS was introduced in commit ec758f98328da3eb933a25dc7a2eed01ef44d849 to overcome linker issues when linking huge linux kernels, e.g. with many modules linked in. But in the kernel module loader there is no support yet for the new relocation types, which is why modules built with -mlong-calls can't be loaded. Furthermore, for modules long calls are not really necessary, since we already use stub sections which resolve long distance calls. So, let's just disable this compiler option when compiling kernel modules. Signed-off-by: Helge Deller <deller@gmx.de>
2013-04-25parisc: uaccess: fix compiler warnings caused by __put_user castingWill Deacon
When targetting 32-bit processors, __put_user emits a pair of stw instructions for the 8-byte case. If the type of __val is a pointer, the marshalling code casts it to the wider integer type of u64, resulting in the following compiler warnings: kernel/signal.c: In function 'copy_siginfo_to_user': kernel/signal.c:2752:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] kernel/signal.c:2752:11: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] [...] This patch fixes the warnings by removing the marshalling code and using the correct output modifiers in the __put_{user,kernel}_asm64 macros so that GCC will allocate the right registers without the need to extract the two words explicitly. Cc: Helge Deller <deller@gmx.de> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Helge Deller <deller@gmx.de>
2013-04-25parisc: Change kunmap macro to static inline functionJohn David Anglin
Change kunmap macro to static inline function to fix build error compiling drivers/base/dma-buf.c. Without the change, the following error can occur: CC drivers/base/dma-buf.o drivers/base/dma-buf.c: In function 'dma_buf_kunmap': drivers/base/dma-buf.c:427:46: error: macro "kunmap" passed 3 arguments, but takes just 1 I believe parisc is the only arch to implement kunmap using a macro. Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Helge Deller <deller@gmx.de> Signed-off-by: Helge Deller <deller@gmx.de>
2013-04-25parisc: Provide __ucmpdi2 to resolve undefined references in 32 bit builds.John David Anglin
The Debian experimental linux source package (3.8.5-1) build fails with the following errors: ... MODPOST 2016 modules ERROR: "__ucmpdi2" [fs/btrfs/btrfs.ko] undefined! ERROR: "__ucmpdi2" [drivers/md/dm-verity.ko] undefined! The attached patch resolves this problem. It is based on the s390 implementation of ucmpdi2.c. Signed-off-by: John David Anglin <dave.anglin@bell.net> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Signed-off-by: Helge Deller <deller@gmx.de>
2013-04-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds
Pull sparc fix from David Miller: "Brown paper bag fix for sparc64" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: Fix missing put_cpu_var() in tlb_batch_add_one() when not batching.
2013-04-24sparc64: Fix missing put_cpu_var() in tlb_batch_add_one() when not batching.David S. Miller
Reported-by: Meelis Roos <mroos@linux.ee> Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-24efi: Check EFI revision in setup_efi_varsJosh Boyer
We need to check the runtime sys_table for the EFI version the firmware specifies instead of just checking for a NULL QueryVariableInfo. Older implementations of EFI don't have QueryVariableInfo but the runtime is a smaller structure, so the pointer to it may be pointing off into garbage. This is apparently the case with several Apple firmwares that support EFI 1.10, and the current check causes them to no longer boot. Fix based on a suggestion from Matthew Garrett. Signed-off-by: Josh Boyer <jwboyer@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-24x86, efi: Fix a build warningBorislav Petkov
Fix this: arch/x86/boot/compressed/eboot.c: In function ‘setup_efi_vars’: arch/x86/boot/compressed/eboot.c:269:2: warning: passing argument 1 of ‘efi_call_phys’ makes pointer from integer without a cast [enabled by default] In file included from arch/x86/boot/compressed/eboot.c:12:0: /w/kernel/linux/arch/x86/include/asm/efi.h:8:33: note: expected ‘void *’ but argument is of type ‘long unsigned int’ after cc5a080c5d40 ("efi: Pass boot services variable info to runtime code"). Reported-by: Paul Bolle <pebolle@tiscali.nl> Cc: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-22Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds
Pull MIPS fix from Ralf Baechle: "Revert the change of the definition of PAGE_MASK which was prettier but broke a few relativly rare platforms" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: Revert "MIPS: page.h: Provide more readable definition for PAGE_MASK."
2013-04-22Revert "MIPS: page.h: Provide more readable definition for PAGE_MASK."Ralf Baechle
This reverts commit c17a6554782ad531f4713b33fd6339ba67ef6391. Manuel Lauss writes: lmo commit c17a6554 (MIPS: page.h: Provide more readable definition for PAGE_MASK) apparently breaks ioremap of 36-bit addresses on my Alchemy systems (PCI and PCMCIA) The reason is that in arch/mips/mm/ioremap.c line 157 (phys_addr &= PAGE_MASK) bits 32-35 are cut off. Seems the new PAGE_MASK is explicitly 32bit, or one could make it signed instead of unsigned long.
2013-04-21Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "Misc fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86: Fix offcore_rsp valid mask for SNB/IVB perf: Treat attr.config as u64 in perf_swevent_init()
2013-04-20Merge branch 'x86-kdump-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull kdump fixes from Peter Anvin: "The kexec/kdump people have found several problems with the support for loading over 4 GiB that was introduced in this merge cycle. This is partly due to a number of design problems inherent in the way the various pieces of kdump fit together (it is pretty horrifically manual in many places.) After a *lot* of iterations this is the patchset that was agreed upon, but of course it is now very late in the cycle. However, because it changes both the syntax and semantics of the crashkernel option, it would be desirable to avoid a stable release with the broken interfaces." I'm not happy with the timing, since originally the plan was to release the final 3.9 tomorrow. But apparently I'm doing an -rc8 instead... * 'x86-kdump-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: kexec: use Crash kernel for Crash kernel low x86, kdump: Change crashkernel_high/low= to crashkernel=,high/low x86, kdump: Retore crashkernel= to allocate under 896M x86, kdump: Set crashkernel_low automatically
2013-04-20Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Peter Anvin: "Three groups of fixes: 1. Make sure we don't execute the early microcode patching if family < 6, since it would touch MSRs which don't exist on those families, causing crashes. 2. The Xen partial emulation of HyperV can be dealt with more gracefully than just disabling the driver. 3. More EFI variable space magic. In particular, variables hidden from runtime code need to be taken into account too." * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, microcode: Verify the family before dispatching microcode patching x86, hyperv: Handle Xen emulation of Hyper-V more gracefully x86,efi: Implement efi_no_storage_paranoia parameter efi: Export efi_query_variable_store() for efivars.ko x86/Kconfig: Make EFI select UCS2_STRING efi: Distinguish between "remaining space" and actually used space efi: Pass boot services variable info to runtime code Move utf16 functions to kernel core and rename x86,efi: Check max_size only if it is non-zero. x86, efivars: firmware bug workarounds should be in platform code
2013-04-20Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: "A set of fixes from various people - Will Deacon gets a prize for removing code this time around. The biggest fix in this lot is sorting out the ARM740T mess. The rest are relatively small fixes." * 'fixes' of git://git.linaro.org/people/rmk/linux-arm: ARM: 7699/1: sched_clock: Add more notrace to prevent recursion ARM: 7698/1: perf: fix group validation when using enable_on_exec ARM: 7697/1: hw_breakpoint: do not use __cpuinitdata for dbg_cpu_pm_nb ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for Feroceon ARM: 7694/1: ARM, TCM: initialize TCM in paging_init(), instead of setup_arch() ARM: 7692/1: iop3xx: move IOP3XX_PERIPHERAL_VIRT_BASE ARM: modules: don't export cpu_set_pte_ext when !MMU ARM: mm: remove broken condition check for v4 flushing ARM: mm: fix numerous hideous errors in proc-arm740.S ARM: cache: remove ARMv3 support code ARM: tlbflush: remove ARMv3 support
2013-04-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds
Pull sparc fixes from David Miller: 1) Fix race in sparc64 TLB shootdowns, we have to synchronize with the sibling cpus completing if we are passing them a reference via pointer to a data structure. 2) Fix cleaning of bitmaps in sparc32, from Akinobu Mita. 3) Fix various sparc header mistakes, some of which resulted in userland build breakage. From Sam Ravnborg. 4) Kill ghost declarations and defines missed when several bits of code got deleted recently. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc64: Fix race in TLB batch processing. sparc: use asm-generic version of types.h bbc_i2c: fix section mismatch warning sparc: use generic headers sparc:cleanup unused code in smp_32.h sparc/iommu: fix typo s/265KB/256KB/ sparc/srmmu: clear trailing edge of bitmap properly sparc:remove unused declaration smp_boot_cpus()
2013-04-19Merge remote-tracking branch 'efi/urgent' into x86/urgentH. Peter Anvin
Matt Fleming (1): x86, efivars: firmware bug workarounds should be in platform code Matthew Garrett (3): Move utf16 functions to kernel core and rename efi: Pass boot services variable info to runtime code efi: Distinguish between "remaining space" and actually used space Richard Weinberger (2): x86,efi: Check max_size only if it is non-zero. x86,efi: Implement efi_no_storage_paranoia parameter Sergey Vlasov (2): x86/Kconfig: Make EFI select UCS2_STRING efi: Export efi_query_variable_store() for efivars.ko Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-04-19x86, microcode: Verify the family before dispatching microcode patchingH. Peter Anvin
For each CPU vendor that implements CPU microcode patching, there will be a minimum family for which this is implemented. Verify this minimum level of support. This can be done in the dispatch function or early in the application functions. Doing the latter turned out to be somewhat awkward because of the ineviable split between the BSP and the AP paths, and rather than pushing deep into the application functions, do this in the dispatch function. Reported-by: "Bryan O'Donoghue" <bryan.odonoghue.lkml@nexus-software.ie> Suggested-by: Borislav Petkov <bp@alien8.de> Cc: Fenghua Yu <fenghua.yu@intel.com> Link: http://lkml.kernel.org/r/1366392183-4149-1-git-send-email-bryan.odonoghue.lkml@nexus-software.ie
2013-04-19sparc64: Fix race in TLB batch processing.David S. Miller
As reported by Dave Kleikamp, when we emit cross calls to do batched TLB flush processing we have a race because we do not synchronize on the sibling cpus completing the cross call. So meanwhile the TLB batch can be reset (tb->tlb_nr set to zero, etc.) and either flushes are missed or flushes will flush the wrong addresses. Fix this by using generic infrastructure to synchonize on the completion of the cross call. This first required getting the flush_tlb_pending() call out from switch_to() which operates with locks held and interrupts disabled. The problem is that smp_call_function_many() cannot be invoked with IRQs disabled and this is explicitly checked for with WARN_ON_ONCE(). We get the batch processing outside of locked IRQ disabled sections by using some ideas from the powerpc port. Namely, we only batch inside of arch_{enter,leave}_lazy_mmu_mode() calls. If we're not in such a region, we flush TLBs synchronously. 1) Get rid of xcall_flush_tlb_pending and per-cpu type implementations. 2) Do TLB batch cross calls instead via: smp_call_function_many() tlb_pending_func() __flush_tlb_pending() 3) Batch only in lazy mmu sequences: a) Add 'active' member to struct tlb_batch b) Define __HAVE_ARCH_ENTER_LAZY_MMU_MODE c) Set 'active' in arch_enter_lazy_mmu_mode() d) Run batch and clear 'active' in arch_leave_lazy_mmu_mode() e) Check 'active' in tlb_batch_add_one() and do a synchronous flush if it's clear. 4) Add infrastructure for synchronous TLB page flushes. a) Implement __flush_tlb_page and per-cpu variants, patch as needed. b) Likewise for xcall_flush_tlb_page. c) Implement smp_flush_tlb_page() to invoke the cross-call. d) Wire up global_flush_tlb_page() to the right routine based upon CONFIG_SMP 5) It turns out that singleton batches are very common, 2 out of every 3 batch flushes have only a single entry in them. The batch flush waiting is very expensive, both because of the poll on sibling cpu completeion, as well as because passing the tlb batch pointer to the sibling cpus invokes a shared memory dereference. Therefore, in flush_tlb_pending(), if there is only one entry in the batch perform a completely asynchronous global_flush_tlb_page() instead. Reported-by: Dave Kleikamp <dave.kleikamp@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Acked-by: Dave Kleikamp <dave.kleikamp@oracle.com>
2013-04-19ARM: 7699/1: sched_clock: Add more notrace to prevent recursionStephen Boyd
cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns() is called by cyc_to_sched_clock(). I suspect that some compilers inline both of these functions into sched_clock() and so we've been getting away without having a notrace marking. It seems that my compiler isn't inlining cyc_to_sched_clock() though, so I'm hitting a recursion bug when I enable the function graph tracer, causing my system to crash. Marking these functions notrace fixes it. Technically cyc_to_ns() doesn't need the notrace because it's already marked inline, but let's just add it so that if we ever remove inline from that function it doesn't blow up. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-04-19Merge tag 'fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "Only one remaining fix for arm-soc platforms at this time, a small bugfix for cpu hotplug on highbank platforms that has become much easier to hit as of late. Details in the patch description, but it's small and well-contained and definitely impacts users of the platform, so 3.9 seems appropriate." * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: highbank: fix cache flush ordering for cpu hotplug
2013-04-18ARM: highbank: fix cache flush ordering for cpu hotplugRob Herring
The L1 data cache flush needs to be after highbank_set_cpu_jump call which pollutes the cache with the l2x0_lock. This causes other cores to deadlock waiting for the l2x0_lock. Moving the flush of the entire data cache after highbank_set_cpu_jump fixes the problem. Use flush_cache_louis instead of flush_cache_all are that is sufficient to flush only the L1 data cache. flush_cache_louis did not exist when highbank_cpu_die was originally written. With PL310 errata 769419 enabled, a wmb is inserted into idle which takes the l2x0_lock. This makes the problem much more easily hit and causes reset to hang. Reported-by: Paolo Pisati <p.pisati@gmail.com> Signed-off-by: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2013-04-18x86, hyperv: Handle Xen emulation of Hyper-V more gracefullyK. Y. Srinivasan
Install the Hyper-V specific interrupt handler only when needed. This would permit us to get rid of the Xen check. Note that when the vmbus drivers invokes the call to register its handler, we are sure to be running on Hyper-V. Signed-off-by: K. Y. Srinivasan <kys@microsoft.com> Link: http://lkml.kernel.org/r/1366299886-6399-1-git-send-email-kys@microsoft.com Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-04-17Merge branch 'akpm' (fixes from Andrew)Linus Torvalds
Pull misc fixes from Andrew Morton: "Ten fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: kernel/signal.c: stop info leak via the tkill and the tgkill syscalls mm/vmscan: fix error return in kswapd_run() hfsplus: fix potential overflow in hfsplus_file_truncate() avr32: fix build error in atstk1006_defconfig hugetlbfs: add swap entry check in follow_hugetlb_page() fs/binfmt_elf.c: fix hugetlb memory check in vma_dump_size() hugetlbfs: stop setting VM_DONTDUMP in initializing vma(VM_HUGETLB) checkpatch: fix stringification macro defect drivers/video/mmp/core.c: fix use-after-free bug thinkpad-acpi: kill hotkey_thread_mutex
2013-04-17avr32: fix build error in atstk1006_defconfigJosh Wu
fixed the following compile error when use avr32 atstk1006_defconfig: drivers/mtd/nand/atmel_nand.c: In function 'pmecc_err_location': drivers/mtd/nand/atmel_nand.c:639: error: implicit declaration of function 'writel_relaxed' which was introduced by commit 1c7b874d33b4 ("mtd: at91: atmel_nand: add Programmable Multibit ECC controller support"). The PMECC for nand flash code uses writel_relaxed(). But in avr32, there is no macro "writel_relaxed" defined. This patch add writex_relaxed macro definitions. Signed-off-by: Josh Wu <josh.wu@atmel.com> Acked-by: Havard Skinnemoen <havard@skinnemoen.net> Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: David Woodhouse <David.Woodhouse@intel.com> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-17ARM: KVM: fix unbalanced get_cpu() in access_dcswMarc Zyngier
In the very unlikely event where a guest would be foolish enough to *read* from a write-only cache maintainance register, we end up with preemption disabled, due to a misplaced get_cpu(). Just move the "is_write" test outside of the critical section. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-17x86, kdump: Change crashkernel_high/low= to crashkernel=,high/lowYinghai Lu
Per hpa, use crashkernel=X,high crashkernel=Y,low instead of crashkernel_hign=X crashkernel_low=Y. As that could be extensible. -v2: according to Vivek, change delimiter to ; -v3: let hign and low only handle simple form and it conforms to description in kernel-parameters.txt still keep crashkernel=X override any crashkernel=X,high crashkernel=Y,low -v4: update get_last_crashkernel returning and add more strict checking in parse_crashkernel_simple() found by HATAYAMA. -v5: Change delimiter back to , according to HPA. also separate parse_suffix from parse_simper according to vivek. so we can avoid @pos in that path. -v6: Tight the checking about crashkernel=X,highblahblah,high found by HTYAYAMA. Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/1366089828-19692-5-git-send-email-yinghai@kernel.org Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-04-17x86, kdump: Retore crashkernel= to allocate under 896MYinghai Lu
Vivek found old kexec-tools does not work new kernel anymore. So change back crashkernel= back to old behavoir, and add crashkernel_high= to let user decide if buffer could be above 4G, and also new kexec-tools will be needed. -v2: let crashkernel=X override crashkernel_high= update description about _high will be ignored by crashkernel=X -v3: update description about kernel-parameters.txt according to Vivek. Signed-off-by: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/1366089828-19692-4-git-send-email-yinghai@kernel.org Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-04-17x86, kdump: Set crashkernel_low automaticallyYinghai Lu
Chao said that kdump does does work well on his system on 3.8 without extra parameter, even iommu does not work with kdump. And now have to append crashkernel_low=Y in first kernel to make kdump work. We have now modified crashkernel=X to allocate memory beyong 4G (if available) and do not allocate low range for crashkernel if the user does not specify that with crashkernel_low=Y. This causes regression if iommu is not enabled. Without iommu, swiotlb needs to be setup in first 4G and there is no low memory available to second kernel. Set crashkernel_low automatically if the user does not specify that. For system that does support IOMMU with kdump properly, user could specify crashkernel_low=0 to save that 72M low ram. -v3: add swiotlb_size() according to Konrad. -v4: add comments what 8M is for according to hpa. also update more crashkernel_low= in kernel-parameters.txt -v5: update changelog according to Vivek. -v6: Change description about swiotlb referring according to HATAYAMA. Reported-by: WANG Chao <chaowang@redhat.com> Tested-by: WANG Chao <chaowang@redhat.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/r/1366089828-19692-2-git-send-email-yinghai@kernel.org Acked-by: Vivek Goyal <vgoyal@redhat.com> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-04-17ARM: 7698/1: perf: fix group validation when using enable_on_execWill Deacon
Events may be created with attr->disabled == 1 and attr->enable_on_exec == 1, which confuses the group validation code because events with the PERF_EVENT_STATE_OFF are not considered candidates for scheduling, which may lead to failure at group scheduling time. This patch fixes the validation check for ARM, so that events in the OFF state are still considered when enable_on_exec is true. Cc: stable@vger.kernel.org Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net> Cc: Jiri Olsa <jolsa@redhat.com> Reported-by: Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-04-17ARM: 7697/1: hw_breakpoint: do not use __cpuinitdata for dbg_cpu_pm_nbBastian Hecht
We must not declare dbg_cpu_pm_nb as __cpuinitdata as we need it after system initialization for Suspend and CPUIdle. This was done in commit 9a6eb310eaa5 ("ARM: hw_breakpoint: Debug powerdown support for self-hosted debug"). Cc: stable@vger.kernel.org Cc: Dietmar Eggemann <Dietmar.Eggemann@arm.com> Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-04-17ARM: 7696/1: Fix kexec by setting outer_cache.inv_all for FeroceonIllia Ragozin
On Feroceon the L2 cache becomes non-coherent with the CPU when the L1 caches are disabled. Thus the L2 needs to be invalidated after both L1 caches are disabled. On kexec before the starting the code for relocation the kernel, the L1 caches are disabled in cpu_froc_fin (cpu_v7_proc_fin for Feroceon), but after L2 cache is never invalidated, because inv_all is not set in cache-feroceon-l2.c. So kernel relocation and decompression may has (and usually has) errors. Setting the function enables L2 invalidation and fixes the issue. Cc: <stable@vger.kernel.org> Signed-off-by: Illia Ragozin <illia.ragozin@grapecom.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-04-17ARM: 7694/1: ARM, TCM: initialize TCM in paging_init(), instead of setup_arch()Joonsoo Kim
tcm_init() call iotable_init() and it use early_alloc variants which do memblock allocation. Directly using memblock allocation after initializing bootmem should not permitted, because bootmem can't know where are additinally reserved. So move tcm_init() to a safe place before initalizing bootmem. (On the U300) Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-04-17ARM: 7692/1: iop3xx: move IOP3XX_PERIPHERAL_VIRT_BASEAaro Koskinen
Currently IOP3XX_PERIPHERAL_VIRT_BASE conflicts with PCI_IO_VIRT_BASE: address size PCI_IO_VIRT_BASE 0xfee00000 0x200000 IOP3XX_PERIPHERAL_VIRT_BASE 0xfeffe000 0x2000 Fix by moving IOP3XX_PERIPHERAL_VIRT_BASE below PCI_IO_VIRT_BASE. The patch fixes the following kernel panic with 3.9-rc1 on iop3xx boards: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.9.0-rc1-iop32x (aaro@blackmetal) (gcc version 4.7.2 (GCC) ) #20 PREEMPT Tue Mar 5 16:44:36 EET 2013 [ 0.000000] bootconsole [earlycon0] enabled [ 0.000000] ------------[ cut here ]------------ [ 0.000000] kernel BUG at mm/vmalloc.c:1145! [ 0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 Not tainted (3.9.0-rc1-iop32x #20) [ 0.000000] PC is at vm_area_add_early+0x4c/0x88 [ 0.000000] LR is at add_static_vm_early+0x14/0x68 [ 0.000000] pc : [<c03e74a8>] lr : [<c03e1c40>] psr: 800000d3 [ 0.000000] sp : c03ffee4 ip : dfffdf88 fp : c03ffef4 [ 0.000000] r10: 00000002 r9 : 000000cf r8 : 00000653 [ 0.000000] r7 : c040eca8 r6 : c03e2408 r5 : dfffdf60 r4 : 00200000 [ 0.000000] r3 : dfffdfd8 r2 : feffe000 r1 : ff000000 r0 : dfffdf60 [ 0.000000] Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 0.000000] Control: 0000397f Table: a0004000 DAC: 00000017 [ 0.000000] Process swapper (pid: 0, stack limit = 0xc03fe1b8) [ 0.000000] Stack: (0xc03ffee4 to 0xc0400000) [ 0.000000] fee0: 00200000 c03fff0c c03ffef8 c03e1c40 c03e7468 00200000 fee00000 [ 0.000000] ff00: c03fff2c c03fff10 c03e23e4 c03e1c38 feffe000 c0408ee4 ff000000 c0408f04 [ 0.000000] ff20: c03fff3c c03fff30 c03e2434 c03e23b4 c03fff84 c03fff40 c03e2c94 c03e2414 [ 0.000000] ff40: c03f8878 c03f6410 ffff0000 000bffff 00001000 00000008 c03fff84 c03f6410 [ 0.000000] ff60: c04227e8 c03fffd4 a0008000 c03f8878 69052e30 c02f96eb c03fffbc c03fff88 [ 0.000000] ff80: c03e044c c03e268c 00000000 0000397f c0385130 00000001 ffffffff c03f8874 [ 0.000000] ffa0: dfffffff a0004000 69052e30 a03f61a0 c03ffff4 c03fffc0 c03dd5cc c03e0184 [ 0.000000] ffc0: 00000000 00000000 00000000 00000000 00000000 c03f8878 0000397d c040601c [ 0.000000] ffe0: c03f8874 c0408674 00000000 c03ffff8 a0008040 c03dd558 00000000 00000000 [ 0.000000] Backtrace: [ 0.000000] [<c03e745c>] (vm_area_add_early+0x0/0x88) from [<c03e1c40>] (add_static_vm_early+0x14/0x68) Tested-by: Mikael Pettersson <mikpe@it.uu.se> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2013-04-17s390: move dummy io_remap_pfn_range() to asm/pgtable.hLinus Torvalds
Commit b4cbb197c7e7 ("vm: add vm_iomap_memory() helper function") added a helper function wrapper around io_remap_pfn_range(), and every other architecture defined it in <asm/pgtable.h>. The s390 choice of <asm/io.h> may make sense, but is not very convenient for this case, and gratuitous differences like that cause unexpected errors like this: mm/memory.c: In function 'vm_iomap_memory': mm/memory.c:2439:2: error: implicit declaration of function 'io_remap_pfn_range' [-Werror=implicit-function-declaration] Glory be the kbuild test robot who noticed this, bisected it, and reported it to the guilty parties (ie me). Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-17x86,efi: Implement efi_no_storage_paranoia parameterRichard Weinberger
Using this parameter one can disable the storage_size/2 check if he is really sure that the UEFI does sane gc and fulfills the spec. This parameter is useful if a devices uses more than 50% of the storage by default. The Intel DQSW67 desktop board is such a sucker for exmaple. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-17Merge branch 'for-rmk/740t' of ↵Russell King
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into fixes
2013-04-16Merge branch 'fixes' of git://git.linaro.org/people/rmk/linux-armLinus Torvalds
Pull ARM fix from Russell King: "A build fix for an incomplete change to the ARM cpu suspend code" * branch 'fixes' of git://git.linaro.org/people/rmk/linux-arm: ARM: Do 15e0d9e37c (ARM: pm: let platforms select cpu_suspend support) properly
2013-04-16Merge git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Marcelo Tosatti: "PPC and ARM KVM fixes" * git://git.kernel.org/pub/scm/virt/kvm/kvm: ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write ARM: KVM: fix KVM_CAP_ARM_SET_DEVICE_ADDR reporting kvm/ppc/e500: eliminate tlb_refs kvm/ppc/e500: g2h_tlb1_map: clear old bit before setting new bit kvm/ppc/e500: h2g_tlb1_rmap: esel 0 is valid kvm/powerpc/e500mc: fix tlb invalidation on cpu migration
2013-04-16Merge tag 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes Pull powerpc fixes from Stephen Rothwell: "Three regresions in the PowerPC code. One from v3.7 the others from this merge window." * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes: powerpc: add a missing label in resume_kernel powerpc: Fix audit crash due to save/restore PPR changes powerpc: fix compiling CONFIG_PPC_TRANSACTIONAL_MEM when CONFIG_ALTIVEC=n
2013-04-16Merge branch 'kvm-arm-fixes-3.9' of git://github.com/columbia/linux-kvm-armMarcelo Tosatti
* 'kvm-arm-fixes-3.9' of git://github.com/columbia/linux-kvm-arm: ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/Write ARM: KVM: fix KVM_CAP_ARM_SET_DEVICE_ADDR reporting Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2013-04-16ARM: KVM: fix L_PTE_S2_RDWR to actually be Read/WriteMarc Zyngier
Looks like our L_PTE_S2_RDWR definition is slightly wrong, and is actually write only (see ARM ARM Table B3-9, Stage 2 control of access permissions). Didn't make a difference for normal pages, as we OR the flags together, but I'm still wondering how it worked for Stage-2 mapped devices, such as the GIC. Brown paper bag time, again. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
2013-04-16ARM: KVM: fix KVM_CAP_ARM_SET_DEVICE_ADDR reportingMarc Zyngier
Commit 3401d54696f9 (KVM: ARM: Introduce KVM_ARM_SET_DEVICE_ADDR ioctl) added support for the KVM_CAP_ARM_SET_DEVICE_ADDR capability, but failed to add a break in the relevant case statement, returning the number of CPUs instead. Luckilly enough, the CONFIG_NR_CPUS=0 patch hasn't been merged yet (https://lkml.org/lkml/diff/2012/3/31/131/1), so the bug wasn't noticed. Just give it a break! Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Christoffer Dall <cdall@cs.columbia.edu>
2013-04-16efi: Export efi_query_variable_store() for efivars.koSergey Vlasov
Fixes build with CONFIG_EFI_VARS=m which was broken after the commit "x86, efivars: firmware bug workarounds should be in platform code". Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-16x86/Kconfig: Make EFI select UCS2_STRINGSergey Vlasov
The commit "efi: Distinguish between "remaining space" and actually used space" added usage of ucs2_*() functions to arch/x86/platform/efi/efi.c, but the only thing which selected UCS2_STRING was EFI_VARS, which is technically optional and can be built as a module. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-16perf/x86: Fix offcore_rsp valid mask for SNB/IVBStephane Eranian
The valid mask for both offcore_response_0 and offcore_response_1 was wrong for SNB/SNB-EP, IVB/IVB-EP. It was possible to write to reserved bit and cause a GP fault crashing the kernel. This patch fixes the problem by correctly marking the reserved bits in the valid mask for all the processors mentioned above. A distinction between desktop and server parts is introduced because bits 24-30 are only available on the server parts. This version of the patch is just a rebase to perf/urgent tree and should apply to older kernels as well. Signed-off-by: Stephane Eranian <eranian@google.com> Cc: peterz@infradead.org Cc: jolsa@redhat.com Cc: gregkh@linuxfoundation.org Cc: security@kernel.org Cc: ak@linux.intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>