Re: [PATCH 4/5] xor/arm64: Use shared NEON intrinsics implementation from 32-bit ARM
Christoph Hellwig <[email protected]>
| Newsgroups | gmane.linux.kernel.cryptoapi,gmane.linux.raid,gmane.linux.ports.arm.kernel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Mar 27, 2026 at 03:45:56PM +0100, Ard Biesheuvel wrote: > On Fri, 27 Mar 2026, at 14:50, Christoph Hellwig wrote: > > On Fri, Mar 27, 2026 at 12:30:52PM +0100, Ard Biesheuvel wrote: > >> From: Ard Biesheuvel <[email protected]> > >> > >> Tweak the arm64 code so that the pure NEON intrinsics implementation of > >> XOR is shared between arm64 and ARM. > > > > Instead of hiding the implementation in a header, just split xor-neon.c > > into two .c files, one of which could be built by arm32 as well. > > That is what patch 3/5 does. This patch wires up that version into arm64, and drops the copy that has become redundant as a result. Yeah, sorry - I misread the series a little. > > > probably > > in the arm/ instead of the arm64/ subdirectory, but we can also add a > > new arm-common one if that's what the arm maintainers prefer. > > Having the shared pure NEON version in arm/ is perfectly fine. So here would be my preference: - keep all the arm/arm64 code in lib/raid/xor/arm - have the neon and EOR3 code in a single xor-neon.c file, with an ifdef CONFIG_ARM64 around the EOE3 routines This avoid the including of .c files which is always a bit ugly. But if there is a strong argument to prefer including of the .c file I can live with that as well. > > Building it as a separate compilation unit for arm64 should also be straight-forward, the only issue is that the 2-way NEON version needs to be shared with the EOR3 compilation unit. > ---end quoted text---