On Fri, Feb 3, 2017 at 5:35 PM, Jassi Brar wrote:
> On Thu, Feb 2, 2017 at 10:17 AM, Anup Patel wrote:
>> The remote processor can have DMAENGINE capabilities and client
>> can pass data to be processed via main memory. In such cases,
>> the client will require DMAble memory for remote processor.
On Sat, Feb 4, 2017 at 12:12 AM, Dan Williams wrote:
> On Fri, Feb 3, 2017 at 2:59 AM, Anup Patel wrote:
>>
>>
>> On Thu, Feb 2, 2017 at 11:31 AM, Dan Williams
>> wrote:
>>>
>>> On Wed, Feb 1, 2017 at 8:47 PM, Anup Patel
>>> wrote:
>>> > The DMAENGINE framework assumes that if PQ offload is sup
This patch removes the functions introduced as wrappers for providing
backwards compatibility to the prior LZ4 version.
They're not needed anymore since there's no callers left.
Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
include/linux/lz4.h | 69
This patch updates the crypto modules using LZ4 compression as well as the
test cases in testmgr.h to work with the new LZ4 module version.
Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
crypto/lz4.c | 23 -
crypto/lz4hc.c | 23 -
crypto/testmgr.h | 1
This patch updates the unlz4 wrapper to work with the
updated LZ4 kernel module version.
Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
lib/decompress_unlz4.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/lib/decompress_unlz4.c b/lib/decom
This patch updates fs/pstore and fs/squashfs to use the updated
functions from the new LZ4 module.
Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
fs/pstore/platform.c | 22 +-
fs/squashfs/lz4_wrapper.c | 12 ++--
2 files changed, 19 insertion
This patchset is for updating the LZ4 compression module to a version based
on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
which provides an "acceleration" parameter as a tradeoff between
high compression ratio and high compression speed.
We want to use LZ4 fast in orde
Instead of unconditionally forcing 4 byte alignment for all generic
chaining modes that rely on crypto_xor() or crypto_inc() (which may
result in unnecessary copying of data when the underlying hardware
can perform unaligned accesses efficiently), make those functions
deal with unaligned input expl
Am Freitag, 3. Februar 2017, 16:42:53 CET schrieb Nitin Kumbhar:
Hi Nitin,
> +
> +int ecdsa_set_pub_key(struct crypto_akcipher *tfm, const void *key,
> + unsigned int keylen)
> +{
> + struct ecdsa_ctx *ctx = ecdsa_get_ctx(tfm);
> + struct ecdsa params;
> + unsigned i
