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: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NDmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NLin Yongting <linyongting@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NLin Yongting <linyongting@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NLin Yongting <linyongting@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Place EXPORT_SYMBOL()s after the function definition.
Tested-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

nwfpe's initialisation message is not a warning, it is purely
informational.  Print it at the appropriate message level.
Tested-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Rather than open coding the printk_ratelimit() check with pr_warn(), use
pr_warn_ratelimited() instead.
Tested-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NAndrew Lunn <andrew@lunn.ch>
Tested-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NLin Yongting <linyongting@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRob Clark <robdclark@gmail.com>
Reviewed-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NRob Clark <robdclark@gmail.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NStepan Moskovchenko <stepanm@codeaurora.org>
Tested-by: NWill Deacon <will.deacon@arm.com>
Tested-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This patch remove clear_thread_flag(TIF_UPROBE) in do_work_pending(),
because uprobe_notify_resume() have do this.
Signed-off-by: NYalin Wang <yalin.wang@sonymobile.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>
Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de>
Acked-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Use the global current_stack_pointer to calculate the end of the stack for
current_pt_regs()
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>
Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de>
Acked-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NMark Charlebois <charlebm@gmail.com>
Signed-off-by: NBehan Webster <behanw@converseincode.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>
Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de>
Acked-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>
Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de>
Acked-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>
Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de>
Acked-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NBehan Webster <behanw@converseincode.com>
Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de>
Reviewed-by: NMark Charlebois <charlebm@gmail.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This breaks the stack end corruption detection facility.

What that facility does it write a magic value to "end_of_stack()"
and checking to see if it gets overwritten.

"end_of_stack()" is "task_thread_info(p) + 1", which for sparc64 is
the beginning of the FPU register save area.

So once the user uses the FPU, the magic value is overwritten and the
debug checks trigger.

Fix this by making the size explicit.

Due to the size we use for the fpsaved[], gsr[], and xfsr[] arrays we
are limited to 7 levels of FPU state saves.  So each FPU register set
is 256 bytes, allocate 256 * 7 for the fpregs area.
Reported-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Every path that ends up at do_sparc64_fault() must install a valid
FAULT_CODE_* bitmask in the per-thread fault code byte.

Two paths leading to the label winfix_trampoline (which expects the
FAULT_CODE_* mask in register %g4) were not doing so:

1) For pre-hypervisor TLB protection violation traps, if we took
   the 'winfix_trampoline' path we wouldn't have %g4 initialized
   with the FAULT_CODE_* value yet.  Resulting in using the
   TLB_TAG_ACCESS register address value instead.

2) In the TSB miss path, when we notice that we are going to use a
   hugepage mapping, but we haven't allocated the hugepage TSB yet, we
   still have to take the window fixup case into consideration and
   in that particular path we leave %g4 not setup properly.

Errors on this sort were largely invisible previously, but after
commit 4ccb9272 ("sparc64: sun4v TLB
error power off events") we now have a fault_code mask bit
(FAULT_CODE_BAD_RA) that triggers due to this bug.

FAULT_CODE_BAD_RA triggers because this bit is set in TLB_TAG_ACCESS
(see #1 above) and thus we get seemingly random bus errors triggered
for user processes.

Fixes: 4ccb9272 ("sparc64: sun4v TLB error power off events")
Reported-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

CR4 isn't constant; at least the TSD and PCE bits can vary.

TBH, treating CR0 and CR3 as constant scares me a bit, too, but it looks
like it's correct.

This adds a branch and a read from cr4 to each vm entry.  Because it is
extremely likely that consecutive entries into the same vcpu will have
the same host cr4 value, this fixes up the vmcs instead of restoring cr4
after the fact.  A subsequent patch will add a kernel-wide cr4 shadow,
reducing the overhead in the common case to just two memory reads and a
branch.
Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
Cc: stable@vger.kernel.org
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Gleb Natapov <gleb@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit e7dbfe34 ("kprobes/x86: Move ftrace-based kprobe code
into kprobes-ftrace.c") switched from using
ARCH_SUPPORTS_KPROBES_ON_FTRACE to CONFIG_KPROBES_ON_FTRACE but
missed removing the define.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: masami.hiramatsu.pt@hitachi.com
Cc: ananth@in.ibm.com
Cc: a.p.zijlstra@chello.nl
Cc: fweisbec@gmail.com
Cc: rostedt@goodmis.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Explicitly set the dr_mode for the second dwc3 controller on the
Arndale Octa board to host mode. This is required to ensure the
controller is initialized in the right mode if the kernel is build
with USB gadget support.
Reported-By: NAndreas Faerber <afaerber@suse.de>
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

In case the optional dr_mode property isn't set in the dwc3 nodes the
the controller will go into OTG mode if both USB host and USB gadget
functionality are enabled in the kernel configuration. Unfortunately
this results in USB not working on exynos5420-peach-pit and
exynos5800-peach-pi with such a kernel configuration unless manually
change the mode. To resolve that explicitly configure the dual role
mode as host.
Signed-off-by: NSjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: NAndreas Faerber <afaerber@suse.de>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

The EIRSR and ELRSR registers are 32-bit registers on GICv2, and we
store these as an array of two such registers on the vgic vcpu struct.
However, we access them as a single 64-bit value or as a bitmap pointer
in the generic vgic code, which breaks BE support.

Instead, store them as u64 values on the vgic structure and do the
word-swapping in the assembly code, which already handles the byte order
for BE systems.
Tested-by: NVictor Kamensky <victor.kamensky@linaro.org>
Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>

CM-QS600 is a APQ8064 based computer on module.
The details are available at
http://compulab.co.il/products/computer-on-modules/cm-qs600/Signed-off-by: NMike Rapoport <mike.rapoport@gmail.com>
Acked-by: NIgor Grinberg <grinberg@compulab.co.il>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

This DTS has support for the Sony Xperia Z1 phone (codenamed Honami).
This first version of the DTS supports just a serial console.
Signed-off-by: NTim Bird <tim.bird@sonymobile.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NKumar Gala <galak@codeaurora.org>

Add SATA PHY and SATA AHCI controller nodes to device tree to enable
generic ahci support on the IPQ8064/AP148 board.
Signed-off-by: NKumar Gala <galak@codeaurora.org>

Commit 0b0b0893 "of/pci: Fix the conversion of IO ranges into IO
resources" changed the behaviour of of_pci_range_to_resource().

Previously it simply populated the resource based on the arguments. Now
it calls pci_register_io_range() and pci_address_to_pio(). These both
have two implementations depending on whether PCI_IOBASE is defined,
which it is not for powerpc.

Further complicating matters, both routines are weak, and powerpc
implements it's own version of one - pci_address_to_pio(). However
powerpc's implementation depends on other initialisations which are done
later in boot.

The end result is incorrectly initialised IO space. Often we can get
away with that, because we don't make much use of IO space. However
virtio requires it, so we see eg:

  pci_bus 0000:00: root bus resource [io  0xffff] (bus address [0xffffffffffffffff-0xffffffffffffffff])
  PCI: Cannot allocate resource region 0 of device 0000:00:01.0, will remap
  virtio-pci 0000:00:01.0: can't enable device: BAR 0 [io  size 0x0020] not assigned

The simplest fix for now is to just stop using of_pci_range_to_resource(),
and open-code the original implementation, that's all we want it to do.

Fixes: 0b0b0893 ("of/pci: Fix the conversion of IO ranges into IO resources")
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>

Commit:
b8865767 ARM: KVM: user_mem_abort: support stage 2 MMIO page mapping

introduced some code in user_mem_abort that failed to compile if
STRICT_MM_TYPECHECKS was enabled.

This patch fixes up the failing comparison.
Signed-off-by: NSteve Capper <steve.capper@linaro.org>
Reviewed-by: NKim Phillips <kim.phillips@linaro.org>
Signed-off-by: NChristoffer Dall <christoffer.dall@linaro.org>