From: "Arnd Bergmann" <arnd@arndb.de>
To: "Will Deacon" <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, "Ard Biesheuvel" <ardb@kernel.org>,
"Eric Biggers" <ebiggers@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Oliver Upton" <oupton@kernel.org>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Marc Zyngier" <maz@kernel.org>,
"Linus Walleij" <linusw@kernel.org>
Subject: Re: [PATCH 00/12] arm64: Remove unused big-endian support
Date: Sun, 16 Aug 2026 12:15:44 +0200 [thread overview]
Message-ID: <b14ee6f2-1b90-4254-822c-ad352646005e@app.fastmail.com> (raw)
In-Reply-To: <aoGHINU1DWOHXgYC@willie-the-truck>
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
next prev parent reply other threads:[~2026-08-16 10:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 14:01 [PATCH 00/12] arm64: Remove unused big-endian support Will Deacon
2026-08-11 14:01 ` [PATCH 01/12] selftests/arm64: Remove " Will Deacon
2026-08-11 14:01 ` [PATCH 02/12] arm64: bpf: Remove big-endian support from the JIT compiler Will Deacon
2026-08-11 14:01 ` [PATCH 03/12] arm64: crypto: Assume a little-endian kernel Will Deacon
2026-08-11 14:01 ` [PATCH 04/12] arm64: lib: Assume a little-endian kernel in custom library routines Will Deacon
2026-08-11 14:01 ` [PATCH 05/12] arm64: lib: Assume a little-endian kernel in optimised string routines Will Deacon
2026-08-11 14:01 ` [PATCH 06/12] arm64: assembler: Remove endianness helper macros Will Deacon
2026-08-11 15:04 ` Ard Biesheuvel
2026-08-16 9:42 ` Will Deacon
2026-08-20 13:19 ` Will Deacon
2026-08-20 13:27 ` Ard Biesheuvel
2026-08-20 13:45 ` Will Deacon
2026-08-20 13:50 ` Ard Biesheuvel
2026-08-21 9:23 ` Will Deacon
2026-08-11 14:01 ` [PATCH 07/12] arm64: vdso32: Always build compat vDSO object as little-endian Will Deacon
2026-08-11 14:01 ` [PATCH 08/12] KVM: arm64: Remove support for a big-endian hypervisor object Will Deacon
2026-08-11 14:01 ` [PATCH 09/12] arm64: Remove all usage of CONFIG_CPU_BIG_ENDIAN Will Deacon
2026-08-11 14:49 ` Marc Zyngier
2026-08-11 14:01 ` [PATCH 10/12] arm64: Remove all usage of __AARCH64EB__ Will Deacon
2026-08-11 14:01 ` [PATCH 11/12] arm64: image: Remove endianness handling for generating image header Will Deacon
2026-08-11 14:01 ` [PATCH 12/12] arm64: Kbuild: Remove vestigial big-endian support Will Deacon
2026-08-11 14:54 ` [PATCH 00/12] arm64: Remove unused " Marc Zyngier
2026-08-11 15:11 ` Arnd Bergmann
2026-08-16 9:47 ` Will Deacon
2026-08-16 10:15 ` Arnd Bergmann [this message]
2026-08-18 10:33 ` Will Deacon
2026-08-18 17:24 ` Eric Biggers
2026-08-11 15:43 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b14ee6f2-1b90-4254-822c-ad352646005e@app.fastmail.com \
--to=arnd@arndb.de \
--cc=ardb@kernel.org \
--cc=ast@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=daniel@iogearbox.net \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox