On 7/10/2015 9:50 PM, scottwood at freescale.com (Scott Wood) wrote:
> On Fri, 2015-07-10 at 13:29 -0500, Pledge Roy-R01356 wrote:
>>> return in_be32((void *)bm + offset);
^
[...]/drivers/soc/fsl/qbman/bman.c: In function ‘__bm_out’:
[...]/drivers/soc/fsl/qbman/bman.c:
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
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
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
> ---
checkpatch complains about formatting, please check.
> drivers/crypto/talitos.c | 33 +
> drivers/crypto/talitos.h |
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
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
On 3/4/2015 2:23 AM, Kim Phillips wrote:
> On Tue, 3 Mar 2015 08:21:37 -0500
> Martin Hicks wrote:
>
>> @@ -1170,6 +1237,8 @@ static struct talitos_edesc
>> *talitos_edesc_alloc(struct device *dev,
>> edesc->dma_len,
>>
On 3/7/2015 3:16 AM, Kim Phillips wrote:
> On Fri, 6 Mar 2015 11:49:43 -0500
> Martin Hicks wrote:
>
>> On Thu, Mar 5, 2015 at 7:16 PM, Kim Phillips
>> wrote:
>>> On Fri, 20 Feb 2015 12:00:10 -0500
>>> Martin Hicks wrote:
>>>
The newer talitos hardware has support for AES in XTS mode.
>>>
On 3/3/2015 7:44 PM, Martin Hicks wrote:
> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
> 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 allow
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
On 3/9/2015 5:08 PM, Martin Hicks wrote:
> On Mon, Mar 9, 2015 at 6:16 AM, Horia Geantă
> wrote:
>> On 3/3/2015 7:44 PM, Martin Hicks wrote:
>>> On Tue, Mar 3, 2015 at 10:44 AM, Horia Geantă
>>> wrote:
>>>>
>>>> For talitos, there are two
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
{aead,ablkcipher_ahash}
On 3/13/2015 4:08 PM, Martin Hicks wrote:
> Hi Horia,
>
> On Wed, Mar 11, 2015 at 11:48 AM, Horia Geantă
> wrote:
>>
>> While here: note that xts-talitos supports only two key lengths - 256
>> and 512 bits. There are tcrypt speed tests that check also for 384-bit
On 3/17/2015 2:19 AM, Kim Phillips wrote:
> On Mon, 16 Mar 2015 12:02:51 +0200
> Horia Geantă 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 pr
On 3/18/2015 12:03 AM, Kim Phillips wrote:
> On Tue, 17 Mar 2015 19:58:55 +0200
> Horia Geantă wrote:
>
>> On 3/17/2015 2:19 AM, Kim Phillips wrote:
>>> On Mon, 16 Mar 2015 12:02:51 +0200
>>> Horia Geantă wrote:
>>>
>>>> On 3/4/2015 2:23 A
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
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 chang
happens now) but could be 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
hould 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
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 i
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
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 incorre
keysize for the
> AEAD size for AES256 + HMAC(SHA512).
>
> Cc: # 3.6+
> Fixes: 357fb60502ede ("crypto: talitos - add sha224, sha384 and sha512 to
> existing AEAD algorithms")
> Signed-off-by: Martin Hicks
Acked-by: Horia Geantă
Thanks,
Horia
Stop.
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
Signed-off-by: Horia Geantă
---
arch/powerpc/Makefile.postlink
On 5/8/2017 2:57 PM, Michael Ellerman wrote:
> Horia Geantă 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/Makefile.postlink:10: include/
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: Loga
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
Cc: Horia Geantă
Cc: Dan Douglass
Cc: Herbert Xu
Cc: "David S. Miller"
Updated patch such that behaviour does
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 fix
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
> ---
> drivers/crypto/talitos.c | 80
> ++
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 mapping/u
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:
&
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().
>>
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() ?
>>>
&
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 addre
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 i
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(&desc->ptr[3], true) == 0)
> talitos_handle_buggy_hash(ctx, edesc, &desc->ptr[3]);
>
> + if (i
ctx.
>
> This patch removes this persistent mapping.
>
> Reported-by: Horia Geanta
> Fixes: 49f9783b0cea ("crypto: talitos - do hw_context DMA mapping outside the
> requests")
> Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on
> SEC1"
or pointer.
>
> Cc: # 4.8+
> Fixes: 549bd8bc5987 ("crypto: talitos - Implement AEAD for SEC1 using
> HMAC_SNOOP_NO_AFEU")
> Reported-by: Horia Geantă
> Signed-off-by: Christophe Leroy
Tested-by: Horia Geantă
Thanks,
Horia
This will allow device drivers to consistently use io{read,write}XX
also for 64-bit accesses.
Signed-off-by: Horia Geantă
---
arch/powerpc/kernel/iomap.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index
This will allow device drivers to consistently use io{read,write}XX
also for 64-bit accesses.
Signed-off-by: Horia Geantă
---
arch/powerpc/kernel/iomap.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/powerpc/kernel/iomap.c b/arch/powerpc/kernel/iomap.c
index
This will allow device drivers to consistently use io{read,write}XX
also for 64-bit accesses.
Acked-by: Michael Ellerman
Signed-off-by: Horia Geantă
---
arch/powerpc/kernel/iomap.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/powerpc/kernel/iomap.c b/arch
41 matches
Mail list logo
