linux-toradex.git/arch/arm/kernel/smp.c, branch v4.3.2

Merge branch 'nmi' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

2015-09-08T19:28:10+00:00

Pull NMI backtrace update from Russell King:
 "These changes convert the x86 NMI handling to be a library
  implementation which other architectures can make use of.  Thomas
  Gleixner has reviewed and tested these changes, and wishes me to send
  these rather than taking them through the tip tree.

  The final patch in the set adds an initial implementation using this
  infrastructure to ARM, even though it doesn't send the IPI at "NMI"
  level.  Patches are in progress to add the ARM equivalent of NMI, but
  we still need the IRQ-level fallback for systems where the "NMI" isn't
  available due to secure firmware denying access to it"

* 'nmi' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: add basic support for on-demand backtrace of other CPUs
  nmi: x86: convert to generic nmi handler
  nmi: create generic NMI backtrace implementation

Merge branches 'cleanup', 'fixes', 'misc', 'omap-barrier' and 'uaccess' into for-linus

2015-09-03T14:28:37+00:00

ARM: 8421/1: smp: Collapse arch_cpu_idle_dead() into cpu_die()

2015-08-25T17:19:19+00:00

The only caller of cpu_die() on ARM is arch_cpu_idle_dead(), so
let's simplify the code by renaming cpu_die() to
arch_cpu_idle_dead(). While were here, drop the __ref annotation
because __cpuinit is gone nowadays.

Signed-off-by: Stephen Boyd 
Signed-off-by: Russell King

ARM: 8392/3: smp: Only expose /sys/.../cpuX/online if hotpluggable

2015-07-31T17:58:30+00:00

Writes to /sys/.../cpuX/online fail if we determine the platform
doesn't support hotplug for that CPU. Furthermore, if the cpu_die
op isn't specified the system hangs when we try to offline a CPU
and it comes right back online unexpectedly. Let's figure this
stuff out before we make the sysfs nodes so that the online file
doesn't even exist if it isn't (at least sometimes) possible to
hotplug the CPU.

Add a new 'cpu_can_disable' op and repoint all 'cpu_disable'
implementations at it because all implementers use the op to
indicate if a CPU can be hotplugged or not in a static fashion.
With PSCI we may need to add a 'cpu_disable' op so that the
secure OS can be migrated off the CPU we're trying to hotplug.
In this case, the 'cpu_can_disable' op will indicate that all
CPUs are hotpluggable by returning true, but the 'cpu_disable' op
will make a PSCI migration call and occasionally fail, denying
the hotplug of a CPU. This shouldn't be any worse than x86 where
we may indicate that all CPUs are hotpluggable but occasionally
we can't offline a CPU due to check_irq_vectors_for_cpu_disable()
failing to find a CPU to move vectors to.

Cc: Mark Rutland 
Cc: Nicolas Pitre 
Cc: Dave Martin 
Acked-by: Simon Horman  [shmobile portion]
Tested-by: Simon Horman 
Cc: Magnus Damm 
Cc: 
Tested-by: Tyler Baker 
Cc: Geert Uytterhoeven 
Signed-off-by: Stephen Boyd 
Signed-off-by: Russell King

ARM: add basic support for on-demand backtrace of other CPUs

2015-07-17T11:23:30+00:00

As we now have generic infrastructure to support backtracing of other
CPUs in the system on lockups, we can start to implement this for ARM.
Initially, we add an IPI based implementation, as the GIC code needs
modification to support the generation of FIQ IPIs, and not all ARM
platforms have the ability to raise a FIQ in the non-secure world.

This provides us with a "best efforts" implementation in the absence
of FIQs.

Signed-off-by: Russell King

Merge branches 'fixes' and 'ioremap' into for-linus

2015-07-07T11:35:33+00:00

ARM: 8393/1: smp: Fix suspicious RCU usage with ipi tracepoints

2015-06-29T10:02:55+00:00

John Stultz reports an RCU splat on boot with ARM ipi trace
events enabled.

===============================
[ INFO: suspicious RCU usage. ]
4.1.0-rc7-00033-gb5bed2f #153 Not tainted
-------------------------------
include/trace/events/ipi.h:68 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
no locks held by swapper/0/0.

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.1.0-rc7-00033-gb5bed2f #153
Hardware name: Qualcomm (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x70/0xbc)
[] (dump_stack) from [] (handle_IPI+0x428/0x604)
[] (handle_IPI) from [] (gic_handle_irq+0x54/0x5c)
[] (gic_handle_irq) from [] (__irq_svc+0x44/0x7c)
Exception stack(0xc09f3f48 to 0xc09f3f90)
3f40:                   00000001 00000001 00000000 c09f73b8 c09f4528 c0a5de9c
3f60: c076b4f0 00000000 00000000 c09ef108 c0a5cec1 00000001 00000000 c09f3f90
3f80: c026bf60 c0210ab8 20000113 ffffffff
[] (__irq_svc) from [] (arch_cpu_idle+0x20/0x3c)
[] (arch_cpu_idle) from [] (cpu_startup_entry+0x2c0/0x5dc)
[] (cpu_startup_entry) from [] (start_kernel+0x358/0x3c4)
[] (start_kernel) from [<8020807c>] (0x8020807c)

At this point in the IPI handling path we haven't called
irq_enter() yet, so RCU doesn't know that we're about to exit
idle and properly warns that we're using RCU from an idle CPU.
Use trace_ipi_entry_rcuidle() instead of trace_ipi_entry() so
that RCU is informed about our exit from idle.

Fixes: 365ec7b17327 ("ARM: add IPI tracepoints")
Reported-by: John Stultz 
Tested-by: John Stultz 
Acked-by: Steven Rostedt 
Reviewed-by: Paul E. McKenney 
Signed-off-by: Stephen Boyd 
Signed-off-by: Russell King

ARM: redo TTBR setup code for LPAE

2015-06-01T22:48:19+00:00

Re-engineer the LPAE TTBR setup code.  Rather than passing some shifted
address in order to fit in a CPU register, pass either a full physical
address (in the case of r4, r5 for TTBR0) or a PFN (for TTBR1).

This removes the ARCH_PGD_SHIFT hack, and the last dangerous user of
cpu_set_ttbr() in the secondary CPU startup code path (which was there
to re-set TTBR1 to the appropriate high physical address space on
Keystone2.)

Tested-by: Murali Karicheri 
Signed-off-by: Russell King

ARM: 8338/1: kexec: Relax SMP validation to improve DT compatibility

2015-04-02T08:59:43+00:00

When trying to kexec into a new kernel on a platform where multiple CPU
cores are present, but no SMP bringup code is available yet, the
kexec_load system call fails with:

    kexec_load failed: Invalid argument

The SMP test added to machine_kexec_prepare() in commit 2103f6cba61a8b8b
("ARM: 7807/1: kexec: validate CPU hotplug support") wants to prohibit
kexec on SMP platforms where it cannot disable secondary CPUs.
However, this test is too strict: if the secondary CPUs couldn't be
enabled in the first place, there's no need to disable them later at
kexec time.  Hence skip the test in the absence of SMP bringup code.

This allows to add all CPU cores to the DTS from the beginning, without
having to implement SMP bringup first, improving DT compatibility.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Stephen Warren 
Signed-off-by: Russell King

Revert "ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo"

2015-01-04T19:39:59+00:00

Commit 9fc2105aeaaf ("ARM: 7830/1: delay: don't bother reporting
bogomips in /proc/cpuinfo") breaks audio in python, and probably
elsewhere, with message

  FATAL: cannot locate cpu MHz in /proc/cpuinfo

I'm not the first one to hit it, see for example

  https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/
  https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1

Reading original changelog, I have to say "Stop breaking working setups.
You know who you are!".

Signed-off-by: Pavel Machek 
Signed-off-by: Linus Torvalds