[PATCH V6 0/3] Rust support for powerpc

[PATCH V6 0/3] Rust support for powerpc

[Mukesh Kumar Chaurasiya (IBM)]

Enable experimental rust support for ppc64le and ppc32be. The patch for
ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been
merged over it. ppc32 needs some toolchain fixes mentioned in the patch
`rust: Add PowerPC support` and the discussion for that is done here[1].

This has been tested on powernv9 hardware and power10 pseries qemu. I
I request Link to test the ppc32 part as i don't have a hardware to test
it out.

[1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr
[2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com

Changelog:
V5 -> V6:
- Added a missing Tested by from Venkat which got missed since V3
- Support is marked as Maintained instead of experimental
V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com

V4 -> V5:
- Removed a nested ifdef from PPC64 for Little endian toolchain
V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com

V3 -> V4:
- Co-developed-by header added in patch 1
V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com

V2 -> V3:
- Splited HAVE_RUST in 2 lines
- BINDGEN_TARGET_powerpc initialized before assigning the same to
  BINDGEN_TARGET
V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com

V1 -> V2:
- jump label fix for rust has been moved to a separate patch
- PPC32 support has been taken
- rust support has been marked experimental
- target.json dependency has been removed
- HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64


Link Mauve (1):
  rust: Add PowerPC support

Mukesh Kumar Chaurasiya (IBM) (2):
  powerpc/jump_label: adjust inline asm to be consistent
  powerpc: Enable Rust for ppc64le

 Documentation/rust/arch-support.rst   |  1 +
 arch/powerpc/Kconfig                  |  2 ++
 arch/powerpc/Makefile                 |  7 +++++++
 arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
 rust/Makefile                         | 10 +++++++++-
 5 files changed, 32 insertions(+), 11 deletions(-)

-- 
2.53.0

[PATCH V6 1/3] powerpc/jump_label: adjust inline asm to be consistent

[Mukesh Kumar Chaurasiya (IBM)]

Added support for a new macro ARCH_STATIC_BRANCH_ASM in powerpc
to avoid duplication of inline asm between C and Rust. This is
inline with commit aecaf181651c '("jump_label: adjust inline asm to be consistent")'

Co-developed-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
---
 arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
index d4eaba459a0e..a6b211502bfe 100644
--- a/arch/powerpc/include/asm/jump_label.h
+++ b/arch/powerpc/include/asm/jump_label.h
@@ -15,14 +15,20 @@
 #define JUMP_ENTRY_TYPE		stringify_in_c(FTR_ENTRY_LONG)
 #define JUMP_LABEL_NOP_SIZE	4
 
+#define JUMP_TABLE_ENTRY(key, label)			\
+	".pushsection __jump_table,  \"aw\"	\n\t"	\
+	".long 1b - ., " label " - .		\n\t"	\
+	JUMP_ENTRY_TYPE key " - .		\n\t"	\
+	".popsection 				\n\t"
+
+#define ARCH_STATIC_BRANCH_ASM(key, label)		\
+	"1:	nop				\n\t"	\
+	JUMP_TABLE_ENTRY(key,label)
+
 static __always_inline bool arch_static_branch(struct static_key *key, bool branch)
 {
-	asm goto("1:\n\t"
-		 "nop # arch_static_branch\n\t"
-		 ".pushsection __jump_table,  \"aw\"\n\t"
-		 ".long 1b - ., %l[l_yes] - .\n\t"
-		 JUMP_ENTRY_TYPE "%c0 - .\n\t"
-		 ".popsection \n\t"
+	asm goto(
+		 ARCH_STATIC_BRANCH_ASM("%c0", "%l[l_yes]")
 		 : :  "i" (&((char *)key)[branch]) : : l_yes);
 
 	return false;
@@ -34,10 +40,7 @@ static __always_inline bool arch_static_branch_jump(struct static_key *key, bool
 {
 	asm goto("1:\n\t"
 		 "b %l[l_yes] # arch_static_branch_jump\n\t"
-		 ".pushsection __jump_table,  \"aw\"\n\t"
-		 ".long 1b - ., %l[l_yes] - .\n\t"
-		 JUMP_ENTRY_TYPE "%c0 - .\n\t"
-		 ".popsection \n\t"
+		 JUMP_TABLE_ENTRY("%c0", "%l[l_yes]")
 		 : :  "i" (&((char *)key)[branch]) : : l_yes);
 
 	return false;
-- 
2.53.0

[PATCH V6 2/3] rust: Add PowerPC support

[Mukesh Kumar Chaurasiya (IBM)]

From: Link Mauve <linkmauve@linkmauve.fr>

For now only Big Endian 32-bit PowerPC is supported, as that is the only
hardware I have.  This has been tested on the Nintendo Wii so far, but I
plan on also using it on the GameCube, Wii U and Apple G4.

These changes aren’t the only ones required to get the kernel to compile
and link on PowerPC, libcore will also have to be changed to not use
integer division to format u64, u128 and core::time::Duration, otherwise
__udivdi3() and __umoddi3() will have to be added.  I have tested this
change by replacing the three implementations with unimplemented!() and
it linked just fine.

Signed-off-by: Link Mauve <linkmauve@linkmauve.fr>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
---
 Documentation/rust/arch-support.rst | 1 +
 arch/powerpc/Kconfig                | 1 +
 arch/powerpc/Makefile               | 2 ++
 rust/Makefile                       | 4 +++-
 4 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index 6e6a515d0899..70b9e192a7a0 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -18,6 +18,7 @@ Architecture   Level of support  Constraints
 ``arm``        Maintained        ARMv7 Little Endian only.
 ``arm64``      Maintained        Little Endian only.
 ``loongarch``  Maintained        \-
+``powerpc``    Maintained        32-bit Big Endian only.
 ``riscv``      Maintained        ``riscv64`` and LLVM/Clang only.
 ``um``         Maintained        \-
 ``x86``        Maintained        ``x86_64`` only.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9537a61ebae0..17db23b82e91 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -283,6 +283,7 @@ config PPC
 	select HAVE_REGS_AND_STACK_ACCESS_API
 	select HAVE_RELIABLE_STACKTRACE
 	select HAVE_RSEQ
+	select HAVE_RUST			if PPC32
 	select HAVE_SAMPLE_FTRACE_DIRECT	if HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 	select HAVE_SAMPLE_FTRACE_DIRECT_MULTI	if HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 	select HAVE_SETUP_PER_CPU_AREA		if PPC64
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index a58b1029592c..9fd82c75dcbd 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -61,6 +61,8 @@ else
 KBUILD_LDFLAGS_MODULE += $(objtree)/arch/powerpc/lib/crtsavres.o
 endif
 
+KBUILD_RUSTFLAGS += --target=powerpc-unknown-linux-gnu
+
 ifdef CONFIG_CPU_LITTLE_ENDIAN
 KBUILD_CPPFLAGS	+= -mlittle-endian
 KBUILD_LDFLAGS	+= -EL
diff --git a/rust/Makefile b/rust/Makefile
index 4dcc2eff51cb..ae22f2c5f0b3 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -384,13 +384,15 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \
 	-fstrict-flex-arrays=% -fmin-function-alignment=% \
 	-fzero-init-padding-bits=% -mno-fdpic \
 	-fdiagnostics-show-context -fdiagnostics-show-context=% \
-	--param=% --param asan-% -fno-isolate-erroneous-paths-dereference
+	--param=% --param asan-% -fno-isolate-erroneous-paths-dereference \
+	-ffixed-r2 -mmultiple -mno-readonly-in-sdata
 
 # Derived from `scripts/Makefile.clang`.
 BINDGEN_TARGET_x86	:= x86_64-linux-gnu
 BINDGEN_TARGET_arm64	:= aarch64-linux-gnu
 BINDGEN_TARGET_arm	:= arm-linux-gnueabi
 BINDGEN_TARGET_loongarch	:= loongarch64-linux-gnusf
+BINDGEN_TARGET_powerpc	:= powerpc-linux-gnu
 BINDGEN_TARGET_um	:= $(BINDGEN_TARGET_$(SUBARCH))
 BINDGEN_TARGET		:= $(BINDGEN_TARGET_$(SRCARCH))
 
-- 
2.53.0

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Alice Ryhl]

On Tue, Feb 10, 2026 at 10:00 AM Mukesh Kumar Chaurasiya (IBM)
<mkchauras@gmail.com> wrote:
>
> From: Link Mauve <linkmauve@linkmauve.fr>
>
> For now only Big Endian 32-bit PowerPC is supported, as that is the only
> hardware I have.  This has been tested on the Nintendo Wii so far, but I
> plan on also using it on the GameCube, Wii U and Apple G4.
>
> These changes aren’t the only ones required to get the kernel to compile
> and link on PowerPC, libcore will also have to be changed to not use
> integer division to format u64, u128 and core::time::Duration, otherwise
> __udivdi3() and __umoddi3() will have to be added.  I have tested this
> change by replacing the three implementations with unimplemented!() and
> it linked just fine.
>
> Signed-off-by: Link Mauve <linkmauve@linkmauve.fr>
> Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>

> diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> index a58b1029592c..9fd82c75dcbd 100644
> --- a/arch/powerpc/Makefile
> +++ b/arch/powerpc/Makefile
> @@ -61,6 +61,8 @@ else
>  KBUILD_LDFLAGS_MODULE += $(objtree)/arch/powerpc/lib/crtsavres.o
>  endif
>
> +KBUILD_RUSTFLAGS += --target=powerpc-unknown-linux-gnu

This needs to be a softfloat target.

Alice

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Link Mauve]

On Sun, Feb 22, 2026 at 07:09:38PM +0100, Alice Ryhl wrote:
> On Tue, Feb 10, 2026 at 10:00 AM Mukesh Kumar Chaurasiya (IBM)
> <mkchauras@gmail.com> wrote:
> >
> > From: Link Mauve <linkmauve@linkmauve.fr>
> >
> > For now only Big Endian 32-bit PowerPC is supported, as that is the only
> > hardware I have.  This has been tested on the Nintendo Wii so far, but I
> > plan on also using it on the GameCube, Wii U and Apple G4.
> >
> > These changes aren’t the only ones required to get the kernel to compile
> > and link on PowerPC, libcore will also have to be changed to not use
> > integer division to format u64, u128 and core::time::Duration, otherwise
> > __udivdi3() and __umoddi3() will have to be added.  I have tested this
> > change by replacing the three implementations with unimplemented!() and
> > it linked just fine.
> >
> > Signed-off-by: Link Mauve <linkmauve@linkmauve.fr>
> > Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
> 
> > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
> > index a58b1029592c..9fd82c75dcbd 100644
> > --- a/arch/powerpc/Makefile
> > +++ b/arch/powerpc/Makefile
> > @@ -61,6 +61,8 @@ else
> >  KBUILD_LDFLAGS_MODULE += $(objtree)/arch/powerpc/lib/crtsavres.o
> >  endif
> >
> > +KBUILD_RUSTFLAGS += --target=powerpc-unknown-linux-gnu
> 
> This needs to be a softfloat target.

Should we come back to describing the target like I did in my first
patch[1] in scripts/generate_rust_target.rs, or should I bring that to
Rust to create a powerpc-unknown-unknown-softfloat target upstream?  Or
is there a better third solution I’m not thinking of?

> 
> Alice
> 

[1] https://lore.kernel.org/rust-for-linux/20260204030507.8203-1-linkmauve@linkmauve.fr/

-- 
Link Mauve

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Miguel Ojeda]

On Sun, Feb 22, 2026 at 8:07 PM Link Mauve <linkmauve@linkmauve.fr> wrote:
>
> Should we come back to describing the target like I did in my first
> patch[1] in scripts/generate_rust_target.rs, or should I bring that to
> Rust to create a powerpc-unknown-unknown-softfloat target upstream?  Or
> is there a better third solution I’m not thinking of?

We are trying to stop using the custom target specs, so we should ask
upstream to give you a built-in target you can use (or equivalently, a
flag to do what you need, but I think the idea is to not have such a
flag).

i.e. even if you used the custom target JSON, we would still need to
ask, since the goal is to remove that script entirely.

Thanks!

Cheers,
Miguel

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Mukesh Kumar Chaurasiya]

On Sun, Feb 22, 2026 at 08:11:17PM +0100, Miguel Ojeda wrote:
> On Sun, Feb 22, 2026 at 8:07 PM Link Mauve <linkmauve@linkmauve.fr> wrote:
> >
> > Should we come back to describing the target like I did in my first
> > patch[1] in scripts/generate_rust_target.rs, or should I bring that to
> > Rust to create a powerpc-unknown-unknown-softfloat target upstream?  Or
> > is there a better third solution I’m not thinking of?
> 
> We are trying to stop using the custom target specs, so we should ask
> upstream to give you a built-in target you can use (or equivalently, a
> flag to do what you need, but I think the idea is to not have such a
> flag).
> 
> i.e. even if you used the custom target JSON, we would still need to
> ask, since the goal is to remove that script entirely.
> 
> Thanks!
> 
> Cheers,
> Miguel

Sorry for the spam, my earlier message got rejected.

I think, disabling altivec, fpu and vsx with compiler flag will work.

What are your opinion on this?

Regards,
Mukesh

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Alice Ryhl]

On Mon, Feb 23, 2026 at 07:56:02AM +0530, Mukesh Kumar Chaurasiya wrote:
> On Sun, Feb 22, 2026 at 08:11:17PM +0100, Miguel Ojeda wrote:
> > On Sun, Feb 22, 2026 at 8:07 PM Link Mauve <linkmauve@linkmauve.fr> wrote:
> > >
> > > Should we come back to describing the target like I did in my first
> > > patch[1] in scripts/generate_rust_target.rs, or should I bring that to
> > > Rust to create a powerpc-unknown-unknown-softfloat target upstream?  Or
> > > is there a better third solution I’m not thinking of?
> > 
> > We are trying to stop using the custom target specs, so we should ask
> > upstream to give you a built-in target you can use (or equivalently, a
> > flag to do what you need, but I think the idea is to not have such a
> > flag).
> > 
> > i.e. even if you used the custom target JSON, we would still need to
> > ask, since the goal is to remove that script entirely.
> 
> I think, disabling altivec, fpu and vsx with compiler flag will work.
> 
> What are your opinion on this?

I think you can and should submit a PR to add a softfloat target to
upstream Rust right now, and I believe there should be no issue in
accepting that.

If there's a workaround we can use on existing compiler versions without
the target, that's great too, but we should get the target in upstream
asap.

Alice

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Mukesh Kumar Chaurasiya]

On Mon, Feb 23, 2026 at 09:22:33AM +0000, Alice Ryhl wrote:
> On Mon, Feb 23, 2026 at 07:56:02AM +0530, Mukesh Kumar Chaurasiya wrote:
> > On Sun, Feb 22, 2026 at 08:11:17PM +0100, Miguel Ojeda wrote:
> > > On Sun, Feb 22, 2026 at 8:07 PM Link Mauve <linkmauve@linkmauve.fr> wrote:
> > > >
> > > > Should we come back to describing the target like I did in my first
> > > > patch[1] in scripts/generate_rust_target.rs, or should I bring that to
> > > > Rust to create a powerpc-unknown-unknown-softfloat target upstream?  Or
> > > > is there a better third solution I’m not thinking of?
> > > 
> > > We are trying to stop using the custom target specs, so we should ask
> > > upstream to give you a built-in target you can use (or equivalently, a
> > > flag to do what you need, but I think the idea is to not have such a
> > > flag).
> > > 
> > > i.e. even if you used the custom target JSON, we would still need to
> > > ask, since the goal is to remove that script entirely.
> > 
> > I think, disabling altivec, fpu and vsx with compiler flag will work.
> > 
> > What are your opinion on this?
> 
> I think you can and should submit a PR to add a softfloat target to
> upstream Rust right now, and I believe there should be no issue in
> accepting that.
> 
> If there's a workaround we can use on existing compiler versions without
> the target, that's great too, but we should get the target in upstream
> asap.
Cool, sounds good.

Regards,
Mukesh
> 
> Alice

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Miguel Ojeda]

On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
<mkchauras@gmail.com> wrote:
>
> I think, disabling altivec, fpu and vsx with compiler flag will work.
>
> What are your opinion on this?

It is really up to upstream Rust -- for us, i.e. the kernel, it
usually doesn't really matter much how things like that are
accomplished: whether via flags, a built-in target, a custom target,
etc. However, we need to know what the path to stability is.

My understanding (but I may be wrong) is that upstream Rust prefer we
use built-in targets for softfloat instead of disabling via
`-Ctarget-feature` (and that the other options may go away soon and/or
will never be stable) -- at least for some cases. For instance, for
arm64, please this recent change kernel-side regarding `neon` as an
entry point:

  446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")

So please ask upstream Rust (probably in their Zulip, e.g. in
t-compiler or rust-for-linux channels) what you should do for powerpc.
They will likely be happy with a PR adding the target (or whatever
they decide) as Alice mentions. And until we reach that minimum
version (in a year or more), we can use something else meanwhile. But
at least we will have a way towards the end goal, if that makes sense.

In case it helps, let me Cc Ralf, Jubilee and Matthew who were
involved in some of that discussion in the past, plus the compiler
leads.

Cheers,
Miguel

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Mukesh Kumar Chaurasiya]

On Mon, Feb 23, 2026 at 04:31:36PM +0100, Miguel Ojeda wrote:
> On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
> <mkchauras@gmail.com> wrote:
> >
> > I think, disabling altivec, fpu and vsx with compiler flag will work.
> >
> > What are your opinion on this?
> 
> It is really up to upstream Rust -- for us, i.e. the kernel, it
> usually doesn't really matter much how things like that are
> accomplished: whether via flags, a built-in target, a custom target,
> etc. However, we need to know what the path to stability is.
> 
> My understanding (but I may be wrong) is that upstream Rust prefer we
> use built-in targets for softfloat instead of disabling via
> `-Ctarget-feature` (and that the other options may go away soon and/or
> will never be stable) -- at least for some cases. For instance, for
> arm64, please this recent change kernel-side regarding `neon` as an
> entry point:
> 
>   446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
> 
Aah, that makes it clearer.
> So please ask upstream Rust (probably in their Zulip, e.g. in
> t-compiler or rust-for-linux channels) what you should do for powerpc.
> They will likely be happy with a PR adding the target (or whatever
> they decide) as Alice mentions. And until we reach that minimum
> version (in a year or more), we can use something else meanwhile. But
> at least we will have a way towards the end goal, if that makes sense.
> 
Yeah makes sense. Will work towards this.

Regards,
Mukesh

> In case it helps, let me Cc Ralf, Jubilee and Matthew who were
> involved in some of that discussion in the past, plus the compiler
> leads.
> 
> Cheers,
> Miguel

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Ralf Jung]

Hi all,

On 23.02.26 16:31, Miguel Ojeda wrote:
> On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
> <mkchauras@gmail.com> wrote:
>>
>> I think, disabling altivec, fpu and vsx with compiler flag will work.
>>
>> What are your opinion on this?
> 
> It is really up to upstream Rust -- for us, i.e. the kernel, it
> usually doesn't really matter much how things like that are
> accomplished: whether via flags, a built-in target, a custom target,
> etc. However, we need to know what the path to stability is.
> 
> My understanding (but I may be wrong) is that upstream Rust prefer we
> use built-in targets for softfloat instead of disabling via
> `-Ctarget-feature` (and that the other options may go away soon and/or
> will never be stable) -- at least for some cases. For instance, for
> arm64, please this recent change kernel-side regarding `neon` as an
> entry point:
> 
>    446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
> 
> So please ask upstream Rust (probably in their Zulip, e.g. in
> t-compiler or rust-for-linux channels) what you should do for powerpc.
> They will likely be happy with a PR adding the target (or whatever
> they decide) as Alice mentions. And until we reach that minimum
> version (in a year or more), we can use something else meanwhile. But
> at least we will have a way towards the end goal, if that makes sense.
> 
> In case it helps, let me Cc Ralf, Jubilee and Matthew who were
> involved in some of that discussion in the past, plus the compiler
> leads.

Upstream Rust dev here. Indeed we'd strongly prefer if this could use a built-in 
Rust target; we can work with you on adding a new target if that is needed.
The kernel currently uses a custom JSON target on x86 and that's quite the 
headache for compiler development: JSON targets are highly unstable and directly 
expose low-level details of how the compiler internally represents targets. When 
we change that representation, we update all built-in targets, but of course we 
cannot update JSON targets. So whenever possible we'd like to move towards 
reducing the number of JSON targets used by the kernel, not increase it. :)

Kind regards,
Ralf

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Mukesh Kumar Chaurasiya]

On Tue, Feb 24, 2026 at 09:58:10AM +0100, Ralf Jung wrote:
> Hi all,
> 
> On 23.02.26 16:31, Miguel Ojeda wrote:
> > On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
> > <mkchauras@gmail.com> wrote:
> > > 
> > > I think, disabling altivec, fpu and vsx with compiler flag will work.
> > > 
> > > What are your opinion on this?
> > 
> > It is really up to upstream Rust -- for us, i.e. the kernel, it
> > usually doesn't really matter much how things like that are
> > accomplished: whether via flags, a built-in target, a custom target,
> > etc. However, we need to know what the path to stability is.
> > 
> > My understanding (but I may be wrong) is that upstream Rust prefer we
> > use built-in targets for softfloat instead of disabling via
> > `-Ctarget-feature` (and that the other options may go away soon and/or
> > will never be stable) -- at least for some cases. For instance, for
> > arm64, please this recent change kernel-side regarding `neon` as an
> > entry point:
> > 
> >    446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
> > 
> > So please ask upstream Rust (probably in their Zulip, e.g. in
> > t-compiler or rust-for-linux channels) what you should do for powerpc.
> > They will likely be happy with a PR adding the target (or whatever
> > they decide) as Alice mentions. And until we reach that minimum
> > version (in a year or more), we can use something else meanwhile. But
> > at least we will have a way towards the end goal, if that makes sense.
> > 
> > In case it helps, let me Cc Ralf, Jubilee and Matthew who were
> > involved in some of that discussion in the past, plus the compiler
> > leads.
> 
> Upstream Rust dev here. Indeed we'd strongly prefer if this could use a
> built-in Rust target; we can work with you on adding a new target if that is
> needed.
> The kernel currently uses a custom JSON target on x86 and that's quite the
> headache for compiler development: JSON targets are highly unstable and
> directly expose low-level details of how the compiler internally represents
> targets. When we change that representation, we update all built-in targets,
> but of course we cannot update JSON targets. So whenever possible we'd like
> to move towards reducing the number of JSON targets used by the kernel, not
> increase it. :)
> 
> Kind regards,
> Ralf
> 
Hey,

Sorry for delayed response. I was out of network zone.

I am not sure about the process of how to get this in rust toolchain.
Should I raise an issue of github for this?

Regards,
Mukesh

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Alice Ryhl]

On Mon, Mar 02, 2026 at 11:25:54AM +0530, Mukesh Kumar Chaurasiya wrote:
> On Tue, Feb 24, 2026 at 09:58:10AM +0100, Ralf Jung wrote:
> > Hi all,
> > 
> > On 23.02.26 16:31, Miguel Ojeda wrote:
> > > On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
> > > <mkchauras@gmail.com> wrote:
> > > > 
> > > > I think, disabling altivec, fpu and vsx with compiler flag will work.
> > > > 
> > > > What are your opinion on this?
> > > 
> > > It is really up to upstream Rust -- for us, i.e. the kernel, it
> > > usually doesn't really matter much how things like that are
> > > accomplished: whether via flags, a built-in target, a custom target,
> > > etc. However, we need to know what the path to stability is.
> > > 
> > > My understanding (but I may be wrong) is that upstream Rust prefer we
> > > use built-in targets for softfloat instead of disabling via
> > > `-Ctarget-feature` (and that the other options may go away soon and/or
> > > will never be stable) -- at least for some cases. For instance, for
> > > arm64, please this recent change kernel-side regarding `neon` as an
> > > entry point:
> > > 
> > >    446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
> > > 
> > > So please ask upstream Rust (probably in their Zulip, e.g. in
> > > t-compiler or rust-for-linux channels) what you should do for powerpc.
> > > They will likely be happy with a PR adding the target (or whatever
> > > they decide) as Alice mentions. And until we reach that minimum
> > > version (in a year or more), we can use something else meanwhile. But
> > > at least we will have a way towards the end goal, if that makes sense.
> > > 
> > > In case it helps, let me Cc Ralf, Jubilee and Matthew who were
> > > involved in some of that discussion in the past, plus the compiler
> > > leads.
> > 
> > Upstream Rust dev here. Indeed we'd strongly prefer if this could use a
> > built-in Rust target; we can work with you on adding a new target if that is
> > needed.
> > The kernel currently uses a custom JSON target on x86 and that's quite the
> > headache for compiler development: JSON targets are highly unstable and
> > directly expose low-level details of how the compiler internally represents
> > targets. When we change that representation, we update all built-in targets,
> > but of course we cannot update JSON targets. So whenever possible we'd like
> > to move towards reducing the number of JSON targets used by the kernel, not
> > increase it. :)
> > 
> > Kind regards,
> > Ralf
> > 
> Hey,
> 
> Sorry for delayed response. I was out of network zone.
> 
> I am not sure about the process of how to get this in rust toolchain.
> Should I raise an issue of github for this?

You would need to add a new file to compiler/rustc_target/src/spec/targets
in the rustc repository.

If you're not sure what to put there, I would suggest coming up with
something that looks plausible, and opening a PR with that. Then others
can help you with filling out the target correctly.

Alice

Re: [PATCH V6 2/3] rust: Add PowerPC support

[Ralf Jung]

Hi all,

On 02.03.26 08:29, Alice Ryhl wrote:
> On Mon, Mar 02, 2026 at 11:25:54AM +0530, Mukesh Kumar Chaurasiya wrote:
>> On Tue, Feb 24, 2026 at 09:58:10AM +0100, Ralf Jung wrote:
>>> Hi all,
>>>
>>> On 23.02.26 16:31, Miguel Ojeda wrote:
>>>> On Mon, Feb 23, 2026 at 3:26 AM Mukesh Kumar Chaurasiya
>>>> <mkchauras@gmail.com> wrote:
>>>>>
>>>>> I think, disabling altivec, fpu and vsx with compiler flag will work.
>>>>>
>>>>> What are your opinion on this?
>>>>
>>>> It is really up to upstream Rust -- for us, i.e. the kernel, it
>>>> usually doesn't really matter much how things like that are
>>>> accomplished: whether via flags, a built-in target, a custom target,
>>>> etc. However, we need to know what the path to stability is.
>>>>
>>>> My understanding (but I may be wrong) is that upstream Rust prefer we
>>>> use built-in targets for softfloat instead of disabling via
>>>> `-Ctarget-feature` (and that the other options may go away soon and/or
>>>> will never be stable) -- at least for some cases. For instance, for
>>>> arm64, please this recent change kernel-side regarding `neon` as an
>>>> entry point:
>>>>
>>>>     446a8351f160 ("arm64: rust: clean Rust 1.85.0 warning using softfloat target")
>>>>
>>>> So please ask upstream Rust (probably in their Zulip, e.g. in
>>>> t-compiler or rust-for-linux channels) what you should do for powerpc.
>>>> They will likely be happy with a PR adding the target (or whatever
>>>> they decide) as Alice mentions. And until we reach that minimum
>>>> version (in a year or more), we can use something else meanwhile. But
>>>> at least we will have a way towards the end goal, if that makes sense.
>>>>
>>>> In case it helps, let me Cc Ralf, Jubilee and Matthew who were
>>>> involved in some of that discussion in the past, plus the compiler
>>>> leads.
>>>
>>> Upstream Rust dev here. Indeed we'd strongly prefer if this could use a
>>> built-in Rust target; we can work with you on adding a new target if that is
>>> needed.
>>> The kernel currently uses a custom JSON target on x86 and that's quite the
>>> headache for compiler development: JSON targets are highly unstable and
>>> directly expose low-level details of how the compiler internally represents
>>> targets. When we change that representation, we update all built-in targets,
>>> but of course we cannot update JSON targets. So whenever possible we'd like
>>> to move towards reducing the number of JSON targets used by the kernel, not
>>> increase it. :)
>>>
>>> Kind regards,
>>> Ralf
>>>
>> Hey,
>>
>> Sorry for delayed response. I was out of network zone.
>>
>> I am not sure about the process of how to get this in rust toolchain.
>> Should I raise an issue of github for this?
> 
> You would need to add a new file to compiler/rustc_target/src/spec/targets
> in the rustc repository.
> 
> If you're not sure what to put there, I would suggest coming up with
> something that looks plausible, and opening a PR with that. Then others
> can help you with filling out the target correctly.

Also see the documentation at 
<https://doc.rust-lang.org/rustc/target-tier-policy.html#adding-a-new-target>.

Kind regards,
Ralf

[PATCH V6 3/3] powerpc: Enable Rust for ppc64le

[Mukesh Kumar Chaurasiya (IBM)]

Enabling rust support for ppc64le only.

Tested on powernv9:

$ uname -rm
6.19.0-rc8+ ppc64le

$ sudo modprobe rust_minimal
[  632.890850] rust_minimal: Rust minimal sample (init)
[  632.890881] rust_minimal: Am I built-in? false
[  632.890898] rust_minimal: test_parameter: 1

$ sudo rmmod rust_minimal
[  648.272832] rust_minimal: My numbers are [72, 108, 200]
[  648.272873] rust_minimal: Rust minimal sample (exit)

$ sudo modprobe rust_print
[  843.410391] rust_print: Rust printing macros sample (init)
[  843.410424] rust_print: Emergency message (level 0) without args
[  843.410451] rust_print: Alert message (level 1) without args
[  843.410477] rust_print: Critical message (level 2) without args
[  843.410503] rust_print: Error message (level 3) without args
[  843.410530] rust_print: Warning message (level 4) without args
[  843.410557] rust_print: Notice message (level 5) without args
[  843.410594] rust_print: Info message (level 6) without args
[  843.410617] rust_print: A line that is continued without args
[  843.410646] rust_print: Emergency message (level 0) with args
[  843.410675] rust_print: Alert message (level 1) with args
[  843.410691] rust_print: Critical message (level 2) with args
[  843.410727] rust_print: Error message (level 3) with args
[  843.410761] rust_print: Warning message (level 4) with args
[  843.410796] rust_print: Notice message (level 5) with args
[  843.410821] rust_print: Info message (level 6) with args
[  843.410854] rust_print: A line that is continued with args
[  843.410892] rust_print: 1
[  843.410895] rust_print: "hello, world"
[  843.410924] rust_print: [samples/rust/rust_print_main.rs:35:5] c = "hello, world"
[  843.410977] rust_print: Arc<dyn Display> says 42
[  843.410979] rust_print: Arc<dyn Display> says hello, world

$ sudo rmmod rust_print
[  843.411003] rust_print: "hello, world"
[  888.499935] rust_print: Rust printing macros sample (exit)

Reviewed-by: Link Mauve <linkmauve@linkmauve.fr>
Tested-by: Link Mauve <linkmauve@linkmauve.fr>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
---
 Documentation/rust/arch-support.rst | 2 +-
 arch/powerpc/Kconfig                | 1 +
 arch/powerpc/Makefile               | 7 ++++++-
 rust/Makefile                       | 6 ++++++
 4 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Documentation/rust/arch-support.rst b/Documentation/rust/arch-support.rst
index 70b9e192a7a0..70bcd726ad0e 100644
--- a/Documentation/rust/arch-support.rst
+++ b/Documentation/rust/arch-support.rst
@@ -18,7 +18,7 @@ Architecture   Level of support  Constraints
 ``arm``        Maintained        ARMv7 Little Endian only.
 ``arm64``      Maintained        Little Endian only.
 ``loongarch``  Maintained        \-
-``powerpc``    Maintained        32-bit Big Endian only.
+``powerpc``    Maintained        64-bit Little Endian. 32-bit Big Endian.
 ``riscv``      Maintained        ``riscv64`` and LLVM/Clang only.
 ``um``         Maintained        \-
 ``x86``        Maintained        ``x86_64`` only.
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 17db23b82e91..954af27e10c5 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -284,6 +284,7 @@ config PPC
 	select HAVE_RELIABLE_STACKTRACE
 	select HAVE_RSEQ
 	select HAVE_RUST			if PPC32
+	select HAVE_RUST			if PPC64 && CPU_LITTLE_ENDIAN
 	select HAVE_SAMPLE_FTRACE_DIRECT	if HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 	select HAVE_SAMPLE_FTRACE_DIRECT_MULTI	if HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 	select HAVE_SETUP_PER_CPU_AREA		if PPC64
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 9fd82c75dcbd..9385db478c59 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -61,7 +61,12 @@ else
 KBUILD_LDFLAGS_MODULE += $(objtree)/arch/powerpc/lib/crtsavres.o
 endif
 
-KBUILD_RUSTFLAGS += --target=powerpc-unknown-linux-gnu
+ifdef CONFIG_PPC64
+KBUILD_RUSTFLAGS	+= --target=powerpc64le-unknown-linux-gnu
+KBUILD_RUSTFLAGS	+= -Ctarget-feature=-mma,-vsx,-hard-float,-altivec
+else
+KBUILD_RUSTFLAGS	+= --target=powerpc-unknown-linux-gnu
+endif
 
 ifdef CONFIG_CPU_LITTLE_ENDIAN
 KBUILD_CPPFLAGS	+= -mlittle-endian
diff --git a/rust/Makefile b/rust/Makefile
index ae22f2c5f0b3..0aef472c6cf5 100644
--- a/rust/Makefile
+++ b/rust/Makefile
@@ -392,7 +392,13 @@ BINDGEN_TARGET_x86	:= x86_64-linux-gnu
 BINDGEN_TARGET_arm64	:= aarch64-linux-gnu
 BINDGEN_TARGET_arm	:= arm-linux-gnueabi
 BINDGEN_TARGET_loongarch	:= loongarch64-linux-gnusf
+
+ifdef CONFIG_PPC64
+BINDGEN_TARGET_powerpc	:= powerpc64le-linux-gnu
+else
 BINDGEN_TARGET_powerpc	:= powerpc-linux-gnu
+endif
+
 BINDGEN_TARGET_um	:= $(BINDGEN_TARGET_$(SUBARCH))
 BINDGEN_TARGET		:= $(BINDGEN_TARGET_$(SRCARCH))
 
-- 
2.53.0

Re: [PATCH V6 0/3] Rust support for powerpc

[Madhavan Srinivasan]

On 2/10/26 2:30 PM, Mukesh Kumar Chaurasiya (IBM) wrote:
> Enable experimental rust support for ppc64le and ppc32be. The patch for
> ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been
> merged over it. ppc32 needs some toolchain fixes mentioned in the patch
> `rust: Add PowerPC support` and the discussion for that is done here[1].
>
> This has been tested on powernv9 hardware and power10 pseries qemu. I
> I request Link to test the ppc32 part as i don't have a hardware to test
> it out.
>
> [1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr
> [2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com

Could see these build issues with the Rust patchset in the compilation 
of powerpc-next-test
This happens when compilation happens only with few threads

# rustc --version
rustc 1.94.0 (4a4ef493e 2026-03-02)

....
   EXPORTS rust/exports_core_generated.h
   BINDGEN rust/bindings/bindings_generated.rs
   BINDGEN rust/bindings/bindings_helpers_generated.rs
   CC      rust/helpers/helpers.o
   EXPORTS rust/exports_helpers_generated.h
   RUSTC L rust/compiler_builtins.o
   RUSTC L rust/ffi.o
   RUSTC PL rust/libproc_macro2.rlib
error[E0464]: multiple candidates for `rmeta` dependency `core` found
  --> rust/proc-macro2/marker.rs:4:5
   |
4 | use core::marker::PhantomData;
   |     ^^^^
   |
   = note: candidate #1: 
/root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/powerpc64le-unknown-linux-gnu/lib/libcore-951759db375eea0c.rmeta
   = note: candidate #2: ./rust/libcore.rmeta

error[E0119]: conflicting implementations of trait `PartialEq` for type 
`fallback::Ident`
    --> rust/proc-macro2/fallback.rs:875:1
     |
869 |   impl PartialEq for Ident {
     |   ------------------------ first implementation here
...
875 | / impl<T> PartialEq<T> for Ident
876 | | where
877 | |     T: ?Sized + AsRef<str>,
     | |___________________________^ conflicting implementation for 
`fallback::Ident`

error[E0277]: `LexError` doesn't implement `std::fmt::Display`
    --> rust/proc-macro2/lib.rs:347:16
     |
347 | impl Error for LexError {}
     |                ^^^^^^^^ unsatisfied trait bound
     |
help: the trait `std::fmt::Display` is not implemented for `LexError`
    --> rust/proc-macro2/lib.rs:204:1
     |
204 | pub struct LexError {
     | ^^^^^^^^^^^^^^^^^^^
note: required by a bound in `std::error::Error`
    --> 
/root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/error.rs:59:26
     |
  59 | pub trait Error: Debug + Display {
     |                          ^^^^^^^ required by this bound in `Error`

error[E0277]: `LexError` doesn't implement `Debug`
    --> rust/proc-macro2/lib.rs:347:16
     |
347 | impl Error for LexError {}
     |                ^^^^^^^^ unsatisfied trait bound
     |
help: the trait `Debug` is not implemented for `LexError`
    --> rust/proc-macro2/lib.rs:204:1
     |
204 | pub struct LexError {
     | ^^^^^^^^^^^^^^^^^^^
     = note: add `#[derive(Debug)]` to `LexError` or manually `impl 
Debug for LexError`
note: required by a bound in `std::error::Error`
    --> 
/root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/error.rs:59:18
     |
  59 | pub trait Error: Debug + Display {
     |                  ^^^^^ required by this bound in `Error`

error: aborting due to 4 previous errors

......
But when parallelized with more threads (-j 128) compilation passes with 
out any error
There is some ordering of libcore is messing up I guess (I could be wrong)
(I have removed the warning of unstable features messages here for 
cleaner output)

....
   VDSO64SYM include/generated/vdso64-offsets.h
   RUSTC L rust/core.o
   BINDGEN rust/bindings/bindings_generated.rs
   BINDGEN rust/bindings/bindings_helpers_generated.rs
   CC      rust/helpers/helpers.o
   RUSTC PL rust/libproc_macro2.rlib
   BINDGEN rust/uapi/uapi_generated.rs
   RSCPP     rust/kernel/generated_arch_static_branch_asm.rs
   RSCPP     rust/kernel/generated_arch_warn_asm.rs
   RSCPP     rust/kernel/generated_arch_reachable_asm.rs
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:5:9: warning: 
'_IOC_SIZEBITS' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:6:9: warning: 
'_IOC_DIRBITS' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:8:9: warning: 
'_IOC_NONE' macro redefined [-Wmacro-redefined]
clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:10:9: warning: 
'_IOC_WRITE' macro redefined [-Wmacro-redefined]
   EXPORTS rust/exports_helpers_generated.h
   RUSTC PL rust/libquote.rlib
   RUSTC PL rust/libsyn.rlib
   RUSTC P rust/libpin_init_internal.so
   RUSTC P rust/libmacros.so
   EXPORTS rust/exports_core_generated.h
   RUSTC L rust/compiler_builtins.o
   RUSTC L rust/ffi.o
   RUSTC L rust/pin_init.o
   RUSTC L rust/build_error.o
   RUSTC L rust/bindings.o
   RUSTC L rust/uapi.o
   EXPORTS rust/exports_bindings_generated.h
   RUSTC L rust/kernel.o
   EXPORTS rust/exports_kernel_generated.h
   LDS     scripts/module.lds
   HOSTCC  usr/gen_init_cpio
   CC      init/main.o
....

Also I see some errors when compiling modules. I am looking at these and 
any help is welcome.
I will pull out Rust patches for now from powerpc-linux next-test branch 
and once this is
restored I will add these patches back to branch for the merge.

Maddy

> Changelog:
> V5 -> V6:
> - Added a missing Tested by from Venkat which got missed since V3
> - Support is marked as Maintained instead of experimental
> V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com
>
> V4 -> V5:
> - Removed a nested ifdef from PPC64 for Little endian toolchain
> V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com
>
> V3 -> V4:
> - Co-developed-by header added in patch 1
> V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com
>
> V2 -> V3:
> - Splited HAVE_RUST in 2 lines
> - BINDGEN_TARGET_powerpc initialized before assigning the same to
>    BINDGEN_TARGET
> V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com
>
> V1 -> V2:
> - jump label fix for rust has been moved to a separate patch
> - PPC32 support has been taken
> - rust support has been marked experimental
> - target.json dependency has been removed
> - HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64
>
>
> Link Mauve (1):
>    rust: Add PowerPC support
>
> Mukesh Kumar Chaurasiya (IBM) (2):
>    powerpc/jump_label: adjust inline asm to be consistent
>    powerpc: Enable Rust for ppc64le
>
>   Documentation/rust/arch-support.rst   |  1 +
>   arch/powerpc/Kconfig                  |  2 ++
>   arch/powerpc/Makefile                 |  7 +++++++
>   arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
>   rust/Makefile                         | 10 +++++++++-
>   5 files changed, 32 insertions(+), 11 deletions(-)
>

Re: [PATCH V6 0/3] Rust support for powerpc

[Mukesh Kumar Chaurasiya]

On Wed, Mar 25, 2026 at 01:59:55PM +0530, Madhavan Srinivasan wrote:
> 
> On 2/10/26 2:30 PM, Mukesh Kumar Chaurasiya (IBM) wrote:
> > Enable experimental rust support for ppc64le and ppc32be. The patch for
> > ppc32 has been provided by Link Mauve[1] and ppc64le support[2] has been
> > merged over it. ppc32 needs some toolchain fixes mentioned in the patch
> > `rust: Add PowerPC support` and the discussion for that is done here[1].
> > 
> > This has been tested on powernv9 hardware and power10 pseries qemu. I
> > I request Link to test the ppc32 part as i don't have a hardware to test
> > it out.
> > 
> > [1] https://lore.kernel.org/all/20260204030507.8203-1-linkmauve@linkmauve.fr
> > [2] https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com
> 
> Could see these build issues with the Rust patchset in the compilation of
> powerpc-next-test
> This happens when compilation happens only with few threads
> 
> # rustc --version
> rustc 1.94.0 (4a4ef493e 2026-03-02)
> 
> ....
>   EXPORTS rust/exports_core_generated.h
>   BINDGEN rust/bindings/bindings_generated.rs
>   BINDGEN rust/bindings/bindings_helpers_generated.rs
>   CC      rust/helpers/helpers.o
>   EXPORTS rust/exports_helpers_generated.h
>   RUSTC L rust/compiler_builtins.o
>   RUSTC L rust/ffi.o
>   RUSTC PL rust/libproc_macro2.rlib
> error[E0464]: multiple candidates for `rmeta` dependency `core` found
>  --> rust/proc-macro2/marker.rs:4:5
>   |
> 4 | use core::marker::PhantomData;
>   |     ^^^^
>   |
>   = note: candidate #1: /root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/powerpc64le-unknown-linux-gnu/lib/libcore-951759db375eea0c.rmeta
>   = note: candidate #2: ./rust/libcore.rmeta
> 
> error[E0119]: conflicting implementations of trait `PartialEq` for type
> `fallback::Ident`
>    --> rust/proc-macro2/fallback.rs:875:1
>     |
> 869 |   impl PartialEq for Ident {
>     |   ------------------------ first implementation here
> ...
> 875 | / impl<T> PartialEq<T> for Ident
> 876 | | where
> 877 | |     T: ?Sized + AsRef<str>,
>     | |___________________________^ conflicting implementation for
> `fallback::Ident`
> 
> error[E0277]: `LexError` doesn't implement `std::fmt::Display`
>    --> rust/proc-macro2/lib.rs:347:16
>     |
> 347 | impl Error for LexError {}
>     |                ^^^^^^^^ unsatisfied trait bound
>     |
> help: the trait `std::fmt::Display` is not implemented for `LexError`
>    --> rust/proc-macro2/lib.rs:204:1
>     |
> 204 | pub struct LexError {
>     | ^^^^^^^^^^^^^^^^^^^
> note: required by a bound in `std::error::Error`
>    --> /root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/error.rs:59:26
>     |
>  59 | pub trait Error: Debug + Display {
>     |                          ^^^^^^^ required by this bound in `Error`
> 
> error[E0277]: `LexError` doesn't implement `Debug`
>    --> rust/proc-macro2/lib.rs:347:16
>     |
> 347 | impl Error for LexError {}
>     |                ^^^^^^^^ unsatisfied trait bound
>     |
> help: the trait `Debug` is not implemented for `LexError`
>    --> rust/proc-macro2/lib.rs:204:1
>     |
> 204 | pub struct LexError {
>     | ^^^^^^^^^^^^^^^^^^^
>     = note: add `#[derive(Debug)]` to `LexError` or manually `impl Debug for
> LexError`
> note: required by a bound in `std::error::Error`
>    --> /root/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/error.rs:59:18
>     |
>  59 | pub trait Error: Debug + Display {
>     |                  ^^^^^ required by this bound in `Error`
> 
> error: aborting due to 4 previous errors
> 
> ......
> But when parallelized with more threads (-j 128) compilation passes with out
> any error
> There is some ordering of libcore is messing up I guess (I could be wrong)
> (I have removed the warning of unstable features messages here for cleaner
> output)
> 
> ....
>   VDSO64SYM include/generated/vdso64-offsets.h
>   RUSTC L rust/core.o
>   BINDGEN rust/bindings/bindings_generated.rs
>   BINDGEN rust/bindings/bindings_helpers_generated.rs
>   CC      rust/helpers/helpers.o
>   RUSTC PL rust/libproc_macro2.rlib
>   BINDGEN rust/uapi/uapi_generated.rs
>   RSCPP     rust/kernel/generated_arch_static_branch_asm.rs
>   RSCPP     rust/kernel/generated_arch_warn_asm.rs
>   RSCPP     rust/kernel/generated_arch_reachable_asm.rs
> clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:5:9: warning:
> '_IOC_SIZEBITS' macro redefined [-Wmacro-redefined]
> clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:6:9: warning:
> '_IOC_DIRBITS' macro redefined [-Wmacro-redefined]
> clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:8:9: warning:
> '_IOC_NONE' macro redefined [-Wmacro-redefined]
> clang diag: ./arch/powerpc/include/uapi/asm/ioctl.h:10:9: warning:
> '_IOC_WRITE' macro redefined [-Wmacro-redefined]
>   EXPORTS rust/exports_helpers_generated.h
>   RUSTC PL rust/libquote.rlib
>   RUSTC PL rust/libsyn.rlib
>   RUSTC P rust/libpin_init_internal.so
>   RUSTC P rust/libmacros.so
>   EXPORTS rust/exports_core_generated.h
>   RUSTC L rust/compiler_builtins.o
>   RUSTC L rust/ffi.o
>   RUSTC L rust/pin_init.o
>   RUSTC L rust/build_error.o
>   RUSTC L rust/bindings.o
>   RUSTC L rust/uapi.o
>   EXPORTS rust/exports_bindings_generated.h
>   RUSTC L rust/kernel.o
>   EXPORTS rust/exports_kernel_generated.h
>   LDS     scripts/module.lds
>   HOSTCC  usr/gen_init_cpio
>   CC      init/main.o
> ....
> 
> Also I see some errors when compiling modules. I am looking at these and any
> help is welcome.
> I will pull out Rust patches for now from powerpc-linux next-test branch and
> once this is
> restored I will add these patches back to branch for the merge.
> 
> Maddy
> 
Aah this happens because core.o is compiled before libproc_macro2.rlib
starts compiling. Once the core.o is compiled it generates the
libcore.rmeta, leading to conflict in two libcore.rmeta available.

I can think of 2 solutions here for this,

1. We can make the libproc_macro2.rlib libquote.rlib libsyn.rlib compile
befor the core.o is compiled OR
2. We can force these to use the toolchain core's metadata and not look
into the kernel's rust directory.

I am still not able to figure out why this is not happening for x86.

What should we do in this case?

Regards,
Mukesh

> > Changelog:
> > V5 -> V6:
> > - Added a missing Tested by from Venkat which got missed since V3
> > - Support is marked as Maintained instead of experimental
> > V5: https://lore.kernel.org/all/20260210053756.2088302-1-mkchauras@gmail.com
> > 
> > V4 -> V5:
> > - Removed a nested ifdef from PPC64 for Little endian toolchain
> > V4: https://lore.kernel.org/all/20260209105456.1551677-1-mkchauras@gmail.com
> > 
> > V3 -> V4:
> > - Co-developed-by header added in patch 1
> > V3: https://lore.kernel.org/all/20260205180429.3280657-1-mkchauras@gmail.com
> > 
> > V2 -> V3:
> > - Splited HAVE_RUST in 2 lines
> > - BINDGEN_TARGET_powerpc initialized before assigning the same to
> >    BINDGEN_TARGET
> > V2: https://lore.kernel.org/all/20260204210125.613350-1-mkchauras@gmail.com
> > 
> > V1 -> V2:
> > - jump label fix for rust has been moved to a separate patch
> > - PPC32 support has been taken
> > - rust support has been marked experimental
> > - target.json dependency has been removed
> > - HAVE_RUST now depends on CPU_LITTLE_ENDIAN for PPC64
> > 
> > 
> > Link Mauve (1):
> >    rust: Add PowerPC support
> > 
> > Mukesh Kumar Chaurasiya (IBM) (2):
> >    powerpc/jump_label: adjust inline asm to be consistent
> >    powerpc: Enable Rust for ppc64le
> > 
> >   Documentation/rust/arch-support.rst   |  1 +
> >   arch/powerpc/Kconfig                  |  2 ++
> >   arch/powerpc/Makefile                 |  7 +++++++
> >   arch/powerpc/include/asm/jump_label.h | 23 +++++++++++++----------
> >   rust/Makefile                         | 10 +++++++++-
> >   5 files changed, 32 insertions(+), 11 deletions(-)
> >