[PATCH] rust: Add PowerPC support

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 <redacted>
---
 Documentation/rust/arch-support.rst   |  1 +
 arch/powerpc/Kconfig                  |  1 +
 arch/powerpc/Makefile                 |  2 ++
 arch/powerpc/include/asm/jump_label.h | 16 ++++++++++------
 rust/Makefile                         |  4 +++-
 scripts/generate_rust_target.rs       | 10 ++++++++++
 6 files changed, 27 insertions(+), 7 deletions(-)

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/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
index d4eaba459a0e..238f0f625a36 100644
--- a/arch/powerpc/include/asm/jump_label.h
+++ b/arch/powerpc/include/asm/jump_label.h

@@ -15,14 +15,18 @@
 #define JUMP_ENTRY_TYPE		stringify_in_c(FTR_ENTRY_LONG)
 #define JUMP_LABEL_NOP_SIZE	4
 
+/* This macro is also expanded on the Rust side. */
+#define ARCH_STATIC_BRANCH_ASM(key, label)		\
+	"1:\n\t"					\
+	"nop # arch_static_branch\n\t"			\
+	".pushsection __jump_table,  \"aw\"\n\t"	\
+	".long 1b - ., " label " - .\n\t"		\
+	 JUMP_ENTRY_TYPE key " - .\n\t"			\
+	 ".popsection \n\t"
+
 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;

diff --git a/rust/Makefile b/rust/Makefile
index 5c0155b83454..377e6fd68524 100644
--- a/rust/Makefile
+++ b/rust/Makefile

@@ -400,13 +400,15 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \
 	-fno-inline-functions-called-once -fsanitize=bounds-strict \
 	-fstrict-flex-arrays=% -fmin-function-alignment=% \
 	-fzero-init-padding-bits=% -mno-fdpic \
-	--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))
 

diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 38b3416bb979..0054880ba0ea 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs

@@ -188,6 +188,16 @@ fn main() {
         panic!("arm uses the builtin rustc target");
     } else if cfg.has("ARM64") {
         panic!("arm64 uses the builtin rustc aarch64-unknown-none target");
+    } else if cfg.has("PPC32") {
+        ts.push("arch", "powerpc");
+        ts.push("data-layout", "E-m:e-p:32:32-Fn32-i64:64-n32");
+        ts.push("features", "+soft-float");
+        ts.push("llvm-target", "powerpc-unknown-eabi");
+        if cfg.rustc_version_atleast(1, 91, 0) {
+            ts.push("target-pointer-width", 32);
+        } else {
+            ts.push("target-pointer-width", "32");
+        }
     } else if cfg.has("RISCV") {
         if cfg.has("64BIT") {
             panic!("64-bit RISC-V uses the builtin rustc riscv64-unknown-none-elf target");

-- 
2.52.0

On Wed, Feb 04, 2026 at 04:05:04AM +0100, Link Mauve wrote:

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.

Super cool!

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.

Uh oh this seems tricky. How is this not a problem on arm32 too?

Perhaps we should just be providing __udivdi3() and __umoddi3() in
general?

In case this patch takes a long time to land, it may make sense to split
this part out in a separate patch that can land now.

Also, consider pre-emptively updating arch_static_branch_jump too. We
probably need it at some point in the future.

Is there no built-in target we can use? I think we want to avoid adding
new targets if at all possible.

Alice

On Wed Feb 4, 2026 at 10:41 AM GMT, Alice Ryhl wrote:

On Wed, Feb 04, 2026 at 04:05:04AM +0100, Link Mauve wrote:

quoted

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.

Super cool!

quoted

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.

Uh oh this seems tricky. How is this not a problem on arm32 too?

Perhaps we should just be providing __udivdi3() and __umoddi3() in
general?

I think there is some concern that if this is provided, then C side that uses
the divide operator instead of dividing function doesn't get linker error
anymore.

However, a proper way is to do this via the hooks that we already have in
`compiler_builtins.rs`.

This can either be replace these with panics or actual implementation, but for
libcore.o only.

Best,
Gary

quoted

diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
index d4eaba459a0e..238f0f625a36 100644
--- a/arch/powerpc/include/asm/jump_label.h
+++ b/arch/powerpc/include/asm/jump_label.h

@@ -15,14 +15,18 @@
 #define JUMP_ENTRY_TYPE		stringify_in_c(FTR_ENTRY_LONG)
 #define JUMP_LABEL_NOP_SIZE	4
 
+/* This macro is also expanded on the Rust side. */
+#define ARCH_STATIC_BRANCH_ASM(key, label)		\
+	"1:\n\t"					\
+	"nop # arch_static_branch\n\t"			\
+	".pushsection __jump_table,  \"aw\"\n\t"	\
+	".long 1b - ., " label " - .\n\t"		\
+	 JUMP_ENTRY_TYPE key " - .\n\t"			\
+	 ".popsection \n\t"
+
 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);

In case this patch takes a long time to land, it may make sense to split
this part out in a separate patch that can land now.

Also, consider pre-emptively updating arch_static_branch_jump too. We
probably need it at some point in the future.

quoted

diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 38b3416bb979..0054880ba0ea 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs

@@ -188,6 +188,16 @@ fn main() {
         panic!("arm uses the builtin rustc target");
     } else if cfg.has("ARM64") {
         panic!("arm64 uses the builtin rustc aarch64-unknown-none target");
+    } else if cfg.has("PPC32") {
+        ts.push("arch", "powerpc");
+        ts.push("data-layout", "E-m:e-p:32:32-Fn32-i64:64-n32");
+        ts.push("features", "+soft-float");
+        ts.push("llvm-target", "powerpc-unknown-eabi");
+        if cfg.rustc_version_atleast(1, 91, 0) {
+            ts.push("target-pointer-width", 32);
+        } else {
+            ts.push("target-pointer-width", "32");
+        }

Is there no built-in target we can use? I think we want to avoid adding
new targets if at all possible.

Alice

On Wed, Feb 04, 2026 at 12:36:38PM +0000, Gary Guo wrote:

On Wed Feb 4, 2026 at 10:41 AM GMT, Alice Ryhl wrote:

quoted

On Wed, Feb 04, 2026 at 04:05:04AM +0100, Link Mauve wrote:

quoted

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.

Super cool!

quoted

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.

Uh oh this seems tricky. How is this not a problem on arm32 too?

Perhaps we should just be providing __udivdi3() and __umoddi3() in
general?

I think there is some concern that if this is provided, then C side that uses
the divide operator instead of dividing function doesn't get linker error
anymore.

However, a proper way is to do this via the hooks that we already have in
`compiler_builtins.rs`.

This can either be replace these with panics or actual implementation, but for
libcore.o only.

Is there any reason to not make it Rust-only but for all Rust code?
Making the / operator work seems like it would be a good idea.

Alice

On Wed, Feb 04, 2026 at 12:55:17PM +0000, Alice Ryhl wrote:

Is there any reason to not make it Rust-only but for all Rust code?
Making the / operator work seems like it would be a good idea.

Why would it be a good idea to have it work on non-native types in Rust?

The reason we don't have them in C is because non-native divisions are
expensive and doing them should be a conscious choice. The very same
argument should be true for Rust code too.

On Wed, Feb 04, 2026 at 02:06:53PM +0100, Peter Zijlstra wrote:

On Wed, Feb 04, 2026 at 12:55:17PM +0000, Alice Ryhl wrote:

quoted

Is there any reason to not make it Rust-only but for all Rust code?
Making the / operator work seems like it would be a good idea.

Why would it be a good idea to have it work on non-native types in Rust?

The reason we don't have them in C is because non-native divisions are
expensive and doing them should be a conscious choice. The very same
argument should be true for Rust code too.

I suppose that's fair. Perhaps one way to go about it could be to create
a clippy lint for 64-bit divisions telling you to use an explicit
division method?

This way cases such as `core` that use division can still use the slash
operator because the lint is not enabled when building core. And normal
kernel code would be told to use the explicit method instead. Or kernel
code could explicitly choose to silence the lint on a specific method if
they want to perform a lot of divisions and know what they are doing.

Alice

Le 04/02/2026 à 11:41, Alice Ryhl a écrit :

On Wed, Feb 04, 2026 at 04:05:04AM +0100, Link Mauve wrote:

quoted

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.

Super cool!

quoted

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.

Uh oh this seems tricky. How is this not a problem on arm32 too?

Perhaps we should just be providing __udivdi3() and __umoddi3() in
general?

We don't want those functions in the kernel as they are sub-optimal and 
unnecessary. Usually the kernel needs can be covered with do_div() or 
other functions in include/asm-generic/div64.h. If we add those 
functions people will start doing divides blindly in the kernel 
forgetting the huge cost a 64 bits divide has on a 32 bits processor.

quoted

diff --git a/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
index d4eaba459a0e..238f0f625a36 100644
--- a/arch/powerpc/include/asm/jump_label.h
+++ b/arch/powerpc/include/asm/jump_label.h

@@ -15,14 +15,18 @@
  #define JUMP_ENTRY_TYPE		stringify_in_c(FTR_ENTRY_LONG)
  #define JUMP_LABEL_NOP_SIZE	4
  
+/* This macro is also expanded on the Rust side. */
+#define ARCH_STATIC_BRANCH_ASM(key, label)		\
+	"1:\n\t"					\
+	"nop # arch_static_branch\n\t"			\
+	".pushsection __jump_table,  \"aw\"\n\t"	\
+	".long 1b - ., " label " - .\n\t"		\
+	 JUMP_ENTRY_TYPE key " - .\n\t"			\
+	 ".popsection \n\t"
+

Would be better split in two with a JUMP_TABLE_ENTRY() macro as other 
architectures and as done by Mukesh in its patch, see 
https://lore.kernel.org/r/20260204042417.83903-1-mkchauras@gmail.com

quoted

  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);

In case this patch takes a long time to land, it may make sense to split
this part out in a separate patch that can land now.

Also, consider pre-emptively updating arch_static_branch_jump too. We
probably need it at some point in the future.

quoted

diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 38b3416bb979..0054880ba0ea 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs

@@ -188,6 +188,16 @@ fn main() {
          panic!("arm uses the builtin rustc target");
      } else if cfg.has("ARM64") {
          panic!("arm64 uses the builtin rustc aarch64-unknown-none target");
+    } else if cfg.has("PPC32") {
+        ts.push("arch", "powerpc");
+        ts.push("data-layout", "E-m:e-p:32:32-Fn32-i64:64-n32");
+        ts.push("features", "+soft-float");
+        ts.push("llvm-target", "powerpc-unknown-eabi");
+        if cfg.rustc_version_atleast(1, 91, 0) {
+            ts.push("target-pointer-width", 32);
+        } else {
+            ts.push("target-pointer-width", "32");
+        }

Is there no built-in target we can use? I think we want to avoid adding
new targets if at all possible.

Alice

On Wed, Feb 04, 2026 at 04:05:04AM +0100, Link Mauve wrote:

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.

Hey Link,
I sent a patch with ppc64le support. 
https://lore.kernel.org/all/20260204042417.83903-1-mkchauras@gmail.com/

Can i take this patch and put ppc64le support over it and send it out?

Regards,
Mukesh

Le 04/02/2026 à 18:33, Mukesh Kumar Chaurasiya a écrit :

[Vous ne recevez pas souvent de courriers de mkchauras@gmail.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

On Wed, Feb 04, 2026 at 04:05:04AM +0100, Link Mauve wrote:

quoted

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.

Hey Link,
I sent a patch with ppc64le support.
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20260204042417.83903-1-mkchauras%40gmail.com%2F&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C9033c0c08e1142c26cc408de6420675d%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639058287509811601%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LglEn8yJoYUcsXoENa8HO4SsOW4kKU397kDNVyfBilg%3D&reserved=0

Can i take this patch and put ppc64le support over it and send it out?

Could also one of you feed https://github.com/linuxppc/issues/issues/451 ?

Thanks
Christophe

Regards,
Mukesh

quoted

Signed-off-by: Link Mauve <redacted>
---
  Documentation/rust/arch-support.rst   |  1 +
  arch/powerpc/Kconfig                  |  1 +
  arch/powerpc/Makefile                 |  2 ++
  arch/powerpc/include/asm/jump_label.h | 16 ++++++++++------
  rust/Makefile                         |  4 +++-
  scripts/generate_rust_target.rs       | 10 ++++++++++
  6 files changed, 27 insertions(+), 7 deletions(-)

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/arch/powerpc/include/asm/jump_label.h b/arch/powerpc/include/asm/jump_label.h
index d4eaba459a0e..238f0f625a36 100644
--- a/arch/powerpc/include/asm/jump_label.h
+++ b/arch/powerpc/include/asm/jump_label.h

@@ -15,14 +15,18 @@
  #define JUMP_ENTRY_TYPE              stringify_in_c(FTR_ENTRY_LONG)
  #define JUMP_LABEL_NOP_SIZE  4

+/* This macro is also expanded on the Rust side. */
+#define ARCH_STATIC_BRANCH_ASM(key, label)           \
+     "1:\n\t"                                        \
+     "nop # arch_static_branch\n\t"                  \
+     ".pushsection __jump_table,  \"aw\"\n\t"        \
+     ".long 1b - ., " label " - .\n\t"               \
+      JUMP_ENTRY_TYPE key " - .\n\t"                 \
+      ".popsection \n\t"
+
  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;

diff --git a/rust/Makefile b/rust/Makefile
index 5c0155b83454..377e6fd68524 100644
--- a/rust/Makefile
+++ b/rust/Makefile

@@ -400,13 +400,15 @@ bindgen_skip_c_flags := -mno-fp-ret-in-387 -mpreferred-stack-boundary=% \
       -fno-inline-functions-called-once -fsanitize=bounds-strict \
       -fstrict-flex-arrays=% -fmin-function-alignment=% \
       -fzero-init-padding-bits=% -mno-fdpic \
-     --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))

diff --git a/scripts/generate_rust_target.rs b/scripts/generate_rust_target.rs
index 38b3416bb979..0054880ba0ea 100644
--- a/scripts/generate_rust_target.rs
+++ b/scripts/generate_rust_target.rs

@@ -188,6 +188,16 @@ fn main() {
          panic!("arm uses the builtin rustc target");
      } else if cfg.has("ARM64") {
          panic!("arm64 uses the builtin rustc aarch64-unknown-none target");
+    } else if cfg.has("PPC32") {
+        ts.push("arch", "powerpc");
+        ts.push("data-layout", "E-m:e-p:32:32-Fn32-i64:64-n32");
+        ts.push("features", "+soft-float");
+        ts.push("llvm-target", "powerpc-unknown-eabi");
+        if cfg.rustc_version_atleast(1, 91, 0) {
+            ts.push("target-pointer-width", 32);
+        } else {
+            ts.push("target-pointer-width", "32");
+        }
      } else if cfg.has("RISCV") {
          if cfg.has("64BIT") {
              panic!("64-bit RISC-V uses the builtin rustc riscv64-unknown-none-elf target");
--

2.52.0