Herbert Xu wrote:
On Thu, Apr 09, 2009 at 03:05:51PM +0200, Patrick McHardy wrote:
It also seems to fix a netfilter problem with modules not loaded
automatically anymore.
They should still autoload, but now you need to retry the operation
manually :)
Right, the second attempt succeeded
Maciej Rutecki wrote:
2009/4/9 Herbert Xu :
[...]
Yes, patch helps. Thanks
It also seems to fix a netfilter problem with modules not loaded
automatically anymore.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
Mo
Ingo Molnar wrote:
btw, on a related note, there's a couple of networking related warning
fixes/annotations i've got queued up.
I've got 37 commits of that nature in the tip/warnings/* topic
branches:
[...]
They are done mainly so that we can notice the warnings we introduce
via any of the
Herbert Xu wrote:
On Wed, Nov 19, 2008 at 02:03:27PM +, Evgeniy Polyakov wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
The descriptors need to be invalidated after processing for ring
cleanup to work properly and to avoid using an old destination
descriptor when the src a
Evgeniy Polyakov wrote:
Hi Patrick.
On Wed, Sep 24, 2008 at 06:40:29PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
[HIFN]: Fix DMA setup
without a changelog :) IIRC the problem is that HIFN sets up each
DMA descriptor for the full request length, even though it should
only cover on
ave HW invalidate src and dest descriptors after processing
The descriptors need to be invalidated after processing for ring
cleanup to work properly and to avoid using an old destination
descriptor when the src and cmd descriptors are already set up
and the dst descriptor isn't
Herbert Xu wrote:
Hi Patrick:
Patrick McHardy <[EMAIL PROTECTED]> wrote:
This patch adds checks to tcrypt to catch destination buffer
corruption for cipher tests across pages, which was useful
while fixing corruption caused by the HIFN driver.
This seems like a pretty useful check.
Evgeniy Polyakov wrote:
On Wed, May 07, 2008 at 03:01:55PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
We can also be safe without volatile annotations.
Yes, will also be taken care of by a later patch :)
I just receive them in a strange order and do not know when others will
arrive
Evgeniy Polyakov wrote:
On Wed, May 07, 2008 at 02:53:17PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
The descriptors need to be invalidated after processing for ring
cleanup to work properly and to avoid using an old destination
descriptor when the src and cmd descriptors
Herbert Xu wrote:
On Tue, Apr 22, 2008 at 10:23:23AM -0700, Loc Ho wrote:
They are attached instead inline until I figure out how to not wrap long
line.
Thanks. I've finally finished testing and integrating it. I've
merged them into one patch and dropped unrelated white-space
changes. You c
Evgeniy Polyakov wrote:
On Wed, May 07, 2008 at 02:45:15PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Of the data buffers only the destination buffer needs to be aligned,
see the Source Pointer description in "2.2 Source Descriptors" in
the HIFN documentation.
Ok, than
Evgeniy Polyakov wrote:
On Wed, May 07, 2008 at 02:14:28PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
[HIFN]: Endianess fixes
HIFN uses little-endian by default, move cpu_to_le32 conversion to hifn_write_0/
hifn_write_1, add sparse annotations and fix an invalid
commit 0b4add2721b85f3ea873b87b02c057f2b5cff7aa
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 13:15:44 2008 +0200
[HIFN]: Have HW invalidate src and dest descriptors after processing
The descriptors need to be invalidated after processing for ring
clea
Herbert Xu wrote:
On Wed, May 07, 2008 at 02:26:30PM +0200, Patrick McHardy wrote:
I'm not entirely sure about the alignmask change at the end of
this patch, is an alignmask of 1 correct if no source buffer
If no alignment is required you want 0, 1 means 2-byte aligned.
T
Note: the DMA setup fixes mentioned in the changelog still
need a bit of work, so I'm not sure if I'll manage to send
them today. This one is fine for review or applying anyway.
commit 163c74fc4f18d086bbb7f114d55bc7dac939d6b7
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date:
Evgeniy Polyakov wrote:
On Wed, May 07, 2008 at 02:26:30PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
I'm not entirely sure about the alignmask change at the end of
this patch, is an alignmask of 1 correct if no source buffer
alignment is required, but the destination buffer s
commit 21b18f9b22c7aa0a458c3f93fc1771a5eb5e70c8
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 13:00:10 2008 +0200
[HIFN]: Fix max queue length value
All but the last element of the command and result descriptor rings can be
used for crypto request
Two questions regarding this patch:
- do OFB and CFB also need ivsize initialization?
- the HIFN documentation doesn't mention OFB and CFB (the
values are marked reserved), do they actually work?
commit d4ef6dd3f4e37a37c0823fd09c53657af63c8d88
Author: Patrick McHardy <[EMAIL PROTECTE
commit 02cabb7369102c475dfa33dbb6787db1855a7062
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 12:54:30 2008 +0200
[HIFN]: Use unique driver names for different algos
When the CryptoAPI instantiates a new algorithm, it performs a lookup
by driver name. Sinc
commit 4f3353b225b7123cf9c04cb9ae3b987f0671ee26
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 12:52:53 2008 +0200
[HIFN]: Properly handle requests for less than the full scatterlist
The scatterlist may contain more data than the crypto request, causing
Evgeniy Polyakov wrote:
Hi.
On Wed, May 07, 2008 at 02:19:36PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
hifn_setup_crypto() needs to return -EINPROGRESS on success to indicate
asynchronous processing to the crypto API. This also means it must not
return the errno code
ge cra_alignmask to 1.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index 4e89cd8..7706461 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -369,6 +369,8 @@ static atomic_t hifn_dev_number;
#de
commit 7e24c849df30a5d2b0bb89165b933ea2faa747bd
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 12:43:20 2008 +0200
[HIFN]: Handle ablkcipher_walk errors
ablkcipher_walk may return a negative error value, handle this properly
instead of treating it as
commit 835b2aece80670cd439ff74e51a647836f73d0ca
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 12:42:06 2008 +0200
[HIFN]: Indicate asynchronous processing to crypto API
hifn_setup_crypto() needs to return -EINPROGRESS on success to indicate
asynch
commit 9dbbaf326c4033cd8d973cb6bf10298faf50180c
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 12:38:01 2008 +0200
[HIFN]: Remove printk_ratelimit() for debugging printk
Without debugging this spams the log with "printk: N messages surpressed"
wi
102
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 12:27:09 2008 +0200
[HIFN]: Endianess fixes
HIFN uses little-endian by default, move cpu_to_le32 conversion to hifn_write_0/
hifn_write_1, add sparse annotations and fix an invalid endian conversion in
hif
if this is considered a problem I would simply remove
the byte count entirely and only check the first byte.
commit b50b099a28f8e970cfe54b38bfc317e213a1faa7
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed May 7 08:32:05 2008 +0200
[TCRYPT]: Catch cipher destination memory corruptio
Patrick McHardy wrote:
Herbert Xu wrote:
On Tue, Apr 29, 2008 at 07:09:39AM +0200, Patrick McHardy wrote:
I've attached two traces, the one from eseqiv and a similar
one from authenc (I've manually overriden eseqiv by chainiv
to test whether its responsible for the broken pac
Herbert Xu wrote:
On Tue, Apr 29, 2008 at 07:09:39AM +0200, Patrick McHardy wrote:
I've attached two traces, the one from eseqiv and a similar
one from authenc (I've manually overriden eseqiv by chainiv
to test whether its responsible for the broken packets I was
seeing, which tur
Herbert Xu wrote:
Hi Patrick:
On Mon, Apr 28, 2008 at 08:55:21PM +0200, Patrick McHardy wrote:
I ran into occasional BUGs in scatterlist.h, which turned
out the be caused by accessing an uninitialized scatterlist
entry from eseqiv. I'm not sure whether this patch is correct
since I
27;t understand why
scatterwalk_sg_next() returns either a scatterlist or a
struct page dependant on the length, but at least it fixes
the BUG() for me :)
commit 7be04e75bc64dc288e51f83495d89135a8c9d4d7
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Mon Apr 28 19:24:23 2008 +0200
commit 5546f35aa64c020074eca8546d638fc0305eb9ff
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Sun Apr 27 22:22:11 2008 +0200
[CRYPTO]: authenc: fix async crypto crash in crypto_authenc_genicv()
crypto_authenc_givencrypt_done uses req->data as struct
aead_givcryp
Evgeniy Polyakov wrote:
Does this patch (on top of unpatched tree) helps?
I can not test it with real hardware, since I'm sicking at home with
laptop only, but I already know how to make a test case for this problem
without complex setup, so if it does not work, I will investigate it
further as
Patrick McHardy wrote:
It also looks like at least two more changes are needed:
> ...
One more thing: I got lots of "printk: 4 messages suppressed"
without any real messages. The reason is a printk_ratelimit()
before a dprintk(). This probably wants either an #ifdef or
a real
Patrick McHardy wrote:
Evgeniy Polyakov wrote:
On Thu, Feb 21, 2008 at 03:20:45PM +0100, Patrick McHardy
([EMAIL PROTECTED]) wrote:
Almost I guess :) There are similar loops in hifn_setup_session().
Additionally we need to check that the return value of ablkcipher_walk()
is not a negative
Evgeniy Polyakov wrote:
On Thu, Feb 21, 2008 at 03:20:45PM +0100, Patrick McHardy ([EMAIL PROTECTED])
wrote:
Almost I guess :) There are similar loops in hifn_setup_session().
Additionally we need to check that the return value of ablkcipher_walk()
is not a negative errno code.
Yep. Kind of
Evgeniy Polyakov wrote:
Hi Herbert.
On Thu, Feb 21, 2008 at 10:10:13PM +0800, Herbert Xu ([EMAIL PROTECTED]) wrote:
Yes by the time the request gets to hifn req->nbytes would have
been decremented by 12 bytes which means that it is now the exact
amount of data that needs to be encrypted.
Howev
Herbert Xu wrote:
On Tue, Feb 19, 2008 at 05:27:25PM +0100, Patrick McHardy wrote:
Yes, probably. So I take it the assumption in HIFN that the
sg-list length matches req->nbytes is incorrect?
Where were you seeing the discrepancy? If it's at the point of
entry into the HIFN code then
Herbert Xu wrote:
Patrick McHardy <[EMAIL PROTECTED]> wrote:
I couldn't figure out where in the crypto code the
nbytes decrement by 12 bytes compared to the length
seen when setting up the crypto operation happens
or I might have tried to properly fix it myself.
I'll happily
Patrick McHardy wrote:
Evgeniy Polyakov wrote:
Hi Patrick.
On Wed, Feb 13, 2008 at 05:44:42PM +0300, Evgeniy Polyakov
([EMAIL PROTECTED]) wrote:
Any chance you can apply following patch and check output for correct
and broken cases (it will produce 2 or 3 debug strings for each crypto
Evgeniy Polyakov wrote:
Hi Patrick.
On Wed, Feb 13, 2008 at 05:44:42PM +0300, Evgeniy Polyakov ([EMAIL PROTECTED])
wrote:
Any chance you can apply following patch and check output for correct
and broken cases (it will produce 2 or 3 debug strings for each crypto
operation)?
diff --git a/drive
I'm getting crashes when using HIFN and IPsec (ESP with
AES + MD5) in the current -git tree. I didn't capture the
Oops, but there seem to be a number of problems:
- hifn_setup_session walks over the scatterlist, subtracting
the scatterlist element size from nbytes until nbytes
reaches zero. I
commit 3810a091ff8bc9b5038647a4b32a08267284f3f9
Author: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed Feb 6 14:56:09 2008 +0100
[HIFN]: Fix invalid config ifdefs for RNG support
The CRYPTO_DEV_HIFN_795X_RNG ifdefs are missing the CONFIG_ prefix.
Signed-off-by: P
Michael Buesch wrote:
On Sunday 18 November 2007 22:32:52 Patrick McHardy wrote:
These patches add support for using the HIFN rng.
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Patrick, can you send this patchset to Andrew for inclusion into -mm?
I think he already pulls from Her
[HIFN]: Add support for using the random number generator
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 352a65d036f53c1e124bef4205d6fcedb78eac2c
tree 190bb0b4a1795e55096552f743af996df2766070
parent 70467fae3a656562f86adefdfe6d54e3ca20feeb
author Patrick McHardy <[EMAIL
[HWRNG]: move status polling loop to data_present callbacks
Handle waiting for new random within the drivers themselves, this allows to
use better suited timeouts for the individual rngs.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 5632554998aafc5605635f842bca50d5353cd9d
r external) and its frequency and uses that to calculate the
optimum multiplier to reach the maximal speed. By default it uses
the external clock and assumes a speed of 66MHz, which effectively
halfs the frequency currently used.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]
deletions(-)
Patrick McHardy (3):
[HWRNG]: move status polling loop to data_present callbacks
[HIFN]: Improve PLL initialization
[HIFN]: Add support for using the random number generator
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of
Herbert Xu wrote:
On Sat, Nov 17, 2007 at 07:53:25PM +, Evgeniy Polyakov wrote:
The second patch adds hw_random support. The ugly part is finding out
when to allow reads from the RNG. It currently translates the public
key engine clock cycles to CPU cycles based on a 4GHz CPU and uses
get
Evgeniy Polyakov wrote:
On Sat, Nov 17, 2007 at 08:30:09PM +0100, Patrick McHardy ([EMAIL PROTECTED])
wrote:
The second patch adds hw_random support. The ugly part is finding out
when to allow reads from the RNG. It currently translates the public
key engine clock cycles to CPU cycles based
[HIFN]: Add support for using the random number generator
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit ad6c98ed1e38edf4da775780b59a0faf56ff42a7
tree 7c733d13a387e18bace04fe904bed9937c0bb628
parent 3ca22e0c464bc84bffdf63d65c1094b2fed78bff
author Patrick McHardy <[EMAIL
lt it uses
the external clock and assumes a speed of 66MHz, which effectively
halfs the frequency currently used.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 3ca22e0c464bc84bffdf63d65c1094b2fed78bff
tree 25f8eec10f986304415f7248255cfa813adf
~2.5mbit.
drivers/crypto/hifn_795x.c | 158 +++-
1 files changed, 156 insertions(+), 2 deletions(-)
Patrick McHardy (2):
[HIFN]: Improve PLL initialization
[HIFN]: Add support for using the random number generator
-
To unsubscribe from this
53 matches
Mail list logo
