From: Miguel Ojeda <ojeda@kernel.org>

The rust modules work on 64-bit RISC-V, with no twiddling required.
Select HAVE_RUST and provide the required flags to kbuild so that the
modules can be used. The Makefile and Kconfig changes are lifted from
work done by Miguel in the Rust-for-Linux tree, hence his authorship.
Following the rabbit hole, the Makefile changes originated in a script,
created based on config files originally added by Gary, hence his
co-authorship.

32-bit is broken in core rust code, so support is limited to 64-bit:
ld.lld: error: undefined symbol: __udivdi3

As 64-bit RISC-V is now supported, add it to the arch support table,
taking the opportunity to sort the table in alphabetical order.

Co-developed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
While adding RISC-V to the table, I took the chance to re-sort it
alphabetically. I didn't think that warranted co-authorship, but given
we had an authorship conversation already I am happy to provide one for
that...
---
 Documentation/rust/arch-support.rst | 3 ++-
 arch/riscv/Kconfig                  | 1 +
 arch/riscv/Makefile                 | 2 ++
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index ed7f4f5b3cf15..77765ffd5af41 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -15,7 +15,8 @@ support corresponds to ``S`` values in the ``MAINTAINERS`` file.
 ============  ================  ==============================================
 Architecture  Level of support  Constraints
 ============  ================  ==============================================
-``x86``       Maintained        ``x86_64`` only.
+``riscv``     Maintained        ``riscv64`` only.
 ``um``        Maintained        ``x86_64`` only.
+``x86``       Maintained        ``x86_64`` only.
 ============  ================  ==============================================
 
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c5e42cc376048..c3179b139361f 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -114,6 +114,7 @@ config RISCV
 	select HAVE_POSIX_CPU_TIMERS_TASK_WORK
 	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RSEQ
+	select HAVE_RUST if 64BIT
 	select HAVE_STACKPROTECTOR
 	select HAVE_SYSCALL_TRACEPOINTS
 	select IRQ_DOMAIN
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 6203c33789228..950612bf193cf 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -31,6 +31,8 @@ ifeq ($(CONFIG_ARCH_RV64I),y)
 	KBUILD_AFLAGS += -mabi=lp64
 
 	KBUILD_LDFLAGS += -melf64lriscv
+
+	KBUILD_RUSTFLAGS += -Ctarget-cpu=generic-rv64
 else
 	BITS := 32
 	UTS_MACHINE := riscv32
-- 
2.39.2

On Tue, Mar 7, 2023 at 11:25 AM Conor Dooley <conor.dooley@microchip.com> wrote:
>
> While adding RISC-V to the table, I took the chance to re-sort it
> alphabetically.

For reference, there is a patch for this coming at:

    https://lore.kernel.org/rust-for-linux/I0YeaNjTtc4Nh47ZLJfAs6rgfAc_QZxhynNfz-GQKssVZ1S2UI_cTScCkp9-oX-hPYVcP3EfF7N0HMB9iAlm1FcvOJagnQoLeHtiW3bGCgM=@bamelis.dev/

Cheers,
Miguel

On Tue, Mar 07, 2023 at 11:56:30AM +0100, Miguel Ojeda wrote:
> On Tue, Mar 7, 2023 at 11:25 AM Conor Dooley <conor.dooley@microchip.com> wrote:
> >
> > While adding RISC-V to the table, I took the chance to re-sort it
> > alphabetically.
> 
> For reference, there is a patch for this coming at:
> 
>     https://lore.kernel.org/rust-for-linux/I0YeaNjTtc4Nh47ZLJfAs6rgfAc_QZxhynNfz-GQKssVZ1S2UI_cTScCkp9-oX-hPYVcP3EfF7N0HMB9iAlm1FcvOJagnQoLeHtiW3bGCgM=@bamelis.dev/

Cool. Git should resolve that, probably without even generating a
conflict in -next, right?

On Tue, Mar 7, 2023 at 12:01 PM Conor Dooley <conor.dooley@microchip.com> wrote:
>
> Cool. Git should resolve that, probably without even generating a
> conflict in -next, right?

I think it will conflict.

Since the cleanup is elsewhere and it may add work for the -next
maintainer, it is probably best to take it out in v2.

Cheers,
Miguel

On Tue, Mar 07, 2023 at 12:56:30PM +0100, Miguel Ojeda wrote:
> On Tue, Mar 7, 2023 at 12:01 PM Conor Dooley <conor.dooley@microchip.com> wrote:
> >
> > Cool. Git should resolve that, probably without even generating a
> > conflict in -next, right?
> 
> I think it will conflict.
> 
> Since the cleanup is elsewhere and it may add work for the -next
> maintainer, it is probably best to take it out in v2.

If you think it will conflict as-is, it's probably gonna conflict either
way.
You've pointed out several small bits, I'll send a v2 in a few days.

Cheers,
Conor.