[PATCH] crypto, x86: aesni - fix token pasting for clang

aes_ctrby8_avx-x86_64.S uses the C preprocessor for token pasting of character sequences that are not valid preprocessor tokens. While this is allowed when preprocessing assembler files it exposes an incompatibilty between the clang and gcc preprocessors where clang does not strip leading white spa

RE: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

Hi David, > While not part of this change, the unrolled loops look as though > they just destroy the cpu cache. > I'd like be convinced that anything does CRC over long enough buffers > to make it a gain at all. > > With modern (not that modern now) superscalar cpus you can often > get the loop in

[PATCH V3 0/3] Support new function in new CCPs

The following series implements new function in a version 5 coprocessor. New features are: - Support for SHA-2 384-bit and 512-bit hashing - Support for 3DES encryption - Support for AES GCM encryption Changes from V2: - Correct a comment in the GCM support code. - Ensure the patches apply to

[PATCH V3 3/3] crypto: ccp - Enable support for AES GCM on v5 CCPs

A version 5 device provides the primitive commands required for AES GCM. This patch adds support for en/decryption. Signed-off-by: Gary R Hook --- drivers/crypto/ccp/Makefile|1 drivers/crypto/ccp/ccp-crypto-aes-galois.c | 252 drivers/crypto/cc

[PATCH V3 2/3] crypto: ccp - Enable 3DES function on v5 CCPs

Wire up support for Triple DES in ECB mode. Signed-off-by: Gary R Hook --- drivers/crypto/ccp/Makefile |1 drivers/crypto/ccp/ccp-crypto-des3.c | 254 ++ drivers/crypto/ccp/ccp-crypto-main.c | 10 + drivers/crypto/ccp/ccp-crypto.h | 22 +++

[PATCH V3 1/3] crypto: ccp - Add SHA-2 384- and 512-bit support

Incorporate 384-bit and 512-bit hashing for a version 5 CCP device Signed-off-by: Gary R Hook --- drivers/crypto/ccp/ccp-crypto-sha.c | 22 +++ drivers/crypto/ccp/ccp-crypto.h |8 ++-- drivers/crypto/ccp/ccp-ops.c| 72 +++ include/linu

Re: [PATCH] dt-bindings: rng: clocks property on omap_rng is optional

On Tue, Mar 07, 2017 at 03:18:28PM +0100, Thomas Petazzoni wrote: > Commit 52060836f79 ("dt-bindings: omap-rng: Document SafeXcel IP-76 > device variant") update the omap_rng Device Tree binding to add support > for the IP-76 variation of the IP. As part of this change, a "clocks" > property was ad

RE: [PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

From: Linuxppc-dev Daniel Axtens > Sent: 15 March 2017 12:38 > The core nuts and bolts of the crc32c vpmsum algorithm will > also work for a number of other CRC algorithms with different > polynomials. Factor out the function into a new asm file. > > To handle multiple users of the function, a use

[PATCH 4/4] crypto: powerpc - Stress test for vpmsum implementations

vpmsum implementations often don't kick in for short test vectors. This is a simple test module that does a configurable number of random tests, each up to 64kB and each with random offsets. Both CRC-T10DIF and CRC32C are tested. Cc: Anton Blanchard Signed-off-by: Daniel Axtens -- Not super f

[PATCH 2/4] crypto: powerpc - Re-enable non-REFLECTed CRCs

When CRC32c was included in the kernel, Anton ripped out the #ifdefs around reflected polynomials, because CRC32c is always reflected. However, not all CRCs use reflection so we'd like to make it optional. Restore the REFLECT parts from Anton's original CRC32 implementation (https://github.com/ant

[PATCH 3/4] crypto: powerpc - Add CRC-T10DIF acceleration

T10DIF is a CRC16 used heavily in NVMe. It turns out we can accelerate it with a CRC32 library and a few little tricks. Provide the accelerator based the refactored CRC32 code. Cc: Anton Blanchard Thanks-to: Hong Bo Peng Signed-off-by: Daniel Axtens --- arch/powerpc/crypto/Makefile

[PATCH 1/4] crypto: powerpc - Factor out the core CRC vpmsum algorithm

The core nuts and bolts of the crc32c vpmsum algorithm will also work for a number of other CRC algorithms with different polynomials. Factor out the function into a new asm file. To handle multiple users of the function, a user simply provides constants, defines the name of their CRC function, an

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

On (03/15/17 10:08), Dmitry Vyukov wrote: > After I've applied the patch these reports stopped to happen, and I > have not seem any other reports that look relevant. > However, it there was one, but it looks like a different issue and it > was probably masked by massive amounts of original deadlock

[PATCH v2 01/14] crypto: sun4i-ss - simplify optional reset handling

As of commit bb475230b8e5 ("reset: make optional functions really optional"), the reset framework API calls use NULL pointers to describe optional, non-present reset controls. This allows to return errors from devm_reset_control_get_optional and to call reset_control_(de)assert unconditionally. S

Re: crypto: deadlock between crypto_alg_sem/rtnl_mutex/genl_mutex

On Tue, Mar 14, 2017 at 4:25 PM, Sowmini Varadhan wrote: > On (03/14/17 09:14), Dmitry Vyukov wrote: >> Another one now involving rds_tcp_listen_stop >: >> kworker/u4:1/19 is trying to acquire lock: >> (sk_lock-AF_INET){+.+.+.}, at: [] lock_sock >> include/net/sock.h:1460 [inline] >> (sk_loc

Re: [PATCH v6 0/4] Broadcom SBA RAID support

On Wed, Mar 15, 2017 at 12:18 AM, Shaohua Li wrote: > On Tue, Mar 14, 2017 at 09:56:35AM -0700, Dan Williams wrote: >> On Mon, Mar 6, 2017 at 1:43 AM, Anup Patel wrote: >> > The Broadcom SBA RAID is a stream-based device which provides >> > RAID5/6 offload. >> > >> > It requires a SoC specific ri

Re: [PATCH v6 0/4] Broadcom SBA RAID support

On Tue, Mar 14, 2017 at 10:26 PM, Dan Williams wrote: > On Mon, Mar 6, 2017 at 1:43 AM, Anup Patel wrote: >> The Broadcom SBA RAID is a stream-based device which provides >> RAID5/6 offload. >> >> It requires a SoC specific ring manager (such as Broadcom FlexRM >> ring manager) to provide ring-ba