aboutsummaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAge
* Merge tag 'trace-fixes-v3.14-rc2' of ↵Linus Torvalds2014-02-15
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull twi tracing fixes from Steven Rostedt: "Two urgent fixes in the tracing utility. The first is a fix for the way the ring buffer stores timestamps. After a restructure of the code was done, the ring buffer timestamp logic missed the fact that the first event on a sub buffer is to have a zero delta, as the full timestamp is stored on the sub buffer itself. But because the delta was not cleared to zero, the timestamp for that event will be calculated as the real timestamp + the delta from the last timestamp. This can skew the timestamps of the events and have them say they happened when they didn't really happen. That's bad. The second fix is for modifying the function graph caller site. When the stop machine was removed from updating the function tracing code, it missed updating the function graph call site location. It is still modified as if it is being done via stop machine. But it's not. This can lead to a GPF and kernel crash if the function graph call site happens to lie between cache lines and one CPU is executing it while another CPU is doing the update. It would be a very hard condition to hit, but the result is severe enough to have it fixed ASAP" * tag 'trace-fixes-v3.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ftrace/x86: Use breakpoints for converting function graph caller ring-buffer: Fix first commit on sub-buffer having non-zero delta
| * ftrace/x86: Use breakpoints for converting function graph callerSteven Rostedt (Red Hat)2014-02-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the conversion was made to remove stop machine and use the breakpoint logic instead, the modification of the function graph caller is still done directly as though it was being done under stop machine. As it is not converted via stop machine anymore, there is a possibility that the code could be layed across cache lines and if another CPU is accessing that function graph call when it is being updated, it could cause a General Protection Fault. Convert the update of the function graph caller to use the breakpoint method as well. Cc: H. Peter Anvin <hpa@zytor.com> Cc: stable@vger.kernel.org # 3.5+ Fixes: 08d636b6d4fb "ftrace/x86: Have arch x86_64 use breakpoints instead of stop machine" Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
* | Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2014-02-15
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 EFI fixes from Peter Anvin: "A few more EFI-related fixes" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/efi: Check status field to validate BGRT header x86/efi: Fix 32-bit fallout
| * \ Merge remote-tracking branch 'efi/urgent' into x86/urgentH. Peter Anvin2014-02-14
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There have been reports of EFI crashes since -rc1. The following two commits fix known issues. * Fix boot failure on 32-bit EFI due to the recent EFI memmap changes merged during the merge window - Borislav Petkov * Avoid a crash during efi_bgrt_init() by detecting invalid BGRT headers based on the 'status' field. Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
| | * | x86/efi: Check status field to validate BGRT headerMatt Fleming2014-02-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Madper reported seeing the following crash, BUG: unable to handle kernel paging request at ffffffffff340003 IP: [<ffffffff81d85ba4>] efi_bgrt_init+0x9d/0x133 Call Trace: [<ffffffff81d8525d>] efi_late_init+0x9/0xb [<ffffffff81d68f59>] start_kernel+0x436/0x450 [<ffffffff81d6892c>] ? repair_env_string+0x5c/0x5c [<ffffffff81d68120>] ? early_idt_handlers+0x120/0x120 [<ffffffff81d685de>] x86_64_start_reservations+0x2a/0x2c [<ffffffff81d6871e>] x86_64_start_kernel+0x13e/0x14d This is caused because the layout of the ACPI BGRT header on this system doesn't match the definition from the ACPI spec, and so we get a bogus physical address when dereferencing ->image_address in efi_bgrt_init(). Luckily the status field in the BGRT header clearly marks it as invalid, so we can check that field and skip BGRT initialisation. Reported-by: Madper Xie <cxie@redhat.com> Suggested-by: Toshi Kani <toshi.kani@hp.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Josh Triplett <josh@joshtriplett.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
| | * | x86/efi: Fix 32-bit falloutBorislav Petkov2014-02-14
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | We do not enable the new efi memmap on 32-bit and thus we need to run runtime_code_page_mkexec() unconditionally there. Fix that. Reported-and-tested-by: Lejun Zhu <lejun.zhu@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
* | | Merge tag 'fixes-for-linus' of ↵Linus Torvalds2014-02-15
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Kevin Hilman: "A collection of ARM SoC fixes for v3.14-rc1. Mostly a collection of Kconfig, device tree data and compilation fixes along with fix to drivers/phy that fixes a boot regression on some Marvell mvebu platforms" * tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: dma: mv_xor: Silence a bunch of LPAE-related warnings ARM: ux500: disable msp2 device tree node ARM: zynq: Reserve not DMAable space in front of the kernel ARM: multi_v7_defconfig: Select CONFIG_SOC_DRA7XX ARM: imx6: Initialize low-power mode early again ARM: pxa: fix various compilation problems ARM: pxa: fix compilation problem on AM300EPD board ARM: at91: add Atmel's SAMA5D3 Xplained board spi/atmel: document clock properties mmc: atmel-mci: document clock properties ARM: at91: enable USB host on at91sam9n12ek board ARM: at91/dt: fix sama5d3 ohci hclk clock reference ARM: at91/dt: sam9263: fix compatibility string for the I2C ata: sata_mv: Fix probe failures with optional phys drivers: phy: Add support for optional phys drivers: phy: Make NULL a valid phy reference ARM: fix HAVE_ARM_TWD selection for OMAP and shmobile ARM: moxart: move DMA_OF selection to driver ARM: hisi: fix kconfig warning on HAVE_ARM_TWD
| * | | ARM: ux500: disable msp2 device tree nodeLinus Walleij2014-02-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 70b41abc151f9 "ARM: ux500: move MSP pin control to the device tree" accidentally activated MSP2, giving rise to a boot scroll scream as the kernel attempts to probe a driver for it and fails to obtain DMA channel 14. Fix this up by marking the node disabled again. Acked-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org>
| * | | ARM: zynq: Reserve not DMAable space in front of the kernelMichal Simek2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reserve space from 0x0 - __pa(swapper_pg_dir), if kernel is loaded from 0, which is not DMAable. It is causing problem with MMC driver and others which want to add dma buffers to this space. Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Kevin Hilman <khilman@linaro.org>
| * | | Merge tag 'at91-fixes' of git://github.com/at91linux/linux-at91 into fixesKevin Hilman2014-02-10
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From Nicolas Ferre: First series of AT91 fixes for 3.14. All of them are DT-related. - fixes for typos in i2c and ohci clocks - addition of a USB host node for at91sam9n12ek - 2 DT documentation updates that have been sent a long time ago - a new board based on the sama5d36 SoC * tag 'at91-fixes' of git://github.com/at91linux/linux-at91: ARM: at91: add Atmel's SAMA5D3 Xplained board spi/atmel: document clock properties mmc: atmel-mci: document clock properties ARM: at91: enable USB host on at91sam9n12ek board ARM: at91/dt: fix sama5d3 ohci hclk clock reference ARM: at91/dt: sam9263: fix compatibility string for the I2C Signed-off-by: Kevin Hilman <khilman@linaro.org>
| | * | | ARM: at91: add Atmel's SAMA5D3 Xplained boardNicolas Ferre2014-02-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add DT file for new SAMA5D3 Xplained board. This board is based on Atmel's SAMA5D36 Cortex-A5 SoC. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
| | * | | ARM: at91: enable USB host on at91sam9n12ek boardBo Shen2014-02-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enable USB host on at91sam9n12ek board. Signed-off-by: Bo Shen <voice.shen@atmel.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
| | * | | ARM: at91/dt: fix sama5d3 ohci hclk clock referenceBoris BREZILLON2014-02-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hclk clock of the ohci node is referencing udphs_clk instead of uhphs_clk. Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
| | * | | ARM: at91/dt: sam9263: fix compatibility string for the I2CJean-Jacques Hiblot2014-02-07
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
| * | | | ARM: multi_v7_defconfig: Select CONFIG_SOC_DRA7XXNishanth Menon2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Select CONFIG_SOC_DRA7XX so that we can boot dra7-evm. DRA7 family are A15 based processors that supports LPAE and an evolutionary update to the OMAP5 generation of processors. Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Kevin Hilman <khilman@linaro.org>
| * | | | ARM: imx6: Initialize low-power mode early againPhilipp Zabel2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 9e8147bb5ec5d1dda2141da70f96b98985a306cb "ARM: imx6q: move low-power code out of clock driver" the kernel fails to boot on i.MX6Q/D if preemption is enabled (CONFIG_PREEMPT=y). The kernel just hangs before the console comes up. The above commit moved the initalization of the low-power mode setting (enabling clocked WAIT states), which was introduced in commit 83ae20981ae924c37d02a42c829155fc3851260c "ARM: imx: correct low-power mode setting", from imx6q_clks_init to imx6q_pm_init. Now it is called much later, after all cores are enabled. This patch moves the low-power mode initialization back to imx6q_clks_init again (and to imx6sl_clks_init). Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org>
| * | | | ARM: pxa: fix various compilation problemsLinus Walleij2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to commit 88f718e3fa4d67f3a8dbe79a2f97d722323e4051 "ARM: pxa: delete the custom GPIO header" some drivers fail compilation, for example like this: In file included from sound/soc/pxa/spitz.c:28:0: sound/soc/pxa/spitz.c: In function ‘spitz_ext_control’: arch/arm/mach-pxa/include/mach/spitz.h:111:30: error: ‘PXA_NR_BUILTIN_GPIO’ undeclared (first use in this function) #define SPITZ_SCP_GPIO_BASE (PXA_NR_BUILTIN_GPIO) (etc.) This is caused by implicit inclusion of <mach/irqs.h> from various board-specific headers under <mach/*> in the PXA platform. So we take a sweep over these, and for every such header that uses PXA_NR_BUILTIN_GPIO or PXA_GPIO_TO_IRQ() we explicitly #include "irqs.h" so that we satisfy the dependency in the board include file alone. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Kevin Hilman <khilman@linaro.org>
| * | | | ARM: pxa: fix compilation problem on AM300EPD boardLinus Walleij2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This board fails compilation like this: arch/arm/mach-pxa/am300epd.c: In function ‘am300_cleanup’: arch/arm/mach-pxa/am300epd.c:179:2: error: implicit declaration of function ‘PXA_GPIO_TO_IRQ’ [-Werror=implicit-function-declaration] free_irq(PXA_GPIO_TO_IRQ(RDY_GPIO_PIN), par); This was caused by commit 88f718e3fa4d67f3a8dbe79a2f97d722323e4051 "ARM: pxa: delete the custom GPIO header" This is because it was previously getting the macro PXA_GPIO_TO_IRQ implicitly from <linux/gpio.h> which in turn implicitly included <mach/gpio.h> which in turn included <mach/irqs.h>. Add the missing include so that the board compiles again. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Kevin Hilman <khilman@linaro.org>
| * | | | ARM: fix HAVE_ARM_TWD selection for OMAP and shmobileRob Herring2014-02-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The selection of HAVE_ARM_TWD for OMAP and shmobile depend on LOCAL_TIMER which no longer exists. They should depend on SMP instead. Cc: Tony Lindgren <tony@atomide.com> Cc: Simon Horman <horms@verge.net.au> Cc: Magnus Damm <magnus.damm@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Olof Johansson <olof@lixom.net>
| * | | | ARM: moxart: move DMA_OF selection to driverRob Herring2014-02-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the DMA_OF selection to the DMA driver to fix kconfig warning: warning: (ARCH_MOXART) selects DMA_OF which has unmet direct dependencies (DMADEVICES && OF) Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Olof Johansson <olof@lixom.net>
| * | | | ARM: hisi: fix kconfig warning on HAVE_ARM_TWDRob Herring2014-02-02
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit "ARM: hisi: don't select SMP" introduced a kconfig warning: warning: (ARCH_HI3xxx) selects HAVE_ARM_TWD which has unmet direct dependencies (SMP) Fix HAVE_ARM_TWD to depend on SMP. Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Olof Johansson <olof@lixom.net>
* | | | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds2014-02-14
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull KVM fixes from Paolo Bonzini: "A small error handling problem and a compile breakage for ARM64" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: arm64: KVM: Add VGIC device control for arm64 KVM: return an error code in kvm_vm_ioctl_register_coalesced_mmio()
| * | | | arm64: KVM: Add VGIC device control for arm64Christoffer Dall2014-02-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the build breakage introduced by c07a0191ef2de1f9510f12d1f88e3b0b5cd8d66f and adds support for the device control API and save/restore of the VGIC state for ARMv8. The defines were simply missing from the arm64 header files and uaccess.h must be implicitly imported from somewhere else on arm. Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | | | | Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2014-02-14
|\ \ \ \ \ | | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Peter Anvin: "A collection of small fixes: - There still seem to be problems with asm goto which requires the empty asm hack. - If SMAP is disabled at compile time, don't enable it nor try to interpret a page fault as an SMAP violation. - Fix a case of unbounded recursion while tracing" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, smap: smap_violation() is bogus if CONFIG_X86_SMAP is off x86, smap: Don't enable SMAP if CONFIG_X86_SMAP is disabled compiler/gcc4: Make quirk for asm_volatile_goto() unconditional x86: Use preempt_disable_notrace() in cycles_2_ns()
| * | | | x86, smap: smap_violation() is bogus if CONFIG_X86_SMAP is offH. Peter Anvin2014-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If CONFIG_X86_SMAP is disabled, smap_violation() tests for conditions which are incorrect (as the AC flag doesn't matter), causing spurious faults. The dynamic disabling of SMAP (nosmap on the command line) is fine because it disables X86_FEATURE_SMAP, therefore causing the static_cpu_has() to return false. Found by Fengguang Wu's test system. [ v3: move all predicates into smap_violation() ] [ v2: use IS_ENABLED() instead of #ifdef ] Reported-by: Fengguang Wu <fengguang.wu@intel.com> Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: <stable@vger.kernel.org> # v3.7+
| * | | | x86, smap: Don't enable SMAP if CONFIG_X86_SMAP is disabledH. Peter Anvin2014-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If SMAP support is not compiled into the kernel, don't enable SMAP in CR4 -- in fact, we should clear it, because the kernel doesn't contain the proper STAC/CLAC instructions for SMAP support. Found by Fengguang Wu's test system. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Link: http://lkml.kernel.org/r/20140213124550.GA30497@localhost Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Cc: <stable@vger.kernel.org> # v3.7+
| * | | | x86: Use preempt_disable_notrace() in cycles_2_ns()Steven Rostedt2014-02-09
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debug preempt is enabled, preempt_disable() can be traced by function and function graph tracing. There's a place in the function graph tracer that calls trace_clock() which eventually calls cycles_2_ns() outside of the recursion protection. When cycles_2_ns() calls preempt_disable() it gets traced and the graph tracer will go into a recursive loop causing a crash or worse, a triple fault. Simple fix is to use preempt_disable_notrace() in cycles_2_ns, which makes sense because the preempt_disable() tracing may use that code too, and it tracing it, even with recursion protection is rather pointless. Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/20140204141315.2a968a72@gandalf.local.home Signed-off-by: Ingo Molnar <mingo@kernel.org>
* | | | Merge branch 'merge' of ↵Linus Torvalds2014-02-12
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc Pull powerpc updates from Ben Herrenschmidt: "Here is some powerpc goodness for -rc2. Arguably -rc1 material more than -rc2 but I was travelling (again !) It's mostly bug fixes including regressions, but there are a couple of new things that I decided to drop-in. One is a straightforward patch from Michael to add a bunch of P8 cache events to perf. The other one is a patch by myself to add the direct DMA (iommu bypass) for PCIe on Power8 for 64-bit capable devices. This has been around for a while, I had lost track of it. However it's been in our internal kernels we use for testing P8 already and it affects only P8 related code. Since P8 is still unreleased the risk is pretty much nil at this point" * 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc/powernv: Add iommu DMA bypass support for IODA2 powerpc: Fix endian issues in kexec and crash dump code powerpc/ppc32: Fix the bug in the init of non-base exception stack for UP powerpc/xmon: Don't signal we've entered until we're finished printing powerpc/xmon: Fix timeout loop in get_output_lock() powerpc/xmon: Don't loop forever in get_output_lock() powerpc/perf: Configure BHRB filter before enabling PMU interrupts crypto/nx/nx-842: Fix handling of vmalloc addresses powerpc/pseries: Select ARCH_RANDOM on pseries powerpc/perf: Add Power8 cache & TLB events powerpc/relocate fix relocate processing in LE mode powerpc: Fix kdump hang issue on p8 with relocation on exception enabled. powerpc/pseries: Disable relocation on exception while going down during crash. powerpc/eeh: Drop taken reference to driver on eeh_rmv_device powerpc: Fix build failure in sysdev/mpic.c for MPIC_WEIRD=y
| * | | | powerpc/powernv: Add iommu DMA bypass support for IODA2Benjamin Herrenschmidt2014-02-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the support for to create a direct iommu "bypass" window on IODA2 bridges (such as Power8) allowing to bypass iommu page translation completely for 64-bit DMA capable devices, thus significantly improving DMA performances. Additionally, this adds a hook to the struct iommu_table so that the IOMMU API / VFIO can disable the bypass when external ownership is requested, since in that case, the device will be used by an environment such as userspace or a KVM guest which must not be allowed to bypass translations. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc: Fix endian issues in kexec and crash dump codeAnton Blanchard2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We expose a number of OF properties in the kexec and crash dump code and these need to be big endian. Cc: stable@vger.kernel.org # v3.13 Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/ppc32: Fix the bug in the init of non-base exception stack for UPKevin Hao2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We would allocate one specific exception stack for each kind of non-base exceptions for every CPU. For ppc32 the CPU hard ID is used as the subscript to get the specific exception stack for one CPU. But for an UP kernel, there is only one element in the each kind of exception stack array. We would get stuck if the CPU hard ID is not equal to '0'. So in this case we should use the subscript '0' no matter what the CPU hard ID is. Signed-off-by: Kevin Hao <haokexin@gmail.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/xmon: Don't signal we've entered until we're finished printingMichael Ellerman2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we set our cpu's bit in cpus_in_xmon, and then we take the output lock and print the exception information. This can race with the master cpu entering the command loop and printing the backtrace. The result is that the backtrace gets garbled with another cpu's exception print out. Fix it by delaying the set of cpus_in_xmon until we are finished printing. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/xmon: Fix timeout loop in get_output_lock()Michael Ellerman2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As far as I can tell, our 70s era timeout loop in get_output_lock() is generating no code. This leads to the hostile takeover happening more or less simultaneously on all cpus. The result is "interesting", some example output that is more readable than most: cpu 0x1: Vector: 100 (Scypsut e0mx bR:e setV)e catto xc0p:u[ c 00 c0:0 000t0o0V0erc0td:o5 rfc28050000]0c00 0 0 0 6t(pSrycsV1ppuot uxe 1m 2 0Rx21e3:0s0ce000c00000t00)00 60602oV2SerucSayt0y 0p 1sxs Fix it by using udelay() in the timeout loop. The wait time and check frequency are arbitrary, but seem to work OK. We already rely on udelay() working so this is not a new dependency. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/xmon: Don't loop forever in get_output_lock()Michael Ellerman2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we enter with xmon_speaker != 0 we skip the first cmpxchg(), we also skip the while loop because xmon_speaker != last_speaker (0) - meaning we skip the second cmpxchg() also. Following that code path the compiler sees no memory barriers and so is within its rights to never reload xmon_speaker. The end result is we loop forever. This manifests as all cpus being in xmon ('c' command), but they refuse to take control when you switch to them ('c x' for cpu # x). I have seen this deadlock in practice and also checked the generated code to confirm this is what's happening. The simplest fix is just to always try the cmpxchg(). Signed-off-by: Michael Ellerman <michael@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/perf: Configure BHRB filter before enabling PMU interruptsAnshuman Khandual2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Right now the config_bhrb() PMU specific call happens after write_mmcr0(), which actually enables the PMU for event counting and interrupts. So there is a small window of time where the PMU and BHRB runs without the required HW branch filter (if any) enabled in BHRB. This can cause some of the branch samples to be collected through BHRB without any filter applied and hence affects the correctness of the results. This patch moves the BHRB config function call before enabling interrupts. Here are some data points captured via trace prints which depicts how we could get PMU interrupts with BHRB filter NOT enabled with a standard perf record command line (asking for branch record information as well). $ perf record -j any_call ls Before the patch:- ls-1962 [003] d... 2065.299590: .perf_event_interrupt: MMCRA: 40000000000 ls-1962 [003] d... 2065.299603: .perf_event_interrupt: MMCRA: 40000000000 ... All the PMU interrupts before this point did not have the requested HW branch filter enabled in the MMCRA. ls-1962 [003] d... 2065.299647: .perf_event_interrupt: MMCRA: 40040000000 ls-1962 [003] d... 2065.299662: .perf_event_interrupt: MMCRA: 40040000000 After the patch:- ls-1850 [008] d... 190.311828: .perf_event_interrupt: MMCRA: 40040000000 ls-1850 [008] d... 190.311848: .perf_event_interrupt: MMCRA: 40040000000 All the PMU interrupts have the requested HW BHRB branch filter enabled in MMCRA. Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com> [mpe: Fixed up whitespace and cleaned up changelog] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/pseries: Select ARCH_RANDOM on pseriesMichael Ellerman2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have a driver for the ARCH_RANDOM hook in rng.c, so we should select ARCH_RANDOM on pseries. Without this the build breaks if you turn ARCH_RANDOM off. This hasn't broken the build because pseries_defconfig doesn't specify a value for PPC_POWERNV, which is default y, and selects ARCH_RANDOM. Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/perf: Add Power8 cache & TLB eventsMichael Ellerman2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/relocate fix relocate processing in LE modeLaurent Dufour2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relocation's code is not working in little endian mode because the r_info field, which is a 64 bits value, should be read from the right offset. The current code is optimized to read the r_info field as a 32 bits value starting at the middle of the double word (offset 12). When running in LE mode, the read value is not correct since only the MSB is read. This patch removes this optimization which consist to deal with a 32 bits value instead of a 64 bits one. This way it works in big and little endian mode. Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc: Fix kdump hang issue on p8 with relocation on exception enabled.Mahesh Salgaonkar2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On p8 systems, with relocation on exception feature enabled we are seeing kdump kernel hang at interrupt vector 0xc*4400. The reason is, with this feature enabled, exception are raised with MMU (IR=DR=1) ON with the default offset of 0xc*4000. Since exception is raised in virtual mode it requires the vector region to be executable without which it fails to fetch and execute instruction at 0xc*4xxx. For default kernel since kernel is loaded at real 0, the htab mappings sets the entire kernel text region executable. But for relocatable kernel (e.g. kdump case) we only copy interrupt vectors down to real 0 and never marked that region as executable because in p7 and below we always get exception in real mode. This patch fixes this issue by marking htab mapping range as executable that overlaps with the interrupt vector region for relocatable kernel. Thanks to Ben who helped me to debug this issue and find the root cause. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/pseries: Disable relocation on exception while going down during crash.Mahesh Salgaonkar2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disable relocation on exception while going down even in kdump case. This is because we are about clear htab mappings while kexec-ing into kdump kernel and we may run into issues if we still have AIL ON. Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc/eeh: Drop taken reference to driver on eeh_rmv_deviceThadeu Lima de Souza Cascardo2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f5c57710dd62dd06f176934a8b4b8accbf00f9f8 ("powerpc/eeh: Use partial hotplug for EEH unaware drivers") introduces eeh_rmv_device, which may grab a reference to a driver, but not release it. That prevents a driver from being removed after it has gone through EEH recovery. This patch drops the reference if it was taken. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Acked-by: Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
| * | | | powerpc: Fix build failure in sysdev/mpic.c for MPIC_WEIRD=yPaul Gortmaker2014-02-10
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 446f6d06fab0b49c61887ecbe8286d6aaa796637 ("powerpc/mpic: Properly set default triggers") breaks the mpc7447_hpc_defconfig as follows: CC arch/powerpc/sysdev/mpic.o arch/powerpc/sysdev/mpic.c: In function 'mpic_set_irq_type': arch/powerpc/sysdev/mpic.c:886:9: error: case label does not reduce to an integer constant arch/powerpc/sysdev/mpic.c:890:9: error: case label does not reduce to an integer constant arch/powerpc/sysdev/mpic.c:894:9: error: case label does not reduce to an integer constant arch/powerpc/sysdev/mpic.c:898:9: error: case label does not reduce to an integer constant Looking at the cpp output (gcc 4.7.3), I see: case mpic->hw_set[MPIC_IDX_VECPRI_SENSE_EDGE] | mpic->hw_set[MPIC_IDX_VECPRI_POLARITY_POSITIVE]: The pointer into an array appears because CONFIG_MPIC_WEIRD=y is set for this platform, thus enabling the following: ------------------- #ifdef CONFIG_MPIC_WEIRD static u32 mpic_infos[][MPIC_IDX_END] = { [0] = { /* Original OpenPIC compatible MPIC */ [...] #define MPIC_INFO(name) mpic->hw_set[MPIC_IDX_##name] #else /* CONFIG_MPIC_WEIRD */ #define MPIC_INFO(name) MPIC_##name #endif /* CONFIG_MPIC_WEIRD */ ------------------- Here we convert the case section to if/else if, and also add the equivalent of a default case to warn about unknown types. Boot tested on sbc8548, build tested on all defconfigs. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
* | | | Merge tag 'microblaze-3.14-rc3' of git://git.monstr.eu/linux-2.6-microblazeLinus Torvalds2014-02-11
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull microblaze fixes from Michal Simek: - Fix two compilation issues - HZ, readq/writeq - Fix stack protection support * tag 'microblaze-3.14-rc3' of git://git.monstr.eu/linux-2.6-microblaze: microblaze: Fix a typo when disabling stack protection microblaze: Define readq and writeq IO helper function microblaze: Fix missing HZ macro
| * | | | microblaze: Fix a typo when disabling stack protectionEdgar E. Iglesias2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correct a typo causing the stack protector to be left enabled. 0xFFFFFFF -> 0xFFFFFFFF Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
| * | | | microblaze: Define readq and writeq IO helper functionMichal Simek2014-02-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some drivers check if readq/writeq functions are defined. If not internal driver functions are used which cause compilation failures. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
| * | | | microblaze: Fix missing HZ macroMichal Simek2014-02-10
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add missing param.h header because of HZ macro. It is causing compilation failure: In file included from include/linux/delay.h:14:0, from drivers/clk/qcom/reset.c:18: drivers/clk/qcom/reset.c: In function 'qcom_reset': arch/microblaze/include/asm/delay.h:39:35: error: 'HZ' undeclared (first use in this function) Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* | | | Merge branch 'for-linus' of ↵Linus Torvalds2014-02-11
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 bugfixes from Martin Schwidefsky: "A collection a bug fixes. Most of them are minor but two of them are more severe. The linkage stack bug can be used by user space to force an oops, with panic_on_oops this is a denial-of-service. And the dump memory detection issue can cause incomplete memory dumps" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/cio: improve cio_commit_config s390: fix kernel crash due to linkage stack instructions s390/dump: Fix dump memory detection s390/appldata: restore missing init_virt_timer() s390/qdio: correct program-controlled interruption checking s390/qdio: for_each macro correctness
| * | | | s390: fix kernel crash due to linkage stack instructionsMartin Schwidefsky2014-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel currently crashes with a low-address-protection exception if a user space process executes an instruction that tries to use the linkage stack. Set the base-ASTE origin and the subspace-ASTE origin of the dispatchable-unit-control-table to point to a dummy ASTE. Set up control register 15 to point to an empty linkage stack with no room left. A user space process with a linkage stack instruction will still crash but with a different exception which is correctly translated to a segmentation fault instead of a kernel oops. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | | s390/dump: Fix dump memory detectionMichael Holzheu2014-02-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dumps created by kdump or zfcpdump can contain invalid memory holes when dumping z/VM systems that have memory pressure. For example: # zgetdump -i /proc/vmcore. Memory map: 0000000000000000 - 0000000000bfffff (12 MB) 0000000000e00000 - 00000000014fffff (7 MB) 000000000bd00000 - 00000000f3bfffff (3711 MB) The memory detection function find_memory_chunks() issues tprot to find valid memory chunks. In case of CMM it can happen that pages are marked as unstable via set_page_unstable() in arch_free_page(). If z/VM has released that pages, tprot returns -EFAULT and indicates a memory hole. So fix this and switch off CMM in case of kdump or zfcpdump. Cc: <stable@vger.kernel.org> Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| * | | | s390/appldata: restore missing init_virt_timer()Gerald Schaefer2014-01-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 27f6b416 "s390/vtimer: rework virtual timer interface" removed the call to init_virt_timer() by mistake, which is added again by this patch. Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>