Re: [PATCH] lib/crc: arm64: use .arch_extension to enable CRC and crypto

[Eric Biggers]

On Fri, Nov 06, 2026 at 09:57:01AM +0100, Ard Biesheuvel wrote:
> Hello Emanuele,
> 
> On Thu, 5 Nov 2026, at 16:41, Emanuele Rocca wrote:
> > Instead of using ".cpu generic+crc+crypto", use ".arch_extension crc" and
> > ".arch_extension crypto" to enable the required instructions.
> >
> > The ".cpu generic+crc+crypto" directive replaces the assembler's current
> > feature set with generic+crc+crypto, dropping any other features that were
> > previously enabled, for example by -march or by a toolchain configured with
> > --with-arch=armv9-a. In contrast, ".arch_extension" enables the requested
> > extensions while preserving the current feature set.
> >
> > This is not a functional change: crc32-core.S only uses base A64
> > instructions plus CRC32 and PMULL, which remain available, and BTI landing
> > pads are emitted as HINT instructions. However, using .arch_extension
> > avoids the pitfall of silently disabling features. See commit 9142c2f8f84b
> > ("octeontx2: use arch_extension to enable LSE").
> >
> 
> I don't mind the patch, but I will point out that issues such as these can
> never occur in .S sources. The emitted instructions are always the same, and
> the only reason we need the .arch is so that the assembler permits the use
> of the special ones.
> 
> Commit 9142c2f8f84b is different because it uses .arch in inline asm, where
> it switches the assembler into a different mode behind the back of the
> compiler, leading it to reject instructions generated by the compiler.
> 

Thanks.  Emanuele, could you maybe note that in the commit message?

Also, this patch is not complete even for lib/crc/arm64/, since
lib/crc/arm64/crc-t10dif-core.S still uses "armv8-a+crypto".  If we're
bothering with this, I would suggest just taking care of both
crc32-core.S and crc-t10dif-core.S in one patch.  (The crypto files I
mentioned before should be a different patch.)

- Eric