<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/mips/kernel, branch linux-5.8.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.8.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.8.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-09-09T17:14:22Z</updated>
<entry>
<title>MIPS: add missing MSACSR and upper MSA initialization</title>
<updated>2020-09-09T17:14:22Z</updated>
<author>
<name>Huang Pei</name>
</author>
<published>2020-09-01T06:53:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b5c901d96a596a20fe97d85690acf23e85d6b857'/>
<id>urn:sha1:b5c901d96a596a20fe97d85690acf23e85d6b857</id>
<content type='text'>
[ Upstream commit bb06748207cfb1502d11b90325eba7f8c44c9f02 ]

In cc97ab235f3f ("MIPS: Simplify FP context initialization), init_fp_ctx
just initialize the fp/msa context, and own_fp_inatomic just restore
FCSR and 64bit FP regs from it, but miss MSACSR and upper MSA regs for
MSA, so MSACSR and MSA upper regs's value from previous task on current
cpu can leak into current task and cause unpredictable behavior when MSA
context not initialized.

Fixes: cc97ab235f3f ("MIPS: Simplify FP context initialization")
Signed-off-by: Huang Pei &lt;huangpei@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: perf: Fix wrong check condition of Loongson event IDs</title>
<updated>2020-09-09T17:14:20Z</updated>
<author>
<name>Tiezhu Yang</name>
</author>
<published>2020-08-27T08:03:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bbb1dc4431b0c37eca621a2d618c8d3c1276e5a9'/>
<id>urn:sha1:bbb1dc4431b0c37eca621a2d618c8d3c1276e5a9</id>
<content type='text'>
[ Upstream commit a231995700c392c0807da95deea231b23fc51a3c ]

According to the user's manual chapter 8.2.1 of Loongson 3A2000 CPU [1]
and 3A3000 CPU [2], we should take some event IDs such as 274, 358, 359
and 360 as valid in the check condition, otherwise they are recognized
as "not supported", fix it.

[1] http://www.loongson.cn/uploadfile/cpu/3A2000/Loongson3A2000_user2.pdf
[2] http://www.loongson.cn/uploadfile/cpu/3A3000/Loongson3A3000_3B3000user2.pdf

Fixes: e9dfbaaeef1c ("MIPS: perf: Add hardware perf events support for new Loongson-3")
Signed-off-by: Tiezhu Yang &lt;yangtiezhu@loongson.cn&gt;
Acked-by: Huang Pei &lt;huangpei@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: BMIPS: Also call bmips_cpu_setup() for secondary cores</title>
<updated>2020-09-09T17:14:14Z</updated>
<author>
<name>Florian Fainelli</name>
</author>
<published>2020-08-19T18:26:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=17c1b210b6eae92193bd0f442136a27ac93c9064'/>
<id>urn:sha1:17c1b210b6eae92193bd0f442136a27ac93c9064</id>
<content type='text'>
[ Upstream commit e14f633b66902615cf7faa5d032b45ab8b6fb158 ]

The initialization done by bmips_cpu_setup() typically affects both
threads of a given core, on 7435 which supports 2 cores and 2 threads,
logical CPU number 2 and 3 would not run this initialization.

Fixes: 738a3f79027b ("MIPS: BMIPS: Add early CPU initialization code")
Signed-off-by: Florian Fainelli &lt;f.fainelli@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: Fix unable to reserve memory for Crash kernel</title>
<updated>2020-08-26T09:49:05Z</updated>
<author>
<name>Jinyang He</name>
</author>
<published>2020-07-25T05:56:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4accb5af385b80d2cb68aa56fcbe818bcd6ee7b9'/>
<id>urn:sha1:4accb5af385b80d2cb68aa56fcbe818bcd6ee7b9</id>
<content type='text'>
[ Upstream commit b1ce9716f3b5ed3b49badf1f003b9e34b7ead0f9 ]

Use 0 as the align parameter in memblock_find_in_range() is
incorrect when we reserve memory for Crash kernel.

The environment as follows:
[    0.000000] MIPS: machine is loongson,loongson64c-4core-rs780e
...
[    1.951016]     crashkernel=64M@128M

The warning as follows:
[    0.000000] Invalid memory region reserved for crash kernel

And the iomem as follows:
00200000-0effffff : System RAM
  04000000-0484009f : Kernel code
  048400a0-04ad7fff : Kernel data
  04b40000-05c4c6bf : Kernel bss
1a000000-1bffffff : pci@1a000000
...

The align parameter may be finally used by round_down() or round_up().
Like the following call tree:

mips-next: mm/memblock.c

memblock_find_in_range
└── memblock_find_in_range_node
    ├── __memblock_find_range_bottom_up
    │   └── round_up
    └── __memblock_find_range_top_down
        └── round_down
\#define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)
\#define round_down(x, y) ((x) &amp; ~__round_mask(x, y))
\#define __round_mask(x, y) ((__typeof__(x))((y)-1))

The round_down(or round_up)'s second parameter must be a power of 2.
If the second parameter is 0, it both will return 0.

Use 1 as the parameter to fix the bug and the iomem as follows:
00200000-0effffff : System RAM
  04000000-0484009f : Kernel code
  048400a0-04ad7fff : Kernel data
  04b40000-05c4c6bf : Kernel bss
  08000000-0bffffff : Crash kernel
1a000000-1bffffff : pci@1a000000
...

Signed-off-by: Jinyang He &lt;hejinyang@loongson.cn&gt;
Reviewed-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: CPU#0 is not hotpluggable</title>
<updated>2020-08-21T11:14:57Z</updated>
<author>
<name>Huacai Chen</name>
</author>
<published>2020-07-16T10:40:23Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=41158a79e505bf38524688243fe1315b724f19cc'/>
<id>urn:sha1:41158a79e505bf38524688243fe1315b724f19cc</id>
<content type='text'>
commit 9cce844abf07b683cff5f0273977d5f8d0af94c7 upstream.

Now CPU#0 is not hotpluggable on MIPS, so prevent to create /sys/devices
/system/cpu/cpu0/online which confuses some user-space tools.

Cc: stable@vger.kernel.org
Signed-off-by: Huacai Chen &lt;chenhc@lemote.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>
<entry>
<title>MIPS: only register FTLBPar exception handler for supported models</title>
<updated>2020-08-19T06:26:51Z</updated>
<author>
<name>WANG Xuerui</name>
</author>
<published>2020-07-29T13:14:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bd82844099c4f668889ea95084cf499b179fa62e'/>
<id>urn:sha1:bd82844099c4f668889ea95084cf499b179fa62e</id>
<content type='text'>
[ Upstream commit efd1b4ad3d5178a74387bc5ff69a2d4585f586c6 ]

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 &lt;chenhc@lemote.com&gt;
Signed-off-by: WANG Xuerui &lt;git@xen0n.name&gt;
Cc: Paul Burton &lt;paulburton@kernel.org&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>Merge tag 'mips_fixes_5.8_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux</title>
<updated>2020-07-05T17:29:32Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2020-07-05T17:29:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=45a5ac7a5cc3c71739d240c422c3818a5bc97fc4'/>
<id>urn:sha1:45a5ac7a5cc3c71739d240c422c3818a5bc97fc4</id>
<content type='text'>
Pull MIPS fixes from Thomas Bogendoerfer:

 - fix for missing hazard barrier

 - DT fix for ingenic

 - DT fix of GPHY names for lantiq

 - fix usage of smp_processor_id() while preemption is enabled

* tag 'mips_fixes_5.8_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
  MIPS: Do not use smp_processor_id() in preemptible code
  MIPS: Add missing EHB in mtc0 -&gt; mfc0 sequence for DSPen
  MIPS: ingenic: gcw0: Fix HP detection GPIO.
  MIPS: lantiq: xway: sysctrl: fix the GPHY clock alias names
</content>
</entry>
<entry>
<title>MIPS: Do not use smp_processor_id() in preemptible code</title>
<updated>2020-07-05T09:43:52Z</updated>
<author>
<name>Xingxing Su</name>
</author>
<published>2020-07-03T04:11:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5868347a192afb99b189d72946ab6a321b6115ac'/>
<id>urn:sha1:5868347a192afb99b189d72946ab6a321b6115ac</id>
<content type='text'>
Use preempt_disable() to fix the following bug under CONFIG_DEBUG_PREEMPT.

[   21.915305] BUG: using smp_processor_id() in preemptible [00000000] code: qemu-system-mip/1056
[   21.923996] caller is do_ri+0x1d4/0x690
[   21.927921] CPU: 0 PID: 1056 Comm: qemu-system-mip Not tainted 5.8.0-rc2 #3
[   21.934913] Stack : 0000000000000001 ffffffff81370000 ffffffff8071cd60 a80f926d5ac95694
[   21.942984]         a80f926d5ac95694 0000000000000000 98000007f0043c88 ffffffff80f2fe40
[   21.951054]         0000000000000000 0000000000000000 0000000000000001 0000000000000000
[   21.959123]         ffffffff802d60cc 98000007f0043dd8 ffffffff81f4b1e8 ffffffff81f60000
[   21.967192]         ffffffff81f60000 ffffffff80fe0000 ffff000000000000 0000000000000000
[   21.975261]         fffffffff500cce1 0000000000000001 0000000000000002 0000000000000000
[   21.983331]         ffffffff80fe1a40 0000000000000006 ffffffff8077f940 0000000000000000
[   21.991401]         ffffffff81460000 98000007f0040000 98000007f0043c80 000000fffba8cf20
[   21.999471]         ffffffff8071cd60 0000000000000000 0000000000000000 0000000000000000
[   22.007541]         0000000000000000 0000000000000000 ffffffff80212ab4 a80f926d5ac95694
[   22.015610]         ...
[   22.018086] Call Trace:
[   22.020562] [&lt;ffffffff80212ab4&gt;] show_stack+0xa4/0x138
[   22.025732] [&lt;ffffffff8071cd60&gt;] dump_stack+0xf0/0x150
[   22.030903] [&lt;ffffffff80c73f5c&gt;] check_preemption_disabled+0xf4/0x100
[   22.037375] [&lt;ffffffff80213b84&gt;] do_ri+0x1d4/0x690
[   22.042198] [&lt;ffffffff8020b828&gt;] handle_ri_int+0x44/0x5c
[   24.359386] BUG: using smp_processor_id() in preemptible [00000000] code: qemu-system-mip/1072
[   24.368204] caller is do_ri+0x1a8/0x690
[   24.372169] CPU: 4 PID: 1072 Comm: qemu-system-mip Not tainted 5.8.0-rc2 #3
[   24.379170] Stack : 0000000000000001 ffffffff81370000 ffffffff8071cd60 a80f926d5ac95694
[   24.387246]         a80f926d5ac95694 0000000000000000 98001007ef06bc88 ffffffff80f2fe40
[   24.395318]         0000000000000000 0000000000000000 0000000000000001 0000000000000000
[   24.403389]         ffffffff802d60cc 98001007ef06bdd8 ffffffff81f4b818 ffffffff81f60000
[   24.411461]         ffffffff81f60000 ffffffff80fe0000 ffff000000000000 0000000000000000
[   24.419533]         fffffffff500cce1 0000000000000001 0000000000000002 0000000000000000
[   24.427603]         ffffffff80fe0000 0000000000000006 ffffffff8077f940 0000000000000020
[   24.435673]         ffffffff81460020 98001007ef068000 98001007ef06bc80 000000fffbbbb370
[   24.443745]         ffffffff8071cd60 0000000000000000 0000000000000000 0000000000000000
[   24.451816]         0000000000000000 0000000000000000 ffffffff80212ab4 a80f926d5ac95694
[   24.459887]         ...
[   24.462367] Call Trace:
[   24.464846] [&lt;ffffffff80212ab4&gt;] show_stack+0xa4/0x138
[   24.470029] [&lt;ffffffff8071cd60&gt;] dump_stack+0xf0/0x150
[   24.475208] [&lt;ffffffff80c73f5c&gt;] check_preemption_disabled+0xf4/0x100
[   24.481682] [&lt;ffffffff80213b58&gt;] do_ri+0x1a8/0x690
[   24.486509] [&lt;ffffffff8020b828&gt;] handle_ri_int+0x44/0x5c

Signed-off-by: Xingxing Su &lt;suxingxing@loongson.cn&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
</entry>
<entry>
<title>MIPS: Add missing EHB in mtc0 -&gt; mfc0 sequence for DSPen</title>
<updated>2020-07-05T09:43:25Z</updated>
<author>
<name>Hauke Mehrtens</name>
</author>
<published>2020-07-02T22:53:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fcec538ef8cca0ad0b84432235dccd9059c8e6f8'/>
<id>urn:sha1:fcec538ef8cca0ad0b84432235dccd9059c8e6f8</id>
<content type='text'>
This resolves the hazard between the mtc0 in the change_c0_status() and
the mfc0 in configure_exception_vector(). Without resolving this hazard
configure_exception_vector() could read an old value and would restore
this old value again. This would revert the changes change_c0_status()
did. I checked this by printing out the read_c0_status() at the end of
per_cpu_trap_init() and the ST0_MX is not set without this patch.

The hazard is documented in the MIPS Architecture Reference Manual Vol.
III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
6.03 table 8.1 which includes:

   Producer | Consumer | Hazard
  ----------|----------|----------------------------
   mtc0     | mfc0     | any coprocessor 0 register

I saw this hazard on an Atheros AR9344 rev 2 SoC with a MIPS 74Kc CPU.
There the change_c0_status() function would activate the DSPen by
setting ST0_MX in the c0_status register. This was reverted and then the
system got a DSP exception when the DSP registers were saved in
save_dsp() in the first process switch. The crash looks like this:

[    0.089999] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.097796] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.107070] Kernel panic - not syncing: Unexpected DSP exception
[    0.113470] Rebooting in 1 seconds..

We saw this problem in OpenWrt only on the MIPS 74Kc based Atheros SoCs,
not on the 24Kc based SoCs. We only saw it with kernel 5.4 not with
kernel 4.19, in addition we had to use GCC 8.4 or 9.X, with GCC 8.3 it
did not happen.

In the kernel I bisected this problem to commit 9012d011660e ("compiler:
allow all arches to enable CONFIG_OPTIMIZE_INLINING"), but when this was
reverted it also happened after commit 172dcd935c34b ("MIPS: Always
allocate exception vector for MIPSr2+").

Commit 0b24cae4d535 ("MIPS: Add missing EHB in mtc0 -&gt; mfc0 sequence.")
does similar changes to a different file. I am not sure if there are
more places affected by this problem.

Signed-off-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
</entry>
<entry>
<title>maccess: rename probe_kernel_{read,write} to copy_{from,to}_kernel_nofault</title>
<updated>2020-06-17T17:57:41Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2020-06-17T07:37:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fe557319aa06c23cffc9346000f119547e0f289a'/>
<id>urn:sha1:fe557319aa06c23cffc9346000f119547e0f289a</id>
<content type='text'>
Better describe what these functions do.

Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
</feed>
