The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.
This patch enable the Security System on the Allwinner A10 SoC Device-tree.
Signed-off-by: LABBE Corentin
---
arch/arm/boot/dts/sun4i-a10.dtsi
The Security System is a hardware cryptographic accelerator that support
AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on many Allwinner SoC.
This patch enable the Security System on the Allwinner A20 SoC Device-tree.
Signed-off-by: LABBE Corentin
---
arch/arm/boot/dts/sun7i-a20.dtsi
This patch adds documentation for Device-Tree bindings for the
Security System cryptographic accelerator driver.
Signed-off-by: LABBE Corentin
---
Documentation/devicetree/bindings/crypto/sun4i-ss.txt | 19 +++
1 file changed, 19 insertions(+)
create mode 100644 Documentation/de
Signed-off-by: LABBE Corentin
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index bbb6aeb..33851b2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -556,6 +556,12 @@ S: Maintained
F: Documentation/i2c/busses/i2c-ali1563
F: drivers/i2c/b
Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC/ECB mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC/ECB mode
Signed-off-by: LABBE
Hello
This is the driver for the Security System included in Allwinner SoC A20.
The Security System (SS for short) is a hardware cryptographic accelerator that
support AES/MD5/SHA1/DES/3DES/PRNG algorithms.
It could be found on others Allwinner SoC:
- A10, A10s, A13, A31 and A33 manual give the s
On 06.07.2015 [16:13:07 +0800], Herbert Xu wrote:
> On Thu, Jul 02, 2015 at 03:42:26PM -0700, Nishanth Aravamudan wrote:
> > Based off the CONFIG_SPU_FS_MODULE code, only attempt to load platform
> > modules if the nx-842 pseries/powernv drivers are built as modules.
> >
> > Otherwise, if CONFIG_D
On 03.07.2015 [11:30:32 +1000], Michael Ellerman wrote:
> On Thu, 2015-07-02 at 15:40 -0700, Nishanth Aravamudan wrote:
> > While we never would successfully load on the wrong machine type, there
> > is extra output by default regardless of machine type.
> >
> > For instance, on a PowerVM LPAR, we
All tests for cbc(aes) use only blocks of data with a multiple of 4.
This test adds a test with some odd SG size.
Signed-off-by: LABBE Corentin
---
crypto/testmgr.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 868edf1..b052555 100644
--- a/c
The AEAD version of cryptd uses the same context for its own state
as well as that of the child. In doing so it did not maintain the
proper ordering, thus resulting in potential state corruption where
the child will overwrite the state stored by cryptd.
This patch fixes and also sets the request
On Mon, Jul 06, 2015 at 02:15:06PM +0530, Lokesh Vutla wrote:
>
> The existing AEAD test case does not do a wait_for_completion(), when
> the return value is EINPROGRESS or EBUSY like it is done for acipher_speed
> tests.
Please fix them to do the wait.
Thanks,
--
Email: Herbert Xu
Home Page:
Hi,
On Monday 06 July 2015 01:14 PM, Herbert Xu wrote:
> On Thu, Jul 02, 2015 at 10:48:40AM +0530, Lokesh Vutla wrote:
>> Adding simple speed tests for a range of block sizes for Async AEAD crypto
>> algorithms.
>>
>> Signed-off-by: Lokesh Vutla
>
> What's wrong with the existing AEAD speed tests
On Mon, Jul 06, 2015 at 07:03:37AM +0300, Baruch Siach wrote:
> These files are generated since commits f2f770d74a8d (crypto: arm/sha256 - Add
> optimized SHA-256/224, 2015-04-03) and c80ae7ca3726 (crypto: arm/sha512 -
> accelerated SHA-512 using ARM generic ASM and NEON, 2015-05-08).
>
> Cc: Ard
On Tue, Jun 30, 2015 at 12:57:14PM -0500, Tom Lendacky wrote:
> Add the necessary module device tables to the platform support to allow
> for autoloading of the CCP driver. This will allow for the CCP's hwrng
> support to be available without having to manually load the driver. The
> module device
On Thu, Jul 02, 2015 at 03:38:00PM -0700, Nishanth Aravamudan wrote:
> Currently, on a LPAR with the nx-842 device disabled, the following
> messages are emitted:
Patches 1-3 applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herber
On Thu, Jul 02, 2015 at 06:33:28PM +0530, Lokesh Vutla wrote:
> dma_unmap_sg() is being called twice after completing the
> task. Looks like this is a copy paste error when creating
> des driver.
> With this the following warn appears during boot:
>
> [4.210457] [ cut here ]---
Hi,
On Monday 06 July 2015 01:05 PM, Herbert Xu wrote:
> On Thu, Jul 02, 2015 at 10:48:38AM +0530, Lokesh Vutla wrote:
>> Now the driver supports gcm mode, add omap-aes-gcm
>> algo info to omap-aes driver.
>>
>> Signed-off-by: Lokesh Vutla
>
> You're using the old AEAD interface. We are now movi
On Thu, Jul 02, 2015 at 03:42:26PM -0700, Nishanth Aravamudan wrote:
> Based off the CONFIG_SPU_FS_MODULE code, only attempt to load platform
> modules if the nx-842 pseries/powernv drivers are built as modules.
>
> Otherwise, if CONFIG_DEV_NX_COMPRESS=y,
> CONFIG_DEV_NX_COMPRESS_PSERIES=y, CONFIG
On Thu, Jul 02, 2015 at 10:48:40AM +0530, Lokesh Vutla wrote:
> Adding simple speed tests for a range of block sizes for Async AEAD crypto
> algorithms.
>
> Signed-off-by: Lokesh Vutla
What's wrong with the existing AEAD speed tests?
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~
On Thu, Jul 02, 2015 at 02:59:03AM -0500, Felipe Balbi wrote:
> On Thu, Jul 02, 2015 at 10:48:34AM +0530, Lokesh Vutla wrote:
> > Use BIT()/GENMASK() macros for all register definitions instead of
> > hand-writing bit masks.
> >
> > Signed-off-by: Lokesh Vutla
> > ---
> > drivers/crypto/omap-aes
On Thu, Jul 02, 2015 at 10:48:33AM +0530, Lokesh Vutla wrote:
> Add aead_request_cast() api to get pointer to aead_request
> from cryto_async_request.
>
> Signed-off-by: Lokesh Vutla
> ---
> include/linux/crypto.h |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/include/linux/c
On Thu, Jul 02, 2015 at 10:48:31AM +0530, Lokesh Vutla wrote:
> OMAP AES driver returns an error if the data is not aligned with
> AES_BLOCK_SIZE bytes.
> But OMAP AES hw allows data input upto 1 byte aligned, but still
> zeros are to be appended and complete AES_BLOCK_SIZE has to be written.
> And
On Thu, Jul 02, 2015 at 10:48:38AM +0530, Lokesh Vutla wrote:
> Now the driver supports gcm mode, add omap-aes-gcm
> algo info to omap-aes driver.
>
> Signed-off-by: Lokesh Vutla
You're using the old AEAD interface. We are now moving to the
new AEAD interface so I will not be accepting any new
23 matches
Mail list logo