summaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)Author
2014-12-02powerpc/eeh: Set EEH_PE_RESET on PE resetGavin Shan
The patch introduces additional flag EEH_PE_RESET to indicate the corresponding PE is under reset. In turn, the PE retrieval bakcend on PowerNV platform can return unfrozen state for the EEH core to moving forward. Flag EEH_PE_CFG_BLOCKED isn't the correct one for the purpose. In PCI passthrou case, the problem is more worse: Guest doesn't recover 6th EEH error. The PE is left in isolated (frozen) and config blocked state on Broadcom adapters. We can't retrieve the PE's state correctly any more, even from the host side via sysfs /sys/bus/pci/devices/xxx/eeh_pe_state. Reported-by: Rajeshkumar Subramanian <rajeshkumars@in.ibm.com> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-12-02powerpc/eeh: Refactor eeh_reset_pe()Gavin Shan
The patch refactors eeh_reset_pe() in order for: * Varied return values for different failure cases. * Replace pr_err() with pr_warn() and print function name. * Coding style cleanup. Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2014-12-01ARM: BCM5301X: Add IRQs to Broadcom's bus-axi in DTS fileHauke Mehrtens
IRQ support for Broadcom's bus-axi driver bcma was merged into John Linville's wireless tree and will show up in 3.19. This patch makes use of this feature in the DTS file for the the BCM5301X SoCs. I left the PCIe controller out, because this still needs some discussion. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
2014-12-02ARM: shmobile: marzen: Remove DU platform deviceLaurent Pinchart
Platform data support has been removed from the DU driver, drop DU support from the legacy Marzen board file. The multiplatform DT-based Marzen support should be used instead. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-02ARM: shmobile: lager: Remove DU platform deviceLaurent Pinchart
Platform data support has been removed from the DU driver, drop DU support from the legacy Lager board file. The multiplatform DT-based Lager support should be used instead. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-12-01ftrace/fgraph/x86: Have prepare_ftrace_return() take ip as first parameterSteven Rostedt (Red Hat)
The function graph helper function prepare_ftrace_return() which does the work to hijack the parent pointer has that parent pointer as its first parameter. Instead, if we make it the second parameter and have ip as the first parameter (self_addr), then it can use the %rdi from save_mcount_regs that loads it already. Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01ftrace/x86: Get rid of ftrace_caller_setupSteven Rostedt (Red Hat)
Move all the work from ftrace_caller_setup into save_mcount_regs. This simplifies the code and makes it easier to understand. Link: http://lkml.kernel.org/r/CA+55aFxUTUbdxpjVMW8X9c=o8sui7OB_MYPfcbJuDyfUWtNrNg@mail.gmail.com Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01ftrace/x86: Have save_mcount_regs macro also save stack frames if neededSteven Rostedt (Red Hat)
The save_mcount_regs macro saves and restores the required mcount regs that need to be saved before calling C code. It is done for all the function hook utilities (static tracing, dynamic tracing, regs, function graph). When frame pointers are enabled, the ftrace trampolines need to set up frames and pointers such that a back trace (dump stack) can continue passed them. Currently, a separate macro is used (create_frame) to do this, but it's only done for the ftrace_caller and ftrace_reg_caller functions. It is not done for the static tracer or function graph tracing. Instead of having a separate macro doing the recording of the frames, have the save_mcount_regs perform this task. This also has all tracers saving the frame pointers when needed. Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01ftrace/x86: Add macro MCOUNT_REG_SIZE for amount of stack used to save ↵Steven Rostedt (Red Hat)
mcount regs The macro save_mcount_regs saves regs onto the stack. But to uncouple the amount of stack used in that macro from the users of the macro, we need to have a define that tells all the users how much stack is used by that macro. This way we can change the amount of stack the macro uses without breaking its users. Also remove some dead code that was left over from commit fdc841b58cf5 "ftrace: x86: Remove check of obsolete variable function_trace_stop". Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01ftrace/x86: Simplify save_mcount_regs on getting RIPSteven Rostedt (Red Hat)
Currently save_mcount_regs is passed a "skip" parameter to know how much stack updated the pt_regs, as it tries to keep the saved pt_regs in the same location for all users. This is rather stupid, especially since the part stored on the pt_regs has nothing to do with what is suppose to be in that location. Instead of doing that, just pass in an "added" parameter that lets that macro know how much stack was added before it was called so that it can get to the RIP. But the difference is that it will now offset the pt_regs by that "added" count. The caller now needs to take care of the offset of the pt_regs. This will make it easier to simplify the code later. Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01ftrace/x86: Have save_mcount_regs store RIP in %rdi for first parameterSteven Rostedt (Red Hat)
Instead of having save_mcount_regs store the RIP in %rdx as a temp register to place it in the proper location of the pt_regs on the stack. Use the %rdi register as the temp register. This lets us remove the extra store in the ftrace_caller_setup macro. Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01ftrace/x86: Rename MCOUNT_SAVE_FRAME and add more detailed commentsSteven Rostedt (Red Hat)
The name MCOUNT_SAVE_FRAME is rather confusing as it really isn't a function frame that is saved, but just the required mcount registers that are needed to be saved before C code may be called. The word "frame" confuses it as being a function frame which it is not. Rename MCOUNT_SAVE_FRAME and MCOUNT_RESTORE_FRAME to save_mcount_regs and restore_mcount_regs respectively. Noticed the lower case, which keeps it from screaming at the reviewers. Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01ftrace/x86: Move MCOUNT_SAVE_FRAME out of header fileSteven Rostedt (Red Hat)
Linus pointed out that MCOUNT_SAVE_FRAME is used in only a single file and that there's no reason that it should be in a header file. Move the macro to the code that uses it. Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01ftrace/x86: Have static tracing also use ftrace_caller_setupSteven Rostedt (Red Hat)
Linus pointed out that there were locations that did the hard coded update of the parent and rip parameters. One of them was the static tracer which could also use the ftrace_caller_setup to do that work. In fact, because it did not use it, it is prone to bugs, and since the static tracer is hardly ever used (who wants function tracing code always being called?) it doesn't get tested very often. I only run a few "does it still work" tests on it. But I do not run stress tests on that code. Although, since it is never turned off, just having it on should be stressful enough. (especially for the performance folks) There's no reason that the static tracer can't also use ftrace_caller_setup. Have it do so. Link: http://lkml.kernel.org/r/CA+55aFwF+qCGSKdGaEgW4p6N65GZ5_XTV=1NbtWDvxnd5yYLiw@mail.gmail.com Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1411262304010.3961@nanos Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2014-12-01arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_opsWill Deacon
This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't actually called outside of a few drivers) into arch_setup_dma_ops, so that we can use IOMMUs for DMA transfers in a more generic fashion. Since this significantly complicates the arch_setup_dma_ops function, it is moved out of line into dma-mapping.c. If CONFIG_ARM_DMA_USE_IOMMU is not set, the iommu parameter is ignored and the normal ops are used instead. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-01arm: call iommu_init before of_platform_populateWill Deacon
We need to ensure that the IOMMUs in the system have a chance to perform some basic initialisation before we start adding masters to them. This patch adds a call to of_iommu_init before of_platform_populate. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-01dma-mapping: detect and configure IOMMU in of_dma_configureWill Deacon
This patch extends of_dma_configure so that it sets up the IOMMU for a device, as well as the coherent/non-coherent DMA mapping ops. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-01dma-mapping: replace set_arch_dma_coherent_ops with arch_setup_dma_opsWill Deacon
set_arch_dma_coherent_ops is called from of_dma_configure in order to swizzle the architectural dma-mapping functions over to a cache-coherent implementation. This is currently implemented only for ARM. In anticipation of re-using this mechanism for IOMMU-backed dma-mapping ops too, this patch replaces the function with a broader arch_setup_dma_ops callback which will be extended in future. Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-01arm64: compat: align cacheflush syscall with arch/armVladimir Murzin
Update handling of cacheflush syscall with changes made in arch/arm counterpart: - return error to userspace when flushing syscall fails - split user cache-flushing into interruptible chunks - don't bother rounding to nearest vma Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> [will: changed internal return value from -EINTR to 0 to match arch/arm/] Signed-off-by: Will Deacon <will.deacon@arm.com>
2014-12-01x86, microcode, AMD: Do not use smp_processor_id() in preemtible contextBorislav Petkov
Hand down the cpu number instead, otherwise lockdep screams when doing echo 1 > /sys/devices/system/cpu/microcode/reload. BUG: using smp_processor_id() in preemptible [00000000] code: amd64-microcode/2470 caller is debug_smp_processor_id+0x12/0x20 CPU: 1 PID: 2470 Comm: amd64-microcode Not tainted 3.18.0-rc6+ #26 ... Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/1417428741-4501-1-git-send-email-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-12-01s390/kprobes: fix instruction copy for out of line executionHeiko Carstens
When we generate the instruction for out of line execution the length of the to be copied instruction was evaluated from a not initialized memory location. Therefore we ended up with a random (2, 4 or 6) number of bytes being copied instead of taking the real instruction length into account. This works surprisingly well most of the time, but still not always. Reported-by: Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-12-01s390: fix machine check handlingSebastian Ott
Commit eb7e7d76 "s390: Replace __get_cpu_var uses" broke machine check handling. We copy machine check information from per-cpu to a stack variable for local processing. Next we should zap the per-cpu variable, not the stack variable. Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com> Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com> Acked-by: Christoph Lameter <cl@linux.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2014-12-01x86, microcode: Limit the microcode reloading to 64-bit for nowBorislav Petkov
First, there was this: https://bugzilla.kernel.org/show_bug.cgi?id=88001 The problem there was that microcode patches are not being reapplied after suspend-to-ram. It was important to reapply them, though, because of for example Haswell's TSX erratum which disabled TSX instructions with a microcode patch. A simple fix was fb86b97300d9 ("x86, microcode: Update BSPs microcode on resume") but, as it is often the case, simple fixes are too simple. This one causes 32-bit resume to fail: https://bugzilla.kernel.org/show_bug.cgi?id=88391 Properly fixing this would require more involved changes for which it is too late now, right before the merge window. Thus, limit this to 64-bit only temporarily. Signed-off-by: Borislav Petkov <bp@suse.de> Link: http://lkml.kernel.org/r/1417353999-32236-1-git-send-email-bp@alien8.de Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2014-12-01ARM: zynq: Remove secondary_startup() declaration from headerMichal Simek
secondary_startup() in the header is not needed at all. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-12-01arm: dts: zynq: Add Digilent ZYBO boardPeter Crosthwaite
Add a DTS describing the Digilent ZYBO board. Similar to ZED but with a 50MHz crystal instead of 33MHz. Acked-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-12-01arm: dts: zynq: Move crystal freq. to board levelPeter Crosthwaite
The fact that all supported boards use the same 33MHz crystal is a co-incidence. The Zynq PS support a range of crystal freqs so the hardcoded setting should be removed from the dtsi. Re-implement it on the board level. This prepares support for Zynq boards with different crystal frequencies (e.g. the Digilent ZYBO). Acked-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2014-11-30hwmon: (ibmpowernv) Use platform 'id_table' to probe the deviceNeelesh Gupta
The current driver probe() function assumes the sensor device to be always present and gets executed every time if the driver is loaded, but the appropriate hardware could not be present. So, move the platform device creation as part of platform init code and use the 'id_table' to check if the device is present or not. Signed-off-by: Neelesh Gupta <neelegup@linux.vnet.ibm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2014-11-30Merge 3.18-rc7 into usb-nextGreg Kroah-Hartman
We need the xhci fixes here and this resolves a merge issue with drivers/usb/dwc3/ep0.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-12-01Merge back earlier cpufreq material for 3.19-rc1.Rafael J. Wysocki
2014-12-01ARM: dts: rockchip: set FIFO size for SDMMC, SDIO and EMMC on rk3066 and rk3188Julien CHAUVEAU
The SDMMC, SDIO and EMMC controllers use an external FIFO whose size is 256x32bit. This patch set the corresponding fifo-depth properties for both RK3066 and RK3188. Signed-off-by: Julien CHAUVEAU <julien.chauveau@neo-technologies.fr> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2014-12-01ARM: dts: rockchip: add label property for leds on Radxa RockRomain Perier
The leds-gpio driver recently switched to the device property API. The device_node name is no longer retrieved if the "label" devicetree property is not found. In this case the driver tries to create entries with (null) name in /sys/class/leds, which is wrong and generates backtrace as several gpio_leds have the same name. Also renamed subnode "yellow" to "blue" to match the last schematics updates. Signed-off-by: Romain Perier <romain.perier@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2014-11-30ARM: mvebu: add SDRAM controller description for Armada XPThomas Petazzoni
The suspend/resume sequence on Armada XP needs to modify a number of registers in the SDRAM controller. Therefore, this commit updates the Armada XP Device Tree description to include the SDRAM controller Device Tree node. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-17-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30ARM: mvebu: adjust mbus controller description on Armada 370/XPThomas Petazzoni
In order to support suspend/resume on Armada XP, an additional set of registers need to be described at the MBus controller level. This commit therefore adjusts the Device Tree of the Armada 370/XP SoC to include those registers in the MBus controller description; Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-16-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30ARM: mvebu: add suspend/resume DT information for Armada XP GPThomas Petazzoni
This commit improves the Armada XP GP Device Tree description to describe the 3 GPIOs that are used to connect the SoC to the PIC micro-controller that we talk to shutdown the SoC when entering suspend to RAM. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-15-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30ARM: mvebu: synchronize secondary CPU clocks on resumeThomas Petazzoni
The Armada XP has multiple cores clocked by independent clocks. The SMP startup code contains a function called set_secondary_cpus_clock() called in armada_xp_smp_prepare_cpus() to ensure the clocks of the secondary CPUs match the clock of the boot CPU. With the introduction of suspend/resume, this operation is no longer needed when booting the system, but also when existing the suspend to RAM state. Therefore this commit reworks a bit the logic: instead of configuring the clock of all secondary CPUs in armada_xp_smp_prepare_cpus(), we do it on a per-secondary CPU basis in armada_xp_boot_secondary(), as this function gets called when existing suspend to RAM for each secondary CPU. Since the function now only takes care of one CPU, we rename it from set_secondary_cpus_clock() to set_secondary_cpu_clock(), and it looses its __init marker, as it is now used beyond the system initialization. Note that we can't use smp_processor_id() directly, because when exiting from suspend to RAM, the code is apparently executed with preemption enabled, so smp_processor_id() is not happy (prints a warning). We therefore switch to using get_cpu()/put_cpu(), even though we pretty much have the guarantee that the code starting the secondary CPUs is going to run on the boot CPU and will not be migrated. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-14-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30ARM: mvebu: make sure MMU is disabled in armada_370_xp_cpu_resumeThomas Petazzoni
The armada_370_xp_cpu_resume() until now was used only as the function called by the SoC when returning from a deep idle state (as used in cpuidle, or when the CPU is brought offline using CPU hotplug). However, it is now also used when exiting the suspend to RAM state. In this case, it is the bootloader that calls back into this function, with the MMU left enabled by the BootROM. Having the MMU enabled when entering this function confuses the kerrnel because we are not using the kernel page tables at this point, but in other mvebu functions we use the information on whether the MMU is enabled or not to find out whether we should talk to the coherency fabric using a physical address or a virtual address. To fix that, we simply disable the MMU when entering this function, so that the kernel is in an expected situation. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-13-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30ARM: mvebu: Armada XP GP specific suspend/resume codeThomas Petazzoni
On the Armada XP GP platform, entering suspend to RAM state is triggering by talking to an external PIC micro-controller connected to the SoC using 3 GPIOs. There is then a small magic sequence of GPIO toggling that needs to be used to tell the PIC to turn off the SoC. The code uses the Device Tree to find out which GPIOs are used to connect to the PIC micro-controller, and then registers its mvebu_armada_xp_gp_pm_enter() callback to the SoC-level PM code. The SoC PM code will call back into this registered function at the very end of the suspend procedure. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-12-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30ARM: mvebu: reserve the first 10 KB of each memory bank for suspend/resumeThomas Petazzoni
When going out of suspend to RAM, the Marvell EBU platforms go through the bootloader, which re-configures the DRAM controller. To achieve this, the bootloader executes a piece of code called the "DDR3 training code". It does some reads/writes to the memory to find out the optimal timings for the memory chip being used. This has the nasty side effect that the first 10 KB of each DRAM chip-select are overwritten by the bootloader when exiting the suspend to RAM state. Therefore, this commit implements the ->reserve() hook for the 'struct machine_desc' used on Armada XP, to reserve the 10 KB of each DRAM chip-select using the memblock API. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-11-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30ARM: mvebu: implement suspend/resume support for Armada XPThomas Petazzoni
This commit implements the core of the platform code to enable suspend/resume on Armada XP. It registers the platform_suspend_ops structure, and implements the ->enter() hook of this structure. It is worth mentioning that this commit only provides the SoC-level part of suspend/resume, which calls into some board-specific code provided in a follow-up commit. The most important thing that this SoC-level code has to do is to build an in-memory structure that contains a magic number, the return address in the kernel after resume, and a set of address/value pairs. This structure is used by the bootloader to restore a certain number of registers (according to the set of address/value pairs) and then jump back into the kernel at the provided location. The code also puts the SDRAM into self-refresh mode, before calling into board-specific code to actually enter the suspend to RAM state. [ jac - add email exchange between Andrew Lunn and Thomas Petazzoni to better describe who consumes the address/value pairs ] > > Is this a well defined mechanism supported by mainline uboot, barebox > > etc. Or is it some Marvell extension to their uboot? > > As far as I know, it is a Marvell extension to their "binary header", > so it's done even before U-Boot starts. Since the hardware needs > assistance from the bootloader to do suspend/resume, there is > necessarily a certain amount of cooperation/agreement needed by what > the kernel does and what the bootloader expects. I'm not sure there's > any "standard" mechanism here. Do you know of any? > > I know the suspend/resume on the Blackfin architecture works the same > way (at least it used to work that way years ago when I did a bit of > Blackfin stuff). And here as well, there was some cooperation between > the kernel and the bootloader. See > arch/blackfin/mach-common/dpmc_modes.S, function do_hibernate() at the > end. > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1416585613-2113-10-git-send-email-thomas.petazzoni@free-electrons.com Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-29netpoll: delete defconfig references to obsolete NETPOLL_TRAPPaul Gortmaker
In commit 9c62a68d13119a1ca9718381d97b0cb415ff4e9d ("netpoll: Remove dead packet receive code (CONFIG_NETPOLL_TRAP)") this Kconfig option was removed. So remove references to it from all defconfigs as well. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-11-29Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
2014-11-28Merge tag 'omap-for-v3.19/gpmc-move-v2' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/omap-gpmc Pull "move omap gpmc to drivers finally" from Tony Lindgren: We can finally move the GPMC code to live in drivers/memory for further clean up work. Note that we still have dependencies to the legacy booting for omap3 board-*.c files for setting up the board specific memory timings. For that we need the timing related things still exposed in include/linux/omap-gpmc.h. This will all become private data to the GPMC driver once the legacy booting support can be dropped. * tag 'omap-for-v3.19/gpmc-move-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: memory: gpmc: Move omap gpmc code to live under drivers ARM: OMAP2+: Move GPMC initcall to devices.c ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-11-28Merge tag 'tegra-for-3.19-soc' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/fixes-non-critical Pull "ARM: tegra: Core code changes for v3.19" from Thierry Reding: This contains a single fix for a bug that was introduced back in v3.13. * tag 'tegra-for-3.19-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: tegra: Re-add removed SoC id macro to tegra_resume() Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-11-28Merge tag 'tegra-for-3.19-defconfig' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/defconfig Pull "ARM: tegra: Default configuration changes for v3.19" from Thierry Reding: This is merely a regeneration of the default configuration to get rid of two symbols that are now enabled by default or removed. * tag 'tegra-for-3.19-defconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: tegra: Regenerate default configuration Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-11-28Merge tag 'bcm5301x-dt-2014-11-27' of https://github.com/hauke/linux into ↵Arnd Bergmann
next/dt Pull "ARM: BCM5301X: Add some more devices to device tree" from Hauke Mehrtens: The most important part is adding the axi bus to the SoC dtsi file, this is the main bus on the SoC. These patches were all send to the arm list and I haven't got any negative responses. Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de> * tag 'bcm5301x-dt-2014-11-27' of https://github.com/hauke/linux: ARM: BCM5301X: Add LEDs for Netgear R6250 V1 ARM: BCM5301X: Add Broadcom's bus-axi to the DTS file Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-11-28arm64: ARM: Fix the Generic Timers interrupt active level descriptionLiviu Dudau
The Cortex-A5x TRM states in paragraph "9.2 Generic Timer functional description" that generic timers provide an active-LOW interrupt output. Fix the device trees to correctly describe this. While doing this update the CPU mask to match the number of described CPUs as well. Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-11-28Merge tag 'mvebu-dt-usb-phy-3.19-3' of git://git.infradead.org/linux-mvebu ↵Arnd Bergmann
into next/dt2 Pull "mvebu DT changes for v3.19 (round 3)" from Jason Cooper: - Armada 375 - Add PHY and USB cluster controller support * tag 'mvebu-dt-usb-phy-3.19-3' of git://git.infradead.org/linux-mvebu: ARM: mvebu: add PHY support to the dts for the USB controllers on Armada 375 ARM: mvebu: add Device Tree description of USB cluster controller on Armada 375 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2014-11-28Merge tag 'armsoc-for-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Arnd Bergmann: "Not much interesting going on fixes-wise for us this week, as it should be for an -rc7. I'm not expecting Olof to work much over Thanksgiving weekend, so I decided to take over again and push these out to you. Just four simple fixes this week: - one missing of_node_put() on armv7 based mvebu - forcing the USB host into the right mode on Chromebook (exynos5-snow) - enabling two important drivers for exynos_defconfig - fixing a noncritical bug for tegra that would cause a regression with common code patches queued for 3.19" * tag 'armsoc-for-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: tegra: irq: fix buggy usage of irq_data irq field ARM: exynos_defconfig: Enable max77802 rtc and clock drivers ARM: dts: Explicitly set dr_mode on exynos5250-snow ARM: mvebu: add missing of_node_put() call in coherency.c
2014-11-28Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-armLinus Torvalds
Pull ARM fixes from Russell King: "Another round of relatively small ARM fixes. Thomas spotted that the strex backoff delay bit was a disable bit, so it needed to be clear for this to work. Vladimir spotted that using a restart block for the cache flush operation would return -EINTR, which userspace was not expecting. Dmitry spotted that the auxiliary control register accesses for Xscale were not correct" * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: 8226/1: cacheflush: get rid of restarting block ARM: 8222/1: mvebu: enable strex backoff delay ARM: 8216/1: xscale: correct auxiliary register in suspend/resume
2014-11-28Merge tag 'v3.18-rc4' into next/dt2Arnd Bergmann
Linux 3.18-rc4 is a dependency for the phy-dt-header branch that is needed for the final mvebu DT changes. Signed-off-by: Arnd Bergmann <arnd@arndb.de>