Re: [GIT PULL] RISC-V updates for v6.18-rc1

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

On Tue, Sep 30, 2025 at 04:53:24PM -0700, Linus Torvalds wrote:
> On Tue, 30 Sept 2025 at 09:04, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Oh Christ. Is somebody seriously working on BE support in 2025?
> 
> Ok, I just googled this, and I am putting my foot down:
> 
>  WE ARE NOT PREEMPTIVELY SUPPORTING BIG-ENDIAN ON RISC-V
> 
> The documented "reasoning" for that craziness is too stupid for words,
> but since riscv.org did put it in words, I'll just quote those words
> here:
> 
>  "There are still applications where the way data is stored matters,
> such as the protocols that move data across the Internet, which are
> defined as big-endian. So when a little-endian system needs to inspect
> or modify a network packet, it has to swap the big-endian values to
> little-endian and back, a process that can take as many as 10-20
> instructions on a RISC-V target which doesn’t implement the Zbb
> extension"
> 
> In other words, it is suggesting that RISC-V add a big-endian mode due to
> 
>  (a) internet protocols - where byte swapping is not an issue
> 
>  (b) using "some RISC-V implementations don't do the existing Zbb
> extension" as an excuse
> 
> This is plain insanity. First off, even if byte swapping was a real
> cost for networking - it's not, the real costs tend to be all in
> memory subsystems - just implement the damn Zbb extension.
> 
> Don't go "we're too incompetent to implement Zbb, so we're now asking
> that EVERYBODY ELSE feel the pain of a much *worse* extension and
> fragmenting RISC-V further".
> 
> I'm hoping this is some April fools joke, but that page is dated
> "March 10, 2025". Close, but not close enough.
> 
> This is the kind of silly stuff that just makes RISC-V look bad.
> 
> Ben - I'm afraid that that page has "further reading" pointing to codethink.
> 

> I see some CONFIG_CPU_BIG_ENDIAN has already made it in, but this
> needs to stop.

Perhaps somewhat ironically, most of the instances of CONFIG_CPU_BIG_ENDIAN
that are already in the kernel are the Zbb specific implementations of
string manipulation functions. IIRC they got added to match the Zbb spec
appendices from which the implementations are sourced and speculatively
in case BE ever did get added. The kexec users are just a straight copy
from the arm64 kexec support. None of that was really done as a
deliberate attempt to add support for BE, in case that assuages concerns
you might have about the taste of the arch maintainers..

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]