<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/mips/include/asm/cpu-features.h, branch linux-rolling-stable</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>MIPS: Always record SEGBITS in cpu_data.vmbits</title>
<updated>2026-04-18T08:46:42+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@orcam.me.uk</email>
</author>
<published>2026-04-10T00:48:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5427c325d016d60c58e6f69cfca7b46a642abce6'/>
<id>5427c325d016d60c58e6f69cfca7b46a642abce6</id>
<content type='text'>
commit 8374c2cb83b95b3c92f129fd56527225c20a058c upstream.

With a 32-bit kernel running on 64-bit MIPS hardware the hardcoded value
of `cpu_vmbits' only records the size of compatibility useg and does not
reflect the size of native xuseg or the complete range of values allowed
in the VPN2 field of TLB entries.

An upcoming change will need the actual VPN2 value range permitted even
in 32-bit kernel configurations, so always include the `vmbits' member
in `struct cpuinfo_mips' and probe for SEGBITS when running on 64-bit
hardware and resorting to the currently hardcoded value of 31 on 32-bit
processors.  No functional change for users of `cpu_vmbits'.

Signed-off-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8374c2cb83b95b3c92f129fd56527225c20a058c upstream.

With a 32-bit kernel running on 64-bit MIPS hardware the hardcoded value
of `cpu_vmbits' only records the size of compatibility useg and does not
reflect the size of native xuseg or the complete range of values allowed
in the VPN2 field of TLB entries.

An upcoming change will need the actual VPN2 value range permitted even
in 32-bit kernel configurations, so always include the `vmbits' member
in `struct cpuinfo_mips' and probe for SEGBITS when running on 64-bit
hardware and resorting to the currently hardcoded value of 31 on 32-bit
processors.  No functional change for users of `cpu_vmbits'.

Signed-off-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: cpu-features: Use boot_cpu_type for CPU type based features</title>
<updated>2023-06-09T07:56:22+00:00</updated>
<author>
<name>Jiaxun Yang</name>
<email>jiaxun.yang@flygoat.com</email>
</author>
<published>2023-06-07T05:51:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5487a7b60695a92cf998350e4beac17144c91fcd'/>
<id>5487a7b60695a92cf998350e4beac17144c91fcd</id>
<content type='text'>
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 &lt;jiaxun.yang@flygoat.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;jiaxun.yang@flygoat.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: cpu-features: Enable octeon_cache by cpu_type</title>
<updated>2023-04-05T07:45:09+00:00</updated>
<author>
<name>Jiaxun Yang</name>
<email>jiaxun.yang@flygoat.com</email>
</author>
<published>2023-04-04T09:33:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f641519409a73403ee6612b8648b95a688ab85c2'/>
<id>f641519409a73403ee6612b8648b95a688ab85c2</id>
<content type='text'>
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 &lt;jiaxun.yang@flygoat.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;jiaxun.yang@flygoat.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Octeon: Opt-out 4k_cache feature</title>
<updated>2023-04-05T07:45:09+00:00</updated>
<author>
<name>Jiaxun Yang</name>
<email>jiaxun.yang@flygoat.com</email>
</author>
<published>2023-04-04T09:33:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=918d779569dafd81fce4257c552aa4205c918c4a'/>
<id>918d779569dafd81fce4257c552aa4205c918c4a</id>
<content type='text'>
Octeon has a different cache interface with traditional R4K one,
just opt-out this flag for octeon to avoid run R4K cache initialization
code accidentally.

Also remove ISA level assumption for 4k cache.

Signed-off-by: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Octeon has a different cache interface with traditional R4K one,
just opt-out this flag for octeon to avoid run R4K cache initialization
code accidentally.

Also remove ISA level assumption for 4k cache.

Signed-off-by: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: adding a safety check for cpu_has_fpu</title>
<updated>2022-05-04T20:26:02+00:00</updated>
<author>
<name>Shida Zhang</name>
<email>zhangshida@kylinos.cn</email>
</author>
<published>2022-05-02T03:20:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=912a4427bec0e423c45dcf2afda079c22f505237'/>
<id>912a4427bec0e423c45dcf2afda079c22f505237</id>
<content type='text'>
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 &lt;macro@orcam.me.uk&gt;
Signed-off-by: Shida Zhang &lt;zhangshida@kylinos.cn&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;macro@orcam.me.uk&gt;
Signed-off-by: Shida Zhang &lt;zhangshida@kylinos.cn&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Remove TX39XX support</title>
<updated>2022-03-01T09:07:22+00:00</updated>
<author>
<name>Thomas Bogendoerfer</name>
<email>tsbogend@alpha.franken.de</email>
</author>
<published>2022-02-22T09:04:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=455481fc9a807798eca05f6fb0918ab88109d845'/>
<id>455481fc9a807798eca05f6fb0918ab88109d845</id>
<content type='text'>
No (active) developer owns this hardware, so let's remove Linux support.

Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Acked-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Tested-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Atsushi Nemoto &lt;anemo@mba.ocn.ne.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
No (active) developer owns this hardware, so let's remove Linux support.

Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Acked-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Tested-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Acked-by: Atsushi Nemoto &lt;anemo@mba.ocn.ne.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: MT extensions are not available on MIPS32r1</title>
<updated>2021-06-29T08:14:58+00:00</updated>
<author>
<name>Paul Cercueil</name>
<email>paul@crapouillou.net</email>
</author>
<published>2021-06-25T10:49:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cad065ed8d8831df67b9754cc4437ed55d8b48c0'/>
<id>cad065ed8d8831df67b9754cc4437ed55d8b48c0</id>
<content type='text'>
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 &lt;paul@crapouillou.net&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;paul@crapouillou.net&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Remove cpu_has_6k_cache and cpu_has_8k_cache in cpu_cache_init()</title>
<updated>2020-11-19T12:28:58+00:00</updated>
<author>
<name>Tiezhu Yang</name>
<email>yangtiezhu@loongson.cn</email>
</author>
<published>2020-11-19T07:53:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6ce91ba8589ab08143939f9d6a58993e36773e75'/>
<id>6ce91ba8589ab08143939f9d6a58993e36773e75</id>
<content type='text'>
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 &lt;yangtiezhu@loongson.cn&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;yangtiezhu@loongson.cn&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: cpu-probe: remove MIPS_CPU_BP_GHIST option bit</title>
<updated>2020-10-12T10:05:40+00:00</updated>
<author>
<name>Thomas Bogendoerfer</name>
<email>tsbogend@alpha.franken.de</email>
</author>
<published>2020-10-09T12:26:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=20cc5b649d9978494fb29259763c2505f6acc3c0'/>
<id>20cc5b649d9978494fb29259763c2505f6acc3c0</id>
<content type='text'>
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 &lt;tsbogend@alpha.franken.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;tsbogend@alpha.franken.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: handle Loongson-specific GSExc exception</title>
<updated>2020-07-31T15:52:47+00:00</updated>
<author>
<name>WANG Xuerui</name>
<email>git@xen0n.name</email>
</author>
<published>2020-07-29T13:14:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bc6e8dc112133a60efbede8acde36dd5d1e748a1'/>
<id>bc6e8dc112133a60efbede8acde36dd5d1e748a1</id>
<content type='text'>
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 &lt;chenhc@lemote.com&gt;
Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Cc: Tiezhu Yang &lt;yangtiezhu@loongson.cn&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;chenhc@lemote.com&gt;
Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Cc: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Cc: Tiezhu Yang &lt;yangtiezhu@loongson.cn&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
