<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/arch/mips, branch v6.12.81</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.81</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.12.81'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-11T12:24:41+00:00</updated>
<entry>
<title>mips: mm: Allocate tlb_vpn array atomically</title>
<updated>2026-04-11T12:24:41+00:00</updated>
<author>
<name>Stefan Wiehler</name>
<email>stefan.wiehler@nokia.com</email>
</author>
<published>2026-03-10T10:40:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6e965c91983a8cad24ec2ae9bd795fb8e28fc90d'/>
<id>urn:sha1:6e965c91983a8cad24ec2ae9bd795fb8e28fc90d</id>
<content type='text'>
commit 01cc50ea5167bb14117257ec084637abe9e5f691 upstream.

Found by DEBUG_ATOMIC_SLEEP:

  BUG: sleeping function called from invalid context at /include/linux/sched/mm.h:306
  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
  preempt_count: 1, expected: 0
  RCU nest depth: 0, expected: 0
  no locks held by swapper/1/0.
  irq event stamp: 0
  hardirqs last  enabled at (0): [&lt;0000000000000000&gt;] 0x0
  hardirqs last disabled at (0): [&lt;ffffffff801477fc&gt;] copy_process+0x75c/0x1b68
  softirqs last  enabled at (0): [&lt;ffffffff801477fc&gt;] copy_process+0x75c/0x1b68
  softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0
  CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.119-d79e757675ec-fct #1
  Stack : 800000000290bad8 0000000000000000 0000000000000008 800000000290bae8
          800000000290bae8 800000000290bc78 0000000000000000 0000000000000000
          ffffffff80c80000 0000000000000001 ffffffff80d8dee8 ffffffff810d09c0
          784bb2a7ec10647d 0000000000000010 ffffffff80a6fd60 8000000001d8a9c0
          0000000000000000 0000000000000000 ffffffff80d90000 0000000000000000
          ffffffff80c9e0e8 0000000007ffffff 0000000000000cc0 0000000000000400
          ffffffffffffffff 0000000000000001 0000000000000002 ffffffffc0149ed8
          fffffffffffffffe 8000000002908000 800000000290bae0 ffffffff80a81b74
          ffffffff80129fb0 0000000000000000 0000000000000000 0000000000000000
          0000000000000000 0000000000000000 ffffffff80129fd0 0000000000000000
          ...
  Call Trace:
  [&lt;ffffffff80129fd0&gt;] show_stack+0x60/0x158
  [&lt;ffffffff80a7f894&gt;] dump_stack_lvl+0x88/0xbc
  [&lt;ffffffff8018d3c8&gt;] __might_resched+0x268/0x288
  [&lt;ffffffff803648b0&gt;] __kmem_cache_alloc_node+0x2e0/0x330
  [&lt;ffffffff80302788&gt;] __kmalloc+0x58/0xd0
  [&lt;ffffffff80a81b74&gt;] r4k_tlb_uniquify+0x7c/0x428
  [&lt;ffffffff80143e8c&gt;] tlb_init+0x7c/0x110
  [&lt;ffffffff8012bdb4&gt;] per_cpu_trap_init+0x16c/0x1d0
  [&lt;ffffffff80133258&gt;] start_secondary+0x28/0x128

Fixes: 231ac951faba ("MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow")
Signed-off-by: Stefan Wiehler &lt;stefan.wiehler@nokia.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Fix the GCC version check for `__multi3' workaround</title>
<updated>2026-04-11T12:24:41+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@orcam.me.uk</email>
</author>
<published>2026-03-30T01:54:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a8d2212538051911379ceb9c644c91ddb66ef8e7'/>
<id>urn:sha1:a8d2212538051911379ceb9c644c91ddb66ef8e7</id>
<content type='text'>
commit ec8bf18814915460d9c617b556bf024efef26613 upstream.

It was only GCC 10 that fixed a MIPS64r6 code generation issue with a
`__multi3' libcall inefficiently produced to perform 64-bit widening
multiplication while suitable machine instructions exist to do such a
calculation.  The fix went in with GCC commit 48b2123f6336 ("re PR
target/82981 (unnecessary __multi3 call for mips64r6 linux kernel)").

Adjust our code accordingly, removing build failures such as:

mips64-linux-ld: lib/math/div64.o: in function `mul_u64_add_u64_div_u64':
div64.c:(.text+0x84): undefined reference to `__multi3'

with the GCC versions affected.

Fixes: ebabcf17bcd7 ("MIPS: Implement __multi3 for GCC7 MIPS64r6 builds")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Closes: https://lore.kernel.org/oe-kbuild-all/202601140146.hMLODc6v-lkp@intel.com/
Signed-off-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Cc: stable@vger.kernel.org # v4.15+
Reviewed-by: David Laight &lt;david.laight.linux@gmail.com.
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>MIPS: SiByte: Bring back cache initialisation</title>
<updated>2026-04-11T12:24:41+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@orcam.me.uk</email>
</author>
<published>2026-03-27T11:38:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ab9a172ca0822288b62cbcb2154b9fca5ded03d8'/>
<id>urn:sha1:ab9a172ca0822288b62cbcb2154b9fca5ded03d8</id>
<content type='text'>
commit d62cf1511743526f530a4c169424e50c757f5a5e upstream.

Bring back cache initialisation for Broadcom SiByte SB1 cores, which has
been removed causing the kernel to hang at bootstrap right after:

Dentry cache hash table entries: 524288 (order: 8, 4194304 bytes, linear)
Inode-cache hash table entries: 262144 (order: 7, 2097152 bytes, linear)

The cause of the problem is R4k cache handlers are also used by Broadcom
SiByte SB1 cores, however with a different cache error exception handler
and therefore not using CPU_R4K_CACHE_TLB:

obj-$(CONFIG_CPU_R4K_CACHE_TLB) += c-r4k.o cex-gen.o tlb-r4k.o
obj-$(CONFIG_CPU_SB1)           += c-r4k.o cerr-sb1.o cex-sb1.o tlb-r4k.o

(from arch/mips/mm/Makefile).

Fixes: bbe4f634f48c ("mips: fix r3k_cache_init build regression")
Signed-off-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Cc: stable@vger.kernel.org # v6.8+
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mips: ralink: update CPU clock index</title>
<updated>2026-04-11T12:24:39+00:00</updated>
<author>
<name>Shiji Yang</name>
<email>yangshiji66@outlook.com</email>
</author>
<published>2026-02-24T02:22:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e8fd60338545f4bc9c23d3d4686c88324aa76fb8'/>
<id>urn:sha1:e8fd60338545f4bc9c23d3d4686c88324aa76fb8</id>
<content type='text'>
[ Upstream commit 43985a62bab9d35e5e9af41118ce2f44c01b97d2 ]

Update CPU clock index to match the clock driver changes.

Fixes: d34db686a3d7 ("clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs")
Signed-off-by: Mieczyslaw Nalewaj &lt;namiltd@yahoo.com&gt;
Signed-off-by: Shiji Yang &lt;yangshiji66@outlook.com&gt;
Reviewed-by: Sergio Paracuellos &lt;sergio.paracuellos@gmail.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>MIPS: rb532: Fix MMIO UART resource registration</title>
<updated>2026-03-04T12:21:54+00:00</updated>
<author>
<name>Jiaxun Yang</name>
<email>jiaxun.yang@flygoat.com</email>
</author>
<published>2026-02-05T10:08:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e7d70a77ad6f41b879e1ef63f26b1d13975d162e'/>
<id>urn:sha1:e7d70a77ad6f41b879e1ef63f26b1d13975d162e</id>
<content type='text'>
[ Upstream commit e93bb4b76cfefb302534246e892c7667491cb8cc ]

Since commit 6e690d54cfa8 ("serial: 8250: fix return error code in
serial8250_request_std_resource()"), registering an 8250 MMIO port
without mapbase no longer works, as the resource range is derived from
mapbase/mapsize.

Populate mapbase and mapsize accordingly. Also drop ugly membase KSEG1
pointer and set UPF_IOREMAP instead, letting the 8250 core perform the
ioremap.

Fixes: 6e690d54cfa8 ("serial: 8250: fix return error code in serial8250_request_std_resource()")
Cc: stable@vger.kernel.org
Reported-by: Waldemar Brodkorb &lt;wbx@openadk.org&gt;
Link: https://lore.kernel.org/linux-mips/aX-d0ShTplHKZT33@waldemar-brodkorb.de/
Signed-off-by: Jiaxun Yang &lt;jiaxun.yang@flygoat.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Loongson: Make cpumask_of_node() robust against NUMA_NO_NODE</title>
<updated>2026-03-04T12:21:26+00:00</updated>
<author>
<name>John Garry</name>
<email>john.g.garry@oracle.com</email>
</author>
<published>2026-01-07T09:40:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0569822bb36c58c4ac59b96bdc8836bb2bbbadee'/>
<id>urn:sha1:0569822bb36c58c4ac59b96bdc8836bb2bbbadee</id>
<content type='text'>
[ Upstream commit d55d3fe2d1470ac5b6e93efe7998b728013c9fc8 ]

The arch definition of cpumask_of_node() cannot handle NUMA_NO_NODE - which
is a valid index - so add a check for this.

Signed-off-by: John Garry &lt;john.g.garry@oracle.com&gt;
Reviewed-by: Huacai Chen &lt;chenhuacai@loongson.cn&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Work around LLVM bug when gp is used as global register variable</title>
<updated>2026-03-04T12:20:46+00:00</updated>
<author>
<name>Yao Zi</name>
<email>me@ziyao.cc</email>
</author>
<published>2026-02-05T15:56:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e3a6498a63394218561065a9a7a597a204f52f6a'/>
<id>urn:sha1:e3a6498a63394218561065a9a7a597a204f52f6a</id>
<content type='text'>
commit 30bfc2d6a1132a89a5f1c3b96c59cf3e4d076ea3 upstream.

On MIPS, __current_thread_info is defined as global register variable
locating in $gp, and is simply assigned with new address during kernel
relocation.

This however is broken with LLVM, which always restores $gp if it finds
$gp is clobbered in any form, including when intentionally through a
global register variable. This is against GCC's documentation[1], which
requires a callee-saved register used as global register variable not to
be restored if it's clobbered.

As a result, $gp will continue to point to the unrelocated kernel after
the epilog of relocate_kernel(), leading to an early crash in init_idle,

[    0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90
[    0.000000] Oops[#1]:
[    0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G        W           6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY
[    0.000000] Tainted: [W]=WARN
[    0.000000] Hardware name: loongson,loongson64v-4core-virtio
[    0.000000] $ 0   : 0000000000000000 0000000000000000 0000000000000001 0000000000000000
[    0.000000] $ 4   : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240
[    0.000000] $ 8   : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001
[    0.000000] $12   : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002
[    0.000000] $16   : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80
[    0.000000] $20   : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80
[    0.000000] $24   : 0000000000000a26 ffffffff8114fb90
[    0.000000] $28   : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90
[    0.000000] Hi    : 0000000000000000
[    0.000000] Lo    : 0000000000000000
[    0.000000] epc   : ffffffff81afada8 init_idle+0x130/0x270
[    0.000000] ra    : ffffffff81afad90 init_idle+0x118/0x270
[    0.000000] Status: 540000e2	KX SX UX KERNEL EXL
[    0.000000] Cause : 00000008 (ExcCode 02)
[    0.000000] BadVA : 0000000000000000
[    0.000000] PrId  : 00006305 (ICT Loongson-3)
[    0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____), tls=0000000000000000)
[    0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000
[    0.000000]         0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528
[    0.000000]         0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000
[    0.000000]         ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258
[    0.000000]         ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98
[    0.000000]         ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000
[    0.000000]         0000000000000000 0000000000000000 0000000000000000 0000000000000000
[    0.000000]         0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000
[    0.000000]         0000000000000000 0000000000000000 0000000000000000 0000000000000000
[    0.000000]         0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002
[    0.000000]         ...
[    0.000000] Call Trace:
[    0.000000] [&lt;ffffffff81afada8&gt;] init_idle+0x130/0x270
[    0.000000] [&lt;ffffffff81afb6c0&gt;] sched_init+0x5c8/0x6c0
[    0.000000] [&lt;ffffffff81ae86dc&gt;] start_kernel+0x27c/0x7a8

This bug has been reported to LLVM[2] and affects version from (at
least) 18 to 21. Let's work around this by using inline assembly to
assign $gp before a fix is widely available.

Cc: stable@vger.kernel.org
Link: https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Global-Register-Variables.html # [1]
Link: https://github.com/llvm/llvm-project/issues/176546 # [2]
Signed-off-by: Yao Zi &lt;me@ziyao.cc&gt;
Acked-by: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits</title>
<updated>2026-01-08T09:14:13+00:00</updated>
<author>
<name>Gregory CLEMENT</name>
<email>gregory.clement@bootlin.com</email>
</author>
<published>2025-11-28T08:30:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e3e33ac2eb69d595079a1a1e444c2fb98efdd42d'/>
<id>urn:sha1:e3e33ac2eb69d595079a1a1e444c2fb98efdd42d</id>
<content type='text'>
[ Upstream commit 36dac9a3dda1f2bae343191bc16b910c603cac25 ]

Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of
dynamic Function Tracer"), the macro UASM_i_LA_mostly has been used,
and this macro can generate more than 2 instructions. At the same
time, the code in ftrace assumes that no more than 2 instructions can
be generated, which is why it stores them in an int[2] array. However,
as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA)
causes a buffer overflow when _mcount is beyond 32 bits. This leads to
corruption of the variables located in the __read_mostly section.

This corruption was observed because the variable
__cpu_primary_thread_mask was corrupted, causing a hang very early
during boot.

This fix prevents the corruption by avoiding the generation of
instructions if they could exceed 2 instructions in
length. Fortunately, insn_la_mcount is only used if the instrumented
code is located outside the kernel code section, so dynamic ftrace can
still be used, albeit in a more limited scope. This is still
preferable to corrupting memory and/or crashing the kernel.

Signed-off-by: Gregory CLEMENT &lt;gregory.clement@bootlin.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Fix a reference leak bug in ip22_check_gio()</title>
<updated>2026-01-08T09:14:04+00:00</updated>
<author>
<name>Haoxiang Li</name>
<email>haoxiang_li2024@163.com</email>
</author>
<published>2025-12-04T10:36:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ed476f3836e1778449042a14a16ade6b1fb5404'/>
<id>urn:sha1:1ed476f3836e1778449042a14a16ade6b1fb5404</id>
<content type='text'>
[ Upstream commit 680ad315caaa2860df411cb378bf3614d96c7648 ]

If gio_device_register fails, gio_dev_put() is required to
drop the gio_dev device reference.

Fixes: e84de0c61905 ("MIPS: GIO bus support for SGI IP22/28")
Signed-off-by: Haoxiang Li &lt;haoxiang_li2024@163.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow</title>
<updated>2025-12-06T21:24:58+00:00</updated>
<author>
<name>Thomas Bogendoerfer</name>
<email>tsbogend@alpha.franken.de</email>
</author>
<published>2025-11-28T16:53:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=63a93d1cd6077d79735f804f5a4957bfb240280c'/>
<id>urn:sha1:63a93d1cd6077d79735f804f5a4957bfb240280c</id>
<content type='text'>
commit 841ecc979b18d3227fad5e2d6a1e6f92688776b5 upstream.

Owing to Config4.MMUSizeExt and VTLB/FTLB MMU features later MIPSr2+
cores can have more than 64 TLB entries.  Therefore allocate an array
for uniquification instead of placing too an small array on the stack.

Fixes: 35ad7e181541 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init")
Co-developed-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Signed-off-by: Maciej W. Rozycki &lt;macro@orcam.me.uk&gt;
Cc: stable@vger.kernel.org # v6.17+: 9f048fa48740: MIPS: mm: Prevent a TLB shutdown on initial uniquification
Cc: stable@vger.kernel.org # v6.17+
Tested-by: Gregory CLEMENT &lt;gregory.clement@bootlin.com&gt;
Tested-by: Klara Modin &lt;klarasmodin@gmail.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
