<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/riscv/kernel/setup.c, branch linux-5.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-08-26T12:35:18Z</updated>
<entry>
<title>riscv: Fix a number of free'd resources in init_resources()</title>
<updated>2021-08-26T12:35:18Z</updated>
<author>
<name>Petr Pavlu</name>
</author>
<published>2021-08-07T17:54:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2d1704c3fe301972c8e139f37561eaed8153cdf8'/>
<id>urn:sha1:2d1704c3fe301972c8e139f37561eaed8153cdf8</id>
<content type='text'>
[ Upstream commit aa3e1ba32e553e611a58145c2eb349802feaa6eb ]

Function init_resources() allocates a boot memory block to hold an array of
resources which it adds to iomem_resource. The array is filled in from its
end and the function then attempts to free any unused memory at the
beginning. The problem is that size of the unused memory is incorrectly
calculated and this can result in releasing memory which is in use by
active resources. Their data then gets corrupted later when the memory is
reused by a different part of the system.

Fix the size of the released memory to correctly match the number of unused
resource entries.

Fixes: ffe0e5261268 ("RISC-V: Improve init_resources()")
Signed-off-by: Petr Pavlu &lt;petr.pavlu@suse.com&gt;
Reviewed-by: Sunil V L &lt;sunilvl@ventanamicro.com&gt;
Acked-by: Nick Kossifidis &lt;mick@ics.forth.gr&gt;
Tested-by: Sunil V L &lt;sunilvl@ventanamicro.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>RISC-V: Fix memblock_free() usages in init_resources()</title>
<updated>2021-06-02T04:16:42Z</updated>
<author>
<name>Wende Tan</name>
</author>
<published>2021-05-22T17:49:51Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=da2d48808fbd1eddefefe245c6c0e92a9195df8b'/>
<id>urn:sha1:da2d48808fbd1eddefefe245c6c0e92a9195df8b</id>
<content type='text'>
`memblock_free()` takes a physical address as its first argument.
Fix the wrong usages in `init_resources()`.

Fixes: ffe0e526126884cf036a6f724220f1f9b4094fd2 ("RISC-V: Improve init_resources()")
Fixes: 797f0375dd2ef5cdc68ac23450cbae9a5c67a74e ("RISC-V: Do not allocate memblock while iterating reserved memblocks")
Signed-off-by: Wende Tan &lt;twd2.me@gmail.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: Consistify protect_kernel_linear_mapping_text_rodata() use</title>
<updated>2021-05-06T16:40:15Z</updated>
<author>
<name>Geert Uytterhoeven</name>
</author>
<published>2021-04-29T15:10:04Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8d91b097335892bfbc9fd5783e80e25f0fb5bb2b'/>
<id>urn:sha1:8d91b097335892bfbc9fd5783e80e25f0fb5bb2b</id>
<content type='text'>
The various uses of protect_kernel_linear_mapping_text_rodata() are
not consistent:
  - Its definition depends on "64BIT &amp;&amp; !XIP_KERNEL",
  - Its forward declaration depends on MMU,
  - Its single caller depends on "STRICT_KERNEL_RWX &amp;&amp; 64BIT &amp;&amp; MMU &amp;&amp;
    !XIP_KERNEL".

Fix this by settling on the dependencies of the caller, which can be
simplified as STRICT_KERNEL_RWX depends on "MMU &amp;&amp; !XIP_KERNEL".
Provide a dummy definition, as the caller is protected by
"IS_ENABLED(CONFIG_STRICT_KERNEL_RWX)" instead of "#ifdef
CONFIG_STRICT_KERNEL_RWX".

Signed-off-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Tested-by: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>RISC-V: enable XIP</title>
<updated>2021-04-26T15:31:28Z</updated>
<author>
<name>Vitaly Wool</name>
</author>
<published>2021-04-13T06:35:14Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=44c922572952d89a1ed15764f2b373ba62692865'/>
<id>urn:sha1:44c922572952d89a1ed15764f2b373ba62692865</id>
<content type='text'>
Introduce XIP (eXecute In Place) support for RISC-V platforms.
It allows code to be executed directly from non-volatile storage
directly addressable by the CPU, such as QSPI NOR flash which can
be found on many RISC-V platforms. This makes way for significant
optimization of RAM footprint. The XIP kernel is not compressed
since it has to run directly from flash, so it will occupy more
space on the non-volatile storage. The physical flash address used
to link the kernel object files and for storing it has to be known
at compile time and is represented by a Kconfig option.

XIP on RISC-V will for the time being only work on MMU-enabled
kernels.

Signed-off-by: Vitaly Wool &lt;vitaly.wool@konsulko.com&gt;
[Alex: Rebase on top of "Move kernel mapping outside the linear mapping" ]
Signed-off-by: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
[Palmer: disable XIP for allyesconfig]
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>RISC-V: Add crash kernel support</title>
<updated>2021-04-26T15:25:24Z</updated>
<author>
<name>Nick Kossifidis</name>
</author>
<published>2021-04-19T00:55:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5640975003d0234da08559677e22ec25b9cb3267'/>
<id>urn:sha1:5640975003d0234da08559677e22ec25b9cb3267</id>
<content type='text'>
This patch allows Linux to act as a crash kernel for use with
kdump. Userspace will let the crash kernel know about the
memory region it can use through linux,usable-memory property
on the /memory node (overriding its reg property), and about the
memory region where the elf core header of the previous kernel
is saved, through a reserved-memory node with a compatible string
of "linux,elfcorehdr". This approach is the least invasive and
re-uses functionality already present.

I tested this on riscv64 qemu and it works as expected, you
may test it by retrieving the dmesg of the previous kernel
through /proc/vmcore, using the vmcore-dmesg utility from
kexec-tools.

Signed-off-by: Nick Kossifidis &lt;mick@ics.forth.gr&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>RISC-V: Add kdump support</title>
<updated>2021-04-26T15:25:23Z</updated>
<author>
<name>Nick Kossifidis</name>
</author>
<published>2021-04-19T00:55:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e53d28180d4d0fd12b6d2bde49cb87aa775b6ba8'/>
<id>urn:sha1:e53d28180d4d0fd12b6d2bde49cb87aa775b6ba8</id>
<content type='text'>
This patch adds support for kdump, the kernel will reserve a
region for the crash kernel and jump there on panic. In order
for userspace tools (kexec-tools) to prepare the crash kernel
kexec image, we also need to expose some information on
/proc/iomem for the memory regions used by the kernel and for
the region reserved for crash kernel. Note that on userspace
the device tree is used to determine the system's memory
layout so the "System RAM" on /proc/iomem is ignored.

I tested this on riscv64 qemu and works as expected, you may
test it by triggering a crash through /proc/sysrq_trigger:

echo c &gt; /proc/sysrq_trigger

Signed-off-by: Nick Kossifidis &lt;mick@ics.forth.gr&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>RISC-V: Improve init_resources()</title>
<updated>2021-04-26T15:25:22Z</updated>
<author>
<name>Nick Kossifidis</name>
</author>
<published>2021-04-19T00:55:37Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ffe0e526126884cf036a6f724220f1f9b4094fd2'/>
<id>urn:sha1:ffe0e526126884cf036a6f724220f1f9b4094fd2</id>
<content type='text'>
The kernel region is always present and we know where it is, no need to
look for it inside the loop, just ignore it like the rest of the
reserved regions within system's memory.

Additionally, we don't need to call memblock_free inside the loop, as if
called it'll split the region of pre-allocated resources in two parts,
messing things up, just re-use the previous pre-allocated resource and
free any unused resources after both loops finish.

Signed-off-by: Nick Kossifidis &lt;mick@ics.forth.gr&gt;
[Palmer: commit text]
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>riscv: Move kernel mapping outside of linear mapping</title>
<updated>2021-04-26T15:25:04Z</updated>
<author>
<name>Alexandre Ghiti</name>
</author>
<published>2021-04-11T16:41:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2bfc6cd81bd17e4306e24ee47b9554c967bcb499'/>
<id>urn:sha1:2bfc6cd81bd17e4306e24ee47b9554c967bcb499</id>
<content type='text'>
This is a preparatory patch for relocatable kernel and sv48 support.

The kernel used to be linked at PAGE_OFFSET address therefore we could use
the linear mapping for the kernel mapping. But the relocated kernel base
address will be different from PAGE_OFFSET and since in the linear mapping,
two different virtual addresses cannot point to the same physical address,
the kernel mapping needs to lie outside the linear mapping so that we don't
have to copy it at the same physical offset.

The kernel mapping is moved to the last 2GB of the address space, BPF
is now always after the kernel and modules use the 2GB memory range right
before the kernel, so BPF and modules regions do not overlap. KASLR
implementation will simply have to move the kernel in the last 2GB range
and just take care of leaving enough space for BPF.

In addition, by moving the kernel to the end of the address space, both
sv39 and sv48 kernels will be exactly the same without needing to be
relocated at runtime.

Suggested-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Alexandre Ghiti &lt;alex@ghiti.fr&gt;
[Palmer: Squash the STRICT_RWX fix, and a !MMU fix]
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'riscv-for-linus-5.12-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2021-02-26T18:28:35Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2021-02-26T18:28:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8b83369ddcb3fb9cab5c1088987ce477565bb630'/>
<id>urn:sha1:8b83369ddcb3fb9cab5c1088987ce477565bb630</id>
<content type='text'>
Pull RISC-V updates from Palmer Dabbelt:
 "A handful of new RISC-V related patches for this merge window:

   - A check to ensure drivers are properly using uaccess. This isn't
     manifesting with any of the drivers I'm currently using, but may
     catch errors in new drivers.

   - Some preliminary support for the FU740, along with the HiFive
     Unleashed it will appear on.

   - NUMA support for RISC-V, which involves making the arm64 code
     generic.

   - Support for kasan on the vmalloc region.

   - A handful of new drivers for the Kendryte K210, along with the DT
     plumbing required to boot on a handful of K210-based boards.

   - Support for allocating ASIDs.

   - Preliminary support for kernels larger than 128MiB.

   - Various other improvements to our KASAN support, including the
     utilization of huge pages when allocating the KASAN regions.

  We may have already found a bug with the KASAN_VMALLOC code, but it's
  passing my tests. There's a fix in the works, but that will probably
  miss the merge window.

* tag 'riscv-for-linus-5.12-mw0' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: (75 commits)
  riscv: Improve kasan population by using hugepages when possible
  riscv: Improve kasan population function
  riscv: Use KASAN_SHADOW_INIT define for kasan memory initialization
  riscv: Improve kasan definitions
  riscv: Get rid of MAX_EARLY_MAPPING_SIZE
  soc: canaan: Sort the Makefile alphabetically
  riscv: Disable KSAN_SANITIZE for vDSO
  riscv: Remove unnecessary declaration
  riscv: Add Canaan Kendryte K210 SD card defconfig
  riscv: Update Canaan Kendryte K210 defconfig
  riscv: Add Kendryte KD233 board device tree
  riscv: Add SiPeed MAIXDUINO board device tree
  riscv: Add SiPeed MAIX GO board device tree
  riscv: Add SiPeed MAIX DOCK board device tree
  riscv: Add SiPeed MAIX BiT board device tree
  riscv: Update Canaan Kendryte K210 device tree
  dt-bindings: add resets property to dw-apb-timer
  dt-bindings: fix sifive gpio properties
  dt-bindings: update sifive uart compatible string
  dt-bindings: update sifive clint compatible string
  ...
</content>
</entry>
<entry>
<title>RISC-V: Fix .init section permission update</title>
<updated>2021-02-03T02:35:42Z</updated>
<author>
<name>Atish Patra</name>
</author>
<published>2021-01-29T19:00:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f105ea9890f42137344f8c08548c895dc9294bd8'/>
<id>urn:sha1:f105ea9890f42137344f8c08548c895dc9294bd8</id>
<content type='text'>
.init section permission should only updated to non-execute if
STRICT_KERNEL_RWX is enabled. Otherwise, this will lead to a kernel hang.

Fixes: 19a00869028f ("RISC-V: Protect all kernel sections including init early")
Cc: stable@vger.kernel.org
Suggested-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Reported-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Atish Patra &lt;atish.patra@wdc.com&gt;
Reviewed-by: Atish Patra &lt;atish.patra@wdc.com&gt;
Signed-off-by: Palmer Dabbelt &lt;palmerdabbelt@google.com&gt;
</content>
</entry>
</feed>
