This patch changes mtk_aes_handle_queue() to make it more generic.
The function argument is now a pointer to struct crypto_async_request,
which is the common base of struct ablkcipher_request and
struct aead_request.
Also this patch introduces struct mtk_aes_base_ctx which will be the
common base
This patch adds support to the CTR mode.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 151 --
1 file changed, 146 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/mediatek/mtk-aes.c
b/drivers/crypto/mediatek/mtk-aes.c
index 5e7c3
This patch moves hardware control block members from
mtk_*_rec to transformation context and refines related
definition. This makes operational context to manage its
own control information easily for each DMA transfer.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 144 ++
Hi,
This series of patches is a global rework of the mtk driver.
Fix bug - incomplete DMA data transfer when SG buffer dst.len != src.len
It also updates some part of the code to make them more generic. For
instance the crypto request queue management supports both async block
cipher and AEAD req
This patch introduces a new callback 'resume' in the struct mtk_aes_rec.
This callback is run to resume/complete the processing of the crypto
request when woken up by AES interrupts when DMA completion.
This callback will help implementing the GCM mode support in further
patches.
Signed-off-by: R
This patch adds support to the GCM mode.
Signed-off-by: Ryder Lee
---
drivers/crypto/Kconfig | 2 +
drivers/crypto/mediatek/mtk-aes.c | 369 -
drivers/crypto/mediatek/mtk-platform.h | 2 +
3 files changed, 369 insertions(+), 4 deletions(-)
Dummy patch to fix typo and indentation.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 90 +-
drivers/crypto/mediatek/mtk-platform.h | 2 +-
drivers/crypto/mediatek/mtk-sha.c | 40 +++
3 files changed, 63 insertions(+), 69
This patch fixes mtk_aes_xmit() data transfer bug.
The original function uses the same loop and ring->pos
to handle both command and result descriptors. But this
produces incomplete results when src.sg_len != dst.sg_len.
To solve the problem, we splits the descriptors into different
loops and use
This patch only regroup functions by usage.
This will help to integrate the GCM support patch later by
adjusting some shared code section, such as common code which
will be reused by GCM, AES mode setting, and DMA transfer.
Signed-off-by: Ryder Lee
---
drivers/crypto/mediatek/mtk-aes.c | 272 +++
On Thu, 19 Jan 2017, Denys Vlasenko wrote:
> A lot of asm-optimized routines in arch/x86/crypto/ keep its
> constants in .data. This is wrong, they should be on .rodata.
>
> Mnay of these constants are the same in different modules.
> For example, 128-bit shuffle mask 0x000102030405060708090A0B0C
A lot of asm-optimized routines in arch/x86/crypto/ keep its
constants in .data. This is wrong, they should be on .rodata.
Mnay of these constants are the same in different modules.
For example, 128-bit shuffle mask 0x000102030405060708090A0B0C0D0E0F
exists in at least half a dozen places.
There
On Thu, Jan 19, 2017 at 10:28:05PM +0100, Denys Vlasenko wrote:
> %progbits form is used on ARM (where @ is a comment char).
>
> x86 consistently uses @progbits everywhere else.
>
> Signed-off-by: Denys Vlasenko
Reviewed-by: Josh Poimboeuf
--
Josh
--
To unsubscribe from this list: send the l
%progbits form is used on ARM (where @ is a comment char).
x86 consistently uses @progbits everywhere else.
Signed-off-by: Denys Vlasenko
CC: Herbert Xu
CC: Josh Poimboeuf
CC: Xiaodong Liu
CC: Megha Dey
CC: George Spelvin
CC: linux-crypto@vger.kernel.org
CC: x...@kernel.org
CC: linux-ker...
Hi Greg,
On 01/19/2017 12:21 PM, Greg KH wrote:
On Thu, Jan 19, 2017 at 01:07:50PM -0500, Brijesh Singh wrote:
The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor,
which is not dedicated solely to crypto. The AMD Secure Processor includes
CCP and PSP (Platform Secure Proc
Hi Greg,
On 01/19/2017 12:18 PM, Greg KH wrote:
On Thu, Jan 19, 2017 at 01:08:01PM -0500, Brijesh Singh wrote:
The CCP device is part of the AMD Secure Processor, which is not dedicated
solely to crypto. Move the CCP device driver to the misc directory in
prepration for expanding the usage of t
On Thu, Jan 19, 2017 at 01:08:11PM -0500, Brijesh Singh wrote:
> The CCP device is part of the AMD Secure Processor. In order to expand the
> usage of the AMD Secure Processor, create a framework that allows functional
> components of the AMD Secure Processor to be initialized and handled
> appropr
On Thu, Jan 19, 2017 at 01:07:50PM -0500, Brijesh Singh wrote:
> The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor,
> which is not dedicated solely to crypto. The AMD Secure Processor includes
> CCP and PSP (Platform Secure Processor) devices.
>
> This patch series moves t
On Thu, Jan 19, 2017 at 01:08:01PM -0500, Brijesh Singh wrote:
> The CCP device is part of the AMD Secure Processor, which is not dedicated
> solely to crypto. Move the CCP device driver to the misc directory in
> prepration for expanding the usage of the AMD Secure Processor. Leaving the
> CCP cry
The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor,
which is not dedicated solely to crypto. The AMD Secure Processor includes
CCP and PSP (Platform Secure Processor) devices.
This patch series moves the CCP device driver to the misc directory and
creates a framework that a
The CCP device is part of the AMD Secure Processor. In order to expand the
usage of the AMD Secure Processor, create a framework that allows functional
components of the AMD Secure Processor to be initialized and handled
appropriately.
Signed-off-by: Brijesh Singh
Signed-off-by: Tom Lendacky
---
Hi Gilad,
On 19 January 2017 at 15:17, Gilad Ben-Yossef wrote:
> I tried adding sg_init_table() where I thought it was appropriate and
> it didn't resolve the issue.
>
> For what it's worth, my guess is that the difference between our
> setups is not related to Arm but to other options or the sto
2017-01-18 5:48 GMT+01:00 Herbert Xu :
> I'm open to other proposals. The basic requirement is to be able to
> process multiple blocks as one entity at the driver level, potentially
> generating the IVs there too.
>
> It's essentially the equivalent to full IPsec offload.
Hm, I just looked at wha
The GNU assembler for ARM version 2.22 or older fails to infer the
element size from the vmov instructions, and aborts the build in
the following way;
.../aes-neonbs-core.S: Assembler messages:
.../aes-neonbs-core.S:817: Error: bad type for scalar -- `vmov q1h[1],r10'
.../aes-neonbs-core.S:817: Er
On Thu, Jan 19, 2017 at 6:42 AM, Binoy Jayan wrote:
> Hi Gilad,
>
> On 18 January 2017 at 20:51, Gilad Ben-Yossef wrote:
>> I have some review comments and a bug report -
>
> Thank you very much for testing this on ARM and for the comments.
My pleasure. Thanks for writing the code :-)
>
>>> +
24 matches
Mail list logo
