arm64: Remove unused big-endian support

The CPU_LE()/CPU_BE() helper macros are only used by head.S. Since big-endian support depends on BROKEN, remove the last users along with the macro definitions. The unused regs_to_64() assembly macro, which somewhat bizarrely behaves differently depend on the endianness, is also removed.

Signed-off-by Will Deacon <[email protected]>

---
 arch/arm64/include/asm/assembler.h | 31 ------------------------------
 arch/arm64/kernel/head.S           |  3 +--
 2 files changed, 1 insertion(+), 33 deletions(-)

arch/arm64/include/asm/assembler.h +0 -31

index effae53e9739..45279e577ff5 100644
@@ -133,37 +133,6 @@ lr	.req	x30		// link register
 	b	\label
 	.endm
 
-/*
- * Select code when configured for BE.
- */
-#ifdef CONFIG_CPU_BIG_ENDIAN
-#define CPU_BE(code...) code
-#else
-#define CPU_BE(code...)
-#endif
-
-/*
- * Select code when configured for LE.
- */
-#ifdef CONFIG_CPU_BIG_ENDIAN
-#define CPU_LE(code...)
-#else
-#define CPU_LE(code...) code
-#endif
-
-/*
- * Define a macro that constructs a 64-bit value by concatenating two
- * 32-bit registers. Note that on big endian systems the order of the
- * registers is swapped.
- */
-#ifndef CONFIG_CPU_BIG_ENDIAN
-	.macro	regs_to_64, rd, lbits, hbits
-#else
-	.macro	regs_to_64, rd, hbits, lbits
-#endif
-	orr	\rd, \lbits, \hbits, lsl #32
-	.endm
-
 /*
  * Pseudo-ops for PC-relative adr/ldr/str <reg>, <symbol> where
  * <symbol> is within the range +/- 4 GB of the PC.

arch/arm64/kernel/head.S +0 -0

index 87a822e5c4ca..8951ce693552 100644

Quoted 9 lines · Will Deacon

arch/arm64/kernel/head.S +0 -1

index 87a822e5c4ca..8951ce693552 100644
@@ -138,8 +138,7 @@ SYM_CODE_START_LOCAL(record_mmu_state)
 	b.ne	0f
 	mrs	x19, sctlr_el2
 0:
-CPU_LE( tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)

arch/arm64/kernel/head.S SYM_CODE_START_LOCAL(record_mmu_state) · line 144

Quoted 5 lines

arch/arm64/kernel/head.S +1 -1

-CPU_BE( tbz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
+	tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f
 	tst	x19, #SCTLR_ELx_C		// Z := (C == 0)
 	and	x19, x19, #SCTLR_ELx_M		// isolate M bit
 	csel	x19, xzr, x19, eq		// clear x19 if Z

There is some more code that can be removed here - see 2ced0f30a426c7301350681f838344d5aea711e3

Quoted 10 lines · Ard Biesheuvel

Quoted 9 lines · Will Deacon

arch/arm64/kernel/head.S +0 -1

index 87a822e5c4ca..8951ce693552 100644
@@ -138,8 +138,7 @@ SYM_CODE_START_LOCAL(record_mmu_state)
 	b.ne	0f
 	mrs	x19, sctlr_el2
 0:
-CPU_LE( tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)

Quoted 8 lines

arch/arm64/kernel/head.S SYM_CODE_START_LOCAL(record_mmu_state) · line 144

Quoted 5 lines

arch/arm64/kernel/head.S +1 -1

-CPU_BE( tbz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
+	tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f
 	tst	x19, #SCTLR_ELx_C		// Z := (C == 0)
 	and	x19, x19, #SCTLR_ELx_M		// isolate M bit
 	csel	x19, xzr, x19, eq		// clear x19 if Z

There is some more code that can be removed here - see 2ced0f30a426c7301350681f838344d5aea711e3

Good spot, thanks! I'll do some more surgery at -rc1.

Quoted 20 lines · Will Deacon

Quoted 18 lines · Ard Biesheuvel

Quoted 5 lines · Will Deacon

arch/arm64/kernel/head.S +0 -0

index 87a822e5c4ca..8951ce693552 100644

arch/arm64/kernel/head.S SYM_CODE_START_LOCAL(record_mmu_state) · line 144

Quoted 9 lines

arch/arm64/kernel/head.S +1 -2

@@ -138,8 +138,7 @@ SYM_CODE_START_LOCAL(record_mmu_state)
 	b.ne	0f
 	mrs	x19, sctlr_el2
 0:
-CPU_LE( tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
-CPU_BE( tbz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
+	tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f
 	tst	x19, #SCTLR_ELx_C		// Z := (C == 0)
 	and	x19, x19, #SCTLR_ELx_M		// isolate M bit
 	csel	x19, xzr, x19, eq		// clear x19 if Z

There is some more code that can be removed here - see 2ced0f30a426c7301350681f838344d5aea711e3

Quoted 1 line

Good spot, thanks! I'll do some more surgery at -rc1.

Looking at this again, I'm not sure we can remove much here. I think we probably still want to force little-endian (i.e. clear the EE bit) if we're entered as big-endian. I've changed the following EOR to a BIC (see below), but I think that's about all we can do?

Quoted 21 lines · Will Deacon

Quoted 20 lines · Will Deacon

Quoted 18 lines · Ard Biesheuvel

Quoted 5 lines · Will Deacon

arch/arm64/kernel/head.S +0 -0

index 87a822e5c4ca..8951ce693552 100644

arch/arm64/kernel/head.S SYM_CODE_START_LOCAL(record_mmu_state) · line 144

Quoted 9 lines

arch/arm64/kernel/head.S +1 -2

@@ -138,8 +138,7 @@ SYM_CODE_START_LOCAL(record_mmu_state)
 	b.ne	0f
 	mrs	x19, sctlr_el2
 0:
-CPU_LE( tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
-CPU_BE( tbz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
+	tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f
 	tst	x19, #SCTLR_ELx_C		// Z := (C == 0)
 	and	x19, x19, #SCTLR_ELx_M		// isolate M bit
 	csel	x19, xzr, x19, eq		// clear x19 if Z

There is some more code that can be removed here - see 2ced0f30a426c7301350681f838344d5aea711e3

Quoted 7 lines

Quoted 1 line

Good spot, thanks! I'll do some more surgery at -rc1.

Looking at this again, I'm not sure we can remove much here. I think we probably still want to force little-endian (i.e. clear the EE bit) if we're entered as big-endian. I've changed the following EOR to a BIC (see below), but I think that's about all we can do?

Well, the only case where we allow an active ID map is when doing EFI boot, which is guaranteed to be little-endian. Since the kernel is now also guaranteed to be little-endian, we should be able to simply kick the CPU in LE mode right at the start, no? And simply ignore the case of a BE bootloader entering with the MMU and caches enabled?

Quoted 31 lines · Ard Biesheuvel

Quoted 21 lines · Will Deacon

Quoted 20 lines · Will Deacon

Quoted 18 lines · Ard Biesheuvel

Quoted 5 lines · Will Deacon

arch/arm64/kernel/head.S +0 -0

index 87a822e5c4ca..8951ce693552 100644

arch/arm64/kernel/head.S SYM_CODE_START_LOCAL(record_mmu_state) · line 144

Quoted 9 lines

arch/arm64/kernel/head.S +1 -2

@@ -138,8 +138,7 @@ SYM_CODE_START_LOCAL(record_mmu_state)
 	b.ne	0f
 	mrs	x19, sctlr_el2
 0:
-CPU_LE( tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
-CPU_BE( tbz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
+	tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f
 	tst	x19, #SCTLR_ELx_C		// Z := (C == 0)
 	and	x19, x19, #SCTLR_ELx_M		// isolate M bit
 	csel	x19, xzr, x19, eq		// clear x19 if Z

There is some more code that can be removed here - see 2ced0f30a426c7301350681f838344d5aea711e3

Quoted 7 lines

Quoted 1 line

Good spot, thanks! I'll do some more surgery at -rc1.

Looking at this again, I'm not sure we can remove much here. I think we probably still want to force little-endian (i.e. clear the EE bit) if we're entered as big-endian. I've changed the following EOR to a BIC (see below), but I think that's about all we can do?

Quoted 5 lines

Well, the only case where we allow an active ID map is when doing EFI boot, which is guaranteed to be little-endian. Since the kernel is now also guaranteed to be little-endian, we should be able to simply kick the CPU in LE mode right at the start, no? And simply ignore the case of a BE bootloader entering with the MMU and caches enabled?

Hmm, so why did we support this in the first place given that EFI is guaranteed to be little-endian? Or was that just because we wanted to handle the case of a big-endian kernel being loaded by EFI?

Quoted 38 lines · Will Deacon

Quoted 31 lines · Ard Biesheuvel

Quoted 21 lines · Will Deacon

Quoted 20 lines · Will Deacon

Quoted 18 lines · Ard Biesheuvel

Quoted 5 lines · Will Deacon

arch/arm64/kernel/head.S +0 -0

index 87a822e5c4ca..8951ce693552 100644

arch/arm64/kernel/head.S SYM_CODE_START_LOCAL(record_mmu_state) · line 144

Quoted 9 lines

arch/arm64/kernel/head.S +1 -2

@@ -138,8 +138,7 @@ SYM_CODE_START_LOCAL(record_mmu_state)
 	b.ne	0f
 	mrs	x19, sctlr_el2
 0:
-CPU_LE( tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
-CPU_BE( tbz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
+	tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f
 	tst	x19, #SCTLR_ELx_C		// Z := (C == 0)
 	and	x19, x19, #SCTLR_ELx_M		// isolate M bit
 	csel	x19, xzr, x19, eq		// clear x19 if Z

There is some more code that can be removed here - see 2ced0f30a426c7301350681f838344d5aea711e3

Quoted 7 lines

Quoted 1 line

Good spot, thanks! I'll do some more surgery at -rc1.

Looking at this again, I'm not sure we can remove much here. I think we probably still want to force little-endian (i.e. clear the EE bit) if we're entered as big-endian. I've changed the following EOR to a BIC (see below), but I think that's about all we can do?

Quoted 5 lines

Well, the only case where we allow an active ID map is when doing EFI boot, which is guaranteed to be little-endian. Since the kernel is now also guaranteed to be little-endian, we should be able to simply kick the CPU in LE mode right at the start, no? And simply ignore the case of a BE bootloader entering with the MMU and caches enabled?

Quoted 4 lines

Hmm, so why did we support this in the first place given that EFI is guaranteed to be little-endian? Or was that just because we wanted to handle the case of a big-endian kernel being loaded by EFI?

The original report is here:
https://lore.kernel.org/linux-arm-kernel/[email protected]/

So it would probably have been sufficient at the time to just kick the CPU into LE mode - I don't remember why I added the additional logic tbh.

Big-endian support on arm64 depends on BROKEN. In preparation for removing the dead code altogether, remove all usage of CONFIG_CPU_BIG_ENDIAN from the arm64 kernel port.

Signed-off-by Will Deacon <[email protected]>

Hi folks,

Big-endian support on arm64 (CONFIG_CPU_BIG_ENDIAN) has depended on BROKEN since 1cf89b6bf660 ("arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN") and has already seen some clean-up patches removing some of the unused support code (e.g. 5276ea17a23c ("lib/crc: arm64: Assume a little-endian kernel")).

Finish the job, and remove the remaining big-endian support code from arm64. Note that the SETEND emulation for 32-bit tasks remains and so some of the mixed-endian EL0 helpers are retained.

I've broken this down into fairly coarse chunks, as it seemed a lot easier to manage than one giant patch (even with the Kconfig being effectively disabled already) and not all of it is just mindless deletion. Despite that, I'm anticipating the whole thing going via the arm64 tree.

Hi folks,

Big-endian support on arm64 (CONFIG_CPU_BIG_ENDIAN) has depended on BROKEN since 1cf89b6bf660 ("arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN") and has already seen some clean-up patches removing some of the unused support code (e.g. 5276ea17a23c ("lib/crc: arm64: Assume a little-endian kernel")).

Finish the job, and remove the remaining big-endian support code from arm64. Note that the SETEND emulation for 32-bit tasks remains and so some of the mixed-endian EL0 helpers are retained.

I've broken this down into fairly coarse chunks, as it seemed a lot easier to manage than one giant patch (even with the Kconfig being effectively disabled already) and not all of it is just mindless deletion. Despite that, I'm anticipating the whole thing going via the arm64 tree.

Quoted 6 lines · Will Deacon

Big-endian support on arm64 (CONFIG_CPU_BIG_ENDIAN) has depended on BROKEN since 1cf89b6bf660 ("arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN") and has already seen some clean-up patches removing some of the unused support code (e.g. 5276ea17a23c ("lib/crc: arm64: Assume a little-endian kernel")).

Quoted 3 lines

Finish the job, and remove the remaining big-endian support code from arm64. Note that the SETEND emulation for 32-bit tasks remains and so some of the mixed-endian EL0 helpers are retained.

I had not expected the removal to come this soon, but I'm not complaining about that. I assume you are planning this for 7.4, leaving 7.3-LTS to still have the code in case someone wants to still use it, right?

Not sure if you saw

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/mm/Kconfig?id=fe91e4e9da70765420538d9cbcf6d9a970237a8d

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/arch/arm/mach-ixp4xx/Kconfig?id=2262f02ac2aa545560a7f182c8e6b5c98e72763c

so for 7.3, we have marked big-endian mode in arm32 as deprecated as well, and also managed to get ixp4xx working again in little-endian mode, which was slightly broken for a few years. It may be good to add a reference to your series for context.

My suggestions there was to possibly remove arm32 big-endian mode at the same time as on arm64, but that does feel a little rushed if ixp4xx only has one release of supporting both, and removing be8 but leaving be32 for a little while longer is probably not worth it.

Quoted 5 lines

I've broken this down into fairly coarse chunks, as it seemed a lot easier to manage than one giant patch (even with the Kconfig being effectively disabled already) and not all of it is just mindless deletion. Despite that, I'm anticipating the whole thing going via the arm64 tree.

I would have done even larger patches, this does already feel fairly fine-grained to me ;-). I had a look at the individual patches to make sure this all makes sense, and I found nothing wrong here.

For a 7.4 (or later) merge:

Acked-by Arnd Bergmann <[email protected]>

There are also a few arm64 specific drivers that I think no longer need a dependency, but none of that is important:

Quoted 6 lines · Arnd Bergmann

On Tue, Aug 11, 2026, at 16:01, Will Deacon wrote:

My suggestions there was to possibly remove arm32 big-endian mode at the same time as on arm64, but that does feel a little rushed if ixp4xx only has one release of supporting both, and removing be8 but leaving be32 for a little while longer is probably not worth it.

Yeah, maybe give it another LTS on the arm32 side? I think arm64 going first is ok, though.

Quoted 6 lines

Quoted 5 lines

I've broken this down into fairly coarse chunks, as it seemed a lot easier to manage than one giant patch (even with the Kconfig being effectively disabled already) and not all of it is just mindless deletion. Despite that, I'm anticipating the whole thing going via the arm64 tree.

Quoted 3 lines

I would have done even larger patches, this does already feel fairly fine-grained to me ;-). I had a look at the individual patches to make sure this all makes sense, and I found nothing wrong here.

If it was just a sed script or similar, I think I'd would've done a giant patch, but some of it is surprisingly error-prone (e.g. when you have a file with a load of '#ifdef CPU_BIG_ENDIAN' and then an '#ifndef CPU_BIG_ENDIAN' hiding in the middle of it all).

Quoted 10 lines · Will Deacon

Quoted 6 lines · Arnd Bergmann

On Tue, Aug 11, 2026, at 16:01, Will Deacon wrote:

My suggestions there was to possibly remove arm32 big-endian mode at the same time as on arm64, but that does feel a little rushed if ixp4xx only has one release of supporting both, and removing be8 but leaving be32 for a little while longer is probably not worth it.

Yeah, maybe give it another LTS on the arm32 side? I think arm64 going first is ok, though.

Right, one more LTS for 32-bit is probably good. We'll see how the OpenWRT/ixp4xx conversion goes for users.

My feeling so far is that running ixp4xx in LE mode is probably fine (there may still be driver bugs), but flashing a running system from one mode to the other is a bit risky and BE32 mode makes this more confusing the BE8.

Quoted 6 lines

Quoted 6 lines

Quoted 5 lines

I've broken this down into fairly coarse chunks, as it seemed a lot easier to manage than one giant patch (even with the Kconfig being effectively disabled already) and not all of it is just mindless deletion. Despite that, I'm anticipating the whole thing going via the arm64 tree.

Quoted 8 lines

Quoted 3 lines

I would have done even larger patches, this does already feel fairly fine-grained to me ;-). I had a look at the individual patches to make sure this all makes sense, and I found nothing wrong here.

If it was just a sed script or similar, I think I'd would've done a giant patch, but some of it is surprisingly error-prone (e.g. when you have a file with a load of '#ifdef CPU_BIG_ENDIAN' and then an '#ifndef CPU_BIG_ENDIAN' hiding in the middle of it all).

Yes, definitely, I've found out the hard way during other feature removal before.

scripts/unifdef.c should be able to help with this, but I never remember that this is a thing.

I had not expected the removal to come this soon, but I'm not complaining about that. I assume you are planning this for 7.4, leaving 7.3-LTS to still have the code in case someone wants to still use it, right?

Hi folks,

Big-endian support on arm64 (CONFIG_CPU_BIG_ENDIAN) has depended on BROKEN since 1cf89b6bf660 ("arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN") and has already seen some clean-up patches removing some of the unused support code (e.g. 5276ea17a23c ("lib/crc: arm64: Assume a little-endian kernel")).

Finish the job, and remove the remaining big-endian support code from arm64. Note that the SETEND emulation for 32-bit tasks remains and so some of the mixed-endian EL0 helpers are retained.