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

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

sparc: Don't do hypervisor calls on non-sun4v in DS driver.

2011-08-16T01:31:43+00:00

commit c92761fd9efcbbcb59e7bf4db88e29ce03229889 upstream.

Reported-by: Pieter-Paul Giesberts 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sparc: Size mondo queues more sanely.

2011-08-16T01:31:41+00:00

[ Upstream commit 961f65fc41cdc1f9099a6075258816c0db98e390 ]

There is currently no upper limit on the mondo queue sizes we'll use,
which guarentees that we'll eventually his page allocation limits, and
thus allocation failures, due to MAX_ORDER.

Cap the sizes sanely, current limits are:

CPU  MONDO	2 * max_possible_cpus
DEV  MONDO	256 (basically NR_IRQS)
RES  MONDO	128
NRES MONDO	4

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