linux-stable.git/arch/mips/include/asm/cpu-features.h, branch linux-5.4.y

MIPS: cpu-features: Use boot_cpu_type for CPU type based features

2023-08-30T14:27:21+00:00

[ Upstream commit 5487a7b60695a92cf998350e4beac17144c91fcd ]

Some CPU feature macros were using current_cpu_type to mark feature
availability.

However current_cpu_type will use smp_processor_id, which is prohibited
under preemptable context.

Since those features are all uniform on all CPUs in a SMP system, use
boot_cpu_type instead of current_cpu_type to fix preemptable kernel.

Cc: stable@vger.kernel.org
Signed-off-by: Jiaxun Yang 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Sasha Levin

MIPS: cpu-features: Enable octeon_cache by cpu_type

2023-08-30T14:27:21+00:00

[ Upstream commit f641519409a73403ee6612b8648b95a688ab85c2 ]

cpu_has_octeon_cache was tied to 0 for generic cpu-features,
whith this generic kernel built for octeon CPU won't boot.

Just enable this flag by cpu_type. It won't hurt orther platforms
because compiler will eliminate the code path on other processors.

Signed-off-by: Jiaxun Yang 
Signed-off-by: Thomas Bogendoerfer 
Stable-dep-of: 5487a7b60695 ("MIPS: cpu-features: Use boot_cpu_type for CPU type based features")
Signed-off-by: Sasha Levin

mips: Fix cpu_has_mips64r1/2 activation for MIPS32 CPUs

2020-06-22T07:30:55+00:00

[ Upstream commit a2ac81c6ef4018ea49c034ce165bb9ea1cf99f3e ]

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 
Signed-off-by: Sasha Levin

MIPS: tlbex: Remove cpu_has_local_ebase

2019-09-03T13:20:54+00:00

The cpu_has_local_ebase macro is, confusingly, not used to indicate
whether the EBase register is local to a CPU or not. Instead it
indicates whether we want to generate the TLB refill exception vector
each time a CPU is brought online. Doing this makes little sense on any
system, since we always use the same value for EBase & thus we cannot
have different TLB refill exception handlers per CPU.

Regenerating the code is not only pointless but also can be actively
harmful, as commit 8759934e2b6b ("MIPS: Build uasm-generated code only
once to avoid CPU Hotplug problem") described. That commit introduced
cpu_has_local_ebase to disable the handler regeneration for Loongson
machines, but this is by no means a Loongson-specific problem.

Remove cpu_has_local_ebase & simply generate the TLB refill handler once
during boot, just like the rest of the TLB exception handlers.

Signed-off-by: Paul Burton 
Reviewed-by: Philippe Mathieu-Daudé 
Cc: linux-mips@vger.kernel.org

MIPS: Treat Loongson Extensions as ASEs

2019-08-26T10:42:40+00:00

Recently, binutils had split Loongson-3 Extensions into four ASEs:
MMI, CAM, EXT, EXT2. This patch do the samething in kernel and expose
them in cpuinfo so applications can probe supported ASEs at runtime.

Signed-off-by: Jiaxun Yang 
Cc: Huacai Chen 
Cc: Yunqiang Su 
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Paul Burton 
Cc: linux-mips@vger.kernel.org

MIPS: MemoryMapID (MMID) Support

2019-02-04T18:56:41+00:00

Introduce support for using MemoryMapIDs (MMIDs) as an alternative to
Address Space IDs (ASIDs). The major difference between the two is that
MMIDs are global - ie. an MMID uniquely identifies an address space
across all coherent CPUs. In contrast ASIDs are non-global per-CPU IDs,
wherein each address space is allocated a separate ASID for each CPU
upon which it is used. This global namespace allows a new GINVT
instruction be used to globally invalidate TLB entries associated with a
particular MMID across all coherent CPUs in the system, removing the
need for IPIs to invalidate entries with separate ASIDs on each CPU.

The allocation scheme used here is largely borrowed from arm64 (see
arch/arm64/mm/context.c). In essence we maintain a bitmap to track
available MMIDs, and MMIDs in active use at the time of a rollover to a
new MMID version are preserved in the new version. The allocation scheme
requires efficient 64 bit atomics in order to perform reasonably, so
this support depends upon CONFIG_GENERIC_ATOMIC64=n (ie. currently it
will only be included in MIPS64 kernels).

The first, and currently only, available CPU with support for MMIDs is
the MIPS I6500. This CPU supports 16 bit MMIDs, and so for now we cap
our MMIDs to 16 bits wide in order to prevent the bitmap growing to
absurd sizes if any future CPU does implement 32 bit MMIDs as the
architecture manuals suggest is recommended.

When MMIDs are in use we also make use of GINVT instruction which is
available due to the global nature of MMIDs. By executing a sequence of
GINVT & SYNC 0x14 instructions we can avoid the overhead of an IPI to
each remote CPU in many cases. One complication is that GINVT will
invalidate wired entries (in all cases apart from type 0, which targets
the entire TLB). In order to avoid GINVT invalidating any wired TLB
entries we set up, we make sure to create those entries using a reserved
MMID (0) that we never associate with any address space.

Also of note is that KVM will require further work in order to support
MMIDs & GINVT, since KVM is involved in allocating IDs for guests & in
configuring the MMU. That work is not part of this patch, so for now
when MMIDs are in use KVM is disabled.

Signed-off-by: Paul Burton 
Cc: linux-mips@vger.kernel.org

MIPS: Hardcode cpu_has_mips* where target ISA allows

2018-11-27T06:49:20+00:00

In the same vein as commit 93e01942a6eb ("MIPS: Hardcode cpu_has_* where
known at compile time due to ISA"), we can use our knowledge of the ISA
being targeted by the kernel build to make cpu_has_mips* macros
compile-time constant in some cases. This allows the compiler greater
opportunity to optimize out code which will never execute.

Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/21245/
Cc: linux-mips@linux-mips.org

MIPS: Use Kconfig to select CPU_NO_EFFICIENT_FFS

2018-11-12T22:26:16+00:00

Select CONFIG_CPU_NO_EFFICIENT_FFS via Kconfig when the kernel is
configured for a pre-MIPS32r1 CPU, rather than defining its equivalent
in asm/cpu-features.h based upon overrides of cpu_has_mips* macros.

The latter only works if a platform has an cpu-feature-overrides.h
header which defines cpu_has_mips* macros, which are not generally
needed. There are many cases where we know that the target ISA for a
kernel build is MIPS32r1 or later & thus includes the CLZ instruction,
without requiring any overrides from the platform. Using Kconfig allows
us to take those into account, and more naturally make a decision about
instruction support using information about the target ISA.

Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/21045/
Cc: Andrew Morton 
Cc: Zhaoxiu Zeng 
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org

MIPS: Hardcode cpu_has_fpu=0 when CONFIG_MIPS_FP_SUPPORT=n

2018-11-09T18:23:15+00:00

When CONFIG_MIPS_FP_SUPPORT=n we don't support floating point, so
there's no point in detecting presence of an FPU. Hardcode
cpu_has_fpu=0 such that we optimize out code that makes use of the FPU.

Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/21005/
Cc: linux-mips@linux-mips.org

MIPS: Hardcode cpu_has_mmips=1 for microMIPS kernels

2018-11-08T18:23:38+00:00

If we built the kernel targeting the microMIPS ISA then the very fact
that the kernel is running implies that the CPU supports microMIPS. Thus
we can hardcode cpu_has_mmips to 1 allowing the compiler greater scope
for optimisation due to the compile-time constant.

Signed-off-by: Paul Burton 
Patchwork: https://patchwork.linux-mips.org/patch/21022/
Cc: linux-mips@linux-mips.org