linux-toradex.git/arch/sparc, 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

sparc32: Correct the return value of memcpy.

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

[ Upstream commit a52312b88c8103e965979a79a07f6b34af82ca4b ]

Properly return the original destination buffer pointer.

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

sparc32: Remove uses of %g7 in memcpy implementation.

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

[ Upstream commit 21f74d361dfd6a7d0e47574e315f780d8172084a ]

This is setting things up so that we can correct the return
value, so that it properly returns the original destination
buffer pointer.

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

sparc32: Remove non-kernel code from memcpy implementation.

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

[ Upstream commit 045b7de9ca0cf09f1adc3efa467f668b89238390 ]

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

sparc: Kill custom io_remap_pfn_range().

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

[ Upstream commit 3e37fd3153ac95088a74f5e7c569f7567e9f993a ]

To handle the large physical addresses, just make a simple wrapper
around remap_pfn_range() like MIPS does.

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

sparc32: Be less strict in matching %lo part of relocation.

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

[ Upstream commit b1f44e13a525d2ffb7d5afe2273b7169d6f2222e ]

The "(insn & 0x01800000) != 0x01800000" test matches 'restore'
but that is a legitimate place to see the %lo() part of a 32-bit
symbol relocation, particularly in tail calls.

Signed-off-by: David S. Miller 
Tested-by: Sergei Trofimovich 
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: Force the execute bit in OpenFirmware's translation entries.

2011-10-16T21:14:51+00:00

In the OF 'translations' property, the template TTEs in the mappings
never specify the executable bit.  This is the case even though some
of these mappings are for OF's code segment.

Therefore, we need to force the execute bit on in every mapping.

This problem can only really trigger on Niagara/sun4v machines and the
history behind this is a little complicated.

Previous to sun4v, the sun4u TTE entries lacked a hardware execute
permission bit.  So OF didn't have to ever worry about setting
anything to handle executable pages.  Any valid TTE loaded into the
I-TLB would be respected by the chip.

But sun4v Niagara chips have a real hardware enforced executable bit
in their TTEs.  So it has to be set or else the I-TLB throws an
instruction access exception with type code 6 (protection violation).

We've been extremely fortunate to not get bitten by this in the past.

The best I can tell is that the OF's mappings for it's executable code
were mapped using permanent locked mappings on sun4v in the past.
Therefore, the fact that we didn't have the exec bit set in the OF
translations we would use did not matter in practice.

Thanks to Greg Onufer for helping me track this down.

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