<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/mips/kernel, branch linux-5.12.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.12.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.12.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-07-19T08:00:51Z</updated>
<entry>
<title>MIPS: cpu-probe: Fix FPU detection on Ingenic JZ4760(B)</title>
<updated>2021-07-19T08:00:51Z</updated>
<author>
<name>Paul Cercueil</name>
</author>
<published>2021-05-30T17:17:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0993df9bb1e4de5b24b696c5bdca9bdf5f2de42a'/>
<id>urn:sha1:0993df9bb1e4de5b24b696c5bdca9bdf5f2de42a</id>
<content type='text'>
[ Upstream commit fc52f92a653215fbd6bc522ac5311857b335e589 ]

Ingenic JZ4760 and JZ4760B do have a FPU, but the config registers don't
report it. Force the FPU detection in case the processor ID match the
JZ4760(B) one.

Signed-off-by: Paul Cercueil &lt;paul@crapouillou.net&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>sched/core: Initialize the idle task with preemption disabled</title>
<updated>2021-07-14T14:59:16Z</updated>
<author>
<name>Valentin Schneider</name>
</author>
<published>2021-05-12T09:46:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1cb358b3ac1bb43aa8c4283830a84216dda65d39'/>
<id>urn:sha1:1cb358b3ac1bb43aa8c4283830a84216dda65d39</id>
<content type='text'>
[ Upstream commit f1a0a376ca0c4ef1fc3d24e3e502acbb5b795674 ]

As pointed out by commit

  de9b8f5dcbd9 ("sched: Fix crash trying to dequeue/enqueue the idle thread")

init_idle() can and will be invoked more than once on the same idle
task. At boot time, it is invoked for the boot CPU thread by
sched_init(). Then smp_init() creates the threads for all the secondary
CPUs and invokes init_idle() on them.

As the hotplug machinery brings the secondaries to life, it will issue
calls to idle_thread_get(), which itself invokes init_idle() yet again.
In this case it's invoked twice more per secondary: at _cpu_up(), and at
bringup_cpu().

Given smp_init() already initializes the idle tasks for all *possible*
CPUs, no further initialization should be required. Now, removing
init_idle() from idle_thread_get() exposes some interesting expectations
with regards to the idle task's preempt_count: the secondary startup always
issues a preempt_disable(), requiring some reset of the preempt count to 0
between hot-unplug and hotplug, which is currently served by
idle_thread_get() -&gt; idle_init().

Given the idle task is supposed to have preemption disabled once and never
see it re-enabled, it seems that what we actually want is to initialize its
preempt_count to PREEMPT_DISABLED and leave it there. Do that, and remove
init_idle() from idle_thread_get().

Secondary startups were patched via coccinelle:

  @begone@
  @@

  -preempt_disable();
  ...
  cpu_startup_entry(CPUHP_AP_ONLINE_IDLE);

Signed-off-by: Valentin Schneider &lt;valentin.schneider@arm.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Acked-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Link: https://lore.kernel.org/r/20210512094636.2958515-1-valentin.schneider@arm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Loongson64: Use _CACHE_UNCACHED instead of _CACHE_UNCACHED_ACCELERATED</title>
<updated>2021-05-19T08:56:13Z</updated>
<author>
<name>Tiezhu Yang</name>
</author>
<published>2021-04-06T09:25:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a3241f9019dfa9c53cf505d02fb9c229edb604de'/>
<id>urn:sha1:a3241f9019dfa9c53cf505d02fb9c229edb604de</id>
<content type='text'>
[ Upstream commit 5e65c52ec716af6e8f51dacdaeb4a4d872249af1 ]

Loongson64 processors have a writecombine issue that maybe failed to
write back framebuffer used with ATI Radeon or AMD GPU at times, after
commit 8a08e50cee66 ("drm: Permit video-buffers writecombine mapping
for MIPS"), there exists some errors such as blurred screen and lockup,
and so on.

[   60.958721] radeon 0000:03:00.0: ring 0 stalled for more than 10079msec
[   60.965315] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000000112 last fence id 0x000000000000011d on ring 0)
[   60.976525] radeon 0000:03:00.0: ring 3 stalled for more than 10086msec
[   60.983156] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000000374 last fence id 0x00000000000003a8 on ring 3)

As discussed earlier [1], it might be better to disable writecombine
on the CPU detection side because the root cause is unknown now.

Actually, this patch is a temporary solution to just make it work well,
it is not a proper and final solution, I hope someone will have a better
solution to fix this issue in the future.

[1] https://lore.kernel.org/patchwork/patch/1285542/

Signed-off-by: Tiezhu Yang &lt;yangtiezhu@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: kernel: setup.c: fix compilation error</title>
<updated>2021-03-30T12:51:23Z</updated>
<author>
<name>Mauri Sandberg</name>
</author>
<published>2021-03-29T12:31:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9ae31e2ab293bf4d9c42e7079b156072f8a7f8ca'/>
<id>urn:sha1:9ae31e2ab293bf4d9c42e7079b156072f8a7f8ca</id>
<content type='text'>
With ath79_defconfig enabling CONFIG_MIPS_ELF_APPENDED_DTB gives a
compilation error. This patch fixes it.

Build log:
...
  CC      kernel/locking/percpu-rwsem.o
../arch/mips/kernel/setup.c:46:39: error: conflicting types for
'__appended_dtb'
 const char __section(".appended_dtb") __appended_dtb[0x100000];
                                       ^~~~~~~~~~~~~~
In file included from ../arch/mips/kernel/setup.c:34:
../arch/mips/include/asm/bootinfo.h:118:13: note: previous declaration
of '__appended_dtb' was here
 extern char __appended_dtb[];
             ^~~~~~~~~~~~~~
  CC      fs/attr.o
make[4]: *** [../scripts/Makefile.build:271: arch/mips/kernel/setup.o]
 Error 1
...

Root cause seems to be:
Fixes: b83ba0b9df56 ("MIPS: of: Introduce helper function to get DTB")

Signed-off-by: Mauri Sandberg &lt;sandberg@mailfence.com&gt;
Reviewed-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Cc: trivial@kernel.org
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
</entry>
<entry>
<title>MIPS: vmlinux.lds.S: Fix appended dtb not properly aligned</title>
<updated>2021-03-16T21:53:08Z</updated>
<author>
<name>Paul Cercueil</name>
</author>
<published>2021-03-16T15:45:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3f6c515d723480bc8afd456b0a52438fe79128a8'/>
<id>urn:sha1:3f6c515d723480bc8afd456b0a52438fe79128a8</id>
<content type='text'>
Commit 6654111c893f ("MIPS: vmlinux.lds.S: align raw appended dtb to 8
bytes") changed the alignment from STRUCT_ALIGNMENT bytes to 8 bytes.

The commit's message makes it sound like it was actually done on
purpose, but this is not the case. The commit was written when raw
appended dtb were not aligned at all. The STRUCT_ALIGN() was added a few
days before, in commit 7a05293af39f ("MIPS: boot/compressed: Copy DTB to
aligned address"). The true purpose of the commit was not to align
specifically to 8 bytes, but to make sure that the generated vmlinux'
size was properly padded to the alignment required for DTBs.

While the switch to 8-byte alignment worked for vmlinux-appended dtb
blobs, it broke vmlinuz-appended dtb blobs, as the decompress routine
moves the blob to a STRUCT_ALIGNMENT aligned address.

Fix this by changing the raw appended dtb blob alignment from 8 bytes
back to STRUCT_ALIGNMENT bytes in vmlinux.lds.S.

Fixes: 6654111c893f ("MIPS: vmlinux.lds.S: align raw appended dtb to 8 bytes")
Cc: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
</entry>
<entry>
<title>MIPS: kernel: Reserve exception base early to prevent corruption</title>
<updated>2021-03-09T10:22:59Z</updated>
<author>
<name>Thomas Bogendoerfer</name>
</author>
<published>2021-03-08T09:24:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739'/>
<id>urn:sha1:bd67b711bfaa02cf19e88aa2d9edae5c1c1d2739</id>
<content type='text'>
BMIPS is one of the few platforms that do change the exception base.
After commit 2dcb39645441 ("memblock: do not start bottom-up allocations
with kernel_end") we started seeing BMIPS boards fail to boot with the
built-in FDT being corrupted.

Before the cited commit, early allocations would be in the [kernel_end,
RAM_END] range, but after commit they would be within [RAM_START +
PAGE_SIZE, RAM_END].

The custom exception base handler that is installed by
bmips_ebase_setup() done for BMIPS5000 CPUs ends-up trampling on the
memory region allocated by unflatten_and_copy_device_tree() thus
corrupting the FDT used by the kernel.

To fix this, we need to perform an early reservation of the custom
exception space. Additional we reserve the first 4k (1k for R3k) for
either normal exception vector space (legacy CPUs) or special vectors
like cache exceptions.

Huge thanks to Serge for analysing and proposing a solution to this
issue.

Fixes: 2dcb39645441 ("memblock: do not start bottom-up allocations with kernel_end")
Reported-by: Kamal Dasu &lt;kdasu.kdev@gmail.com&gt;
Debugged-by: Serge Semin &lt;Sergey.Semin@baikalelectronics.ru&gt;
Acked-by: Mike Rapoport &lt;rppt@linux.ibm.com&gt;
Tested-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Reviewed-by: Serge Semin &lt;fancer.lancer@gmail.com&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
</entry>
<entry>
<title>MIPS: vmlinux.lds.S: align raw appended dtb to 8 bytes</title>
<updated>2021-03-08T17:36:08Z</updated>
<author>
<name>Bjørn Mork</name>
</author>
<published>2021-03-07T18:23:01Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6654111c893fec1516d83046d2b237e83e0d5967'/>
<id>urn:sha1:6654111c893fec1516d83046d2b237e83e0d5967</id>
<content type='text'>
The devicetree specification requires 8-byte alignment in
memory. This is now enforced by libfdt since commit 79edff12060f
("scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9")
which included the upstream commit 5e735860c478 ("libfdt: Check for
8-byte address alignment in fdt_ro_probe_()").

This broke the MIPS raw appended DTBs which would be appended to
the image immediately following the initramfs section.  This ends
with a 32bit size, resulting in a 4-byte alignment of the DTB.

Fix by padding with zeroes to 8-bytes when MIPS_RAW_APPENDED_DTB
is defined.

Fixes: 79edff12060f ("scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9")
Cc: Rob Herring &lt;robh+dt@kernel.org&gt;
Cc: Frank Rowand &lt;frowand.list@gmail.com&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
</entry>
<entry>
<title>MIPS: boot/compressed: Copy DTB to aligned address</title>
<updated>2021-03-08T10:49:47Z</updated>
<author>
<name>Paul Cercueil</name>
</author>
<published>2021-03-03T19:33:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=7a05293af39fc716d0f51c0164cbb727302396a2'/>
<id>urn:sha1:7a05293af39fc716d0f51c0164cbb727302396a2</id>
<content type='text'>
Since 5.12-rc1, the Device Tree blob must now be properly aligned.

Therefore, the decompress routine must be careful to copy the blob at
the next aligned address after the kernel image.

This commit fixes the kernel sometimes not booting with a Device Tree
blob appended to it.

Fixes: 79edff12060f ("scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9")
Signed-off-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Acked-by: Rob Herring &lt;robh@kernel.org&gt;
Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
</content>
</entry>
<entry>
<title>Merge tag 'io_uring-worker.v3-2021-02-25' of git://git.kernel.dk/linux-block</title>
<updated>2021-02-27T16:29:02Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2021-02-27T16:29:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5695e51619745d4fe3ec2506a2f0cd982c5e27a4'/>
<id>urn:sha1:5695e51619745d4fe3ec2506a2f0cd982c5e27a4</id>
<content type='text'>
Pull io_uring thread rewrite from Jens Axboe:
 "This converts the io-wq workers to be forked off the tasks in question
  instead of being kernel threads that assume various bits of the
  original task identity.

  This kills &gt; 400 lines of code from io_uring/io-wq, and it's the worst
  part of the code. We've had several bugs in this area, and the worry
  is always that we could be missing some pieces for file types doing
  unusual things (recent /dev/tty example comes to mind, userfaultfd
  reads installing file descriptors is another fun one... - both of
  which need special handling, and I bet it's not the last weird oddity
  we'll find).

  With these identical workers, we can have full confidence that we're
  never missing anything. That, in itself, is a huge win. Outside of
  that, it's also more efficient since we're not wasting space and code
  on tracking state, or switching between different states.

  I'm sure we're going to find little things to patch up after this
  series, but testing has been pretty thorough, from the usual
  regression suite to production. Any issue that may crop up should be
  manageable.

  There's also a nice series of further reductions we can do on top of
  this, but I wanted to get the meat of it out sooner rather than later.
  The general worry here isn't that it's fundamentally broken. Most of
  the little issues we've found over the last week have been related to
  just changes in how thread startup/exit is done, since that's the main
  difference between using kthreads and these kinds of threads. In fact,
  if all goes according to plan, I want to get this into the 5.10 and
  5.11 stable branches as well.

  That said, the changes outside of io_uring/io-wq are:

   - arch setup, simple one-liner to each arch copy_thread()
     implementation.

   - Removal of net and proc restrictions for io_uring, they are no
     longer needed or useful"

* tag 'io_uring-worker.v3-2021-02-25' of git://git.kernel.dk/linux-block: (30 commits)
  io-wq: remove now unused IO_WQ_BIT_ERROR
  io_uring: fix SQPOLL thread handling over exec
  io-wq: improve manager/worker handling over exec
  io_uring: ensure SQPOLL startup is triggered before error shutdown
  io-wq: make buffered file write hashed work map per-ctx
  io-wq: fix race around io_worker grabbing
  io-wq: fix races around manager/worker creation and task exit
  io_uring: ensure io-wq context is always destroyed for tasks
  arch: ensure parisc/powerpc handle PF_IO_WORKER in copy_thread()
  io_uring: cleanup -&gt;user usage
  io-wq: remove nr_process accounting
  io_uring: flag new native workers with IORING_FEAT_NATIVE_WORKERS
  net: remove cmsg restriction from io_uring based send/recvmsg calls
  Revert "proc: don't allow async path resolution of /proc/self components"
  Revert "proc: don't allow async path resolution of /proc/thread-self components"
  io_uring: move SQPOLL thread io-wq forked worker
  io-wq: make io_wq_fork_thread() available to other users
  io-wq: only remove worker from free_list, if it was there
  io_uring: remove io_identity
  io_uring: remove any grabbing of context
  ...
</content>
</entry>
<entry>
<title>Merge tag 'mips_5.12_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux</title>
<updated>2021-02-25T20:18:21Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2021-02-25T20:18:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=a6525b999970466b548d41e73d3b814233fa42ca'/>
<id>urn:sha1:a6525b999970466b548d41e73d3b814233fa42ca</id>
<content type='text'>
Pull more MIPS updates from Thomas Bogendoerfer:

 - added n64 block driver

 - fix for ubsan warnings

 - fix for bcm63xx platform

 - update of linux-mips mailinglist

* tag 'mips_5.12_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
  arch: mips: update references to current linux-mips list
  mips: bmips: init clocks earlier
  vmlinux.lds.h: catch even more instrumentation symbols into .data
  n64: store dev instance into disk private data
  n64: cleanup n64cart_probe()
  n64: cosmetics changes
  n64: remove curly brackets
  n64: use sector SECTOR_SHIFT instead 512
  n64: use enums for reg
  n64: move module param at the top
  n64: move module info at the end
  n64: use pr_fmt to avoid duplicate string
  block: Add n64 cart driver
</content>
</entry>
</feed>
