On Wed, 25 Feb 2009, Geert Uytterhoeven wrote:
> Modify SquashFS 4 to use the new "pcomp" crypto interface for decompression,
> instead of calling the underlying zlib library directly. This simplifies e.g.
> the addition of support for hardware decompression and different decompression
> algorithms
On Wed, 11 Mar 2009, Geert Uytterhoeven wrote:
> On Sun, 8 Mar 2009, Phillip Lougher wrote:
> > Two API issues of concern (one major, one minor). Both of these relate to
> > the
> > way Squashfs drives the decompression code, where it repeatedly calls it
> > supplying additional input/output buff
This is version two of the the driver. New things:
- aes-ecb passes selftests
- aes-cbc passes selftests
The driver still does memcpy() from/to sram. To solve this, a dma driver
would be required but first I wanted to compare the performance between
now and nothing/generic aes. However I managed t
> I have encountered a problem with the new HiFn driver in 2.6.27,
> cryptsetup and luks.
the mailinglist you posted to mainly deals with loop-aes these days,
the dm-crypt/luks/mainline loop-crypto guys for some obscure reason
opted to start a mailinglist of the same name at
linux-crypto@vger.kern
Hi.
On Tue, Mar 17, 2009 at 10:58:44PM +0100, Sebastian Andrzej Siewior
(arm-ker...@ml.breakpoint.cc) wrote:
> +struct crypto_priv {
Please use less generic names over the file.
> + void __iomem *reg;
> + void __iomem *sram;
> + int irq;
> + struct task_struct *queue_th;
> +
> +
On Tue, Mar 17, 2009 at 11:33:32PM +0100, markus reichelt (m...@mareichelt.de)
wrote:
> > I have encountered a problem with the new HiFn driver in 2.6.27,
> > cryptsetup and luks.
>
> the mailinglist you posted to mainly deals with loop-aes these days,
> the dm-crypt/luks/mainline loop-crypto guy
Use crypto_alloc_base() instead of crypto_alloc_ablkcipher() to
allocate underlying tfm in cryptd_alloc_ablkcipher. Because
crypto_alloc_ablkcipher() prefer GENIV encapsulated crypto instead of
raw one, while cryptd_alloc_ablkcipher needed the raw one.
Signed-off-by: Huang Ying
---
crypto/crypt
Blkcipher touching FPU need to be enclosed by kernel_fpu_begin() and
kernel_fpu_end(). If they are invoked in cipher algorithm
implementation, they will be invoked for each block, so that
performance will be hurt, because they are "slow" operations. This
patch implements "fpu" template, which makes
Because kernel_fpu_begin() and kernel_fpu_end() operations are too
slow, the performance gain of general mode implementation + aes-aesni
is almost all compensated.
The AES-NI support for more modes are implemented as follow:
- Add a new AES algorithm implementation named __aes-aesni without
ker
