summaryrefslogtreecommitdiffstats
path: root/arch/arm
Commit message (Collapse)AuthorAgeFilesLines
*---. Merge branches 'fixes', 'misc', 'pm' and 'sa1100' into for-nextRussell King2014-12-0570-779/+1027
|\ \ \
| | | * ARM: 8243/1: sa1100: add a clock alias for sa1111 pcmcia deviceDmitry Eremin-Solenikov2014-12-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SA-1111 uses internal MMIO space offsets as a device name, so device name for sa1111 pcmcia is 1800 (PCMCIA is at offset 0x1800). Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8242/1: sa1100: add cpu clockDmitry Eremin-Solenikov2014-12-051-7/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both SA1100 framebuffer and PCMCIA drivers require knowledge of cpu frequency to correctly program timings. Currently they receive timing information by calling cpufreq_get(0). However if cpu frequency driver is not enabled (e.g. due to unsupported DRAM chip/board on sa1110) cpufreq_get(0) returns 0, causing incorrect timings to be programmed. Add cpu clock returning cpu frequency, to be used by sa11x0 fb and pcmcia drivers. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8234/1: sa1100: reorder IRQ handling codeDmitry Eremin-Solenikov2014-12-031-89/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch just reorders functions/data inside sa1100 irq driver to be able to merge functions that have the same code after converting to irqdomains and hwirq. No real code changes. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8233/1: sa1100: switch to hwirq usageDmitry Eremin-Solenikov2014-12-031-23/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Switch internally to using hardware irq numbers (hwirq). In case of GPIO interrupts, hwirq is equal to GPIO number. In case of system interrupts, hwirq is equal to interrupt number in the interrupt controller. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8232/1: sa1100: merge GPIO multiplexer IRQ to "normal" irq domainDmitry Eremin-Solenikov2014-12-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IRQ_GPIO11_27 is a shared IRQ receiving IRQs from "high" GPIOs. It is still handled by sa1100_normal_chip, so there is no point to exclude it from "normal" irq domain. The IRQF_VALID flag set by domain map function will be cleared by irq_set_chained_handler() internally. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8231/1: sa1100: introduce irqdomains supportDmitry Eremin-Solenikov2014-12-032-17/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use irqdomains to manage both system and GPIO interrupts on SA1100 SoC family. This opens path to further cleanup and unification in sa1100 IRQ drivers. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8230/1: sa1100: shift IRQs by oneDmitry Eremin-Solenikov2014-12-031-51/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As IRQ0 should not be used (especially in when using irq domains), shift all virtual IRQ numbers by one. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8229/1: sa1100: replace irq numbers with names in irq driverDmitry Eremin-Solenikov2014-12-031-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for further changes replace direct IRQ numbers with pre-defined names. This imposes no real code changes. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8228/1: sa1100: drop entry-macro.SDmitry Eremin-Solenikov2014-12-031-41/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As mach-sa1100 was converted to MULTI_IRQ_HANDLER, drop now-unused entry-macro.S file. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | | * ARM: 8227/1: sa1100: switch to MULTI_IRQ_HANDLERDmitry Eremin-Solenikov2014-12-032-0/+21
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Add sa1100_handle_irq implementating handle_irq for sa1100 platform. It is more or less a translation of old assembly code from assembler to plain C. Also install this irq handler from sa1100_init_irq(). Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8221/1: PJ4: allow building in Thumb-2 modeArd Biesheuvel2014-12-032-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two files that get included when building the multi_v7_defconfig target fail to build when selecting THUMB2_KERNEL for this configuration. In both cases, we can just build the file as ARM code, as none of its symbols are exported to modules, so there are no interworking concerns. In the iwmmxt.S case, add ENDPROC() declarations so the symbols are annotated as functions, resulting in the linker to emit the appropriate mode switches. Acked-by: Nicolas Pitre <nico@linaro.org> Tested-by: Olof Johansson <olof@lixom.net> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8241/1: Update processor_modes for hyp and monitor modeStephen Boyd2014-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the kernel is running in hypervisor mode or monitor mode we'll print UK6_32 or UK10_32 if we call into __show_regs(). Let's update these strings to indicate the new modes that didn't exist when this code was written. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8240/1: MCPM: document mcpm_sync_init()Nicolas Pitre2014-12-031-0/+17
| | | | | | | | | | | | | | | Signed-off-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8239/1: Introduce {set,clear}_pte_bitJungseung Lee2014-12-031-11/+51
| | | | | | | | | | | | | | | | | | | | | | | | Introduce helper functions for pte_mk* functions and it would be used to change individual bits in ptes at times. Signed-off-by: Jungseung Lee <js07.lee@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8238/1: mm: Refine set_memory_* functionsJungseung Lee2014-12-033-39/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | set_memory_* functions have same implementation except memory attribute. This patch makes to use common function for these, and pull out the functions into arch/arm/mm/pageattr.c like arm64 did. It will reduce code size and enhance the readability. Signed-off-by: Jungseung Lee <js07.lee@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8237/1: fix flush_pfn_aliasJungseung Lee2014-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | L1_CACHE_BYTES could be larger than real L1 cache line size. In that case, flush_pfn_alias() would omit to flush last bytes as much as L1_CACHE_BYTES - real cache line size. So fix end address to "to + PAGE_SIZE - 1". The bottom bits of the address is LINELEN. that is ignored by mcrr. Signed-off-by: Jungseung Lee <js07.lee@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8236/1: mm: fix discard_old_kernel_dataJungseung Lee2014-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | L1_CACHE_BYTES could be larger value than real L1 cache line size. In that case, discard_old_kernel_data() would omit to invalidate last bytes as much as L1_CACHE_BYTES - real cache line size. So fix end address to "to + PAGE_SIZE -1". The bottom bits of the address is LINELEN. that is ignored by mcrr. Signed-off-by: Jungseung Lee <js07.lee@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8235/1: Support for the PXN CPU feature on ARMv7Jungseung Lee2014-12-034-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Modern ARMv7-A/R cores optionally implement below new hardware feature: - PXN: Privileged execute-never(PXN) is a security feature. PXN bit determines whether the processor can execute software from the region. This is effective solution against ret2usr attack. On an implementation that does not include the LPAE, PXN is optionally supported. This patch set PXN bit on user page table for preventing user code execution with privilege mode. Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Jungseung Lee <js07.lee@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8218/1: warn if bad IRQ was scheduledDmitry Eremin-Solenikov2014-11-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If somebody causes an unexpected bad IRQ, this even will be unnoticed in both dmesg and system logs. If the "bad" IRQ is stuck, the device will just hang silently w/o reporting anything. Compare this to the generic behaviour (from include/asm-generic/hardirq.h) which prints a message with critical level. So to help everybody, include the same message into ARM-specific ack_bad_irq(). Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8217/1: sa1100 collie: use gpio-charger instead of pda-powerDmitry Eremin-Solenikov2014-11-271-48/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use gpio-charger driver instead of pda-power: it automatically cares about used gpio and since collie does not differentiate between usb and ac chargers, pda-power is an overkill for it. As a bonus this allows us to remove gpio_to_irq calls from machine init call - it is fragile. These gpio_to_irq calls will fail if gpios are registered later, via device driver mechanisms. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8225/1: Add unwinding support for memory copy functionsLin Yongting2014-11-274-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The memory copy functions(memcpy, __copy_from_user, __copy_to_user) never had unwinding annotations added. Currently, when accessing invalid pointer by these functions occurs the backtrace shown will stop at these functions or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace in following cases: 1. die on accessing invalid pointer by these functions 2. kprobe trapped at any instruction within these functions 3. interrupted at any instruction within these functions Signed-off-by: Lin Yongting <linyongting@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8224/1: Add unwinding support for memmove functionLin Yongting2014-11-271-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The memmove function never had unwinding annotations added. Currently, when accessing invalid pointer by memmove occurs the backtrace shown will stop at memmove or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace in following cases: 1. die on accessing invalid pointer by memmove 2. kprobe trapped at any instruction within memmove 3. interrupted at any instruction within memmove Signed-off-by: Lin Yongting <linyongting@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8223/1: Add unwinding support for __memzero functionLin Yongting2014-11-271-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The __memzero function never had unwinding annotations added. Currently, when accessing invalid pointer by __memzero occurs the backtrace shown will stop at __memzero or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace in following cases: 1. die on accessing invalid pointer by __memzero 2. kprobe trapped at any instruction within __memzero 3. interrupted at any instruction within __memzero Signed-off-by: Lin Yongting <linyongting@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: io.c: clean up EXPORT_SYMBOL()sRussell King2014-11-211-3/+2
| | | | | | | | | | | | | | | | | | | | | Place EXPORT_SYMBOL()s after the function definition. Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: move ftrace assembly code to separate fileRussell King2014-11-213-235/+244
| | | | | | | | | | | | | | | | | | | | | | | | | | | The ftrace assembly code doesn't need to live in entry-common.S and be surrounded with #ifdef CONFIG_FUNCTION_TRACER. Instead, move it to its own file and conditionally assemble it. Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: add machine name to stack dump outputRussell King2014-11-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The generic dump_stack() code provides the facility to include the machine name in the stack dump, which can be useful information. Add a call to dump_stack_set_arch_desc() for the generic code to print this information. Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: remove "SMP: Total of %d processors activated." messageRussell King2014-11-211-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | The "SMP: Total of %d processors activated." message which we print in smp_cpus_done() provides no further information than the message in genreic code in smp_announce(). Kill it. Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: reduce "Booted secondary processor" message to debug levelRussell King2014-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Drop the "CPUn: Booted secondary processor" message from info to debug level. We later print how many CPUs came online, so listing each one is redundant, and when using hotplug, can be quite noisy. Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: drop nwfpe initialisation message from warning to info levelRussell King2014-11-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | nwfpe's initialisation message is not a warning, it is purely informational. Print it at the appropriate message level. Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: use pr_warn_ratelimited() when migrating IRQsRussell King2014-11-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Rather than open coding the printk_ratelimit() check with pr_warn(), use pr_warn_ratelimited() instead. Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: convert printk(KERN_* to pr_*Russell King2014-11-2128-146/+128
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert many (but not all) printk(KERN_* to pr_* to simplify the code. We take the opportunity to join some printk lines together so we don't split the message across several lines, and we also add a few levels to some messages which were previously missing them. Tested-by: Andrew Lunn <andrew@lunn.ch> Tested-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8204/1: Add unwinding support for memset functionLin Yongting2014-11-211-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The memset function never had unwinding annotations added. Currently, when accessing NULL pointer by memset occurs the backtrace shown will stop at memset or some completely unrelated function. Add unwinding annotations in hopes of getting a more useful backtrace when accessing NULL pointer by memset, kprobe or interrupt. Signed-off-by: Lin Yongting <linyongting@gmail.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8203/1: mm: try to re-use old ASID assignments following a rolloverWill Deacon2014-11-211-24/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than unconditionally allocating a fresh ASID to an mm from an older generation, attempt to re-use the old assignment where possible. This can bring performance benefits on systems where the ASID is used to tag things other than the TLB (e.g. branch prediction resources). Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8215/1: vfp: Silence mvfr0 variable unused warningStephen Boyd2014-11-211-23/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Stephen Rothwell reports that commit 3f4c9f8f0a20 ("ARM: 8197/1: vfp: Fix VFPv3 hwcap detection on CPUID based cpus") introduced a variable unused warning. arch/arm/vfp/vfpmodule.c: In function 'vfp_init': arch/arm/vfp/vfpmodule.c:725:6: warning: unused variable 'mvfr0' [-Wunused-variable] u32 mvfr0; Silence this warning by using IS_ENABLED instead of ifdefs. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8197/1: vfp: Fix VFPv3 hwcap detection on CPUID based cpusStephen Boyd2014-11-212-41/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The subarchitecture field in the fpsid register is 7 bits wide on ARM CPUs using the CPUID identification scheme, spanning bits 22 to 16. The topmost bit is used to designate that the subarchitecture designer is not ARM when it is set to 1. On non-CPUID scheme CPUs the subarchitecture field is only 4 bits wide and the higher bits are used to indicate no double precision support (bit 20) and the FTSMX/FLDMX format (bits 21-22). The VFP support code only looks at bits 19-16 to determine the VFP version. On Qualcomm's processors (Krait and Scorpion) we should see that we have HWCAP_VFPv3 but we don't because bit 22 is set to 1 to indicate that the subarchitecture is not implemented by ARM and the rest of the bits are left as 0 because this is the first subarchitecture that Qualcomm has designed. Unfortunately we can't just widen the FPSID subarchitecture bitmask to consider all the bits on a CPUID scheme because there may be CPUs without the CPUID scheme that have VFP without double precision support and then the version would be a very wrong and large number. Instead, update the version detection logic to consider if the CPU is using the CPUID scheme. If the CPU is using CPUID scheme, use the MVFR registers to determine what version of VFP is supported. We already do this for VFPv4, so do something similar for VFPv3 and look for single or double precision support in MVFR0. Otherwise fall back to using FPSID to detect VFP support on non-CPUID scheme CPUs. We know that VFPv3 is only present in CPUs that have support for the CPUID scheme so this should be equivalent. Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8196/1: vfp: Workaround bad MVFR1 register on some KraitsStephen Boyd2014-11-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain versions of the Krait processor don't report that they support the fused multiply accumulate instruction via the MVFR1 register despite the fact that they actually do. Unfortunately we use this register to identify support for VFPv4. Override the hwcap on all Krait processors to indicate support for VFPv4 to workaround this. Tested-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8195/1: vfp: Bounce undefined instructions in vectored modeStepan Moskovchenko2014-11-171-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain ARM CPU implementations (e.g. Cortex-A15) may not raise a floating- point exception whenever deprecated short-vector VFP instructions are executed. Instead these instructions are treated as UNALLOCATED. Change the VFP exception handling code to emulate short-vector instructions even if FPEXC exception bits are not set. Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org> Tested-by: Will Deacon <will.deacon@arm.com> Tested-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8194/1: remove clear_thread_flag(TIF_UPROBE)Yalin Wang2014-11-171-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | This patch remove clear_thread_flag(TIF_UPROBE) in do_work_pending(), because uprobe_notify_resume() have do this. Signed-off-by: Yalin Wang <yalin.wang@sonymobile.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8176/1: Use current_stack_pointer in unwind_backtraceBehan Webster2014-11-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and clang. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8175/1: Use current_stack_pointer to calculate pt_regs addressBehan Webster2014-11-131-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the global current_stack_pointer to calculate the end of the stack for current_pt_regs() Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8174/1: Use global stack register variable for percpuMark Charlebois2014-11-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using global current_stack_pointer works on both clang and gcc. current_stack_pointer is an unsigned long and needs to be cast as a pointer to dereference. Signed-off-by: Mark Charlebois <charlebm@gmail.com> Signed-off-by: Behan Webster <behanw@converseincode.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8173/1: Calculate current_thread_info from current_stack_pointerBehan Webster2014-11-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and clang. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8172/1: Use current_stack_pointer in save_stack_trace_tskBehan Webster2014-11-131-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and clang. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8171/1: Use current_stack_pointer for return_addressBehan Webster2014-11-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and Clang. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | ARM: 8170/1: Add global named register current_stack_pointer for ARMBehan Webster2014-11-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Define a global named register for current_stack_pointer. The use of this new variable guarantees that both gcc and clang can access this register in C code. Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | | ARM: 8226/1: cacheflush: get rid of restarting blockVladimir Murzin2014-11-272-40/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We cannot restart cacheflush safely if a process provides user-defined signal handler and signal is pending. In this case -EINTR is returned and it is expected that process re-invokes syscall. However, there are a few problems with that: * looks like nobody bothers checking return value from cacheflush * but if it did, we don't provide the restart address for that, so the process has to use the same range again * ...and again, what might lead to looping forever So, remove cacheflush restarting code and terminate cache flushing as early as fatal signal is pending. Cc: stable@vger.kernel.org # 3.12+ Reported-by: Chanho Min <chanho.min@lge.com> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | | ARM: 8222/1: mvebu: enable strex backoff delayThomas Petazzoni2014-11-271-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under extremely rare conditions, in an MPCore node consisting of at least 3 CPUs, two CPUs trying to perform a STREX to data on the same shared cache line can enter a livelock situation. This patch enables the HW mechanism that overcomes the bug. This fixes the incorrect setup of the STREX backoff delay bit due to a wrong description in the specification. Note that enabling the STREX backoff delay mechanism is done by leaving the bit *cleared*, while the bit was currently being set by the proc-v7.S code. [Thomas: adapt to latest mainline, slightly reword the commit log, add stable markers.] Fixes: de4901933f6d ("arm: mm: Add support for PJ4B cpu and init routines") Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by: Nadav Haklai <nadavh@marvell.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | | ARM: 8216/1: xscale: correct auxiliary register in suspend/resumeDmitry Eremin-Solenikov2014-11-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the manuals I have, XScale auxiliary register should be reached with opc_2 = 1 instead of crn = 1. cpu_xscale_proc_init correctly uses c1, c0, 1 arguments, but cpu_xscale_do_suspend and cpu_xscale_do_resume use c1, c1, 0. Correct suspend/resume functions to also use c1, c0, 1. The issue was primarily noticed thanks to qemu reporing "unsupported instruction" on the pxa suspend path. Confirmed in PXA210/250 and PXA255 XScale Core manuals and in PXA270 and PXA320 Developers Guides. Harware tested by me on tosa (pxa255). Robert confirmed on pxa270 board. Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Cc: stable@vger.kernel.org Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | | ARM: 8198/1: make kuser helpers depend on MMUNathan Lynch2014-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kuser helpers page is not set up on non-MMU systems, so it does not make sense to allow CONFIG_KUSER_HELPERS to be enabled when CONFIG_MMU=n. Allowing it to be set on !MMU results in an oops in set_tls (used in execve and the arm_syscall trap handler): Unhandled exception: IPSR = 00000005 LR = fffffff1 CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216 task: 8b838000 ti: 8b82a000 task.ti: 8b82a000 PC is at flush_thread+0x32/0x40 LR is at flush_thread+0x21/0x40 pc : [<8f00157a>] lr : [<8f001569>] psr: 4100000b sp : 8b82be20 ip : 00000000 fp : 8b83c000 r10: 00000001 r9 : 88018c84 r8 : 8bb85000 r7 : 8b838000 r6 : 00000000 r5 : 8bb77400 r4 : 8b82a000 r3 : ffff0ff0 r2 : 8b82a000 r1 : 00000000 r0 : 88020354 xPSR: 4100000b CPU: 0 PID: 1 Comm: swapper Not tainted 3.18.0-rc1-00041-ga30465a #216 [<8f002bc1>] (unwind_backtrace) from [<8f002033>] (show_stack+0xb/0xc) [<8f002033>] (show_stack) from [<8f00265b>] (__invalid_entry+0x4b/0x4c) As best I can tell this issue existed for the set_tls ARM syscall before commit fbfb872f5f41 "ARM: 8148/1: flush TLS and thumbee register state during exec" consolidated the TLS manipulation code into the set_tls helper function, but now that we're using it to flush register state during execve, !MMU users encounter the oops at the first exec. Prevent CONFIG_MMU=n configurations from enabling CONFIG_KUSER_HELPERS. Fixes: fbfb872f5f41 (ARM: 8148/1: flush TLS and thumbee register state during exec) Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com> Reported-by: Stefan Agner <stefan@agner.ch> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: stable@vger.kernel.org Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
OpenPOWER on IntegriCloud