Re: [PATCH v2 3/5] crypto: talitos: Fix off-by-one and use all hardware slots

2015-03-04 Thread Martin Hicks
Ok, I'm fine dropping this patch.  I'm sure it doesn't affect
performance in a measurable way.

mh

On Tue, Mar 3, 2015 at 7:35 PM, Kim Phillips  wrote:
> On Tue,  3 Mar 2015 08:21:35 -0500
> Martin Hicks  wrote:
>
>> The submission count was off by one.
>>
>> Signed-off-by: Martin Hicks 
>> ---
> sadly, this directly contradicts:
>
> commit 4b24ea971a93f5d0bec34bf7bfd0939f70cfaae6
> Author: Vishnu Suresh 
> Date:   Mon Oct 20 21:06:18 2008 +0800
>
> crypto: talitos - Preempt overflow interrupts off-by-one fix
>
> My guess is your request submission pattern differs from that of
> Vishnu's (probably IPSec and/or tcrypt), or later h/w versions have
> gotten better about dealing with channel near-overflow conditions.
> Either way, I'd prefer we not do this: it might break others, and
> I'm guessing doesn't improve performance _that_ much?
>
> If it does, we could risk it and restrict it to SEC versions 3.3 and
> above maybe?  Not sure what to do here exactly, barring digging up
> and old 2.x SEC and testing.
>
> Kim
>
> p.s. I checked, Vishnu isn't with Freescale anymore, so I can't
> cc him.



-- 
Martin Hicks P.Eng.  | m...@bork.org
Bork Consulting Inc. |   +1 (613) 266-2296
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 3/5] crypto: talitos: Fix off-by-one and use all hardware slots

2015-03-03 Thread Kim Phillips
On Tue,  3 Mar 2015 08:21:35 -0500
Martin Hicks  wrote:

> The submission count was off by one.
> 
> Signed-off-by: Martin Hicks 
> ---
sadly, this directly contradicts:

commit 4b24ea971a93f5d0bec34bf7bfd0939f70cfaae6
Author: Vishnu Suresh 
Date:   Mon Oct 20 21:06:18 2008 +0800

crypto: talitos - Preempt overflow interrupts off-by-one fix

My guess is your request submission pattern differs from that of
Vishnu's (probably IPSec and/or tcrypt), or later h/w versions have
gotten better about dealing with channel near-overflow conditions.
Either way, I'd prefer we not do this: it might break others, and
I'm guessing doesn't improve performance _that_ much?

If it does, we could risk it and restrict it to SEC versions 3.3 and
above maybe?  Not sure what to do here exactly, barring digging up
and old 2.x SEC and testing.

Kim

p.s. I checked, Vishnu isn't with Freescale anymore, so I can't
cc him.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v2 3/5] crypto: talitos: Fix off-by-one and use all hardware slots

2015-03-03 Thread Martin Hicks
The submission count was off by one.

Signed-off-by: Martin Hicks 
---
 drivers/crypto/talitos.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 89cf4d5..7709805 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -2722,8 +2722,7 @@ static int talitos_probe(struct platform_device *ofdev)
goto err_out;
}
 
-   atomic_set(&priv->chan[i].submit_count,
-  -(priv->chfifo_len - 1));
+   atomic_set(&priv->chan[i].submit_count, -priv->chfifo_len);
}
 
dma_set_mask(dev, DMA_BIT_MASK(36));
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev