When starting secondary VPEs which support EVA and the SegCtl registers,
copy the memory segmentation configuration from the running VPE to ensure
that all VPEs in the core have a consistent virtual memory map.

The EVA configuration of secondary cores is dealt with when starting the
core via the CM.
Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13291/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The SegCtl registers are standard for MIPSr3..MIPSr5. Add definitions of
these registers and use them rather than constants
Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Cc: Joshua Kinard <kumba@gentoo.org>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Chris Packham <judge.packham@gmail.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13290/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Commit 12822570 ("MIPS: Separate XPA CPU feature into LPA and MVH")
wasn't fully applied, possibly due to a conflict with commit
f270d881 ("MIPS: Detect MIPSr6 Virtual Processor support"). This
left decode_config5() referring to the non-existent MIPS_CPU_XPA, which
breaks the build when XPA is enabled:

arch/mips/kernel/cpu-probe.c In function ‘decode_config5’:
arch/mips/kernel/cpu-probe.c:838:17: error: ‘MIPS_CPU_XPA’ undeclared (first use in this function)
   c->options |= MIPS_CPU_XPA;
                    ^

Apply the missing hunk, dropping the CONFIG_XPA ifdef and setting the
MIPS_CPU_MVH option when Config5.MVH is set.

Fixes: 12822570 ("MIPS: Separate XPA CPU feature into LPA and MVH")
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Link: https://patchwork.linux-mips.org/patch/13112/
Patchwork: https://patchwork.linux-mips.org/patch/13277/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

When using an external interrupt controller (EIC) the interrupt mask
bits in the cop0 Status register are reused for the Interrupt Priority
Level, and any interrupts with a priority lower than the field will be
ignored. Clear the field to 0 by default such that all interrupts are
serviced.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Reviewed-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Tested-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Cc: Qais Yousef <qsyousef@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13273/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

When using an external interrupt controller (EIC) the interrupt mask
bits in the cop0 Status register are reused for the Interrupt Priority
Level, and any interrupts with a priority lower than the field will be
ignored. Clear the field to 0 by default such that all interrupts are
serviced. Without doing so we default to arbitrarily ignoring all or
some subset of interrupts.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Reviewed-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Tested-by: NMatt Redfearn <matt.redfearn@imgtec.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Joe Perches <joe@perches.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13272/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

PIC32 clock driver is now implemented as platform driver instead of
as part of of_clk_init(). It meants all the clock modules are available
quite late in the boot sequence. So request for CPU clock by clk_get_sys()
and clk_get_rate() to find c0_timer rate fails.

To fix this use PIC32 specific early clock functions implemented for early
console support.
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: Joshua Henderson <digitalpeer@digitalpeer.com>
Patchwork: https://patchwork.linux-mips.org/patch/13262/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

ath79_ddr_pci_win_base has the type void __iomem *, so register offsets
need to be a multiple of 4.

Cc: Alban Bedel <albeu@free.fr>
Fixes: 24b0e3e8 ("MIPS: ath79: Improve the DDR controller interface")
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Cc: sergei.shtylyov@cogentembedded.com
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13258/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

AR913x, AR724x and AR933x are the only SoCs where the
ath79_ddr_wb_flush_base starts at 0x7c, all newer SoCs use 0x9c
Invert the logic to make the code compatible with AR95xx
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Cc: albeu@free.fr
Cc: sergei.shtylyov@cogentembedded.com
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13257/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The VZ guest register & TLB access macros introduced in commit "MIPS:
Add guest CP0 accessors" use VZ ASE specific instructions that aren't
understood by versions of binutils prior to 2.24.

Add a check for whether the toolchain supports the -mvirt option,
similar to the MSA toolchain check, and implement the accessors using
.word if not.

Due to difficulty in converting compiler specified registers (e.g. "$3")
to usable numbers (e.g. "3") in inline asm, we need to copy to/from a
temporary register, namely the assembler temporary (at/$1), and specify
guest CP0 registers numerically in the gc0 macros.

Fixes: 7eb91118 ("MIPS: Add guest CP0 accessors")
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reported-by: NGuenter Roeck <linux@roeck-us.net>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-next@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13255/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Fix perf hardware performance counter event numbers for I6400. This core
does not follow the performance event numbering scheme of previous MIPS
cores. All performance counters (both odd and even) are capable of
counting any of the available events.

Fixes: 4e88a862 ("MIPS: Add cases for CPU_I6400")
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13259/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Fix a modular `declance' regression caused by LMO commit bb46bf30d13f
("DECstation SCSI driver clean-ups.")
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13256/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Fix a build regression from commit c9017757 ("MIPS: init upper 64b
of vector registers when MSA is first used"):

arch/mips/built-in.o: In function `enable_restore_fp_context':
traps.c:(.text+0xbb90): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbb90): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'
traps.c:(.text+0xbef0): undefined reference to `_init_msa_upper'
traps.c:(.text+0xbef0): relocation truncated to fit: R_MIPS_26 against `_init_msa_upper'

to !CONFIG_CPU_HAS_MSA configurations with older GCC versions, which are
unable to figure out that calls to `_init_msa_upper' are indeed dead.
Of the many ways to tackle this failure choose the approach we have
already taken in `thread_msa_context_live'.

[ralf@linux-mips.org: Drop patch segment to junk file.]
Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: stable@vger.kernel.org # v3.16+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13271/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Fix mips_cm_lock_other compilation error when MIPS_CM is not selected.
This was introduced in commit 23d5de8e (MIPS: CM: Introduce core-other
locking functions)
Signed-off-by: NTony Wu <tung7970@gmail.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/11698/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The genvdso program modifies the debug and stripped versions of the
VDSOs in place, and errors if the modification has already taken place.
Unfortunately this means that a rebuild which tries to rerun genvdso to
generate vdso*-image.c without also rebuilding vdso.so.dbg (for example
if genvdso.c is modified) hits a build error like this:

arch/mips/vdso/genvdso 'arch/mips/vdso/vdso.so.dbg' already contains a '.MIPS.abiflags' section

This is fixed by reorganising the rules such that unmodified .so files
have a .raw suffix, and these are copied in the same rule that runs
genvdso on the copies.

I.e. previously we had:

 cmd_vdsold:
  link objects -> vdso.so.dbg

 cmd_genvdso:
  strip vdso.so.dbg -> vdso.so
  run genvdso -> vdso-image.c
   and modify vdso.so.dbg and vdso.so in place

Now we have:

 cmd_vdsold:
  link objects -> vdso.so.dbg.raw

 a new cmd_objcopy based strip rule (inspired by ARM):
  strip vdso.so.dbg.raw -> vdso.so.raw

 cmd_genvdso:
  copy vdso.so.dbg.raw -> vdso.so.dbg
  copy vdso.so.raw -> vdso.so
  run genvdso -> vdso-image.c
   and modify vdso.so.dbg and vdso.so in place
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13250/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The DT fragment will select the ohci-platform driver, since that can
handle the JZ4740 OHCI just fine. While I don't have a JZ4740-based
board with anything connected to the USB host controller, I did test
the generic OHCI driver successfully on a JZ4770-based board.

The device is disabled by default; boards that want to use it can
override the "status" property. The mass-production Qi LB60 boards
don't use the USB host controller.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13104/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

AVT2 was a prototype board of which about 5 were made, none of which
are in use anymore.
Signed-off-by: NMaarten ter Huurne <maarten@treewalker.org>
Acked-by: NLars-Peter Clausen <lars@metafoo.de>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13103/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Now that there are different revisions of the Pistachio SoC
in circulation, add this information to the boot log to make
it easier for users to determine which hardware they have.
Signed-off-by: NJames Hartley <james.hartley@imgtec.com>
Signed-off-by: NIonela Voinescu <ionela.voinescu@imgtec.com>
Cc: Andrew Bresticker <abrestic@chromium.org>
Cc: Jonas Gorski <jogo@openwrt.org>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13130/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The CPU actually runs at 1405Mhz which gives us a 175625000 Hz MIPS timer
frequency (CPU frequency / 8).

Fixes: e4c7d009 ("MIPS: BMIPS: Add BCM7435 dtsi")
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: john@phrozen.org
Cc: cernekee@gmail.com
Cc: jaedon.shin@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/13132/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Mediatek MT7620 SoC has syscfg0 bits where it sets the type of memory being used.
However, sometimes those bits are not set properly (reading "11"). In this case, the SoC assumes SDRAM.
The patch below reflects that.
Signed-off-by: NSashka Nochkin <linux-mips@durdom.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13135/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

If a kernel doesn't support MSA context (ie. CONFIG_CPU_HAS_MSA=n) then
it will only keep 64 bits per FP register in thread context, and the
calls to set_fpr64 in restore_msa_extcontext will overrun the end of the
FP register context into the FCSR & MSACSR values. GCC 6.x has become
smart enough to detect this & complain like so:

    arch/mips/kernel/signal.c: In function 'protected_restore_fp_context':
    ./arch/mips/include/asm/processor.h:114:17: error: array subscript is above array bounds [-Werror=array-bounds]
      fpr->val##width[FPR_IDX(width, idx)] = val;   \
      ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
    ./arch/mips/include/asm/processor.h:118:1: note: in expansion of macro 'BUILD_FPR_ACCESS'
     BUILD_FPR_ACCESS(64)

The only way to trigger this code to run would be for a program to set
up an artificial extended MSA context structure following a sigframe &
execute sigreturn. Whilst this doesn't allow a program to write to any
state that it couldn't already, it makes little sense to allow this
"restoration" of MSA context in a system that doesn't support MSA.

Fix this by killing a program with SIGSYS if it tries something as crazy
as "restoring" fake MSA context in this way, also fixing the build error
& allowing for most of restore_msa_extcontext to be optimised out of
kernels without support for MSA.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Reported-by: NMichal Toman <michal.toman@imgtec.com>
Fixes: bf82cb30 ("MIPS: Save MSA extended context around signals")
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Michal Toman <michal.toman@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: stable <stable@vger.kernel.org> # v4.3+
Patchwork: https://patchwork.linux-mips.org/patch/13164/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Calculate the MIPS clockevent device's min_delta_ns dynamically based on
the time it takes to perform the mips_next_event() sequence.

Virtualisation in particular makes the current fixed min_delta of 0x300
inappropriate under some circumstances, as the CP0_Count and CP0_Compare
registers may be being emulated by the hypervisor, and the frequency may
not correspond directly to the CPU frequency.

We actually use twice the median of multiple 75th percentiles of
multiple measurements of how long the mips_next_event() sequence takes,
in order to fairly efficiently eliminate outliers due to unexpected
hypervisor latency (which would need handling with retries when it
occurs during normal operation anyway).
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13176/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

When estimating the clock frequency based on the RTC, take seconds into
account in case the Update In Progress (UIP) bit wasn't seen. This can
happen in virtual machines (which may get pre-empted by the hypervisor
at inopportune times) with QEMU emulating the RTC (and in fact not
setting the UIP bit for very long), especially on slow hosts such as
FPGA systems and hardware emulators. This results in several seconds
actually having elapsed before seeing the UIP bit instead of just one
second, and exaggerated timer frequencies.

While updating the comments, they're also fixed to match the code in
that the rising edge of the update flag is detected first, not the
falling edge.

The rising edge gives a more precise point to read the counters in a
virtualised system than the falling edge, resulting in a more accurate
frequency.

It does however mean that we have to also wait for the falling edge
before doing the read of the RTC seconds register, otherwise it seems to
be possible in slow hardware emulation to stray into the interval when
the RTC time is undefined during the update (at least 244uS after the
rising edge of the update flag). This can result in both seconds values
reading the same, and it wrapping to 60 seconds, vastly underestimating
the frequency.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13174/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The sampling of the GIC counter on Malta after observing a rising edge
of the RTC update flag differs slightly between the first and second
sample, with the first sample also calling gic_start_count(). The two
samples should really be taken as similarly as possible to get the most
accurate figure, so move the gic_start_count() call before detecting the
rising edge.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13173/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Commit 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options
for MIPS") added support for the PR_SET_FP_MODE prctl, which allows a
userland program to modify its FP mode at runtime. This is most notably
required if dynamic linking leads to the FP mode requirement changing at
runtime from that indicated in the initial executable's ELF header. In
order to avoid overhead in the general FP context restore code, it aimed
to have threads in the process become unable to enable the FPU during a
mode switch & have the thread calling the prctl syscall wait for all
other threads in the process to be context switched at least once. Once
that happens we can know that no thread in the process whose mode will
be switched has live FP context, and it's safe to perform the mode
switch. However in the (rare) case of modeswitches occurring in
multithreaded programs this can lead to indeterminate delays for the
thread invoking the prctl syscall, and the code monitoring for those
context switches was woefully inadequate for all but the simplest cases.

Fix this by broadcasting an IPI if other CPUs may have live FP context
for an affected thread, with a handler causing those CPUs to relinquish
their FPU ownership. Threads will then be allowed to continue running
but will stall on the wait_on_atomic_t in enable_restore_fp_context if
they attempt to use FP again whilst the mode switch is still in
progress. The end result is less fragile poking at scheduler context
switch counts & a more expedient completion of the mode switch.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Fixes: 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: stable <stable@vger.kernel.org> # v4.0+
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13145/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Whilst a PR_SET_FP_MODE prctl is performed there are decisions made
based upon whether the task is executing on the current CPU. This may
change if we're preempted, so disable preemption to avoid such changes
for the lifetime of the mode switch.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Fixes: 9791554b ("MIPS,prctl: add PR_[GS]ET_FP_MODE prctl options for MIPS")
Reviewed-by: NMaciej W. Rozycki <macro@imgtec.com>
Tested-by: NAurelien Jarno <aurelien@aurel32.net>
Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: stable <stable@vger.kernel.org> # v4.0+
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13144/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

If an address error exception occurs for a LDXC1 or SDXC1 instruction,
within the cop1x opcode space, allow it to be passed through to the FPU
emulator rather than resulting in a SIGILL. This causes LDXC1 & SDXC1 to
be handled in a manner consistent with the more common LDC1 & SDC1
instructions.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Tested-by: NAurelien Jarno <aurelien@aurel32.net>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13143/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Correct the cases missed with commit 9b26616c ("MIPS: Respect the
ISA level in FCSR handling") and prevent writes to read-only FCSR bits
there.

This in particular applies to FP context initialisation where any IEEE
754-2008 bits preset by `mips_set_personality_nan' are cleared before
the relevant ptrace(2) call takes effect and the PTRACE_POKEUSR request
addressing FPC_CSR where no masking of read-only FCSR bits is done.

Remove the FCSR clearing from FP context initialisation then and unify
PTRACE_POKEUSR/FPC_CSR and PTRACE_SETFPREGS handling, by factoring out
code from `ptrace_setfpregs' and calling it from both places.

This mostly matters to soft float configurations where the emulator can
be switched this way to a mode which should not be accessible and cannot
be set with the CTC1 instruction.  With hard float configurations any
effect is transient anyway as read-only bits will retain their values at
the time the FP context is restored.
Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: stable@vger.kernel.org # v4.0+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13239/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Fix a floating-point context restoration regression introduced with
commit 9b26616c ("MIPS: Respect the ISA level in FCSR handling")
that causes a Floating Point exception and consequently a kernel oops
with hard float configurations when one or more FCSR Enable and their
corresponding Cause bits are set both at a time via a ptrace(2) call.

To do so reinstate Cause bit masking originally introduced with commit
b1442d39 ("MIPS: Prevent user from setting FCSR cause bits") to
address this exact problem and then inadvertently removed from the
PTRACE_SETFPREGS request with the commit referred above.
Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: stable@vger.kernel.org # v4.0+
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13238/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

- now clock nodes definition is merged with core .dtsi file
- only one rootclk is now part of DT
- clock clients also updated based on new binding doc
Signed-off-by: NPurna Chandra Mandal <purna.mandal@microchip.com>
Signed-off-by: NJoshua Henderson <joshua.henderson@microchip.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Sandeep Sheriker <sandeepsheriker.mallikarjun@microchip.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: linux-clk@vger.kernel.org
Cc: devicetree@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/13248/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Remove a duplicate o32 `elf_check_arch' implementation, move all macro
variants to <asm/elf.h> and define them unconditionally under indvidual
names, substituting alias `elf_check_arch' definitions in variant code.
Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13245/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13244/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Move the `mips_elf_abiflags_v0' structure and FP ABI flag macros outside
#ifndef ELF_ARCH.  These are public interfaces.
Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13243/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The GuestCtl1 CP0 register can contain the GuestID used for root TLB
operations, which affects TLB matching. The other TLB registers are
already dumped out to the log on a machine check exception due to
multiple matching TLB entries, so also dump the value of the GuestCtl1
register if GuestIDs are supported.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13232/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The GuestID for root TLB operations (GuestCtl1.RID) is modified by TLB
reads, so needs preserving by dump_tlb() like the ASID field of EntryHi.

Also dump the GuestID of each entry if it exists alongside the ASID, as
it forms an important part of the TLB entry when VZ guests are used.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13230/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Add a few new cpu-features.h definitions for VZ sub-features, namely the
existence of the CP0_GuestCtl0Ext, CP0_GuestCtl1, and CP0_GuestCtl2
registers, and support for GuestID to dialias TLB entries belonging to
different guests.

Also add certain features present in the guest, with the naming scheme
cpu_guest_has_*. These are added separately to the main options bitfield
since they generally parallel similar features in the root context. A
few of these (FPU, MSA, watchpoints, perf counters, CP0_[X]ContextConfig
registers, MAAR registers, and probably others in future) can be
dynamically configured in the guest context, for which the
cpu_guest_has_dyn_* macros are added.

[ralf@linux-mips.org: Resolve merge conflict.]
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13231/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Add guest CP0 accessors and guest TLB operations along the same lines as
the existing macros and functions for the root CP0.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NDavid Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13229/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Add various register definitions to <asm/mipsregs.h> for the coprocessor
zero registers in the VZ ASE, namely CP0_GuestCtl0, CP0_GuestCtl0Ext,
CP0_GuestCtl1, CP0_GuestCtl2, CP0_GuestCtl3, and CP0_GTOffset.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Acked-by: NDavid Daney <david.daney@cavium.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13228/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The decode_config4() function reads kscratch_mask from
CP0_Config4.KScrExist using a hard coded shift and mask. We already have
a definition for the mask in mipsregs.h, so add a definition for the
shift and make use of them.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13227/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Add CPU feature for standard MIPS r2 performance counters, as determined
by the Config1.PC bit. Both perf_events and oprofile probe this bit, so
lets combine the probing and change both to use cpu_has_perf.

This will also be used for VZ support in KVM to know whether performance
counters exist which can be exposed to guests.

[ralf@linux-mips.org: resolve conflict.]
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Robert Richter <rric@kernel.org>
Cc: linux-mips@linux-mips.org
Cc: oprofile-list@lists.sf.net
Patchwork: https://patchwork.linux-mips.org/patch/13226/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The CP0_[X]ContextConfig registers are present if CP0_Config3.CTXTC or
CP0_Config3.SM are set, and provide more control over which bits of
CP0_[X]Context are set to the faulting virtual address on a TLB
exception.

KVM/VZ will need to be able to save and restore these registers in the
guest context, so add the relevant definitions and probing of the
ContextConfig feature in the root context first.

[ralf@linux-mips.org: resolve merge conflict.]
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/13225/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>