linux-stable.git/arch/mips/include/asm, branch v3.16.45

MIPS: Fix special case in 64 bit IP checksumming.

2017-06-05T20:17:10+00:00

commit 66fd848cadaa6be974a8c780fbeb328f0af4d3bd upstream.

For certain arguments such as saddr = 0xc0a8fd60, daddr = 0xc0a8fda1,
len = 80, proto = 17, sum = 0x7eae049d there will be a carry when
folding the intermediate 64 bit checksum to 32 bit but the code doesn't
add the carry back to the one's complement sum, thus an incorrect result
will be generated.

Reported-by: Mark Zhang 
Signed-off-by: Ralf Baechle 
Reviewed-by: James Hogan 
Signed-off-by: James Hogan 
Signed-off-by: Ben Hutchings

MIPS: Zero variable read by get_user / __get_user in case of an error.

2017-04-04T21:21:56+00:00

commit 640465bda58c7078725201be7430c31a349121e9 upstream.

This wasn't happening in all cases.

Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings 
Cc: Arnd Bergmann

MIPS: wrap cfcmsa & ctcmsa accesses for toolchains with MSA support

2017-04-04T21:21:54+00:00

commit e1bebbab1eaecac77d77033010b5e0f51b737e64 upstream.

Uses of the cfcmsa & ctcmsa instructions were not being wrapped by a
macro in the case where the toolchain supports MSA, since the arguments
exactly match a typical use of the instructions. However using current
toolchains this leads to errors such as:

  arch/mips/kernel/genex.S:437: Error: opcode not supported on this processor: mips32r2 (mips32r2) `cfcmsa $5,1'

Thus uses of the instructions must be in the context of a ".set msa"
directive, however doing that from the users of the instructions would
be messy due to the possibility that the toolchain does not support
MSA. Fix this by renaming the macros (prepending an underscore) in order
to avoid recursion when attempting to emit the instructions, and provide
implementations for the TOOLCHAIN_SUPPORTS_MSA case which ".set msa" as
appropriate.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9163/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings

MIPS: remove MSA macro recursion

2017-04-04T21:21:54+00:00

commit a3a49810c55e3489dfb5d72a9b2e41ab1db9ffb9 upstream.

Recursive macros made the code more concise & worked great for the
case where the toolchain doesn't support MSA. However, with toolchains
which do support MSA they lead to build failures such as:

  arch/mips/kernel/r4k_switch.S: Assembler messages:
  arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[2],$1'
  arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w(0+1)[3],$1'
  arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[2],$1'
  arch/mips/kernel/r4k_switch.S:148: Error: invalid operands `insert.w $w((0+1)+1)[3],$1'
  ...

Drop the recursion from msa_init_all_upper invoking the msa_init_upper
macro explicitly for each vector register.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9162/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings

MIPS: assume at as source/dest of MSA copy/insert instructions

2017-04-04T21:21:54+00:00

commit f23ce3883a30743a5b779dc6fb90ca8620688a23 upstream.

Assuming at ($1) as the source or destination register of copy or
insert instructions:

  - Simplifies the macros providing those instructions for toolchains
    without MSA support.

  - Avoids an unnecessary move instruction when at is used as the source
    or destination register anyway.

  - Is sufficient for the uses to be introduced in the kernel by a
    subsequent patch.

Note that due to a patch ordering snafu on my part this also fixes the
currently broken build with MSA support enabled. The build has been
broken since commit c9017757c532 "MIPS: init upper 64b of vector
registers when MSA is first used", which this patch should have
preceeded.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9161/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings

MIPS: Push .set mips64r* into the functions needing it

2017-04-04T21:21:54+00:00

commit 631afc65e8f4f845945ef9e90236d10cee601498 upstream.

The {save,restore}_fp_context{,32} functions require that the assembler
allows the use of sdc instructions on any FP register, and this is
acomplished by setting the arch to mips64r2 or mips64r6
(using MIPS_ISA_ARCH_LEVEL_RAW).

However this has the effect of enabling the assembler to use mips64
instructions in the expansion of pseudo-instructions. This was done in
the (now-reverted) commit eec43a224cf1 "MIPS: Save/restore MSA context
around signals" which led to my mistakenly believing that there was an
assembler bug, when in reality the assembler was just emitting mips64
instructions. Avoid the issue for future commits which will add code to
r4k_fpu.S by pushing the .set MIPS_ISA_ARCH_LEVEL_RAW directives into
the functions that require it, and remove the spurious assertion
declaring the assembler bug.

Signed-off-by: Paul Burton 
[james.hogan@imgtec.com: Rebase on v4.0-rc1 and reword commit message to
 reflect use of MIPS_ISA_ARCH_LEVEL_RAW]
Signed-off-by: James Hogan 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9612/
Signed-off-by: Ralf Baechle 
[bwh: Backported to 3.16: in r4k_fpu.S, keep using arch=r4000]
Signed-off-by: Ben Hutchings

MIPS: mipsregs.h: Add write_32bit_cp1_register()

2017-04-04T21:21:53+00:00

commit 5e32033e14ca9c7f7341cb383f5a05699b0b5382 upstream.

Add a write_32bit_cp1_register() macro to compliment the
read_32bit_cp1_register() macro. This is to abstract whether .set
hardfloat needs to be used based on GAS_HAS_SET_HARDFLOAT.

The implementation of _read_32bit_cp1_register() .sets mips1 due to
failure of gas v2.19 to assemble cfc1 for Octeon (see commit
25c300030016 ("MIPS: Override assembler target architecture for
octeon.")). I haven't copied this over to _write_32bit_cp1_register() as
I'm uncertain whether it applies to ctc1 too, or whether anybody cares
about that version of binutils any longer.

Signed-off-by: James Hogan 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: David Daney 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9172/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings

MIPS: Fix build with binutils 2.24.51+

2017-04-04T21:21:53+00:00

commit 842dfc11ea9a21f9825167c8a4f2834b205b0a79 upstream.

Starting with version 2.24.51.20140728 MIPS binutils complain loudly
about mixing soft-float and hard-float object files, leading to this
build failure since GCC is invoked with "-msoft-float" on MIPS:

{standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
  LD      arch/mips/alchemy/common/built-in.o
mipsel-softfloat-linux-gnu-ld: Warning: arch/mips/alchemy/common/built-in.o
 uses -msoft-float (set by arch/mips/alchemy/common/prom.o),
 arch/mips/alchemy/common/sleeper.o uses -mhard-float

To fix this, we detect if GAS is new enough to support "-msoft-float" command
option, and if it does, we can let GCC pass it to GAS;  but then we also need
to sprinkle the files which make use of floating point registers with the
necessary ".set hardfloat" directives.

Signed-off-by: Manuel Lauss 
Cc: Linux-MIPS 
Cc: Matthew Fortune 
Cc: Markos Chandras 
Cc: Maciej W. Rozycki 
Patchwork: https://patchwork.linux-mips.org/patch/8355/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings 
Cc: Arnd Bergmann

MIPS: init upper 64b of vector registers when MSA is first used

2017-04-04T21:21:53+00:00

commit c9017757c532d48bf43d6e7d3b7282443ad4207b upstream.

When a task first makes use of MSA we need to ensure that the upper
64b of the vector registers are set to some value such that no
information can be leaked to it from the previous task to use MSA
context on the CPU. The architecture formerly specified that these
bits would be cleared to 0 when a scalar FP instructions wrote to the
aliased FP registers, which would have implicitly handled this as the
kernel restored scalar FP context. However more recent versions of the
specification now state that the value of the bits in such cases is
unpredictable. Initialise them explictly to be sure, and set all the
bits to 1 rather than 0 for consistency with the least significant
64b.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7497/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings 
Cc: Arnd Bergmann

MIPS: save/disable MSA in lose_fpu

2017-04-04T21:21:53+00:00

commit 33c771ba5c5d067f85a5a6c4b11047219b5b8f4e upstream.

The kernel depends upon MSA never being enabled when the FPU is not, a
condition which is currently violated in a few places (whilst saving
sigcontext, following mips_cpu_save). Catch all the problem cases by
disabling MSA in lose_fpu, after saving context if necessary.

Signed-off-by: Paul Burton 
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7302/
Signed-off-by: Ralf Baechle 
Signed-off-by: Ben Hutchings 
Cc: Arnd Bergmann