[PATCH] arm64: Kconfig: Make CPU_BIG_ENDIAN depend on BROKEN

[J. Neuschäfer]

On Mon, Sep 29, 2025 at 11:52:48AM +0100, Catalin Marinas wrote:
> On Mon, Sep 29, 2025 at 02:18:55AM +0200, J. Neuschäfer wrote:
> > On Fri, Sep 19, 2025 at 07:40:25PM +0100, Will Deacon wrote:
> > > Big-endian arm64 configurations are vanishingly rare, yet we still claim
> > > to support them in Linux despite very limited testing or visible
> > > interest. Supporting big-endian adds unnecessary burden to reviewers and
> > > contributors which, without any known active users, is hard to justify.
> > > For example, recent work to improve our futex routines and to implement
> > > nested virtualisation support is non-trivially complicated by having to
> > > support both big- and little-endianness.
> > > 
> > > Back in 2019 [1], it was claimed that Huawei were using arm64 big-endian
> > > machines in their telecommunication products but I don't know whether
> > > that's still the case and certainly haven't seen any patch contributions
> > > to help support or maintain it.
> > > 
> > > Make CPU_BIG_ENDIAN depend on BROKEN as an initial deprecation step
> > > towards its removal.
> > 
> > As of this month (September 2025) there's a new community project [1,2]
> > to revive aarch64_be. Jens Reidel (CC'd) and I are involved in it. We've
> > been fixing several aarch64_be-related bugs, but mostly[3] in userspace,
> > because the kernel support is pretty solid.
> > 
> > So, just so it doesn't go unmentioned, there is interest in keeping
> > big-endian ARM64 alive.
> 
> It's nice to see it gets testing but is there any actual beyond you and
> Jens (i.e. in production somewhere like Huawei's case)? We want to
> assess whether it's worth the kernel maintenance and testing hassle and
> for how long.

We don't have any commercial or large deployments, no. It's currently
one build host and manual testing on additional machines.

I'd be sad to see big-endian arm64 support removed because it's an
opportunity to test for endian-related bugs (in various packages, not
just the kernel) on widely available and reasonably fast hardware.

I understand the maintenance cost argument, and I'm fine with the
CONFIG_BROKEN dependency, even if it might be applied to features that
cause problems in the future (such as nested virt) — it's easy to work
around, and features can be fixed as needed. A complete removal will
likely be harder to revert, though, especially once code simplifications
are made based on supporting only little-endian. That's my concern.


Best regards,
J. Neuschäfer