linux.git/arch/mips/include/asm/cpu-features.h, branch v6.0

MIPS: adding a safety check for cpu_has_fpu

2022-05-04T20:26:02+00:00

There is a chance 'cpu_has_fpu' would still be overridden when the
CONFIG_MIPS_FP_SUPPORT configuration option has been disabled. So
add a safety check for 'cpu_has_fpu'.

Suggested-by: Maciej W. Rozycki 
Signed-off-by: Shida Zhang 
Signed-off-by: Thomas Bogendoerfer

MIPS: Remove TX39XX support

2022-03-01T09:07:22+00:00

No (active) developer owns this hardware, so let's remove Linux support.

Signed-off-by: Thomas Bogendoerfer 
Acked-by: Guenter Roeck 
Reviewed-by: Geert Uytterhoeven 
Tested-by: Geert Uytterhoeven 
Acked-by: Atsushi Nemoto

MIPS: MT extensions are not available on MIPS32r1

2021-06-29T08:14:58+00:00

MIPS MT extensions were added with the MIPS 34K processor, which was
based on the MIPS32r2 ISA.

This fixes a build error when building a generic kernel for a MIPS32r1
CPU.

Fixes: c434b9f80b09 ("MIPS: Kconfig: add MIPS_GENERIC_KERNEL symbol")
Cc: stable@vger.kernel.org # v5.9
Signed-off-by: Paul Cercueil 
Signed-off-by: Thomas Bogendoerfer

MIPS: Remove cpu_has_6k_cache and cpu_has_8k_cache in cpu_cache_init()

2020-11-19T12:28:58+00:00

Since commit 02cf2119684e ("Cleanup the mess in cpu_cache_init."),
cpu_has_6k_cache and cpu_has_8k_cache have no user, r6k_cache_init()
and r8k_cache_init() are not defined for over 15 years, just remove
them.

Signed-off-by: Tiezhu Yang 
Signed-off-by: Thomas Bogendoerfer

MIPS: cpu-probe: remove MIPS_CPU_BP_GHIST option bit

2020-10-12T10:05:40+00:00

MIPS_CPU_BP_GHIST is only set two times and more or less immediately
used in cpu-probe.c itself. Remove this option to make room in options
word.

Signed-off-by: Thomas Bogendoerfer

MIPS: handle Loongson-specific GSExc exception

2020-07-31T15:52:47+00:00

Newer Loongson cores (Loongson-3A R2 and newer) use the
implementation-dependent ExcCode 16 to signal Loongson-specific
exceptions. The extended cause is put in the non-standard CP0.Diag1
register which is CP0 Register 22 Select 1, called GSCause in Loongson
manuals. Inside is an exception code bitfield called GSExcCode, only
codes 0 to 6 inclusive are documented (so far, in the Loongson 3A3000
User Manual, Volume 2).

During experiments, it was found that some undocumented unprivileged
instructions can trigger the also-undocumented GSExcCode 8 on Loongson
3A4000. Processor state is not corrupted, but we cannot continue without
further knowledge, and Loongson is not providing that information as of
this writing. So we send SIGILL on seeing this exception code to thwart
easy local DoS attacks.

Other exception codes are made fatal, partly because of insufficient
knowledge, also partly because they are not as easily reproduced. None
of them are encountered in the wild with upstream kernels and userspace
so far.

Some older cores (Loongson-3A1000 and Loongson-3B1500) have ExcCode 16
too, but the semantic is equivalent to GSExcCode 0. Because the
respective manuals did not mention the CP0.Diag1 register or its read
behavior, these cores are not covered in this patch, as MFC0 from
non-existent CP0 registers is UNDEFINED according to the MIPS
architecture spec.

Reviewed-by: Huacai Chen 
Signed-off-by: WANG Xuerui 
Cc: Huacai Chen 
Cc: Jiaxun Yang 
Cc: Tiezhu Yang 
Signed-off-by: Thomas Bogendoerfer

MIPS: only register FTLBPar exception handler for supported models

2020-07-31T15:52:10+00:00

Previously ExcCode 16 is unconditionally treated as the FTLB parity
exception (FTLBPar), but in fact its semantic is implementation-
dependent. Looking at various manuals it seems the FTLBPar exception is
only present on some recent MIPS Technologies cores, so only register
the handler on these.

Fixes: 75b5b5e0a262790f ("MIPS: Add support for FTLBs")
Reviewed-by: Huacai Chen 
Signed-off-by: WANG Xuerui 
Cc: Paul Burton 
Signed-off-by: Thomas Bogendoerfer

KVM: MIPS: Introduce and use cpu_guest_has_ldpte

2020-06-04T17:49:00+00:00

Loongson-3 has lddir/ldpte instructions and their related CP0 registers
are the same as HTW. So we introduce a cpu_guest_has_ldpte flag and use
it to indicate whether we need to save/restore HTW related CP0 registers
(PWBase, PWSize, PWField and PWCtl).

Acked-by: Thomas Bogendoerfer 
Reviewed-by: Aleksandar Markovic 
Signed-off-by: Huacai Chen 
Co-developed-by: Jiaxun Yang 
Message-Id: <1590220602-3547-7-git-send-email-chenhc@lemote.com>
Signed-off-by: Paolo Bonzini

mips: Add CP0 Write Merge config support

2020-05-22T07:11:45+00:00

CP0 config register may indicate whether write-through merging
is allowed. Currently there are two types of the merging available:
SysAD Valid and Full modes. Whether each of them are supported by
the core is implementation dependent. Moreover whether the ability
to change the mode also depends on the chip family instance. Taking
into account all of this we created a dedicated mm_config() method
to detect and enable merging if it's supported. It is called for
MIPS-type processors at CPU-probe stage and attempts to detect whether
the write merging is available. If it's known to be supported and
switchable, then switch on the full mode. Otherwise just perform the
CP0.Config.MM field analysis.

In addition there are platforms like InterAptiv/ProAptiv, which do have
the MM bit field set by default, but having write-through cacheing
unsupported makes write-merging also unsupported. In this case we just
ignore the MM field value.

Co-developed-by: Alexey Malahov 
Signed-off-by: Alexey Malahov 
Signed-off-by: Serge Semin 
Cc: Thomas Bogendoerfer 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer

mips: Fix cpu_has_mips64r1/2 activation for MIPS32 CPUs

2020-05-22T07:11:15+00:00

Commit 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA
allows") updated the cpu_has_mips* macro to be replaced with a constant
expression where it's possible. By mistake it wasn't done correctly
for cpu_has_mips64r1/cpu_has_mips64r2 macro. They are defined to
be replaced with conditional expression __isa_range_or_flag(), which
means either ISA revision being within the range or the corresponding
CPU options flag was set at the probe stage or both being true at the
same time. But the ISA level value doesn't indicate whether the ISA is
MIPS32 or MIPS64. Due to this if we select MIPS32r1 - MIPS32r5
architectures the __isa_range() macro will activate the
cpu_has_mips64rX flags, which is incorrect. In order to fix the
problem we make sure the 64bits CPU support is enabled by means of
checking the flag cpu_has_64bits aside with proper ISA range and specific
Revision flag being set.

Fixes: 1aeba347b3a9 ("MIPS: Hardcode cpu_has_mips* where target ISA allows")
Signed-off-by: Serge Semin 
Cc: Alexey Malahov 
Cc: Thomas Bogendoerfer 
Cc: Paul Burton 
Cc: Ralf Baechle 
Cc: Arnd Bergmann 
Cc: Rob Herring 
Cc: devicetree@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer