linux-toradex.git/arch/sparc/kernel, branch v3.0.29

sparc64: Fix bootup crash on sun4v.

2012-04-22T23:21:24+00:00

commit 9e0daff30fd7ecf698e5d20b0fa7f851e427cca5 upstream.

The DS driver registers as a subsys_initcall() but this can be too
early, in particular this risks registering before we've had a chance
to allocate and setup module_kset in kernel/params.c which is
performed also as a subsyts_initcall().

Register DS using device_initcall() insteal.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Eliminate obsolete __handle_softirq() function

2012-04-22T23:21:24+00:00

commit 3d3eeb2ef26112a200785e5fca58ec58dd33bf1e upstream.

The invocation of softirq is now handled by irq_exit(), so there is no
need for sparc64 to invoke it on the trap-return path.  In fact, doing so
is a bug because if the trap occurred in the idle loop, this invocation
can result in lockdep-RCU failures.  The problem is that RCU ignores idle
CPUs, and the sparc64 trap-return path to the softirq handlers fails to
tell RCU that the CPU must be considered non-idle while those handlers
are executing.  This means that RCU is ignoring any RCU read-side critical
sections in those handlers, which in turn means that RCU-protected data
can be yanked out from under those read-side critical sections.

The shiny new lockdep-RCU ability to detect RCU read-side critical sections
that RCU is ignoring located this problem.

The fix is straightforward: Make sparc64 stop manually invoking the
softirq handlers.

Reported-by: Meelis Roos 
Suggested-by: David Miller 
Signed-off-by: Paul E. McKenney 
Tested-by: Meelis Roos 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Fix handling of orig_i0 wrt. debugging when restarting syscalls.

2012-01-06T22:14:05+00:00

[ A combination of upstream commits 1d299bc7732c34d85bd43ac1a8745f5a2fed2078 and
  e88d2468718b0789b4c33da2f7e1cef2a1eee279 ]

Although we provide a proper way for a debugger to control whether
syscall restart occurs, we run into problems because orig_i0 is not
saved and restored properly.

Luckily we can solve this problem without having to make debuggers
aware of the issue.  Across system calls, several registers are
considered volatile and can be safely clobbered.

Therefore we use the pt_regs save area of one of those registers, %g6,
as a place to save and restore orig_i0.

Debuggers transparently will do the right thing because they save and
restore this register already.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix masking and shifting in VIS fpcmp emulation.

2012-01-06T22:14:04+00:00

[ Upstream commit 2e8ecdc008a16b9a6c4b9628bb64d0d1c05f9f92 ]

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Patch sun4v code sequences properly on module load.

2012-01-06T22:14:02+00:00

[ Upstream commit 0b64120cceb86e93cb1bda0dc055f13016646907 ]

Some of the sun4v code patching occurs in inline functions visible
to, and usable by, modules.

Therefore we have to patch them up during module load.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Fix MSIQ HV call ordering in pci_sun4v_msiq_build_irq().

2012-01-06T22:14:01+00:00

[ Upstream commit 7cc8583372a21d98a23b703ad96cab03180b5030 ]

This silently was working for many years and stopped working on
Niagara-T3 machines.

We need to set the MSIQ to VALID before we can set it's state to IDLE.

On Niagara-T3, setting the state to IDLE first was causing HV_EINVAL
errors.  The hypervisor documentation says, rather ambiguously, that
the MSIQ must be "initialized" before one can set the state.

I previously understood this to mean merely that a successful setconf()
operation has been performed on the MSIQ, which we have done at this
point.  But it seems to also mean that it has been set VALID too.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc64: Only Panther cheetah+ chips have POPC.

2011-10-03T18:40:02+00:00

commit 1a8e0da5937a6c87807083baa318cf8f98dac9aa upstream.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc32,sun4d: Change IPI IRQ level to prevent collision between IPI and timer interrupt

2011-10-03T18:40:01+00:00

commit 38f7f8f05e8239e9871f7e1c4b0a842080e85315 upstream.

On Sun4d systems running in SMP mode, IRQ 14 is used for timer interrupts
and has a specialized interrupt handler. IPI is currently set to use IRQ 14
as well, which causes it to trigger the timer interrupt handler, and not the
IPI interrupt handler.

The IPI interrupt is therefore changed to IRQ 13, which is the highest
normally handled interrupt. This IRQ is also used for SBUS interrupts,
however there is nothing in the IPI/SBUS interrupt handlers that indicate
that they will not handle sharing the interrupt.
(IRQ 13 is indicated as audio interrupt, which is unlikely to be found in a
sun4d system)

Signed-off-by: Kjetil Oftedal 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: fix array bounds error setting up PCIC NMI trap

2011-10-03T18:40:01+00:00

commit 4a0342ca8e8150bd47e7118a76e300692a1b6b7b upstream.

  CC      arch/sparc/kernel/pcic.o
arch/sparc/kernel/pcic.c: In function 'pcic_probe':
arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds]
arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds]
cc1: all warnings being treated as errors

I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via
the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear
to be 4 instructions long and I presume from the usage that instructions are
int sized.

Signed-off-by: Ian Campbell 
Cc: "David S. Miller" 
Cc: sparclinux@vger.kernel.org
Reviewed-by: Sam Ravnborg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Allow handling signals when stack is corrupted.

2011-10-03T18:39:59+00:00

commit 5598473a5b40c47a8c5349dd2c2630797169cf1a upstream.

If we can't push the pending register windows onto the user's stack,
we disallow signal delivery even if the signal would be delivered on a
valid seperate signal stack.

Add a register window save area in the signal frame, and store any
unsavable windows there.

On sigreturn, if any windows are still queued up in the signal frame,
try to push them back onto the stack and if that fails we kill the
process immediately.

This allows the debug/tst-longjmp_chk2 glibc test case to pass.

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman