On 10/22/2019 6:30 PM, Andrey Smirnov wrote:
> Use devres to de-initialize the RNG and drop explicit de-initialization
> code in caam_remove().
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vg
On 10/22/2019 6:30 PM, Andrey Smirnov wrote:
> Move the call to devm_of_platform_populate() at the end of
> caam_probe(), so we won't try to add any child devices until all of
> the initialization is finished successfully.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
>
On 10/14/2019 3:19 PM, Ard Biesheuvel wrote:
> Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
> dated 20 august 2015 introduced the new skcipher API which is supposed to
> replace both blkcipher and ablkcipher. While all consumers of the API have
> been converted long a
On 9/26/2019 3:26 PM, Iuliana Prodan wrote:
> The mapped_{src,dst}_nents _returned_ from the dma_map_sg
> call (which could be less than src/dst_nents) have to be
> used to generate the job descriptors.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Thanks,
Horia
On 9/25/2019 4:04 PM, Iuliana Prodan wrote:
> @@ -428,17 +433,18 @@ static int set_rsa_priv_f1_pdb(struct akcipher_request
> *req,
> return -ENOMEM;
> }
>
> - if (edesc->src_nents > 1) {
> + if (edesc->mapped_src_nents > 1) {
> pdb->sgf |= RSA_PRIV_PDB_S
On 9/18/2019 9:01 AM, Andrey Smirnov wrote:
> On Wed, Sep 11, 2019 at 2:35 AM Horia Geanta wrote:
>>
>> On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
>>> In order to allow caam_jr_enqueue() to lock underlying JR's
>>> device (via device_lock(), see commit that
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> @@ -906,6 +900,13 @@ static int caam_probe(struct platform_device *pdev)
> debugfs_create_blob("tdsk", S_IRUSR | S_IRGRP | S_IROTH, ctrlpriv->ctl,
> &ctrlpriv->ctl_tdsk_wrap);
> #endif
> +
> + ret = devm_of_platform_p
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to de-initialize the RNG and drop explicit de-initialization
> code in caam_remove().
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to de-initialize the QI and drop explicit de-initialization
> code in caam_remove().
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger.
On 9/18/2019 6:13 AM, Andrey Smirnov wrote:
>> I think you need to do some form of slow wait loop in jrpriv until
>> jrpriv->tfm_count reaches zero.
> Hmm, what do we do if it never does? Why do you think it would be
> better than cancelling all outstanding jobs and resetting the HW?
>
Herbert,
W
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> In order to allow caam_jr_enqueue() to lock underlying JR's
> device (via device_lock(), see commit that follows) we need to make
> sure that no code calls caam_jr_enqueue() as a part of caam_jr_probe()
> to avoid a deadlock. Unfortunately, current imple
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to de-initialize the RNG and drop explicit de-initialization
> code in caam_remove().
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger
On 9/9/2019 3:52 PM, Herbert Xu wrote:
> On Mon, Sep 09, 2019 at 12:07:17PM +0000, Horia Geanta wrote:
>>
>> Why all?
>> I've ack-ed only 1 and 4.
>>
>> Besides this, patches 11 and/or 12 break the functionality,
>> i.e. driver gets stuck during crypt
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to remove debugfs and drop corresponding
> debugfs_remove_recursive() call.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger.kernel.or
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to unmap memory and drop corresponding iounmap() call.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-ker...@
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Use devres to unmap memory and drop explicit de-initialization
> code.
>
> NOTE: There's no corresponding unmapping code in caam_jr_remove which
> seems like a resource leak.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc
On 9/9/2019 10:53 AM, Herbert Xu wrote:
> On Tue, Sep 03, 2019 at 07:35:03PM -0700, Andrey Smirnov wrote:
>> Everyone:
>>
>> This series bugfixes and small improvement I made while doing more
>> testing of CAAM code:
>>
>> - "crypto: caam - make sure clocks are enabled first"
>>
>>fixes a rece
On 9/9/2019 10:46 AM, Herbert Xu wrote:
> On Tue, Sep 03, 2019 at 07:35:07PM -0700, Andrey Smirnov wrote:
>> With IRQ requesting being managed by devres we need to make sure that
>> we dispose of IRQ mapping after and not before it is free'd (otherwise
>> we'll end up with a warning from the kernel
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> Irq_of_parse_and_map will return zero in case of error, so add a error
> check for that.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Horia Geantă
> Cc: Herbert Xu
> Cc: Iuliana Prodan
> Cc: linux-crypto@vger.kernel.
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> With IRQ requesting being managed by devres we need to make sure that
> we dispose of IRQ mapping after and not before it is free'd (otherwise
> we'll end up with a warning from the kernel). To achieve that simply
> convert IRQ mapping to rely on devres
On 9/4/2019 5:35 AM, Andrey Smirnov wrote:
> In order to access IP block's registers we need to enable appropriate
> clocks first, otherwise we are risking hanging the CPU.
>
> The problem becomes very apparent when trying to use CAAM driver built
> as a kernel module. In that case caam_probe() ge
On 8/31/2019 12:01 AM, Andrey Smirnov wrote:
> Add node for CAAM - Cryptographic Acceleration and Assurance Module.
>
> Signed-off-by: Horia Geantă
> Signed-off-by: Andrey Smirnov
> Cc: Cory Tusar
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Herbert Xu
> Cc: Shawn Guo
> Cc: Iuliana Prodan
> C
On 8/13/2019 9:51 PM, Andrey Smirnov wrote:
> On Tue, Aug 13, 2019 at 6:59 AM Horia Geanta wrote:
>>
>> On 8/12/2019 11:08 PM, Andrey Smirnov wrote:
>>> Everyone:
>>>
>>> Picking up where Chris left off (I chatted with him privately
>>> before
On 8/12/2019 11:08 PM, Andrey Smirnov wrote:
> Everyone:
>
> Picking up where Chris left off (I chatted with him privately
> beforehead), this series adds support for i.MX8MQ to CAAM driver. Just
> like [v1], this series is i.MX8MQ only.
>
> Feedback is welcome!
> Thanks,
> Andrey Smirnov
>
> Ch
On 8/12/2019 10:27 PM, Andrey Smirnov wrote:
> On Mon, Aug 5, 2019 at 1:23 AM Horia Geanta wrote:
>>
>> On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
>>> @@ -603,11 +603,13 @@ static int caam_probe(struct platform_device *pdev)
>>> ret = init_clocks(d
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> i.MX8 SoC still use 32-bit addresses in its CAAM implmentation, so
i.MX8 SoC or i.MX8 mScale?
Looking at the documentation, some i.MX8 parts (for e.g. QM and QXP)
allow for 36-bit addresses.
> change all of the code to be able to handle that.
>
Should
On 7/31/2019 4:06 PM, Iuliana Prodan wrote:
> Added inline helper functions to check authsize and assoclen for
> gcm, rfc4106 and rfc4543.
> Added, also, inline helper function to check key length for AES algorithms.
> These are used in the generic implementation of gcm/rfc4106/rfc4543
> and aes.
On 7/30/2019 1:33 PM, Iuliana Prodan wrote:
> --- a/include/crypto/gcm.h
> +++ b/include/crypto/gcm.h
> @@ -1,8 +1,63 @@
> #ifndef _CRYPTO_GCM_H
> #define _CRYPTO_GCM_H
>
> +#include
> +
This is new in v2 and I missed it initially.
If needed, should be used instead.
Horia
On 7/30/2019 2:06 PM, Iuliana Prodan wrote:
> Update share descriptor for rfc4106 to skip instructions in case
> cryptlen is zero. If no instructions are jumped the DECO hangs and a
> timeout error is thrown.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geanta
Thanks,
Horia
On 7/30/2019 2:03 PM, Iuliana Prodan wrote:
> Based on seqiv, IPsec ESP and rfc4543/rfc4106 the assoclen can be 16 or
> 20 bytes.
>
> From esp4/esp6, assoclen is sizeof IP Header. This includes spi, seq_no
> and extended seq_no, that is 8 or 12 bytes.
> In seqiv, to asscolen is added the IV size (
On 7/30/2019 1:33 PM, Iuliana Prodan wrote:
> Add inline helper function to check key length for AES algorithms.
> The key can be 128, 192 or 256 bits size.
> This function is used in the generic aes implementation.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Thanks,
Horia
On 7/30/2019 1:33 PM, Iuliana Prodan wrote:
> Added inline helper functions to check authsize and assoclen for
> gcm, rfc4106 and rfc4543.
> These are used in the generic implementation of gcm, rfc4106 and
> rfc4543.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Thanks,
Horia
On 7/28/2019 11:50 PM, Richard Weinberger wrote:
> - Ursprüngliche Mail -
>> Right now we're evaluating two options:
>> -reworking v5 above
>> -using crypto engine (crypto/crypto_engine.c)
>>
>> Ideally crypto engine should be the way to go.
>> However we need to make sure performance degra
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> Since 32-bit of both wr_reg64 and rd_reg64 now use 64-bit IO helpers,
> these functions should no longer be necessary. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Thanks,
Horia
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> Following the same transformation logic as outlined in previous commit
> converting wr_reg64, convert rd_reg64 to use helpers from
> first. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
Thanks,
Horia
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> In order to be able to unify 64 and 32 bit implementations of
> wr_reg64, let's convert it to use helpers from
> first. Here are the steps of the
> transformation:
>
> 1. Inline wr_reg32 helpers:
>
> if (!caam_imx && caam_little_end) {
>
On 7/26/2019 6:55 PM, Pascal Van Leeuwen wrote:
> Hi,
>
> I recently watched some patches fly by fixing issues in other drivers
> regarding the checking
> of supposedly illegal AAD sizes - i.e. to match the generic implementation
> there.
> I followed that with some interest as I'm about to impl
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> Check the return value of the hardware registration for caam_rng and free
> resources in case of failure.
>
> Fixes: e24f7c9 ("crypto: caam - hwrng support")
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
but please use at least 12 charac
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> @@ -892,24 +895,26 @@ void cnstr_shdsc_rfc4106_encap(u32 * const desc, struct
> alginfo *cdata,
> append_math_sub_imm_u32(desc, VARSEQINLEN, REG3, IMM, ivsize);
> append_math_add(desc, VARSEQOUTLEN, ZERO, REG3, CAAM_CMD_SZ);
>
> - /*
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> Check assoclen to solve the extra tests that expect -EINVAL to be
> returned when the associated data size is not valid.
>
> Validated assoclen for RFC4106 and RFC4543 which expects an assoclen
> of 16 or 20.
> Based on seqiv, IPsec ESP and RFC4543/RFC
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> Check authsize to solve the extra tests that expect -EINVAL to be
> returned when the authentication tag size is not valid.
>
> Validated authsize for GCM, RFC4106 and RFC4543.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Thanks,
Hor
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> Check key length to solve the extra tests that expect -EINVAL to be
> returned when the key size is not valid.
>
> Validated AES keylen for skcipher, ahash and aead.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Thanks,
Horia
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> From: Horia Geantă
>
> Fuzz testing uncovered an issue when |user key| > |derived key|.
> Derived key generation has to be fixed in two cases:
>
> 1. Era >= 6 (DKP is available)
> DKP cannot be used with immediate input key if |user key| > |derived k
On 7/25/2019 4:58 PM, Iuliana Prodan wrote:
> From: Horia Geantă
>
> skcipher encryption might fail and in some cases, like (invalid) input
> length smaller then block size, updating the IV would lead to panic
> due to copying from a negative offset (req->cryptlen - ivsize).
>
In v1 I mentioned
On 7/25/2019 4:47 PM, Iuliana Prodan wrote:
> Added inline helper functions to check authsize and assoclen for
> gcm and rfc4106.
Also rfc4543.
> diff --git a/include/crypto/gcm.h b/include/crypto/gcm.h
> index c50e057..9834b97 100644
> --- a/include/crypto/gcm.h
> +++ b/include/crypto/gcm.h
> @@
On 7/25/2019 4:47 PM, Iuliana Prodan wrote:
> Add inline helper function to check key length for AES algorithms.
> The key can be 128, 192 or 256 bits size.
> This function is used in the generic aes and aes_ti implementations.
>
Looks good.
Will need to respin it, since aes has just been refactor
On 7/25/2019 12:22 AM, Richard Weinberger wrote:
> Hi!
>
> Recently I had the pleasure to debug a lockup on a imx6 based platform.
> It turned out that the lockup was caused by the CAAM driver because it
> just returns -EBUSY upon a full job ring.
>
> Then I found commits:
> 0618764cb25f ("dm cry
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> In order to avoid any risk of JR IRQ request being handled while some
> of the resources used for that are not yet allocated move the code
> requesting said IRQ to the endo of caam_jr_init(). No functional
^ typo
> change in
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> Use deveres to allocate all of the resources in caam_jr_init() (DMA
> coherent and regular memory, IRQs) drop calls to corresponding
> deallocation routines. No functional change intended.
>
> Signed-off-by: Andrey Smirnov
Reviewed-by: Horia Geantă
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> Simplify clock initialization code by converting it to use clk-bulk,
> devres and soc_device_match() match table. No functional change
> intended.
>
Thanks.
Two nitpicks below.
> +static int init_clocks(struct device *dev,
> +struc
On 7/23/2019 12:14 PM, Vakul Garg wrote:
> Add support of printing the dpseci frame queue statistics using debugfs.
>
> Signed-off-by: Vakul Garg
Reviewed-by: Horia Geantă
Thanks,
Horia
On 7/17/2019 6:25 PM, Andrey Smirnov wrote:
> In order to be able to configure CAAM pointer size at run-time, which
> needed to support i.MX8MQ, which is 64-bit SoC with 32-bit pointer
> size, convert CAAM_PTR_SZ to refer to a global variable of the same
> name ("caam_ptr_sz") and adjust the rest o
On 7/23/2019 11:42 AM, Vakul Garg wrote:
> diff --git a/drivers/crypto/caam/dpseci-debugfs.c
> b/drivers/crypto/caam/dpseci-debugfs.c
> new file mode 100644
> index ..2e43ba9b7491
> --- /dev/null
> +++ b/drivers/crypto/caam/dpseci-debugfs.c
> @@ -0,0 +1,80 @@
> +/* SPDX-License-Identif
On 7/23/2019 4:20 AM, Vakul Garg wrote:
>>> @@ -64,6 +65,7 @@ struct dpaa2_caam_priv {
>>> struct iommu_domain *domain;
>>>
>>> struct dpaa2_caam_priv_per_cpu __percpu *ppriv;
>>> + struct dentry *dfs_root;
>> dfs_root is used only in dpseci-debugfs.c, let's have it there as global.
>>
>
On 7/22/2019 5:29 PM, Vakul Garg wrote:
>> -Original Message-
>> From: Horia Geanta
>> Sent: Monday, July 22, 2019 7:55 PM
>> To: Vakul Garg ; linux-crypto@vger.kernel.org
>> Cc: Aymen Sghaier ;
>> herb...@gondor.apana.org.au
>> Subject: Re:
On 7/19/2019 2:23 PM, Vakul Garg wrote:
[...]
> +if CRYPTO_DEV_FSL_DPAA2_CAAM
> +
> +config CRYPTO_DEV_FSL_DPAA2_CAAM_DEBUGFS
> + depends on DEBUG_FS
> + bool "Enable debugfs support"
> + help
> + Selecting this will enable printing of various debug information
> + in the
On 7/18/2019 5:49 PM, Iuliana Prodan wrote:
> Moved to a common location the symbols shared by all CAAM drivers (jr,
> qi, qi2).
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
> ---
> This patch depends on series:
> https://patchwork.kernel.org/project/linux-crypto/list/?series=147
On 7/18/2019 2:29 PM, Vakul Garg wrote:
> While running ipsec processing for traffic through multiple network
> interfaces, it is observed that caam driver gets less time to poll
> responses from caam block compared to ethernet driver. This is because
> ethernet driver has as many napi instances pe
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> To be consistent with other CAAM modules, caamhash should return 0
> instead of -ENODEV in case CAAM has no MDHA.
>
> Based on commit 1b46c90c8e00 ("crypto: caam - convert top level drivers to
> libraries")
> the value returned by entry point is never
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> To know if a registration succeeded added a new struct,
> caam_akcipher_alg, that keeps, also, the registration status.
> This status is updated in caam_pkc_init and verified in
> caam_pkc_exit to unregister an algorithm.
>
Fixes: 1b46c90c8e00 ("crypto
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Commit 1b46c90c8e00 ("crypto: caam - convert top level drivers to libraries")
> changed entry and exit points behavior for caamalg,
> caamalg_qi, caamalg_qi2, caamhash, caampkc, caamrng.
>
> For example, previously caam_pkc_init() and caam_pkc_exit() w
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Check the return value of the hardware registration for caam_rng and free
> resources in case of failure.
>
> Fixes: 6e4e603a9 ("crypto: caam - Dynamic memory allocation for caam_rng_ctx
> object")
This should be:
Fixes: e24f7c9e87d4 ("crypto: caam -
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Update share descriptor for rfc4106 to skip instructions in case
> cryptlen is zero. If no instructions are jumped the DECO hangs and a
> timeout error is thrown.
>
> Signed-off-by: Iuliana Prodan
> ---
> drivers/crypto/caam/caamalg_desc.c | 46
> ++
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Check zero-length input, for skcipher algorithm, to solve the extra
> tests. This is a valid operation, therefore the API will return no error.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Horia
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
[...]
> --- a/drivers/crypto/caam/common_if.c
> +++ b/drivers/crypto/caam/common_if.c
> @@ -66,6 +66,23 @@ int check_rfc4106_authsize(unsigned int authsize)
> }
> EXPORT_SYMBOL(check_rfc4106_authsize);
>
> +/*
> + * validate assoclen for RFC4106/RFC45
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
[...]
> diff --git a/drivers/crypto/caam/caamalg_qi.c
> b/drivers/crypto/caam/caamalg_qi.c
> index 46097e3..5f9b14a 100644
> --- a/drivers/crypto/caam/caamalg_qi.c
> +++ b/drivers/crypto/caam/caamalg_qi.c
> @@ -18,6 +18,7 @@
> #include "qi.h"
> #includ
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Check key length to solve the extra tests that expect -EINVAL to be
> returned when the key size is not valid.
>
> Validated AES keylen for skcipher and ahash.
>
Also aead was updated.
> The check_aes_keylen function is added in a common file, to be
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> From: Horia Geantă
>
> Update alginfo struct to keep both virtual and dma key addresses,
> so that descriptors have them at hand.
> One example where this is needed is in the xcbc(aes) shared descriptors,
> which are updated in current patch.
> Anothe
On 7/18/2019 5:45 PM, Iuliana Prodan wrote:
> From: Horia Geantă
>
> skcipher encryption might fail and in some cases, like (invalid) input
> length smaller then block size, updating the IV would lead to panic
> due to copying from a negative offset (req->cryptlen - ivsize).
>
The commit message
Hi,
With fuzz testing enabled, I am seeing xts(aes) failures on caam drivers.
Below are several failures, extracted from different runs:
[3.921654] alg: skcipher: xts-aes-caam encryption unexpectedly succeeded on
test vector "random: len=40 klen=64"; expected_error=-22, cfg="random: inplace
On 7/10/2019 1:13 PM, Vakul Garg wrote:
> Add support of printing the dpseci frame queue statistics using debugfs.
>
Please move this into a separate file, that gets compiled only if
CONFIG_DEBUG_FS=y.
Function(s) that are needed outside this file should be called unconditionally
and should have
On 7/4/2019 2:45 AM, Leonard Crestez wrote:
> On 7/3/2019 8:14 PM, Andrey Smirnov wrote:
>> On Wed, Jul 3, 2019 at 6:51 AM Leonard Crestez
>> wrote:
>>> On 7/3/2019 11:14 AM, Andrey Smirnov wrote:
Move tasklet_init() call further down in order to simplify error path
cleanup. No function
On 7/3/2019 11:14 AM, Andrey Smirnov wrote:
> Use devres to allocate 'outring' and drop corresponding call to
> dma_free_coherent() as well as extra references to 'struct
> jr_outentry' (needed in following commits). No functional change
> inteded.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Sp
On 7/3/2019 7:27 PM, Fuqian Huang wrote:
> kmemdup is introduced to duplicate a region of memory in a neat way.
> Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
> write the size twice (sometimes lead to mistakes), kmemdup improves
> readability, leads to smaller code and also r
On 6/28/2019 12:35 PM, Ard Biesheuvel wrote:
> Signed-off-by: Ard Biesheuvel
Tested-by: Horia Geantă
Thanks,
Horia
On 6/27/2019 5:54 PM, Ard Biesheuvel wrote:
> On Thu, 27 Jun 2019 at 16:50, Ard Biesheuvel
> wrote:
>>
>> On Thu, 27 Jun 2019 at 16:44, Horia Geanta wrote:
>>>
>>> On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
>>>> n my effort to remove crypto_allo
On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
> n my effort to remove crypto_alloc_cipher() invocations from non-crypto
> code, i ran into a DES call in the CIFS driver. This is addressed in
> patch #30.
>
> The other patches are cleanups for the quirky DES interface, and lots
> of duplication of th
On 6/27/2019 3:03 PM, Ard Biesheuvel wrote:
> @@ -785,20 +781,23 @@ static int skcipher_setkey(struct crypto_skcipher
> *skcipher, const u8 *key,
> static int des_skcipher_setkey(struct crypto_skcipher *skcipher,
> const u8 *key, unsigned int keylen)
> {
> - u32
On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> Exactly the same code to figure out DMA mask is repeated twice in the
> driver code. To avoid repetition, move that logic into a standalone
> subroutine in intern.h. While at it re-shuffle the code to make it
> more readable with early returns.
>
> Sig
On 6/22/2019 3:32 AM, Ard Biesheuvel wrote:
> Signed-off-by: Ard Biesheuvel
> ---
> drivers/crypto/caam/caamalg.c | 13 +++
> drivers/crypto/caam/caamalg_qi.c | 23 ++--
> drivers/crypto/caam/caamalg_qi2.c | 23 ++--
> drivers/crypto/caam/compat.h
On 6/27/2019 12:12 PM, Ard Biesheuvel wrote:
> On Thu, 27 Jun 2019 at 11:10, Horia Geanta wrote:
>>
>> (changed subject to make patchwork happy
>> was: [RFC PATCH 27/30] crypto: des - split off DES library from generic DES
>> cipher driver)
>>
>> On
On 6/22/2019 3:31 AM, Ard Biesheuvel wrote:
> Signed-off-by: Ard Biesheuvel
> ---
> drivers/crypto/bcm/cipher.c | 82 +---
> drivers/crypto/caam/caamalg.c | 31
> 2 files changed, 37 insertions(+), 76 deletions(-)
>
Typo: caam changes should be part of next patch (06/3
(changed subject to make patchwork happy
was: [RFC PATCH 27/30] crypto: des - split off DES library from generic DES
cipher driver)
On 6/22/2019 3:32 AM, Ard Biesheuvel wrote:
> diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
> index 3720ddabb507..4a358391b6cb 100644
> ---
On 6/13/2019 3:48 PM, Christophe Leroy wrote:
> @@ -336,15 +336,18 @@ static void flush_channel(struct device *dev, int ch,
> int error, int reset_ch)
> tail = priv->chan[ch].tail;
> while (priv->chan[ch].fifo[tail].desc) {
> __be32 hdr;
> + struct talitos_ede
On 6/13/2019 3:48 PM, Christophe Leroy wrote:
> On SEC1, hash provides wrong result when performing hashing in several
> steps with input data SG list has more than one element. This was
> detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
>
> [ 44.185947] alg: hash: md5-talitos test failed (wrong
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> Next patch will require struct talitos_edesc to be defined
> earlier in talitos.c
>
> This patch moves it into talitos.h so that it can be used
> from any place in talitos.c
>
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahas
On 6/13/2019 3:16 PM, Christophe Leroy wrote:
>
>
> Le 13/06/2019 à 14:13, Horia Geanta a écrit :
>> On 6/11/2019 5:39 PM, Christophe Leroy wrote:
>>> Next patch will require struct talitos_edesc to be defined
>>> earlier in talitos.c
>>>
>>> T
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> icv_ool is not used anymore, drop it.
>
> Fixes: 9cc87bc3613b ("crypto: talitos - fix AEAD processing")
I can't find this SHA1.
Are you referring to commit e345177ded17 ("crypto: talitos - fix AEAD
processing.")?
Horia
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> When building for SEC1 only, talitos2_done functions are unneeded
> and should go away.
>
> For this, use has_ftr_sec1() which will always return true when only
> SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
>
> Signed-off-b
On 6/13/2019 3:32 PM, Christophe Leroy wrote:
>
>
> Le 13/06/2019 à 14:24, Horia Geanta a écrit :
>> On 6/13/2019 3:16 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 13/06/2019 à 14:13, Horia Geanta a écrit :
>>>> On 6/11/2019 5:39 PM, Christ
On 6/12/2019 8:52 AM, Christophe Leroy wrote:
>
>
> Le 11/06/2019 à 18:30, Horia Geanta a écrit :
>> On 6/11/2019 6:40 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 11/06/2019 à 17:37, Horia Geanta a écrit :
>>>> On 6/11/2019 5:39 PM, Christ
On 6/12/2019 8:49 AM, Christophe Leroy wrote:
> Below commit came with a typo in the CONFIG_ symbol, leading
> to a permanently reduced max key size regarless of the driver
> capabilities.
>
> Reported-by: Horia Geantă
> Fixes: b8fbdc2bc4e7 ("crypto: talitos - reduce max key size for SEC1")
> Sig
On 6/12/2019 4:06 PM, Shawn Guo wrote:
> On Wed, Jun 12, 2019 at 11:45:18AM +0000, Horia Geanta wrote:
>> On 6/12/2019 1:40 PM, Shawn Guo wrote:
>>> On Thu, Jun 06, 2019 at 11:02:55AM +0300, Horia Geantă wrote:
>>>> From: Iuliana Prodan
>>>>
>>&g
On 6/12/2019 1:40 PM, Shawn Guo wrote:
> On Thu, Jun 06, 2019 at 11:02:55AM +0300, Horia Geantă wrote:
>> From: Iuliana Prodan
>>
>> Add crypto node in device tree for CAAM support.
>>
>> Noteworthy is that on 7ulp the interrupt line is shared
>> between the two job rings.
>>
>> Signed-off-by: Iul
On 6/12/2019 12:40 PM, Sascha Hauer wrote:
> Hi Horia,
>
> On Wed, May 15, 2019 at 01:35:16PM +0000, Horia Geanta wrote:
>> For talitos, the problem is the lack of IV update.
>>
>> For caam, the problem is incorrect IV update (output IV is equal to last
>> cipher
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
>
>
> Le 11/06/2019 à 17:37, Horia Geanta a écrit :
>> On 6/11/2019 5:39 PM, Christophe Leroy wrote:
>>> This series is the last set of fixes for the Talitos driver.
>>>
>>> We now get a fully clean boot on
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> This series is the last set of fixes for the Talitos driver.
>
> We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
> SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
>
I am getting below failures on a sec 3.3.2 (p102
On 6/11/2019 3:38 PM, Christophe Leroy wrote:
>
>
> Le 11/06/2019 à 13:57, Horia Geanta a écrit :
>> On 6/6/2019 2:31 PM, Christophe Leroy wrote:
>>> Next patch will require struct talitos_edesc to be defined
>>> earlier in talitos.c
>>>
>>> T
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
> This series is the last set of fixes for the Talitos driver.
>
> We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
> SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
>
I get failures, probably due to patch 1/5:
alg:
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
> Next patch will require struct talitos_edesc to be defined
> earlier in talitos.c
>
> This patch moves it into talitos.h so that it can be used
> from any place in talitos.c
>
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash
1 - 100 of 286 matches
Mail list logo
