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.

Will

Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au> 
Cc: Marc Zyngier <maz@kernel.org>

--->8

Will Deacon (12):
  selftests/arm64: Remove big-endian support
  arm64: bpf: Remove big-endian support from the JIT compiler
  arm64: crypto: Assume a little-endian kernel
  arm64: lib: Assume a little-endian kernel in custom library routines
  arm64: lib: Assume a little-endian kernel in optimised string routines
  arm64: assembler: Remove endianness helper macros
  arm64: vdso32: Always build compat vDSO object as little-endian
  KVM: arm64: Remove support for a big-endian hypervisor object
  arm64: Remove all usage of CONFIG_CPU_BIG_ENDIAN
  arm64: Remove all usage of __AARCH64EB__
  arm64: image: Remove endianness handling for generating image header
  arm64: Kbuild: Remove vestigial big-endian support

 arch/arm64/Kconfig                           | 35 +-------
 arch/arm64/Makefile                          | 12 +--
 arch/arm64/crypto/aes-ce-ccm-core.S          |  4 +-
 arch/arm64/crypto/aes-neonbs-core.S          |  4 +-
 arch/arm64/crypto/ghash-ce-core.S            |  6 +-
 arch/arm64/crypto/sm4-ce-cipher-core.S       |  4 +-
 arch/arm64/include/asm/assembler.h           | 42 ---------
 arch/arm64/include/asm/compat.h              | 14 ---
 arch/arm64/include/asm/elf.h                 | 12 ---
 arch/arm64/include/asm/processor.h           |  2 -
 arch/arm64/include/asm/ptrace.h              |  6 --
 arch/arm64/include/asm/sysreg.h              | 50 +++--------
 arch/arm64/include/asm/thread_info.h         |  5 --
 arch/arm64/include/asm/word-at-a-time.h      |  6 --
 arch/arm64/include/uapi/asm/byteorder.h      |  4 -
 arch/arm64/kernel/fpsimd.c                   | 21 +----
 arch/arm64/kernel/head.S                     |  7 +-
 arch/arm64/kernel/image.h                    | 38 +-------
 arch/arm64/kernel/kexec_image.c              |  5 +-
 arch/arm64/kernel/kgdb.c                     |  3 -
 arch/arm64/kernel/ptrace.c                   |  8 +-
 arch/arm64/kernel/signal32.c                 | 13 ---
 arch/arm64/kernel/sys32.c                    |  5 --
 arch/arm64/kernel/vdso32/Makefile            |  4 -
 arch/arm64/kvm/hyp/include/nvhe/spinlock.h   |  4 -
 arch/arm64/kvm/hyp/nvhe/gen-hyprel.c         | 16 ----
 arch/arm64/lib/csum.c                        | 17 ----
 arch/arm64/lib/memchr.S                      |  2 +-
 arch/arm64/lib/memcmp.S                      |  2 -
 arch/arm64/lib/strcmp.S                      | 34 +------
 arch/arm64/lib/strlen.S                      | 26 ------
 arch/arm64/lib/strncmp.S                     | 93 ++------------------
 arch/arm64/lib/strnlen.S                     | 16 +---
 arch/arm64/mm/extable.c                      |  5 --
 arch/arm64/net/bpf_jit_comp.c                | 11 ---
 tools/testing/selftests/arm64/fp/fp-ptrace.c | 19 +---
 tools/testing/selftests/rseq/rseq-arm64.h    |  5 --
 37 files changed, 50 insertions(+), 510 deletions(-)

-- 
2.55.0.679.g6767b8d81c-goog

On Tue, Aug 11, 2026 at 03:01:19PM +0100, Will Deacon wrote:
> 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.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

On Tue, Aug 11, 2026, at 16:01, Will Deacon wrote:
> 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 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.

> 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 <arnd@arndb.de>

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

diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
index aeff08ccbadd..1ae7b146b241 100644
--- a/drivers/crypto/hisilicon/Kconfig
+++ b/drivers/crypto/hisilicon/Kconfig
@@ -53,7 +53,6 @@ config CRYPTO_DEV_HISI_ZIP
 	tristate "Support for HiSilicon ZIP accelerator"
 	depends on PCI_MSI
 	depends on ARM64 || (COMPILE_TEST && 64BIT)
-	depends on !CPU_BIG_ENDIAN || COMPILE_TEST
 	depends on UACCE || UACCE=n
 	depends on ACPI
 	select CRYPTO_DEV_HISI_QM
diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig
index c7f8413ab996..f0c1061b0005 100644
--- a/drivers/firmware/qcom/Kconfig
+++ b/drivers/firmware/qcom/Kconfig
@@ -18,7 +18,6 @@ config QCOM_PAS_TEE
 	tristate "Qualcomm PAS TEE interface driver"
 	select QCOM_PAS
 	depends on TEE
-	depends on !CPU_BIG_ENDIAN
 	default m if ARCH_QCOM
 	help
 	  Enable the generic Peripheral Authentication Service (PAS) provided
diff --git a/drivers/firmware/tegra/Kconfig b/drivers/firmware/tegra/Kconfig
index 3a9162706439..e9271d706726 100644
--- a/drivers/firmware/tegra/Kconfig
+++ b/drivers/firmware/tegra/Kconfig
@@ -14,7 +14,6 @@ config TEGRA_IVC
 config TEGRA_BPMP
 	bool "Tegra BPMP driver"
 	depends on ARCH_TEGRA && TEGRA_HSP_MBOX
-	depends on !CPU_BIG_ENDIAN
 	select TEGRA_IVC
 	help
 	  BPMP (Boot and Power Management Processor) is designed to off-loading
diff --git a/drivers/soc/tegra/Kconfig b/drivers/soc/tegra/Kconfig
index 8b6fdb9ad1ea..318e7b604342 100644
--- a/drivers/soc/tegra/Kconfig
+++ b/drivers/soc/tegra/Kconfig
@@ -102,7 +102,6 @@ config ARCH_TEGRA_210_SOC
 config ARCH_TEGRA_186_SOC
 	bool "NVIDIA Tegra186 SoC"
 	default ARCH_TEGRA
-	depends on !CPU_BIG_ENDIAN
 	select PINCTRL_TEGRA186
 	select MAILBOX
 	select SOC_TEGRA_PMC
@@ -117,7 +116,6 @@ config ARCH_TEGRA_186_SOC
 config ARCH_TEGRA_194_SOC
 	bool "NVIDIA Tegra194 SoC"
 	default ARCH_TEGRA
-	depends on !CPU_BIG_ENDIAN
 	select MAILBOX
 	select PINCTRL_TEGRA194
 	select SOC_TEGRA_PMC
@@ -127,7 +125,6 @@ config ARCH_TEGRA_194_SOC
 config ARCH_TEGRA_234_SOC
 	bool "NVIDIA Tegra234 SoC"
 	default ARCH_TEGRA
-	depends on !CPU_BIG_ENDIAN
 	select MAILBOX
 	select PINCTRL_TEGRA234
 	select SOC_TEGRA_PMC
@@ -137,7 +134,6 @@ config ARCH_TEGRA_234_SOC
 config ARCH_TEGRA_238_SOC
 	bool "NVIDIA Tegra238 SoC"
 	default ARCH_TEGRA
-	depends on !CPU_BIG_ENDIAN
 	select MAILBOX
 	select SOC_TEGRA_PMC
 	help
@@ -152,7 +148,6 @@ config ARCH_TEGRA_241_SOC
 config ARCH_TEGRA_264_SOC
 	bool "NVIDIA Tegra264 SoC"
 	default ARCH_TEGRA
-	depends on !CPU_BIG_ENDIAN
 	select MAILBOX
 	select SOC_TEGRA_PMC
 	help
diff --git a/drivers/tee/qcomtee/Kconfig b/drivers/tee/qcomtee/Kconfig
index 9f19dee08db4..bd9be3e9a9ac 100644
--- a/drivers/tee/qcomtee/Kconfig
+++ b/drivers/tee/qcomtee/Kconfig
@@ -3,7 +3,6 @@
 config QCOMTEE
 	tristate "Qualcomm TEE Support"
 	depends on ARCH_QCOM || COMPILE_TEST
-	depends on !CPU_BIG_ENDIAN
 	select QCOM_SCM
 	select QCOM_TZMEM_MODE_SHMBRIDGE
 	help

On Tue, Aug 11, 2026 at 05:11:47PM +0200, Arnd Bergmann wrote:
> 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?

It's already been BROKEN (and thus is dead code) since v6.18.  Some of
that dead code has already been removed.  Other code never actually
worked correctly on big endian in the first place and no one ever cared.

Acked-by: Eric Biggers <ebiggers@kernel.org>

- Eric

Hi Arnd,

On Tue, Aug 11, 2026 at 05:11:47PM +0200, Arnd Bergmann wrote:
> On Tue, Aug 11, 2026, at 16:01, Will Deacon wrote:
> > 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 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?

Yes, this is for 7.4.

> 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.

Thanks, I'll do that!

> 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.

> > 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.

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

> For a 7.4 (or later) merge:
> 
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> 
> There are also a few arm64 specific drivers that I think no
> longer need a dependency, but none of that is important:

I think there might also be some logic in the SMMUv3 driver which could
go. Perhaps I'll add a driver patch on the end of the next version to
pick this up.

Cheers,

Will

On Sun, Aug 16, 2026, at 11:47, Will Deacon wrote:
> On Tue, Aug 11, 2026 at 05:11:47PM +0200, Arnd Bergmann wrote:
>> 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.

>> > 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.
>
> 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.

     Arnd

On Sun, Aug 16, 2026 at 12:15:44PM +0200, Arnd Bergmann wrote:
> On Sun, Aug 16, 2026, at 11:47, Will Deacon wrote:
> > On Tue, Aug 11, 2026 at 05:11:47PM +0200, Arnd Bergmann wrote:
> >> 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.
> 
> >> > 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.
> >
> > 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 didn't even know about that! I'll see if it spots anything I missed...

Will

On Tue, 11 Aug 2026 15:01:19 +0100,
Will Deacon <will@kernel.org> wrote:
> 
> 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.

FWIW:

Acked-by: Marc Zyngier <maz@kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.