Re: [PATCH 06/12] arm64: assembler: Remove endianness helper macros

Will Deacon <[email protected]>
Newsgroups gmane.linux.kernel,gmane.linux.ports.arm.kernel
Message-ID <aogZKCKxXISedTj5@willie-the-truck>
On Thu, Aug 20, 2026 at 04:50:41PM +0300, Ard Biesheuvel wrote:
> 
> 
> On Thu, 20 Aug 2026, at 16:45, Will Deacon wrote:
> > On Thu, Aug 20, 2026 at 04:27:06PM +0300, Ard Biesheuvel wrote:
> >> 
> >> On Thu, 20 Aug 2026, at 16:19, Will Deacon wrote:
> >> > On Sun, Aug 16, 2026 at 10:42:40AM +0100, Will Deacon wrote:
> >> >> On Tue, Aug 11, 2026 at 05:04:43PM +0200, Ard Biesheuvel wrote:
> >> >> > On Tue, 11 Aug 2026, at 16:01, Will Deacon wrote:
> >> >> > > diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> >> >> > > index 87a822e5c4ca..8951ce693552 100644
> >> >> > > --- a/arch/arm64/kernel/head.S
> >> >> > > +++ b/arch/arm64/kernel/head.S
> >> >> > > @@ -138,8 +138,7 @@ SYM_CODE_START_LOCAL(record_mmu_state)
> >> >> > >  	b.ne	0f
> >> >> > >  	mrs	x19, sctlr_el2
> >> >> > >  0:
> >> >> > > -CPU_LE( tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
> >> >> > > -CPU_BE( tbz	x19, #SCTLR_ELx_EE_SHIFT, 1f	)
> >> >> > > +	tbnz	x19, #SCTLR_ELx_EE_SHIFT, 1f
> >> >> > >  	tst	x19, #SCTLR_ELx_C		// Z := (C == 0)
> >> >> > >  	and	x19, x19, #SCTLR_ELx_M		// isolate M bit
> >> >> > >  	csel	x19, xzr, x19, eq		// clear x19 if Z
> >> >> > 
> >> >> > There is some more code that can be removed here - see
> >> >> > 2ced0f30a426c7301350681f838344d5aea711e3
> >> >> 
> >> >> Good spot, thanks! I'll do some more surgery at -rc1.
> >> >
> >> > Looking at this again, I'm not sure we can remove much here. I think we
> >> > probably still want to force little-endian (i.e. clear the EE bit) if
> >> > we're entered as big-endian. I've changed the following EOR to a BIC
> >> > (see below), but I think that's about all we can do?
> >> >
> >> 
> >> Well, the only case where we allow an active ID map is when doing EFI
> >> boot, which is guaranteed to be little-endian. Since the kernel is now
> >> also guaranteed to be little-endian, we should be able to simply kick
> >> the CPU in LE mode right at the start, no? And simply ignore the case
> >> of a BE bootloader entering with the MMU and caches enabled?
> >
> > Hmm, so why did we support this in the first place given that EFI is
> > guaranteed to be little-endian? Or was that just because we wanted to
> > handle the case of a big-endian kernel being loaded by EFI?
> >
> 
> The original report is here:
> https://lore.kernel.org/linux-arm-kernel/[email protected]/
> 
> So it would probably have been sufficient at the time to just kick
> the CPU into LE mode - I don't remember why I added the additional
> logic tbh.

Okey doke. I'll do it in v2, but as a standalone patch rather than folding
it in with this one..

Will
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.