Re: [PATCH 17/25] s390: move the XOR code to lib/raid/
Heiko Carstens <[email protected]>
| Newsgroups | org.kernel.vger.sparclinux,dev.linux.lists.loongarch,org.infradead.lists.linux-riscv,org.infradead.lists.linux-um,org.kernel.vger.linux-alpha,org.kernel.vger.linux-arch,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-crypto,org.kernel.vger.linux-kernel,org.kernel.vger.linux-raid,org.kernel.vger.linux-s390,org.ozlabs.lists.linuxppc-dev |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Feb 26, 2026 at 07:10:29AM -0800, Christoph Hellwig wrote: > Move the optimized XOR into lib/raid and include it it in xor.ko > instead of unconditionally building it into the main kernel image. > > Signed-off-by: Christoph Hellwig <[email protected]> > --- > arch/s390/lib/Makefile | 2 +- > lib/raid/xor/Makefile | 1 + > {arch/s390/lib => lib/raid/xor/s390}/xor.c | 2 -- > 3 files changed, 2 insertions(+), 3 deletions(-) > rename {arch/s390/lib => lib/raid/xor/s390}/xor.c (98%) FWIW: Acked-by: Heiko Carstens <[email protected]> However, I just had a look at the s390 implementation and just saw that the inline assembly constraints for xor_xc_2() are incorrect. "bytes", "p1", and "p2" are input operands, while all three of them are modified within the inline assembly. Given that the function consists only of this inline assembly I doubt that this causes any harm, however I still want to fix this now; but your patch should apply fine with or without this fixed.