On Tue, Sep 01, 2020 at 01:40:15PM +0200, Maxime Ripard wrote:
> On Tue, Sep 01, 2020 at 12:57:19PM +0200, Corentin Labbe wrote:
> > On Tue, Sep 01, 2020 at 11:32:49AM +0200, Maxime Ripard wrote:
> > > On Mon, Aug 31, 2020 at 09:30:59AM +0200, Martin Cerveny wrote:
> > > > Like A33 "sun4i-ss" has a
On Tue, Sep 1, 2020 at 9:16 PM Jason A. Donenfeld wrote:
>
> Hi Uros,
>
> Any benchmarks for this? Seems like it's all in initialization code,
> right? I'm CC'ing Andy into this.
This patch should have no performance effect, it saves REX prefix byte
when the optimization is applied to legacy regi
On Tue, Sep 1, 2020 at 9:12 PM Jason A. Donenfeld wrote:
>
> On Tue, Sep 1, 2020 at 8:13 PM Jason A. Donenfeld wrote:
> > operands are the same. Also, have you seen any measurable differences
> > when benching this? I can stick it into kbench9000 to see if you
> > haven't looked yet.
>
> On a Sky
Hello,
syzbot found the following issue on:
HEAD commit:96d454cd Merge tag 'arm64-fixes' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1015301e90
kernel config: https://syzkaller.appspot.com/x/.config?x=978db74cb30aa994
das
Hi Uros,
Any benchmarks for this? Seems like it's all in initialization code,
right? I'm CC'ing Andy into this.
Jason
On Thu, Aug 27, 2020 at 07:38:31PM +0200, Uros Bizjak wrote:
> x86_64 zero extends 32bit operations, so for 64bit operands,
> XORL r32,r32 is functionally equal to XORQ r64,r64,
On Tue, Sep 1, 2020 at 8:13 PM Jason A. Donenfeld wrote:
> operands are the same. Also, have you seen any measurable differences
> when benching this? I can stick it into kbench9000 to see if you
> haven't looked yet.
On a Skylake server (Xeon Gold 5120), I'm unable to see any measurable
differen
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: bbb2832620ac4e136416aa97af7310636422dea9
commit: 0c3dc787a62aef3ca7aedf3797ec42fff9b0a913 [2/46] crypto: algapi - Remove
skbuff.h inclusion
config: arm-allyesconfig (attached as .config)
compiler: arm
Hi Uros,
Thanks for this patch. This seems correct to me, since indeed those
clear the top bits anyway, and having smaller code seems good. But
first -- I'm wondering -- have you stuck this into Vale/Hacl to see if
it still checks out there? I'm CC'ing Karthik/Aymeric/Chris/Jonathan
who might be i
(+ Jason)
On Thu, 27 Aug 2020 at 20:31, Uros Bizjak wrote:
>
> x86_64 zero extends 32bit operations, so for 64bit operands,
> XORL r32,r32 is functionally equal to XORL r64,r64, but avoids
> a REX prefix byte when legacy registers are used.
>
> Signed-off-by: Uros Bizjak
> Cc: Herbert Xu
> Cc:
On 8/31/2020 10:58 AM, Andy Shevchenko wrote:
Use traditional error check pattern
ret = ...;
if (ret)
return ret;
...
instead of checking error code to be 0.
Signed-off-by: Andy Shevchenko
Reviewed-by: Iuliana Prodan
---
drivers/crypto/caam/ctrl
On Tue, Sep 01, 2020 at 11:47:03AM +0300, Ard Biesheuvel wrote:
> On Tue, 1 Sep 2020 at 09:28, Herbert Xu wrote:
> >
> > Since commit b56f5cbc7e08ec7d31c42fc41e5247677f20b143 ("crypto:
> > arm/aes-neonbs - resolve fallback cipher at runtime") the CBC
> > encryption path in aes-neonbs is now identi
Since commit b56f5cbc7e08ec7d31c42fc41e5247677f20b143 ("crypto:
arm/aes-neonbs - resolve fallback cipher at runtime") the CBC
encryption path in aes-neonbs is now identical to that obtained
through the cbc template. This means that it can simply call
the generic cbc template instead of doing its o
Now that crypto/cbc.h is only used by the generic cbc template,
we can merge it back into the CBC code.
Signed-off-by: Herbert Xu
diff --git a/crypto/cbc.c b/crypto/cbc.c
index e6f6273a7d39..0d9509dff891 100644
--- a/crypto/cbc.c
+++ b/crypto/cbc.c
@@ -6,7 +6,6 @@
*/
#include
-#include
#
On Tue, 1 Sep 2020 at 14:48, Herbert Xu wrote:
>
> Since commit b56f5cbc7e08ec7d31c42fc41e5247677f20b143 ("crypto:
> arm/aes-neonbs - resolve fallback cipher at runtime") the CBC
> encryption path in aes-neonbs is now identical to that obtained
> through the cbc template. This means that it can s
On Tue, Sep 01, 2020 at 12:57:19PM +0200, Corentin Labbe wrote:
> On Tue, Sep 01, 2020 at 11:32:49AM +0200, Maxime Ripard wrote:
> > On Mon, Aug 31, 2020 at 09:30:59AM +0200, Martin Cerveny wrote:
> > > Like A33 "sun4i-ss" has a difference, it give SHA1 digest
> > > directly in BE. So add new compa
On Tue, Sep 01, 2020 at 11:32:49AM +0200, Maxime Ripard wrote:
> On Mon, Aug 31, 2020 at 09:30:59AM +0200, Martin Cerveny wrote:
> > Like A33 "sun4i-ss" has a difference, it give SHA1 digest
> > directly in BE. So add new compatible.
> >
> > Tested-by: Martin Cerveny
>
> The Tested-by tag is for
On Mon, Aug 31, 2020 at 09:31:00AM +0200, Martin Cerveny wrote:
> V3s contains crypto engine that is compatible with "sun4i-ss".
>
> Tested-by: Martin Cerveny
> Signed-off-by: Martin Cerveny
> ---
> arch/arm/boot/dts/sun8i-v3s.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff -
On Mon, Aug 31, 2020 at 09:30:59AM +0200, Martin Cerveny wrote:
> Like A33 "sun4i-ss" has a difference, it give SHA1 digest
> directly in BE. So add new compatible.
>
> Tested-by: Martin Cerveny
The Tested-by tag is for the other developpers. You're very much
expected to have tested your patch b
On Tue, 1 Sep 2020 at 09:28, Herbert Xu wrote:
>
> Since commit b56f5cbc7e08ec7d31c42fc41e5247677f20b143 ("crypto:
> arm/aes-neonbs - resolve fallback cipher at runtime") the CBC
> encryption path in aes-neonbs is now identical to that obtained
> through the cbc template. This means that it can s
19 matches
Mail list logo
