omment
> format, i.e. '/*', to prevent kernel-doc from parsing it.
This makes sense.
Reviewed-by: Daniel Axtens
Kind regards,
Daniel
>
> Signed-off-by: Aditya Srivastava
> ---
> * Applies perfectly on next-20210319
>
> drivers/crypto/vmx/aes.c | 2 +-
>
The CTR code comes from OpenSSL, where it does a 32-bit counter.
The kernel has a 128-bit counter. This difference has lead to
issues.
Document it.
Signed-off-by: Daniel Axtens
---
drivers/crypto/vmx/aesp8-ppc.pl | 22 --
1 file changed, 20 insertions(+), 2 deletions
Daniel Axtens writes:
> The kernel self-tests picked up an issue with CTR mode:
> alg: skcipher: p8_aes_ctr encryption test failed (wrong result) on test
> vector 3, cfg="uneven misaligned splits, may sleep"
>
> Test vector 3 has an IV of F
Michael Ellerman writes:
> Daniel Axtens writes:
>> VMX ghash was using a fallback that did not support interleaving simd
>> and nosimd operations, leading to failures in the extended test suite.
>>
>> If I understood correctly, Eric's suggestion was to use
texts. I wasn't able to get that to work - I think
there's a very different key structure and data layout being used.
So instead steal the arm64 approach and perform the fallback
operations directly if required.
Reported-by: Eric Biggers
Signed-off-by: Daniel Axtens
---
Tested on BE
Eric Biggers writes:
> On Thu, May 16, 2019 at 12:12:48PM +1000, Daniel Axtens wrote:
>>
>> I'm also seeing issues with ghash with the extended tests:
>>
>> [7.582926] alg: hash: p8_ghash test failed (wrong result) on test vector
>> 0, cfg=&qu
Daniel Axtens writes:
> Herbert Xu writes:
>
>> On Wed, May 15, 2019 at 03:35:51AM +1000, Daniel Axtens wrote:
>>>
>>> By all means disable vmx ctr if I don't get an answer to you in a
>>> timeframe you are comfortable with, but I am going to at leas
was probably a typo originally, what with q and w being
adjacent. It is a pretty narrow edge case: I am really
impressed by the quality of the kernel self-tests!
Fixes: 5c380d623ed3 ("crypto: vmx - Add support for VMS instructions by ASM")
Cc: sta...@vger.kernel.org
Signed-off-by: D
Herbert Xu writes:
> On Wed, May 15, 2019 at 03:35:51AM +1000, Daniel Axtens wrote:
>>
>> By all means disable vmx ctr if I don't get an answer to you in a
>> timeframe you are comfortable with, but I am going to at least try to
>> have a look.
>
> I'm
Michael Ellerman writes:
> Herbert Xu writes:
>> On Mon, May 06, 2019 at 08:53:17AM -0700, Eric Biggers wrote:
>>>
>>> Any progress on this? Someone just reported this again here:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=203515
>>
>> Guys if I don't get a fix for this soon I'll have to d
> So although this sits in arch/powerpc, it's heavy on the crypto which is
> not my area of expertise (to say the least!), so I think it should
> probably go via Herbert and the crypto tree?
That was my thought as well. Sorry - probably should have put that in
the comments somewhere.
Regards,
Dan
Hi David,
> While not part of this change, the unrolled loops look as though
> they just destroy the cpu cache.
> I'd like be convinced that anything does CRC over long enough buffers
> to make it a gain at all.
>
> With modern (not that modern now) superscalar cpus you can often
> get the loop in
vpmsum implementations often don't kick in for short test vectors.
This is a simple test module that does a configurable number of
random tests, each up to 64kB and each with random offsets.
Both CRC-T10DIF and CRC32C are tested.
Cc: Anton Blanchard
Signed-off-by: Daniel Axtens
--
Not
github.com/antonblanchard/crc32-vpmsum)
That implementation is available under GPLv2+, so we're OK
from a licensing point of view:
https://github.com/antonblanchard/crc32-vpmsum/blob/master/LICENSE.TXT
As CRC32c requires REFLECT, add that #define.
Cc: Anton Blanchard
Signed-off-by: Daniel
T10DIF is a CRC16 used heavily in NVMe.
It turns out we can accelerate it with a CRC32 library and a few
little tricks.
Provide the accelerator based the refactored CRC32 code.
Cc: Anton Blanchard
Thanks-to: Hong Bo Peng
Signed-off-by: Daniel Axtens
---
arch/powerpc/crypto/Makefile
,
and then #includes the core algorithm file.
Cc: Anton Blanchard
Signed-off-by: Daniel Axtens
--
It's possible at this point to argue that the address
of the constant tables should be passed in to the function,
rather than doing this somewhat unconventional #include.
However, we're ab
.org
Signed-off-by: Daniel Axtens
---
arch/powerpc/crypto/crc32c-vpmsum_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/crypto/crc32c-vpmsum_glue.c
b/arch/powerpc/crypto/crc32c-vpmsum_glue.c
index 9fa046d56eba..411994551afc 100644
--- a/arch/powerp
Haren Myneni writes:
> NX842 coprocessor sets bit 3 if queue is overflow. It is just for
> information to the user. So the driver prints this informative message
> and ignores it.
What queue, and what happens when the queue overflows? It seems like
*something* would need to be done, somewhere, b
18 matches
Mail list logo
