From: Ye Xingchen <[email protected]>
crypto/algapi.h is included more than once.
Signed-off-by: Ye Xingchen <[email protected]>
---
arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c b/arch/powerpc/crypto/aes-gcm-p10-glue.c
index c95f5b7cc456..1533c8cdd26f 100644
--- a/arch/powerpc/crypto/aes-gcm-p10-glue.c
+++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c
@@ -8,7 +8,6 @@
#include <asm/unaligned.h>
#include <asm/simd.h>
#include <asm/switch_to.h>
-#include <crypto/algapi.h>
#include <crypto/aes.h>
#include <crypto/algapi.h>
#include <crypto/b128ops.h>
--
2.25.1
Hi,
Le 14/03/2023 à 09:31, [email protected] a écrit :
> From: Ye Xingchen <[email protected]>
>
> crypto/algapi.h is included more than once.
>
> Signed-off-by: Ye Xingchen <[email protected]>
You already sent this patch, see
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/[email protected]/
Any reason for resending ?
Christophe
> ---
> arch/powerpc/crypto/aes-gcm-p10-glue.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/powerpc/crypto/aes-gcm-p10-glue.c b/arch/powerpc/crypto/aes-gcm-p10-glue.c
> index c95f5b7cc456..1533c8cdd26f 100644
> --- a/arch/powerpc/crypto/aes-gcm-p10-glue.c
> +++ b/arch/powerpc/crypto/aes-gcm-p10-glue.c
> @@ -8,7 +8,6 @@
> #include <asm/unaligned.h>
> #include <asm/simd.h>
> #include <asm/switch_to.h>
> -#include <crypto/algapi.h>
> #include <crypto/aes.h>
> #include <crypto/algapi.h>
> #include <crypto/b128ops.h>
On Tue, Mar 14, 2023 at 08:47:30AM +0000, Christophe Leroy wrote:
>
> Any reason for resending ?
The p10 patches were reverted, and have only just been re-instated.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu <[email protected]> writes:
> On Tue, Mar 14, 2023 at 08:47:30AM +0000, Christophe Leroy wrote:
>>
>> Any reason for resending ?
>
> The p10 patches were reverted, and have only just been re-instated.
Hmm. Seems none of them were ever Cc'ed to linuxppc-dev. So this is the
first I've seen of them.
We seem to have two almost identical copies of ppc-xlate.pl now :/
$ find . -name ppc-xlate.pl
./arch/powerpc/crypto/ppc-xlate.pl
./drivers/crypto/vmx/ppc-xlate.pl
And notably the new one doesn't have the changes from commit
505ea33089dc ("powerpc/64: Add big-endian ELFv2 flavour to crypto VMX
asm generation"), so that probably breaks the build for some configs.
There's also now two new .pl files with identical names, but different
content to the copies in drivers/crypto/vmx:
$ find . -name "*-ppc.pl" | xargs wc -l
370 ./arch/powerpc/crypto/ghashp8-ppc.pl
585 ./arch/powerpc/crypto/aesp8-ppc.pl
243 ./drivers/crypto/vmx/ghashp8-ppc.pl
3846 ./drivers/crypto/vmx/aesp8-ppc.pl
5044 total
Also PPC_MODULE_FEATURE_P10 should be in arch/powerpc/include/asm/cpufeature.h.
And CRYPTO_AES_GCM_P10 should not depend on POWER10_CPU, that restricts
it to being built when the kernel is built to run *only* on Power10,
which basically no one does, certainly no distro.
The code needs to detect at runtime if it's on Power10, and only
register itself if so.
cheers
On Tue, Mar 14, 2023 at 09:44:52PM +1100, Michael Ellerman wrote:
>
> Hmm. Seems none of them were ever Cc'ed to linuxppc-dev. So this is the
> first I've seen of them.
Sorry, I didn't know that you weren't aware of this change. I
will be more careful with these ppc patches in future.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Herbert Xu <[email protected]> writes:
> On Tue, Mar 14, 2023 at 09:44:52PM +1100, Michael Ellerman wrote:
>>
>> Hmm. Seems none of them were ever Cc'ed to linuxppc-dev. So this is the
>> first I've seen of them.
>
> Sorry, I didn't know that you weren't aware of this change. I
> will be more careful with these ppc patches in future.
No worries, not your fault. My comments were mostly intended for Danny.
Although one question I do have for you is what rules, if any, do we
have for deciding whether crypto code goes in drivers/crypto vs
arch/*/crypto?
On powerpc we have some in arch/powerpc/crypto and some in
drivers/crypto/vmx, and I don't really know why it's split that way.
It seems like drivers/crypto is where non-CPU crypto accelerator drivers
go, but then it also has lots of in-CPU crypto code as well AFAICS.
I wonder if we should move drivers/crypto/vmx into arch/powerpc/crypto,
so that all the powerpc CRYPTOGAMS code is in one place. That would help
to clean up some of the duplication of perl scripts we now have.
cheers
On Thu, Mar 16, 2023 at 02:58:04PM +1100, Michael Ellerman wrote:
>
> Although one question I do have for you is what rules, if any, do we
> have for deciding whether crypto code goes in drivers/crypto vs
> arch/*/crypto?
If it's on the CPU then it should probably live under arch. Yes
there have been exceptions in the past, with VIA PadLock on x86
and vmx on PPC being prime examples.
> I wonder if we should move drivers/crypto/vmx into arch/powerpc/crypto,
> so that all the powerpc CRYPTOGAMS code is in one place. That would help
> to clean up some of the duplication of perl scripts we now have.
Yes I think that would certainly make sense.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt