Re: [GIT] Networking

On Tue, Jul 11, 2017 at 01:31:14PM -0700, David Miller wrote: > > Acked-by: David S. Miller > > Looks good, is this going via my tree or your's? I'll push it along. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/

Re: [GIT] Networking

From: Herbert Xu Date: Mon, 10 Jul 2017 22:00:48 +0800 > crypto: af_alg - Avoid sock_graft call warning > > The newly added sock_graft warning triggers in af_alg_accept. > It's harmless as we're essentially doing sock->sk = sock->sk. > > The sock_graft call is

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On Tue, Jul 11, 2017 at 11:53:11AM -0700, Dave Watson wrote: > On 07/11/17 08:29 AM, Steffen Klassert wrote: > > Sorry for replying to old mail... > > > +int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx) > > > +{ > > > > ... > > > > > + > > > + if (!sw_ctx->aead_send) { > > > +

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

On 07/11/17 08:29 AM, Steffen Klassert wrote: > Sorry for replying to old mail... > > +int tls_set_sw_offload(struct sock *sk, struct tls_context *ctx) > > +{ > > ... > > > + > > + if (!sw_ctx->aead_send) { > > + sw_ctx->aead_send = crypto_alloc_aead("gcm(aes)", 0, 0); > > +

Re: [PATCH 00/10] Fix alignment issues in staging/ccree

On Sun, Jul 02, 2017 at 01:25:45AM +0200, Simon Sandström wrote: > Fixes a total of 195 alignment issues in staging/ccree reported by > checkpatch.pl. Adds a few "line over 80 characters" warnings as a > result of the realignments, but I could try to get rid of them in the > same patchset if

[PATCH] staging: ccree: move FIPS support to kernel infrastructure

The ccree driver had its own FIPS support, complete with a test harness comparable to crypto testmgr and an implementation which disables crypto functionality on FIPS test error detection, either in Linux or from TEE. This patch removes the duplication, while reimplementing the handling of TEE

Re: [PATCH 1/2] staging: ccree: remove unnecessary cast on kmalloc

On Sun, Jul 9, 2017 at 8:43 AM, Gustavo A. R. Silva wrote: > The assignment operator implicitly converts a void pointer to the type of the > pointer it is assigned to. > > This issue was detected using Coccinelle and the following semantic patch: > > @@ > expression * e;

Re: [PATCH 0/5] staging: ccree: fix checkpatch errors

Tyler, On Tue, Jul 11, 2017 at 4:38 PM, Gilad Ben-Yossef wrote: > On Mon, Jul 10, 2017 at 12:10 AM, wrote: >> From: Tyler Olivieri >> >> This patchset fixes several checkpatch errors and warnings in /staging/ccree:

Re: [PATCH v2] staging: ccree: Use __func__ instead of function name

Hello Karthik , Thank you for the patch. On Thu, Jun 29, 2017 at 8:08 PM, wrote: > From: Karthik Tummala > > Fixed following checkpatch.pl warning: > WARNING: Prefer using '"%s...", __func__' to using > the function's name, in a string > >

Re: [PATCH 0/5] staging: ccree: fix checkpatch errors

On Mon, Jul 10, 2017 at 12:10 AM, wrote: > From: Tyler Olivieri > > This patchset fixes several checkpatch errors and warnings in /staging/ccree: > > ERROR: that open brace { should be on the previous line > ERROR: open brace '{' following

Re: [PATCH] Stagingdriver cctree: Fix for checkpatch warning

Hello Philip, Thank your patch. Your patch subject line is not descriptive and not formatted well. A better subject would be something like: staging: ccree: move comment to fit coding style Thanks, Gilad On Fri, Jun 30, 2017 at 7:32 AM, wrote: > From: Bincy K

Re: [PATCH 00/10] Fix alignment issues in staging/ccree

On Mon, Jul 3, 2017 at 3:28 PM, Simon Sandström wrote: > On Mon, Jul 03, 2017 at 10:19:31AM +0300, Gilad Ben-Yossef wrote: >> but for the few cases where its a complex expression that can be >> broken down like this one: >> >> WARNING: line over 80 characters >> #93: FILE:

Re: HELP writing crypto driver for HW with blocksize hash

On Tue, Jul 11, 2017 at 1:50 PM, Kamil Konieczny wrote: > On 11.07.2017 12:30, Gilad Ben-Yossef wrote: >> On Tue, Jul 11, 2017 at 10:52 AM, Kamil Konieczny >> wrote: >>> >>> >>> I am writing crypto driver for hash MD5/SHA1/SHA256

Re: HELP writing crypto driver for HW with blocksize hash

On 11.07.2017 12:30, Gilad Ben-Yossef wrote: > On Tue, Jul 11, 2017 at 10:52 AM, Kamil Konieczny > wrote: >> >> >> I am writing crypto driver for hash MD5/SHA1/SHA256 on Exynos 4412, >> and I am facing some (minor?) difficulties. [...] >> So there is no [...]

Re: HELP writing crypto driver for HW with blocksize hash

On Tue, Jul 11, 2017 at 10:52 AM, Kamil Konieczny wrote: > > Hi, > > I am writing crypto driver for hash MD5/SHA1/SHA256 on Exynos 4412, > and I am facing some (minor?) difficulties. > > In old days, hadware (HW) can only do basic hash block operation, > so at the

[PATCH] crypto: brcm - remove BCM_PDC_MBOX dependency in Kconfig

SPU driver is dependent on generic MAILBOX API's to communicate with underlying DMA engine driver. So this patch removes BCM_PDC_MBOX "depends on" for SPU driver in Kconfig and adds MAILBOX as dependent module. Fixes: 9d12ba86f818 ("crypto: brcm - Add Broadcom SPU driver") Signed-off-by:

HELP writing crypto driver for HW with blocksize hash

Hi, I am writing crypto driver for hash MD5/SHA1/SHA256 on Exynos 4412, and I am facing some (minor?) difficulties. In old days, hadware (HW) can only do basic hash block operation, so at the end it needed to finalize hash, and driver need to write some bits into buffer to get message hash. Time

[PATCH 2/2] crypto: hwrng remember rng chosen by user

When a user chooses a rng source via sysfs attribute this rng should be sticky, even when other sources with better quality to register. This patch introduces a simple way to remember the user's choice. This is reflected by a new sysfs attribute file 'rng_selected' which shows if the current rng

[PATCH 1/2] crypto: hwrng use rng source with best quality

This patch rewoks the hwrng to always use the rng source with best entropy quality. On registation and unregistration the hwrng now tries to choose the best (= highest quality value) rng source. The handling of the internal list of registered rng sources is now always sorted by quality and the

Re: [PATCH v3 net-next 3/4] tls: kernel TLS support

Sorry for replying to old mail... On Wed, Jun 14, 2017 at 11:37:39AM -0700, Dave Watson wrote: > +static int tls_do_encryption(struct tls_context *tls_ctx, > + struct tls_sw_context *ctx, size_t data_len, > + gfp_t flags) > +{ > + unsigned int

[PATCH] crypto: caam - free qman_fq after kill_fq

kill_fq removes a complete frame queue, it needs to free the qman_fq in the last. Else kmemleak will report the below warning: unreferenced object 0x800073085c80 (size 128): comm "cryptomgr_test", pid 199, jiffies 4294937850 (age 67.840s) hex dump (first 32 bytes): 00 00 00 00 00 00