MMUv4 supports 2 concurrent page sizes: Normal and Super [4K to 16M]

So far Linux supported a single super page size for a given Normal page,
depending on the software page walking address split.
e.g. we had 11:8:13 address split for 8K page, which meant super page
was 2 ^(8+13) = 2M (given that THP size has to be PMD_SHIFT)

Now we turn this around, by allowing multiple Super Pages in Kconfig
(currently 2M and 16M only) and forcing page walker address split to
PGDIR_SHIFT and PAGE_SHIFT

For configs without Super page, things are same as before and
PGDIR_SHIFT can be hacked to get non default address split

The motivation for this change is a customer who needs 16M super page
and a 8K Normal page combo.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

ARC HS Cores support configurable multiple interrupt priorities of upto
16 levels.

There is processor "interrupt preemption threshhold" in STATUS32.E[4:1]
And several places need to set this up:
1. seed value as kernel is booting
2. seed value for user space programs
3. Arg to SLEEP instruction in idle task (what interrupt prio can wake)
4. Per-IRQ line prioirty (i.e. what is the priority of interrupt
   raised by a peripheral or timer or perf counter...

Currently above sites use the highest priority 0. This can be potential
problem when multiple priorities are supported. e.g. user space could
only be interrupted by P0 interrupt, not others...
So turn this over and instead make default interruption level to be
the lowest priority possible 15. This should be fine even if there are
fewer priority levels configured (say two: P0 HIGH, P1 LOW)

This feature also effectively disables FIRQ feature if present in
hardware config. With old code, a P0 interrupt would be FIRQ, needing
special handling (ISR or Register Banks) which is NOT supported yet.
Now it not be P0 (P15 or whatever is lowest prio) so FIRQ is not
triggered.
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

... it is now called Global Free Running Counter
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Returning to delay slot, riding an interrupti, had one loose end.
AUX_USER_SP used for restoring user mode SP upon RTIE was not being
setup from orig task's saved value, causing task to use wrong SP,
leading to ProtV errors.

The reason being:
 - INTERRUPT_EPILOGUE returns to a kernel trampoline, thus not expected to restore it
 - EXCEPTION_EPILOGUE is not used at all

Fix that by restoring AUX_USER_SP explicitly in the trampoline.

This was broken in the original workaround, but the error scenarios got
reduced considerably since v3.14 due to following:

 1. The Linuxthreads.old based userspace at the time caused many more
    exceptions in delay slot than the current NPTL based one.
    Infact with current userspace the error doesn't happen at all.

 2. Return from interrupt (delay slot or otherwise) doesn't get exercised much
    after commit 4de0e528 ("Really Re-enable interrupts to avoid deadlocks")
    since IRQ_ACTIVE.active being clear means most returns are as if from pure
    kernel (even for active interrupts)

Infact the issue only happened in an experimental branch where I was tinkering with
reverted 4de0e528

Cc: stable@kernel.org # v4.2+
Fixes: 4255b07f ("ARCv2: STAR 9000793984: Handle return from intr to Delay Slot")
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Since WM8650 has the same 'WMT' SDHC controller as WM8505, and the driver
is already in the kernel, this node enables the controller support for
WM8650
Signed-off-by: NRoman Volkov <rvolkov@v1ros.org>
Reviewed-by: NAlexey Charkov <alchark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Commit 69fb4dca ("power: Add an axp20x-usb-power driver") introduced a
new driver for the USB power supply used on various Allwinner based SBCs.
However, the driver was not added to multi_v7_defconfig which breaks USB
support for some boards (e.g. LeMaker BananaPi) as the kernel will now
turn off the USB power supply during boot by default if the driver isn't
present. (This was not the case in linux 4.3 or lower where the USB power
was always left on.)

Hence, add the driver to multi_v7_defconfig in order to keep USB support
working on those boards that require it.
Signed-off-by: NTimo Sigurdsson <public_timo.s@silentcreek.de>
Tested-by: NTimo Sigurdsson <public_timo.s@silentcreek.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

While setting the KVM PIT counters in 'kvm_pit_load_count', if
'hpet_legacy_start' is set, the function disables the timer on
channel[0], instead of the respective index 'channel'. This is
because channels 1-3 are not linked to the HPET.  Fix the caller
to only activate the special HPET processing for channel 0.
Reported-by: NP J P <pjp@fedoraproject.org>
Fixes: 0185604cSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Commit 0976c946
"arm/versatile: Fix versatile irq specifications"
has an off-by-one error on the Versatile AB that has
been regressing the Versatile AB hardware for some time.

However it seems like the interrupt assignments have
never been correct and I have now adjusted them according
to the specification. The masks for the valid interrupts
made it impossible to assign the right SIC interrupt
for the MMCI, so I went in and fixed these to correspond
to the specifications, and added references if anyone
wants to double-check.

Due to the Versatile PB including the Versatile AB
as a base DTS file, we need to override and correct
some values to correspond to the actual changes in the
hardware.

For the Versatile PB I don't think the IRQ line
assignment for MMCI has ever been correct for either of
the two MMCI blocks. It would be nice if someone with the
physical PB board could test this.

Patch tested on the Versatile AB, QEMU for Versatile AB
and QEMU for Versatile PB.

Cc: Rob Herring <robh@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: stable@vger.kernel.org
Fixes: 0976c946 ("arm/versatile: Fix versatile irq specifications")
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

The Nomadik has sporadic crashes because of these latencies, setting
them to max makes the platform work nicely, so use this values for
now.

These latencies were set to 2 since the Nomadik platform was merged,
but I suspect they never took effect until the right size and
associativity for the cache was specified in the device tree and
that is why the crash comes now.

Cc: stable@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Commit 63aa945b ("memory: omap-gpmc: Add Kconfig option for debug")
unified the GPMC debug for the SoCs with GPMC. The commit also left out
the option for HWMOD_INIT_NO_RESET as we now require proper timings for
GPMC to be able to remap GPMC devices out of address 0.

Unfortunately on Nokia N900, onenand now only partially works with the
device tree provided timings. It works enough to get detected but the
clock rate supported by the onenand chip gets misdetected. This in turn
causes the GPMC timings to be miscalculated and this leads into file
system corruption on N900.

Looks like onenand needs CS_CONFIG1 bit 27 WRITETYPE set for for sync
write. This is needed also for async timings when we write to onenand
with omap2_onenand_set_async_mode(). Without sync write bit set, the
async read for the onenand ONENAND_REG_VERSION_ID will return 0xfff.

Let's exit with an error if onenand rate is not detected. And let's
remove the extra call to omap2_onenand_set_async_mode() as we only need
to do this once at the end of omap2_onenand_setup_async().

Fixes: 63aa945b ("memory: omap-gpmc: Add Kconfig option for debug")
Cc: stable@vger.kernel.org # v4.2+
Reported-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: NIvaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The LSR instruction cannot be used to perform a zero right shift since a
0 as the immediate value (imm5) in the LSR instruction encoding means
that a shift of 32 is perfomed.  See DecodeIMMShift() in the ARM ARM.

Make the JIT skip generation of the LSR if a zero-shift is requested.

This was found using american fuzzy lop.
Signed-off-by: NRabin Vincent <rabin@rab.in>
Acked-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The SKF_AD_ALU_XOR_X ancillary is not like the other ancillary data
instructions since it XORs A with X while all the others replace A with
some loaded value.  All the BPF JITs fail to clear A if this is used as
the first instruction in a filter.  This was found using american fuzzy
lop.

Add a helper to determine if A needs to be cleared given the first
instruction in a filter, and use this in the JITs.  Except for ARM, the
rest have only been compile-tested.

Fixes: 34805931 ("net: filter: get rid of BPF_S_* enum")
Signed-off-by: NRabin Vincent <rabin@rab.in>
Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
Acked-by: NAlexei Starovoitov <ast@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This allows the build system to know that it can't attempt to
configure the Lustre virtual block device, for example, when tilepro
is using 64KB pages (as it does by default).  The tilegx build
already provided those symbols.

Previously we required that the tilepro hypervisor be rebuilt with
a different hardcoded page size in its headers, and then Linux be
rebuilt using the updated hypervisor header.  Now we allow each of
the hypervisor and Linux to be built independently.  We still check
at boot time to ensure that the page size provided by the hypervisor
matches what Linux expects.
Signed-off-by: NChris Metcalf <cmetcalf@ezchip.com>
Cc: stable@vger.kernel.org [3.19+]

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The GLIBC folks would like to eliminate socketcall support
eventually, and this makes sense regardless so wire them
all up.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 69fb4dca ("power: Add an axp20x-usb-power driver") introduced a new
driver for the USB power supply used on various Allwinner based SBCs. However,
the driver was not added to sunxi_defconfig which breaks USB support for some
boards (e.g. LeMaker BananaPi) as the kernel will now turn off the USB power
supply during boot by default if the driver isn't present. (This was not the
case in linux 4.3 or lower where the USB power was always left on.)

Hence, add the driver to sunxi_defconfig in order to keep USB support working
on those boards that require it.
Signed-off-by: NTimo Sigurdsson <public_timo.s@silentcreek.de>
Reported-by: NDavid Tulloh <david@tulloh.id.au>
Tested-by: NDavid Tulloh <david@tulloh.id.au>
Tested-by: NTimo Sigurdsson <public_timo.s@silentcreek.de>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>

The MMCFG PCI accessors weren't being setup for NumacConnect2
correctly due to over-early assignment; this would create the
potential for the wrong PCI domain to be accessed.

Fix this by using the correct arch-specific PCI init function.
Signed-off-by: NDaniel J Blueman <daniel@numascale.com>
Acked-by: NSteffen Persvold <sp@numascale.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/1451498807-15920-1-git-send-email-daniel@numascale.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

m32r allmodconfig was failing with the error:

  error: implicit declaration of function 'read'

On checking io.h it turned out that 'read' is not defined but 'readb' is
defined and 'ioread8' will then obviously mean 'readb'.

At the same time some of the helper functions ioreadN_rep() and
iowriteN_rep() were missing which also led to the build failure.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

m32r allmodconfig is failing with:

  In file included from ../include/linux/kvm_para.h:4:0,
                   from ../kernel/watchdog.c:26:
  ../include/uapi/linux/kvm_para.h:30:26: fatal error: asm/kvm_para.h: No such file or directory

kvm_para.h was not included in the build.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the build warning:

  arch/x86/xen/suspend.c: In function 'xen_arch_pre_suspend':
  arch/x86/xen/suspend.c:70:9: error: implicit declaration of function 'xen_pv_domain' [-Werror=implicit-function-declaration]
          if (xen_pv_domain())
              ^
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 2a037f31 ("MIPS: VDSO: Fix build error") tries to fix a build
error seen with binutils 2.24 and earlier. However, the fix does not work,
and again results in the already known build errors if the kernel is built
with an earlier version of binutils.

CC      arch/mips/vdso/gettimeofday.o
/tmp/ccnOVbHT.s: Assembler messages:
/tmp/ccnOVbHT.s:50: Error: can't resolve `_start' {*UND* section} - `L0 {.text section}
/tmp/ccnOVbHT.s:374: Error: can't resolve `_start' {*UND* section} - `L0 {.text section}
scripts/Makefile.build:258: recipe for target 'arch/mips/vdso/gettimeofday.o' failed
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1

Fixes: 2a037f31 ("MIPS: VDSO: Fix build error")
Cc: Qais Yousef <qais.yousef@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/11926/Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Cc: stable@vger.kernel.org # 3.15+
Reviewed-by: NJeff Layton <jeff.layton@primarydata.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Short story: Exception handlers used by some copy_to_user() and
copy_from_user() functions do not diligently clean up floating point
register usage, and this can result in a user process seeing invalid
values in floating point registers. This sometimes makes the process
fail.

Long story: Several cpu-specific (NG4, NG2, U1, U3) memcpy functions
use floating point registers and VIS alignaddr/faligndata to
accelerate data copying when source and dest addresses don't align
well. Linux uses a lazy scheme for saving floating point registers; It
is not done upon entering the kernel since it's a very expensive
operation. Rather, it is done only when needed. If the kernel ends up
not using FP regs during the course of some trap or system call, then
it can return to user space without saving or restoring them.

The various memcpy functions begin their FP code with VISEntry (or a
variation thereof), which saves the FP regs. They conclude their FP
code with VISExit (or a variation) which essentially marks the FP regs
"clean", ie, they contain no unsaved values. fprs.FPRS_FEF is turned
off so that a lazy restore will be triggered when/if the user process
accesses floating point regs again.

The bug is that the user copy variants of memcpy, copy_from_user() and
copy_to_user(), employ an exception handling mechanism to detect faults
when accessing user space addresses, and when this handler is invoked,
an immediate return from the function is forced, and VISExit is not
executed, thus leaving the fprs register in an indeterminate state,
but often with fprs.FPRS_FEF set and one or more dirty bits. This
results in a return to user space with invalid values in the FP regs,
and since fprs.FPRS_FEF is on, no lazy restore occurs.

This bug affects copy_to_user() and copy_from_user() for NG4, NG2,
U3, and U1. All are fixed by using a new exception handler for those
loads and stores that are done during the time between VISEnter and
VISExit.

n.b. In NG4memcpy, the problematic code can be triggered by a copy
size greater than 128 bytes and an unaligned source address.  This bug
is known to be the cause of random user process memory corruptions
while perf is running with the callgraph option (ie, perf record -g).
This occurs because perf uses copy_from_user() to read user stacks,
and may fault when it follows a stack frame pointer off to an
invalid page. Validation checks on the stack address just obscure
the underlying problem.
Signed-off-by: NRob Gardner <rob.gardner@oracle.com>
Signed-off-by: NDave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There have been several reports of random processes being killed with
a bus error or segfault during userspace stack walking in perf.  One
of the root causes of this problem is an asynchronous modification to
thread_info fault_address and fault_code, which stems from a perf
counter interrupt arriving during kernel processing of a "benign"
fault, such as a TSB miss. Since perf_callchain_user() invokes
copy_from_user() to read user stacks, a fault is not only possible,
but probable. Validity checks on the stack address merely cover up the
problem and reduce its frequency.

The solution here is to save and restore fault_address and fault_code
in perf_callchain_user() so that the benign fault handler is not
disturbed by a perf interrupt.
Signed-off-by: NRob Gardner <rob.gardner@oracle.com>
Signed-off-by: NDave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When an interrupt (such as a perf counter interrupt) is delivered
while executing in user space, the trap entry code puts ASI_AIUS in
%asi so that copy_from_user() and copy_to_user() will access the
correct memory. But if a perf counter interrupt is delivered while the
cpu is already executing in kernel space, then the trap entry code
will put ASI_P in %asi, and this will prevent copy_from_user() from
reading any useful stack data in either of the perf_callchain_user_X
functions, and thus no user callgraph data will be collected for this
sample period. An additional problem is that a fault is guaranteed
to occur, and though it will be silently covered up, it wastes time
and could perturb state.

In perf_callchain_user(), we ensure that %asi contains ASI_AIUS
because we know for a fact that the subsequent calls to
copy_from_user() are intended to read the user's stack.

[ Use get_fs()/set_fs() -DaveM ]
Signed-off-by: NRob Gardner <rob.gardner@oracle.com>
Signed-off-by: NDave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 28a1f533 delays setting %pil to avoid potential
hardirq stack overflow in the common rtrap_irq path.
Setting %pil also needs to be delayed in the rtrap_nmi
path for the same reason.
Signed-off-by: NRob Gardner <rob.gardner@oracle.com>
Signed-off-by: NDave Aldridge <david.j.aldridge@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add ADI (Application Data Integrity) capability to cpu capabilities list.
ADI capability allows virtual addresses to be encoded with a tag in
bits 63-60. This tag serves as an access control key for the regions
of virtual address with ADI enabled and a key set on them. Hypervisor
encodes this capability as "adp" in "hwcap-list" property in machine
description.
Signed-off-by: NKhalid Aziz <khalid.aziz@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

After hooking up system call, userfaultfd selftest was successful for
both 32 and 64 bit version of test.
Signed-off-by: NMike Kravetz <mike.kravetz@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Enabling CPUFreq support for Tegra124 Chromebooks is causing the Tegra124
to hang when resuming from suspend.

When CPUFreq is enabled, the CPU clock is changed from the PLLX clock to
the DFLL clock during kernel boot. When resuming from suspend the CPU
clock is temporarily changed back to the PLLX clock before switching back
to the DFLL. If the DFLL is operating at a much lower frequency than the
PLLX when we enter suspend, and so the CPU voltage rail is at a voltage
too low for the CPUs to operate at the PLLX frequency, then the device
will hang.

Please note that the PLLX is used in the resume sequence to switch the CPU
clock from the very slow 32K clock to a faster clock during early resume
to speed up the resume sequence before the DFLL is resumed.

Ideally, we should fix this by setting the suspend frequency so that it
matches the PLLX frequency, however, that would be a bigger change. For
now simply disable CPUFreq support for Tegra124 Chromebooks to avoid the
hang when resuming from suspend.

Fixes: 9a0baee9 ("ARM: tegra: Enable CPUFreq support for Tegra124
		      Chromebooks")
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

Fix a pointer cast typo introduced in v4.4-rc5 especially visible for
the i386 subarchitecture where it results in a kernel crash.

[ Also removed pointless cast as per Al Viro - Linus ]

Fixes: 8090bfd2 ("um: Fix fpstate handling")
Signed-off-by: NMickaël Salaün <mic@digikod.net>
Cc: Jeff Dike <jdike@addtoit.com>
Acked-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Currently if userspace restores the pit counters with a count of 0
on channels 1 or 2 and the guest attempts to read the count on those
channels, then KVM will perform a mod of 0 and crash.  This will ensure
that 0 values are converted to 65536 as per the spec.

This is CVE-2015-7513.
Signed-off-by: NAndy Honig <ahonig@google.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Virtual machines can be run with CPUID such that there are no MTRRs.
In that case, the firmware will never enable MTRRs and it is obviously
undesirable to run the guest entirely with UC memory.  Check out guest
CPUID, and use WB memory if MTRR do not exist.

Cc: qemu-stable@nongnu.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Conversion of MTRRs to ranges used the maxphyaddr from the boot CPU.
This is wrong, because var_mtrr_range's mask variable then is discontiguous
(like FF00FFFF000, where the first run of 0s corresponds to the bits
between host and guest maxphyaddr).  Instead always set up the masks
to be full 64-bit values---we know that the reserved bits at the top
are zero, and we can restore them when reading the MSR.  This way
var_mtrr_range gets a mask that just works.

Fixes: a13842dc
Cc: qemu-stable@nongnu.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This fixes the slow-down of VM running with pci-passthrough, since some MTRR
range changed from MTRR_TYPE_WRBACK to MTRR_TYPE_UNCACHABLE.  Memory in the
0K-640K range was incorrectly treated as uncacheable.

Fixes: f7bfb57b
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=107561
Cc: qemu-stable@nongnu.org
Signed-off-by: NAlexis Dambricourt <alexis.dambricourt@gmail.com>
[Use correct BZ for "Fixes" annotation.  - Paolo]
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

c861519f ("MIPS: Fix delay loops which may
be removed by GCC.") which made it upstream was an outdated version of the
patch and is lacking some the removal of two variables that became unused
thus resulting in further warnings and build breakage.  The commit
from ae878615d7cee5d7346946cf1ae1b60e427013c2 was correct however.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Commit ebb5e78c ("MIPS: Initial implementation of a VDSO") introduced a
build error.

For MIPS VDSO to be compiled it requires binutils version 2.25 or above but
the check in the Makefile had inverted logic causing it to be compiled in if
binutils is below 2.25.

This fixes the following compilation error:

CC      arch/mips/vdso/gettimeofday.o
/tmp/ccsExcUd.s: Assembler messages:
/tmp/ccsExcUd.s:62: Error: can't resolve `_start' {*UND* section} - `L0' {.text section}
/tmp/ccsExcUd.s:467: Error: can't resolve `_start' {*UND* section} - `L0' {.text section}
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1
make[1]: *** [arch/mips/vdso] Error 2
make: *** [arch/mips] Error 2

[ralf@linux-mips: Fixed Sergei's complaint on the formatting of the
cited commit and generally reformatted the log message.]
Signed-off-by: NQais Yousef <qais.yousef@imgtec.com>
Cc: alex@alex-smith.me.uk
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/11745/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Commit 977e043d ("MIPS: kernel: cps-vec: Replace mips32r2 ISA level
with mips64r2") leads to .set mips64r2 directives being present in 32
bit (ie. CONFIG_32BIT=y) kernels. This is incorrect & leads to MIPS64
instructions being emitted by the assembler when expanding
pseudo-instructions. For example the "move" instruction can legitimately
be expanded to a "daddu". This causes problems when the kernel is run on
a MIPS32 CPU, as CONFIG_32BIT kernels of course often are...

Fix this by dropping the .set <ISA> directives entirely now that Kconfig
should be ensuring that kernels including this code are built with a
suitable -march= compiler flag.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: <stable@vger.kernel.org> # 3.16+
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/10869/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>