On 7/23/2018 8:00 PM, Roy Pledge wrote:
> Convert the Datapath I/O documentation to .rst format
> and move to the Documation/networking/dpaa2 directory
typo: ^^^ Documentation
>
> Signed-off-by: Roy Pledge
> ---
> .../networking/dpaa2/dpio-driver.rst | 30
> ++
On 7/24/2018 5:21 PM, Roy Pledge wrote:
> Move the NXP DPIO (Datapath I/O driver) from the staging/fsl-mc/bus/dpio
> directory to the drivers/soc/fsl directory.
>
> The DPIO driver enables access to the Queue and Buffer Managemer (QBMAN)
> hardware of NXP DPAA2 devices. This is a prerequiste for m
On 11/9/2018 3:11 AM, Marc Gonzalez wrote:
> Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
> enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
> which is not set. Enable FSL_MC_BUS, and build FSL_MC_DPIO and
> CRYPTO_DEV_FSL_DPAA2_CAAM as modules.
>
> Signed-
On 7/5/2018 10:41 PM, Roy Pledge wrote:
> Move the NXP DPIO (Datapath I/O driver) from the staging/fsl-mc/bus/dpio
> directory to the drivers/soc/fsl directory.
>
> The DPIO driver enables access to the Queue and Buffer Managemer (QBMAN)
> hardware of NXP DPAA2 devices. This is a prerequiste for m
On 12/13/2018 9:34 AM, Christophe Leroy wrote:
> [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
> dma_nommu_map_page+0x44/0xd4
> [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
> 4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
> [2.38474
On 12/10/2018 6:50 PM, Ioana Ciornei wrote:
> Automatically add a device link between the actual device requesting the
> dpaa2_io_service_register and the underlying dpaa2_io used. This link
> will ensure that when a DPIO device, which is indirectly used by other
> devices, is unbound any consumer
On 12/15/2018 11:44 PM, Stefan Wahren wrote:
> Hi,
>
>> Olof Johansson hat am 13. Dezember 2018 um 07:48
>> geschrieben:
>>
>>
>> On Fri, Nov 09, 2018 at 06:05:24AM +, Horia Geanta wrote:
>>> On 11/9/2018 3:11 AM, Marc Gonzalez wrote:
>>&g
On 12/20/2018 5:28 PM, Arnd Bergmann wrote:
> On Wed, Dec 19, 2018 at 11:18 AM Horia Geantă wrote:
>>
>> This reverts commit d9678adbe733a770428a98651beaa2817d503ed3.
>>
>> Received below report from Stefan.
>> Revert the commit until CAAM driver dependency cycles are fixed.
>>
>> this patch in ne
On 12/20/2018 5:28 PM, Arnd Bergmann wrote:
> My previous bugfix was incomplete, we still have a broken kernel
> with CRYPTO_DEV_FSL_CAAM=m and CRYPTO_DEV_FSL_DPAA2_CAAM=y:
>
> drivers/crypto/caam/caamalg_desc.o: In function `cnstr_shdsc_aead_null_encap':
> caamalg_desc.c:(.text+0x14): undefined r
On 1/8/2019 8:56 AM, Christophe Leroy wrote:
> This patch moves the mapping of IV after the kmalloc(). This
> avoids having to unmap in case kmalloc() fails.
>
> Signed-off-by: Christophe Leroy
Reviewed-by: Horia Geantă
Since patch 2/2 is Cc-ing stable, this one should do the same.
Herbert, cou
On 1/8/2019 8:56 AM, Christophe Leroy wrote:
> [2.364486] WARNING: CPU: 0 PID: 60 at ./arch/powerpc/include/asm/io.h:837
> dma_nommu_map_page+0x44/0xd4
> [2.373579] CPU: 0 PID: 60 Comm: cryptomgr_test Tainted: GW
> 4.20.0-rc5-00560-g6bfb52e23a00-dirty #531
> [2.384740]
On 12/21/2018 10:07 AM, Christophe Leroy wrote:
[snip]
> IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
> cannot be DMA mapped anymore.
> This looks better, thanks.
> This patch copies the IV into the extended descriptor when iv is not
> a valid linear address.
>
Thoug
On 1/4/2019 5:17 PM, Horia Geanta wrote:
> On 12/21/2018 10:07 AM, Christophe Leroy wrote:
> [snip]
>> IV cannot be on stack when CONFIG_VMAP_STACK is selected because the stack
>> cannot be DMA mapped anymore.
>> This looks better, thanks.
>
>> This patc
On 10/30/2018 10:31 PM, Roy Pledge wrote:
> Starting with v5 of NXP QBMan devices the hardware supports using
> regular cacheable/shareable memory as the backing store for the
> portals.
>
> This patch adds support for the new portal mode by switching to
> use the DPRC get object region v2 command
On 11/7/2018 10:49 PM, Marc Gonzalez wrote:
> [ Add interested parties ]
>
> On 07/11/2018 21:18, Marc Gonzalez wrote:
>
>> Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
>> enabled CRYPTO_DEV_FSL_DPAA2_CAAM, which depends on FSL_MC_DPIO,
>> which is not set.
>>
Thanks Marc
On 11/8/2018 1:23 PM, Horia Geanta wrote:
> On 11/7/2018 10:49 PM, Marc Gonzalez wrote:
>> [ Add interested parties ]
>>
>> On 07/11/2018 21:18, Marc Gonzalez wrote:
>>
>>> Commit e8342cc7954e ("enable CAAM crypto engine on QorIQ DPAA2 SoCs")
>>&
On 11/8/2018 3:23 PM, Marc Gonzalez wrote:
>
>
> On November 8, 2018 12:38:10 PM GMT+01:00, Horia Geanta
> wrote:
>> On 11/8/2018 1:23 PM, Horia Geanta wrote:
>>> On 11/7/2018 10:49 PM, Marc Gonzalez wrote:
>>>> [ Add interested parties ]
>>>
On 8/29/2018 3:31 AM, Scott Wood wrote:
> On Tue, 2018-08-21 at 15:45 -0500, Rob Herring wrote:
>> On Mon, Aug 20, 2018 at 1:52 PM Vabhav Sharma wrote:
>>> +/ {
>>> + model = "NXP Layerscape LX2160ARDB";
>>> + compatible = "fsl,lx2160a-rdb", "fsl,lx2160a";
>>> +
>>> + aliases {
>
.
Signed-off-by: Lei Xu
Signed-off-by: Horia Geanta
---
net/xfrm/xfrm_algo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index debe733386f8..ca21ba7a0716 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -220,7 +220,7
Hi,
I am sending this patch as RFC, since the change is likely to create
interoperability issues.
I'd like to get some comments on what should be the correct approach in this
standard vs. de facto setup.
Note that an older commit (which is no longer in git's history, but can be found
here https:/
(0xFF << BIT_SHIFT)
where "OxFF <<" is considered to be parameter type.
When parsing, we can differentiate beween these two types of macros by
checking whether there is at least one whitespace b/w "#define" and
first opening paranthesis.
Signed-off-by: Horia Gean
On 2/9/2019 8:31 AM, Wen Yang wrote:
> The of_find_device_by_node() takes a reference to the underlying device
> structure, we should release that reference.
>
> Fixes: 35af64038623 ("crypto: caam - Check for CAAM block presence before
> registering with crypto layer")
> Signed-off-by: Wen Yang
On 2/11/2019 2:31 PM, Wen Yang wrote:
> The of_find_device_by_node() takes a reference to the underlying device
> structure, we should release that reference.
>
> Fixes: 35af64038623 ("crypto: caam - Check for CAAM block presence before
> registering with crypto layer")
Fixes: b189817cf789 ("cryp
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 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-cry...@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 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: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:
> 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 2/8/2019 3:51 PM, Iuliana Prodan wrote:
> This patch set adds ecb mode support for aes, des, 3des and arc4 ciphers.
> skcipher implementation is reused, making sure to handle the no IV case.
>
For the series:
Reviewed-by: Horia Geantă
Thanks,
Horia
On 1/22/2019 5:14 PM, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: "Horia Geantă"
> Cc: Aymen Sghaier
> Cc: Herbert Xu
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/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 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/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/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 2/9/2019 11:52 PM, Eric Biggers wrote:
> Do you have an actual use case for adding more DES, 3DES, and ARC4
> implementations, or are you simply adding them because the hardware happens to
> supports it? These old ciphers are insecure, so IMO more implementations
> should
> only be added if th
On 2/13/2019 4:49 PM, Philipp Puschmann wrote:
> When quality is set to 0 this driver is not used as randomness source by
> HWRNG framework at all. So set the quality and finally make this driver
> work. The value of the quality was discussed before
> ( see see https://patchwork.kernel.org/patch/98
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:
> 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 5/21/2019 4:34 PM, Christophe Leroy wrote:
> For decrypt, req->cryptlen includes the size of the authentication
> part while all functions of the driver expect cryptlen to be
> the size of the encrypted data.
>
> As it is not expected to change req->cryptlen, this patch
> implements local calcu
On 5/28/2019 12:52 PM, Iuliana Prodan wrote:
> The problem is with the input data size sent to CAAM for encrypt/decrypt.
> Pkcs1pad is failing due to pkcs1 padding done in SW starting with0x01
> instead of 0x00 0x01.
> CAAM expects an input of modulus size. For this we strip the leading
> zeros in
On 5/31/2019 2:06 PM, Iuliana Prodan wrote:
> Disabled the check and set of 'mem' and 'emi_slow'
> clocks, since these are not available for iMX7ULP.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Thanks,
Horia
On 9/15/2016 5:37 PM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 15 Sep 2016 16:27:23 +0200
>
> Some update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (6):
> Use kmalloc_array() in ahash_setkey()
> Rename jump labels in ahash_
On 10/4/2016 10:33 AM, Marcus Folkesson wrote:
> i.MX6UL does only require three clocks to enable CAAM module.
>
> Signed-off-by: Marcus Folkesson
Reviewed-by: Horia Geantă
Thanks,
Horia
On 10/26/2016 12:29 AM, Arnd Bergmann wrote:
> Building the caam driver on arm64 produces a harmless warning:
>
> drivers/crypto/caam/caamalg.c:140:139: warning: comparison of distinct
> pointer types lacks a cast
>
> We can use min_t to tell the compiler which type we want it to use
> here.
>
On 11/5/2016 1:17 AM, Sven Ebenfeld wrote:
> When using AES-XTS on a Wandboard, we receive a Mode error:
> caam_jr 2102000.jr1: 20001311: CCB: desc idx 19: AES: Mode error.
>
> Due to the Security Reference Manual, the Low Power AES units
s/Due to/According to
> of the i.MX6 do not support the XT
On 9/15/2016 5:43 PM, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Thu, 15 Sep 2016 11:20:09 +0200
>
> * A multiplication for the size determination of a memory allocation
> indicated that an array data structure should be processed.
> Thus use the corresponding function "kmalloc_a
48 matches
Mail list logo
