On 05/13/2014 09:43 AM, Marc Kleine-Budde wrote:
On 05/13/2014 07:14 AM, Oliver Hartkopp wrote:
Hello Jet,
this is likely not CAN related, as
# CONFIG_CAN is not set
and all the CAN changes introduced by Marc's merge are not even compiled in
your setup.
So I assume the issue somewhere
Hi Linus:
This push fixes a NULL pointer dereference on allocation failure
in caam, as well as a regression in the ctr mode on s390 that was
added with the recent concurrency fixes.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
On Fri, May 09, 2014 at 12:57:39AM +0300, Stanimir Vabanov wrote:
Hi Herbert,
On 04/28/2014 11:59 AM, Herbert Xu wrote:
On Mon, Apr 14, 2014 at 03:48:37PM +0300, Stanimir Varbanov wrote:
+#define QCE_MAJOR_VERSION50x05
+#define QCE_QUEUE_LENGTH 50
What is the purpose of
On Fri, May 09, 2014 at 08:34:40PM -0500, Kim Phillips wrote:
From: Vakul Garg va...@freescale.com
Re-initialize keys_fit_inline to avoid using its stale encrypt() shared
descriptor value prior to building descriptors for the decrypt() and
givencrypt() cases.
Signed-off-by: Vakul Garg
On 01.05.2014 18:51, Ard Biesheuvel wrote:
The Crypto Extensions based SHA1 implementation uses the NEON register file,
and hence runs with preemption disabled. This patch adds a TIF_NEED_RESCHED
check to its inner loop so we at least give up the CPU voluntarily when we
are running in process
In this patch series, we introduce the multi-buffer crypto algorithm on
x86_64 and apply it to SHA1 hash computation. The multi-buffer technique
takes advantage of the 8 data lanes in the AVX2 registers and allows
computation to be performed on data from multiple jobs in parallel.
This allows us
For x86_64, it is not necessary to incur the additional overhead in
kmap_atomic to map the scatter gather buffer to a linear address.
Mapping the address directly will allow in x86_64 allows multi-buffer
crypto hash alogrithms to have several unfinished buffers with their
address stored in job
This patch introduces the data structures and prototypes of functions
needed for computing SHA1 hash using multi-buffer. Included are the
structures of the multi-buffer SHA1 job, job scheduler in C and x86
assembly.
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
This patch introduces the multi-buffer crypto daemon which is responsible
for submitting crypto jobs in a work queue to the responsible multi-buffer
crypto algorithm. The idea of the multi-buffer algorihtm is to put
data streams from multiple jobs in a wide (AVX2) register and then
take advantage
This patch introduces the assembly routines to do SHA1 computation on
buffers belonging to serveral jobs at once. The assembly routines are
optimized with AVX2 instructions that have 8 data lanes and using AVX2
registers.
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
This patch introduces the routines used to submit and flush buffers
belonging to SHA1 crypto jobs to the SHA1 multibuffer algorithm. It is
implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
This patch introduces the multi-buffer scheduler which is responsible
for submitting scatter-gather buffers from several SHA1 jobs to the
multi-buffer algorithm. It also contains the flush routine to that's
called by the crypto daemon to complete the job when no new jobs arrive
before the
On Tue, May 13, 2014 at 04:19:42PM -0700, Tim Chen wrote:
For x86_64, it is not necessary to incur the additional overhead in
kmap_atomic to map the scatter gather buffer to a linear address.
Mapping the address directly will allow in x86_64 allows multi-buffer
crypto hash alogrithms to have
On Wed, 2014-05-14 at 07:34 +0800, Herbert Xu wrote:
Why do we need this patch since kmap_atomic is equivalent to
page_address plus preempt_disable on x86-64?
For multi-buffers, you may still have some data lanes with jobs
that are partially completed when you need to put the thread
to
On Tue, May 13, 2014 at 04:40:58PM -0700, Tim Chen wrote:
On Wed, 2014-05-14 at 07:34 +0800, Herbert Xu wrote:
Why do we need this patch since kmap_atomic is equivalent to
page_address plus preempt_disable on x86-64?
For multi-buffers, you may still have some data lanes with jobs
On Tue, May 13, 2014 at 04:19:45PM -0700, Tim Chen wrote:
diff --git a/crypto/shash.c b/crypto/shash.c
index 929058a..6f40424 100644
--- a/crypto/shash.c
+++ b/crypto/shash.c
@@ -229,6 +229,42 @@ int shash_ahash_update(struct ahash_request *req, struct
shash_desc *desc)
}
On Fri, May 09, 2014 at 08:37:58AM +0200, Ard Biesheuvel wrote:
@Herbert, Jussi: care to share your opinion on the SHAx, GHASH and AES
patches above? Herbert has already acked the ccm patch, but Catalin is
requesting for more review and/or acknowledgements before merging
these patches for
Ard Biesheuvel ard.biesheu...@linaro.org wrote:
+ /*
+* Pass current's thread info pointer to sha1_ce_transform()
+* below if we want it to play nice under preemption.
+*/
+ if ((IS_ENABLED(CONFIG_PREEMPT_VOLUNTARY)
Dmitry Kasatkin dmitry.kasat...@gmail.com wrote:
Hi,
ahash allows to use HW acceleration, but usually it comes at a cost of
additional HW related configuration overhead, such as configuring hash
module, DMA, etc. For that reason hashing small chucks of data is
faster doing it with shash
19 matches
Mail list logo
