On Wed, Apr 08, 2015 at 10:45:45AM -0400, Dan Streetman wrote:
>
> Ok I'll see if I can include a sw compression implementation.
That would be great!
> ah ok, so you mean it can still be a crypto_comp interface, just move
> its location and/or merge it into nx-842.c?
Oh yes of course. There is
On Wed, Apr 8, 2015 at 10:16 AM, Herbert Xu wrote:
> On Tue, Apr 07, 2015 at 01:34:30PM -0400, Dan Streetman wrote:
>> Add configurable module to perform self-tests on any crypto compression
>> driver.
>>
>> This allows testing any crypto compression driver with any input buffer,
>> at varying ali
On Wed, Apr 8, 2015 at 10:38 AM, Herbert Xu wrote:
> On Wed, Apr 08, 2015 at 10:28:23AM -0400, Dan Streetman wrote:
>>
>> So, the sw implementation is only for decompression; there's no sw
>> compression implementation in these patches.
>
> As a general rule we don't add any hardware implementatio
On Wed, Apr 08, 2015 at 10:28:23AM -0400, Dan Streetman wrote:
>
> So, the sw implementation is only for decompression; there's no sw
> compression implementation in these patches.
As a general rule we don't add any hardware implementation unless
there is a software implementation. The reason is
On Wed, Apr 8, 2015 at 10:16 AM, Herbert Xu wrote:
> On Tue, Apr 07, 2015 at 01:34:28PM -0400, Dan Streetman wrote:
>> Update the crypto 842 driver to no longer fallback to LZO if the 842
>> hardware is unavailable. Simplify the crpypto 842 driver to remove all
>> headers indicating 842/lzo.
>>
>
On Tue, Apr 07, 2015 at 05:13:41PM +0200, Steffen Trumtrar wrote:
> With commit
>
> 7e77bdebff5cb1e9876c561f69710b9ab8fa1f7e crypto: af_alg - fix backlog
> handling
>
> in place, the backlog works under all circumstances where it previously
> failed, atleast
> for the sahara driver. Use i
On Tue, Apr 07, 2015 at 05:45:01PM +0800, Leilei Zhao wrote:
> The series of patches add crypto driver for SAMA5D4 and
> fix some bugs about Atmel crypto driver:
> - Add new IP version for AES and SHA.
> - The spinlock is not initialized before using.
> - Fix sg list management to avoid crash i
On Wed, Apr 08, 2015 at 04:18:56PM +0200, Ard Biesheuvel wrote:
>
> So what about
>
> > +typedef void (sha1_block_fn)(int blocks, u8 const *src, u32 *state,
> > + bool final);
>
> ?
Looks good to me.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~
On 8 April 2015 at 16:06, Herbert Xu wrote:
> On Wed, Apr 08, 2015 at 03:40:56PM +0200, Ard Biesheuvel wrote:
>>
>> This is not the partial code path, it is the .finup path, in fact.
>> Anything that hashes data that is often a multiple of the block size
>> (which is more likely for block based ap
On Tue, Apr 07, 2015 at 01:34:30PM -0400, Dan Streetman wrote:
> Add configurable module to perform self-tests on any crypto compression
> driver.
>
> This allows testing any crypto compression driver with any input buffer,
> at varying alignments and lengths. It calculates the average bytes per
On Tue, Apr 07, 2015 at 01:34:28PM -0400, Dan Streetman wrote:
> Update the crypto 842 driver to no longer fallback to LZO if the 842
> hardware is unavailable. Simplify the crpypto 842 driver to remove all
> headers indicating 842/lzo.
>
> The crypto 842 driver should do 842-format compression a
On Wed, Apr 08, 2015 at 03:40:56PM +0200, Ard Biesheuvel wrote:
>
> This is not the partial code path, it is the .finup path, in fact.
> Anything that hashes data that is often a multiple of the block size
> (which is more likely for block based applications than for IPsec, I
> think) should benefi
On 8 April 2015 at 15:40, Ard Biesheuvel wrote:
> On 8 April 2015 at 15:30, Herbert Xu wrote:
>> On Wed, Apr 08, 2015 at 03:25:14PM +0200, Ard Biesheuvel wrote:
>>>
>>> Not having to call the function twice is the whole point. In the arm64
>>> case, all the SHA-256 round keys can be kept in regis
On 8 April 2015 at 15:30, Herbert Xu wrote:
> On Wed, Apr 08, 2015 at 03:25:14PM +0200, Ard Biesheuvel wrote:
>>
>> Not having to call the function twice is the whole point. In the arm64
>> case, all the SHA-256 round keys can be kept in registers (it has 32
>> 16-byte SIMD registers), and that is
On Wed, Apr 08, 2015 at 03:25:14PM +0200, Ard Biesheuvel wrote:
>
> Not having to call the function twice is the whole point. In the arm64
> case, all the SHA-256 round keys can be kept in registers (it has 32
> 16-byte SIMD registers), and that is what motivates this pattern. By
> passing a head b
On 8 April 2015 at 15:19, Herbert Xu wrote:
> On Tue, Apr 07, 2015 at 10:51:49AM +0200, Ard Biesheuvel wrote:
>>
>> +typedef void (sha1_block_fn)(int blocks, u8 const *src, u32 *state,
>> + const u8 *head, void *p);
>
> Does this really need five arguments? First of all we
On Tue, Apr 07, 2015 at 10:51:49AM +0200, Ard Biesheuvel wrote:
>
> +typedef void (sha1_block_fn)(int blocks, u8 const *src, u32 *state,
> + const u8 *head, void *p);
Does this really need five arguments? First of all we can get rid
of head by just calling this function tw
17 matches
Mail list logo
