Re: [PATCH v2 net-next 3/3] crypto: caam: Replace in_irq() usage.

be scheduled. > > Signed-off-by: Sebastian Andrzej Siewior > Cc: "Horia Geantă" > Cc: Aymen Sghaier > Cc: Herbert Xu > Cc: "David S. Miller" > Cc: Madalin Bucur > Cc: Jakub Kicinski > Cc: Li Yang > Cc: linux-cry...@vger.kernel.org >

Re: [PATCH v2 net-next 1/3] soc/fsl/qbman: Add an argument to signal if NAPI processing is required.

changed if it is wrong > due to `budget' handling. > Looks good to me. > Add an argument to __poll_portal_fast() which is true if NAPI needs to be > scheduled. This requires propagating the value to the caller including > `qman_cb_dqrr' typedef which is used by the dpaa and

Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero

On 8/10/2020 8:03 PM, Eric Biggers wrote: > On Mon, Aug 10, 2020 at 05:33:39PM +0300, Horia Geantă wrote: >> On 8/10/2020 4:45 PM, Herbert Xu wrote: >>> On Mon, Aug 10, 2020 at 10:20:20AM +, Van Leeuwen, Pascal wrote: >>>> >>>> With all due respect

Re: [PATCH 19/22] crypto: inside-secure - add check for xts input length equal to zero

On 8/10/2020 4:45 PM, Herbert Xu wrote: > On Mon, Aug 10, 2020 at 10:20:20AM +, Van Leeuwen, Pascal wrote: >> >> With all due respect, but this makes no sense. > > I agree. This is a lot of churn for no gain. > I would say the gain is that all skcipher algorithms would behave the same when

[PATCH] powerpc/dts/fsl: add crypto node alias for B4

crypto node alias is needed by U-boot to identify the node and perform fix-ups, like adding "fsl,sec-era" property. Signed-off-by: Horia Geantă --- arch/powerpc/boot/dts/fsl/b4qds.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/boot/dts/fsl/b4qds.dtsi b/arch/po

[PATCH] soc: fsl: guts: make fsl_guts_get_svr() static

The export of fsl_guts_get_svr() is a left-over, it's currently used only internally and users needing SoC information should use the generic soc_device infrastructure. Signed-off-by: Horia Geantă --- drivers/soc/fsl/guts.c | 3 +-- include/linux/fsl/guts.h | 2 -- 2 files changed, 1

Re: [PATCH v2] crypto: talitos - fix IPsec cipher in length

or pointer. > > Cc: <sta...@vger.kernel.org> # 4.8+ > Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using > HMAC_SNOOP_NO_AFEU") > Reported-by: Horia Geantă <horia.gea...@nxp.com> > Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr> Tested-by: Horia Geantă <horia.gea...@nxp.com> Thanks, Horia

Re: [PATCH 1/2] crypto: talitos - don't persistently map req_ctx->hw_context and req_ctx->buf

data for ahash on > SEC1") > Signed-off-by: Christophe Leroy <christophe.le...@c-s.fr> Tested-by: Horia Geantă <horia.gea...@nxp.com> Please add this to 4.15.y -stable tree. Thanks, Horia

Re: [PATCH 17/18] crypto: talitos - chain in buffered data for ahash on SEC1

On 10/6/2017 4:05 PM, Christophe Leroy wrote: [...] > @@ -1778,6 +1814,36 @@ static int common_nonsnoop_hash(struct talitos_edesc > *edesc, > if (is_sec1 && from_talitos_ptr_len(>ptr[3], true) == 0) > talitos_handle_buggy_hash(ctx, edesc, >ptr[3]); > > + if (is_sec1 &&

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

On 2/22/2018 1:47 PM, Herbert Xu wrote: > On Tue, Feb 20, 2018 at 11:32:25AM +0000, Horia Geantă wrote: >> >> If final/finup is optional, how is the final hash supposed to be retrieved? > > Sometimes the computation ends with a partial hash, that's what > export is for

Re: [PATCH 4.14, 4.9] crypto: talitos - fix Kernel Oops on hashing an empty file

On 2/22/2018 9:08 AM, Christophe Leroy wrote: > Upstream 87a81dce53b1ea61acaeefa5191a0376a2d1d721 > > Performing the hash of an empty file leads to a kernel Oops > > [ 44.504600] Unable to handle kernel paging request for data at address > 0x000c > [ 44.512819] Faulting instruction

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

On 2/20/2018 12:34 PM, Herbert Xu wrote: > On Mon, Feb 19, 2018 at 01:16:30PM +0000, Horia Geantă wrote: >> >>> And what about ALGIF path from user space ? >>> What if the user never calls the last sendmsg() which will call >>> hash_finup() ? >>

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

On 2/19/2018 11:14 AM, Christophe LEROY wrote: > Le 19/02/2018 à 09:30, Horia Geantă a écrit : >> On 2/19/2018 9:58 AM, Christophe LEROY wrote: >>> Le 18/02/2018 à 18:14, Horia Geantă a écrit : >>>> There is no ahash_exit() callback mirroring ahash_init(). >>

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

On 2/19/2018 9:58 AM, Christophe LEROY wrote: > Le 18/02/2018 à 18:14, Horia Geantă a écrit : >> There is no ahash_exit() callback mirroring ahash_init(). >> >> The clean-up of request ctx should be done in the last states of the hash >> flows >> described here: &

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

On 2/17/2018 6:32 PM, Christophe LEROY wrote: > > > Le 07/02/2018 à 15:39, Horia Geantă a écrit : >> On 10/6/2017 4:06 PM, Christophe Leroy wrote: >>> At every request, we map and unmap the same hash hw_context. >>> >>> This patch moves the dma

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

On 10/6/2017 4:06 PM, Christophe Leroy wrote: > At every request, we map and unmap the same hash hw_context. > > This patch moves the dma mapping/unmapping in functions ahash_init() > and ahash_import(). > > Signed-off-by: Christophe Leroy > --- >

Re: [PATCH 00/18] crypto: talitos - fixes and performance improvement

On 10/12/2017 6:20 PM, Herbert Xu wrote: > On Fri, Oct 06, 2017 at 03:04:31PM +0200, Christophe Leroy wrote: >> This serie fixes and improves the talitos crypto driver. >> >> First 6 patchs are fixes of failures reported by the new tests in the >> kernel crypto test manager. >> Looks like these

[PATCH v2 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

Now that ioread64 and iowrite64 are always available we don't need the ugly ifdefs to change their implementation when they are not. Signed-off-by: Logan Gunthorpe <log...@deltatee.com> Cc: Horia Geantă <horia.gea...@nxp.com> Cc: Dan Douglass <dan.dougl...@nxp.com> Cc

Re: [PATCH 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

return ((u64)rd_reg32((u32 __iomem *)(reg)) << 32 | - (u64)rd_reg32((u32 __iomem *)(reg) + 1)); + return ioread64be(reg); } -#endif /* CONFIG_64BIT */ #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT #ifdef CONFIG_SOC_IMX7D > Signed-off-by: Logan Gunth

Re: [PATCH] powerpc: fix distclean with Makefile.postlink

On 5/8/2017 2:57 PM, Michael Ellerman wrote: > Horia Geantă <horia.gea...@nxp.com> writes: > >> Makefile.postlink always includes include/config/auto.conf, however >> this file is not present in a clean kernel tree, causing make to fail: >> >> arch/powerpc/

[PATCH] powerpc: fix distclean with Makefile.postlink

. make: *** [vmlinuxclean] Error 2 Change the inclusion such that file not being found does not trigger an error. Fixes: f188d0524d7e ("powerpc: Use the new post-link pass to check relocations") Reported-by: Mircea Pop <mircea@nxp.com> Signed-off-by: Horia Geantă <h

Re: [PATCH v2] crypto: talitos: Extend max key length for SHA384/512-HMAC and AEAD

or the > AEAD size for AES256 + HMAC(SHA512). > > Cc: <sta...@vger.kernel.org> # 3.6+ > Fixes: 357fb60502ede ("crypto: talitos - add sha224, sha384 and sha512 to > existing AEAD algorithms") > Signed-off-by: Martin Hicks <m...@bork.org> Acked-by: Horia Geantă <horia.gea...@nxp.com> Thanks, Horia

Re: [PATCH] crypto: talitos: Extend max key length for SHA384/512-HMAC

On 4/27/2017 6:46 PM, Martin Hicks wrote: > > The max keysize for both of these is 128, not 96. Before, with keysizes > over 96, the memcpy in ahash_setkey() would overwrite memory beyond the > key field. > While here, what about aead_setkey()? AFAICT, TALITOS_MAX_KEY_SIZE value has been

[PATCH v3 4/8] powerpc: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Acked-by: Michael Ellerman <m...@ellerman.id.au> Signed-off-by: Horia Geantă <horia.gea...@nxp.com> --- arch/powerpc/kernel/iomap.c | 24 1 file changed, 24 inserti

[PATCH v2 4/8] powerpc: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Signed-off-by: Horia Geantă <horia.gea...@nxp.com> --- arch/powerpc/kernel/iomap.c | 24 1 file changed, 24 insertions(+) diff --git a/arch/powerpc/kernel/iomap.c

[PATCH 3/7] powerpc: add io{read,write}64 accessors

This will allow device drivers to consistently use io{read,write}XX also for 64-bit accesses. Signed-off-by: Horia Geantă <horia.gea...@nxp.com> --- arch/powerpc/kernel/iomap.c | 24 1 file changed, 24 insertions(+) diff --git a/arch/powerpc/kernel/iomap.c

Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling

On 3/18/2015 12:03 AM, Kim Phillips wrote: On Tue, 17 Mar 2015 19:58:55 +0200 Horia Geantă horia.gea...@freescale.com wrote: On 3/17/2015 2:19 AM, Kim Phillips wrote: On Mon, 16 Mar 2015 12:02:51 +0200 Horia Geantă horia.gea...@freescale.com wrote: On 3/4/2015 2:23 AM, Kim Phillips wrote

Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling

On 3/17/2015 2:19 AM, Kim Phillips wrote: On Mon, 16 Mar 2015 12:02:51 +0200 Horia Geantă horia.gea...@freescale.com wrote: On 3/4/2015 2:23 AM, Kim Phillips wrote: Only potential problem is getting the crypto API to set the GFP_DMA flag in the allocation request, but presumably

Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling

On 3/4/2015 2:23 AM, Kim Phillips wrote: Only potential problem is getting the crypto API to set the GFP_DMA flag in the allocation request, but presumably a CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that. Seems there are quite a few places that do not use the

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

On 3/9/2015 5:08 PM, Martin Hicks wrote: On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă horia.gea...@freescale.com wrote: On 3/3/2015 7:44 PM, Martin Hicks wrote: On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă horia.gea...@freescale.com wrote: For talitos, there are two cases: 1. request

Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling

On 3/6/2015 6:48 AM, Herbert Xu wrote: On Thu, Mar 05, 2015 at 11:35:23AM +0200, Horia Geantă wrote: Only potential problem is getting the crypto API to set the GFP_DMA flag in the allocation request, but presumably a CRYPTO_TFM_REQ_DMA crt_flag can be made to handle that. Right

Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support

On 3/7/2015 3:16 AM, Kim Phillips wrote: On Fri, 6 Mar 2015 11:49:43 -0500 Martin Hicks m...@bork.org wrote: On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips kim.phill...@freescale.com wrote: On Fri, 20 Feb 2015 12:00:10 -0500 Martin Hicks m...@bork.org wrote: The newer talitos hardware has

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

On 3/3/2015 7:44 PM, Martin Hicks wrote: On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă horia.gea...@freescale.com wrote: On 3/3/2015 12:09 AM, Martin Hicks wrote: On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote: If crypto API allows to encrypt more sectors in one run (handling

Re: [PATCH v2 5/5] crypto: talitos: Add software backlog queue handling

On 3/4/2015 2:23 AM, Kim Phillips wrote: On Tue, 3 Mar 2015 08:21:37 -0500 Martin Hicks m...@bork.org wrote: @@ -1170,6 +1237,8 @@ static struct talitos_edesc *talitos_edesc_alloc(struct device *dev, edesc-dma_len,

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

On 3/3/2015 12:09 AM, Martin Hicks wrote: On Mon, Mar 02, 2015 at 03:37:28PM +0100, Milan Broz wrote: If crypto API allows to encrypt more sectors in one run (handling IV internally) dmcrypt can be modified of course. But do not forget we can use another IV (not only sequential number)

Re: [PATCH 0/2] crypto: talitos: Add AES-XTS mode

On 2/20/2015 7:00 PM, Martin Hicks wrote: This adds the AES-XTS mode, supported by the Freescale SEC 3.3.2. One of the nice things about this hardware is that it knows how to deal with encrypt/decrypt requests that are larger than sector size, but that also requires that that the sector

Re: [PATCH 2/5] crypto: talitos: Remove MD5_BLOCK_SIZE

On 2/20/2015 6:21 PM, Martin Hicks wrote: This is properly defined in the md5 header file. --- Signed-off-by tag is missing. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 2/2] crypto: talitos: Add AES-XTS Support

On 2/20/2015 7:00 PM, Martin Hicks wrote: The newer talitos hardware has support for AES in XTS mode. Signed-off-by: Martin Hicks m...@bork.org --- checkpatch complains about formatting, please check. drivers/crypto/talitos.c | 33 +

Re: [PATCH 5/5] crypto: talitos: Add software backlog queue handling

On 2/20/2015 6:21 PM, Martin Hicks wrote: I was running into situations where the hardware FIFO was filling up, and the code was returning EAGAIN to dm-crypt and just dropping the submitted crypto request. This adds support in talitos for a software backlog queue. When requests can't be