<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/riscv, branch v6.11</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'riscv-for-linus-6.11-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux</title>
<updated>2024-09-12T20:03:45+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-09-12T20:03:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8581ae1ea0d203a71851b21455c2d5167ba00e50'/>
<id>8581ae1ea0d203a71851b21455c2d5167ba00e50</id>
<content type='text'>
Pull RISC-V fixes from Palmer Dabbelt:

 - Two fixes for smp_processor_id() calls in preemptible sections: one
   if the perf driver, and one in the fence.i prctl.

* tag 'riscv-for-linus-6.11-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: Disable preemption while handling PR_RISCV_CTX_SW_FENCEI_OFF
  drivers: perf: Fix smp_processor_id() use in preemptible code
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull RISC-V fixes from Palmer Dabbelt:

 - Two fixes for smp_processor_id() calls in preemptible sections: one
   if the perf driver, and one in the fence.i prctl.

* tag 'riscv-for-linus-6.11-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
  riscv: Disable preemption while handling PR_RISCV_CTX_SW_FENCEI_OFF
  drivers: perf: Fix smp_processor_id() use in preemptible code
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'arm-fixes-6.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc</title>
<updated>2024-09-11T18:26:56+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-09-11T18:26:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=77f587896757708780a7e8792efe62939f25a5ab'/>
<id>77f587896757708780a7e8792efe62939f25a5ab</id>
<content type='text'>
Pull ARM SoC fixes from Arnd Bergmann:
 "The bulk of the changes this time are for device tree files in the
  rockchips platform, addressing correctness issues on individual
  boards, plus one change in the rk356x SoC file to make it match the
  binding.

  The only other changes that came in are

   - a CPU frequencey scaling fix for JH7110 (RISC-V)

   - a build fix for the cznic hwrandom driver

   - a fix for a deadlock in qualcomm uefi secure application firmware
     driver"

* tag 'arm-fixes-6.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  platform: cznic: turris-omnia-mcu: fix HW_RANDOM dependency
  riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz
  firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()
  arm64: dts: rockchip: Fix compatibles for RK3588 VO{0,1}_GRF
  dt-bindings: soc: rockchip: Fix compatibles for RK3588 VO{0,1}_GRF
  arm64: dts: rockchip: override BIOS_DISABLE signal via GPIO hog on RK3399 Puma
  arm64: dts: rockchip: fix eMMC/SPI corruption when audio has been used on RK3399 Puma
  arm64: dts: rockchip: fix PMIC interrupt pin in pinctrl for ROCK Pi E
  arm64: dts: rockchip: Remove broken tsadc pinctrl binding for rk356x
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ARM SoC fixes from Arnd Bergmann:
 "The bulk of the changes this time are for device tree files in the
  rockchips platform, addressing correctness issues on individual
  boards, plus one change in the rk356x SoC file to make it match the
  binding.

  The only other changes that came in are

   - a CPU frequencey scaling fix for JH7110 (RISC-V)

   - a build fix for the cznic hwrandom driver

   - a fix for a deadlock in qualcomm uefi secure application firmware
     driver"

* tag 'arm-fixes-6.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  platform: cznic: turris-omnia-mcu: fix HW_RANDOM dependency
  riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz
  firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()
  arm64: dts: rockchip: Fix compatibles for RK3588 VO{0,1}_GRF
  dt-bindings: soc: rockchip: Fix compatibles for RK3588 VO{0,1}_GRF
  arm64: dts: rockchip: override BIOS_DISABLE signal via GPIO hog on RK3399 Puma
  arm64: dts: rockchip: fix eMMC/SPI corruption when audio has been used on RK3399 Puma
  arm64: dts: rockchip: fix PMIC interrupt pin in pinctrl for ROCK Pi E
  arm64: dts: rockchip: Remove broken tsadc pinctrl binding for rk356x
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'riscv-soc-fixes-for-v6.11-final' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes</title>
<updated>2024-09-11T08:54:37+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-09-11T08:54:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=0e7af99aef5f58b4bae00e45fd1c2626a987f7bb'/>
<id>0e7af99aef5f58b4bae00e45fd1c2626a987f7bb</id>
<content type='text'>
RISC-V soc fixes for v6.11-final

StarFive:
A fix to return one of the clocks on the JH7110 from 1 GHz to 1.5 GHz

Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;

* tag 'riscv-soc-fixes-for-v6.11-final' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
  riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz

Link: https://lore.kernel.org/r/20240909-hybrid-groovy-601a33b5b309@spud
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
RISC-V soc fixes for v6.11-final

StarFive:
A fix to return one of the clocks on the JH7110 from 1 GHz to 1.5 GHz

Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;

* tag 'riscv-soc-fixes-for-v6.11-final' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
  riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz

Link: https://lore.kernel.org/r/20240909-hybrid-groovy-601a33b5b309@spud
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: Disable preemption while handling PR_RISCV_CTX_SW_FENCEI_OFF</title>
<updated>2024-09-11T03:38:46+00:00</updated>
<author>
<name>Charlie Jenkins</name>
<email>charlie@rivosinc.com</email>
</author>
<published>2024-09-03T22:52:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7c1e5b9690b0e14acead4ff98d8a6c40f2dff54b'/>
<id>7c1e5b9690b0e14acead4ff98d8a6c40f2dff54b</id>
<content type='text'>
The icache will be flushed in switch_to() if force_icache_flush is true,
or in flush_icache_deferred() if icache_stale_mask is set. Between
setting force_icache_flush to false and calculating the new
icache_stale_mask, preemption needs to be disabled. There are two
reasons for this:

1. If CPU migration happens between force_icache_flush = false, and the
   icache_stale_mask is set, an icache flush will not be emitted.
2. smp_processor_id() is used in set_icache_stale_mask() to mark the
   current CPU as not needing another flush since a flush will have
   happened either by userspace or by the kernel when performing the
   migration. smp_processor_id() is currently called twice with preemption
   enabled which causes a race condition. It allows
   icache_stale_mask to be populated with inconsistent CPU ids.

Resolve these two issues by setting the icache_stale_mask before setting
force_icache_flush to false, and using get_cpu()/put_cpu() to obtain the
smp_processor_id().

Signed-off-by: Charlie Jenkins &lt;charlie@rivosinc.com&gt;
Fixes: 6b9391b581fd ("riscv: Include riscv_set_icache_flush_ctx prctl")
Link: https://lore.kernel.org/r/20240903-fix_fencei_optimization-v2-1-8025f20171fc@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The icache will be flushed in switch_to() if force_icache_flush is true,
or in flush_icache_deferred() if icache_stale_mask is set. Between
setting force_icache_flush to false and calculating the new
icache_stale_mask, preemption needs to be disabled. There are two
reasons for this:

1. If CPU migration happens between force_icache_flush = false, and the
   icache_stale_mask is set, an icache flush will not be emitted.
2. smp_processor_id() is used in set_icache_stale_mask() to mark the
   current CPU as not needing another flush since a flush will have
   happened either by userspace or by the kernel when performing the
   migration. smp_processor_id() is currently called twice with preemption
   enabled which causes a race condition. It allows
   icache_stale_mask to be populated with inconsistent CPU ids.

Resolve these two issues by setting the icache_stale_mask before setting
force_icache_flush to false, and using get_cpu()/put_cpu() to obtain the
smp_processor_id().

Signed-off-by: Charlie Jenkins &lt;charlie@rivosinc.com&gt;
Fixes: 6b9391b581fd ("riscv: Include riscv_set_icache_flush_ctx prctl")
Link: https://lore.kernel.org/r/20240903-fix_fencei_optimization-v2-1-8025f20171fc@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: dts: starfive: jh7110-common: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz</title>
<updated>2024-09-08T22:20:19+00:00</updated>
<author>
<name>Xingyu Wu</name>
<email>xingyu.wu@starfivetech.com</email>
</author>
<published>2024-08-26T08:04:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=61f2e8a3a94175dbbaad6a54f381b2a505324610'/>
<id>61f2e8a3a94175dbbaad6a54f381b2a505324610</id>
<content type='text'>
CPUfreq supports 4 cpu frequency loads on 375/500/750/1500MHz.
But now PLL0 rate is 1GHz and the cpu frequency loads become
250/333/500/1000MHz in fact.

The PLL0 rate should be default set to 1.5GHz and set the
cpu_core rate to 500MHz in safe.

Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for JH7110 SoC")
Signed-off-by: Xingyu Wu &lt;xingyu.wu@starfivetech.com&gt;
Reviewed-by: Hal Feng &lt;hal.feng@starfivetech.com&gt;
Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CPUfreq supports 4 cpu frequency loads on 375/500/750/1500MHz.
But now PLL0 rate is 1GHz and the cpu frequency loads become
250/333/500/1000MHz in fact.

The PLL0 rate should be default set to 1.5GHz and set the
cpu_core rate to 500MHz in safe.

Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for JH7110 SoC")
Signed-off-by: Xingyu Wu &lt;xingyu.wu@starfivetech.com&gt;
Reviewed-by: Hal Feng &lt;hal.feng@starfivetech.com&gt;
Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: Fix RISCV_ALTERNATIVE_EARLY</title>
<updated>2024-09-03T14:57:55+00:00</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alexghiti@rivosinc.com</email>
</author>
<published>2024-08-29T16:50:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1ff95eb2bebda50c4c5406caaf201e0fcb24cc8f'/>
<id>1ff95eb2bebda50c4c5406caaf201e0fcb24cc8f</id>
<content type='text'>
RISCV_ALTERNATIVE_EARLY will issue sbi_ecall() very early in the boot
process, before the first memory mapping is setup so we can't have any
instrumentation happening here.

In addition, when the kernel is relocatable, we must also not issue any
relocation this early since they would have been patched virtually only.

So, instead of disabling instrumentation for the whole kernel/sbi.c file
and compiling it with -fno-pie, simply move __sbi_ecall() and
__sbi_base_ecall() into their own file where this is fixed.

Reported-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Closes: https://lore.kernel.org/linux-riscv/20240813-pony-truck-3e7a83e9759e@spud/
Reported-by: syzbot+cfbcb82adf6d7279fd35@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-riscv/00000000000065062c061fcec37b@google.com/
Fixes: 1745cfafebdf ("riscv: don't use global static vars to store alternative data")
Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20240829165048.49756-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
RISCV_ALTERNATIVE_EARLY will issue sbi_ecall() very early in the boot
process, before the first memory mapping is setup so we can't have any
instrumentation happening here.

In addition, when the kernel is relocatable, we must also not issue any
relocation this early since they would have been patched virtually only.

So, instead of disabling instrumentation for the whole kernel/sbi.c file
and compiling it with -fno-pie, simply move __sbi_ecall() and
__sbi_base_ecall() into their own file where this is fixed.

Reported-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Closes: https://lore.kernel.org/linux-riscv/20240813-pony-truck-3e7a83e9759e@spud/
Reported-by: syzbot+cfbcb82adf6d7279fd35@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-riscv/00000000000065062c061fcec37b@google.com/
Fixes: 1745cfafebdf ("riscv: don't use global static vars to store alternative data")
Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20240829165048.49756-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: Do not restrict memory size because of linear mapping on nommu</title>
<updated>2024-09-03T14:57:27+00:00</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alexghiti@rivosinc.com</email>
</author>
<published>2024-08-27T06:52:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5f771088a2b5edd6f2c5c9f34484ca18dc389f3e'/>
<id>5f771088a2b5edd6f2c5c9f34484ca18dc389f3e</id>
<content type='text'>
It makes no sense to restrict physical memory size because of linear
mapping size constraints when there is no linear mapping, so only do
that when mmu is enabled.

Reported-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Closes: https://lore.kernel.org/linux-riscv/CAMuHMdW0bnJt5GMRtOZGkTiM7GK4UaLJCDMF_Ouq++fnDKi3_A@mail.gmail.com/
Fixes: 3b6564427aea ("riscv: Fix linear mapping checks for non-contiguous memory regions")
Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Tested-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Link: https://lore.kernel.org/r/20240827065230.145021-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It makes no sense to restrict physical memory size because of linear
mapping size constraints when there is no linear mapping, so only do
that when mmu is enabled.

Reported-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Closes: https://lore.kernel.org/linux-riscv/CAMuHMdW0bnJt5GMRtOZGkTiM7GK4UaLJCDMF_Ouq++fnDKi3_A@mail.gmail.com/
Fixes: 3b6564427aea ("riscv: Fix linear mapping checks for non-contiguous memory regions")
Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Tested-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Link: https://lore.kernel.org/r/20240827065230.145021-1-alexghiti@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: Fix toolchain vector detection</title>
<updated>2024-09-03T14:57:05+00:00</updated>
<author>
<name>Anton Blanchard</name>
<email>antonb@tenstorrent.com</email>
</author>
<published>2024-08-19T00:11:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5ba7a75a53dffbf727e842b5847859bb482ac4aa'/>
<id>5ba7a75a53dffbf727e842b5847859bb482ac4aa</id>
<content type='text'>
A recent change to gcc flags rv64iv as no longer valid:

   cc1: sorry, unimplemented: Currently the 'V' implementation
   requires the 'M' extension

and as a result vector support is disabled. Fix this by adding m
to our toolchain vector detection code.

Signed-off-by: Anton Blanchard &lt;antonb@tenstorrent.com&gt;
Fixes: fa8e7cce55da ("riscv: Enable Vector code to be built")
Link: https://lore.kernel.org/r/20240819001131.1738806-1-antonb@tenstorrent.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A recent change to gcc flags rv64iv as no longer valid:

   cc1: sorry, unimplemented: Currently the 'V' implementation
   requires the 'M' extension

and as a result vector support is disabled. Fix this by adding m
to our toolchain vector detection code.

Signed-off-by: Anton Blanchard &lt;antonb@tenstorrent.com&gt;
Fixes: fa8e7cce55da ("riscv: Enable Vector code to be built")
Link: https://lore.kernel.org/r/20240819001131.1738806-1-antonb@tenstorrent.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>riscv: misaligned: Restrict user access to kernel memory</title>
<updated>2024-09-01T00:43:38+00:00</updated>
<author>
<name>Samuel Holland</name>
<email>samuel.holland@sifive.com</email>
</author>
<published>2024-08-15T00:57:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b686ecdeacf6658e1348c1a32a08e2e72f7c0f00'/>
<id>b686ecdeacf6658e1348c1a32a08e2e72f7c0f00</id>
<content type='text'>
raw_copy_{to,from}_user() do not call access_ok(), so this code allowed
userspace to access any virtual memory address.

Cc: stable@vger.kernel.org
Fixes: 7c83232161f6 ("riscv: add support for misaligned trap handling in S-mode")
Fixes: 441381506ba7 ("riscv: misaligned: remove CONFIG_RISCV_M_MODE specific code")
Signed-off-by: Samuel Holland &lt;samuel.holland@sifive.com&gt;
Reviewed-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20240815005714.1163136-1-samuel.holland@sifive.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
raw_copy_{to,from}_user() do not call access_ok(), so this code allowed
userspace to access any virtual memory address.

Cc: stable@vger.kernel.org
Fixes: 7c83232161f6 ("riscv: add support for misaligned trap handling in S-mode")
Fixes: 441381506ba7 ("riscv: misaligned: remove CONFIG_RISCV_M_MODE specific code")
Signed-off-by: Samuel Holland &lt;samuel.holland@sifive.com&gt;
Reviewed-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
Link: https://lore.kernel.org/r/20240815005714.1163136-1-samuel.holland@sifive.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge patch series "riscv: mm: Do not restrict mmap address based on hint"</title>
<updated>2024-08-29T13:22:51+00:00</updated>
<author>
<name>Palmer Dabbelt</name>
<email>palmer@rivosinc.com</email>
</author>
<published>2024-08-29T13:03:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=84cfab9a1805f8e300e945f26e3fdff6d125bc20'/>
<id>84cfab9a1805f8e300e945f26e3fdff6d125bc20</id>
<content type='text'>
Charlie Jenkins &lt;charlie@rivosinc.com&gt; says:

There have been a couple of reports that using the hint address to
restrict the address returned by mmap hint address has caused issues in
applications. A different solution for restricting addresses returned by
mmap is necessary to avoid breakages.

[Palmer: This also just wasn't doing the right thing in the first place,
as it didn't handle the sv39 cases we were trying to deal with.]

* b4-shazam-merge:
  riscv: mm: Do not restrict mmap address based on hint
  riscv: selftests: Remove mmap hint address checks
  Revert "RISC-V: mm: Document mmap changes"

Link: https://lore.kernel.org/r/20240826-riscv_mmap-v1-0-cd8962afe47f@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Charlie Jenkins &lt;charlie@rivosinc.com&gt; says:

There have been a couple of reports that using the hint address to
restrict the address returned by mmap hint address has caused issues in
applications. A different solution for restricting addresses returned by
mmap is necessary to avoid breakages.

[Palmer: This also just wasn't doing the right thing in the first place,
as it didn't handle the sv39 cases we were trying to deal with.]

* b4-shazam-merge:
  riscv: mm: Do not restrict mmap address based on hint
  riscv: selftests: Remove mmap hint address checks
  Revert "RISC-V: mm: Document mmap changes"

Link: https://lore.kernel.org/r/20240826-riscv_mmap-v1-0-cd8962afe47f@rivosinc.com
Signed-off-by: Palmer Dabbelt &lt;palmer@rivosinc.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
