Thread (28 messages) flat view 28 messages, 6 authors, 19d ago

Re: [PATCH 00/12] arm64: Remove unused big-endian support

From: Will Deacon <will@kernel.org>
Date: 2026-08-16 09:47:28
Also in: lkml

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:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help