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: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 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
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 and decompression
only. It should not fallback to LZO compression/decompr
