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 same datasheet for SS than A20
- A23 speak about a security system but without precisions
- A80 and A83T datasheet speak about a security system with more functions
(SHA224/SHA256/RSA/CRC), they will be supported in a separate driver.
This driver currently supports:
- 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
The driver exposes all those algorithms through the kernel cryptographic API.
The driver support only CPU driven (aka poll mode) transfer mode,
since the DMA engine of the A20 does not have a mainline driver yet.
For the moment the driver is fully synchronous.
A patch exists for making the driver asynchronous at the costs of badly decreasing performance.
It will be re-introduced later when DMA will be supported.
Changes since v10
- fix checkpatch --strict issues (except for BIT where it is volontary)
- lots of spelling fix
- add mode to algt
- import/export now initialize correctly op
- replace some dev_err with dev_err_ratelimited
Changes since v9
- use spin_lock_bh instead of spin_lock_irqx
- use sg_miter always with SG_MITER_ATOMIC flag
- rework the hash update functions
- the DES/3DES/AES now uses two functions one for all case and one for SG with
size not multiple of 4 and so remove the fallback for DES/3DES
- add A10 support, tested by Matthieu CERDA
- fix export/import functions
- do not use any _relaxed read/write
- write IV at end of cipher functions
Changes since v8
- use sg_miter in cipher functions, this clean all kmap stuff (thanks to bbrezillon)
- use GIC in dt interupts
- rename all references (files/dtcompatible) from sunxi to sun4i in prevision of futur A80/A83 driver
Changes since v7
- Add ECB block mode
- split the sunxi_ss_cipher_init in two
- remove sunxi_ss_cipher_encrypt/sunxi_ss_cipher_decrypt
- use now sunxi_ss_block_method_encrypt and sunxi_ss_block_method_decrypt
- Add weak DES key test needed by ECB tests
Changes since v6:
- Use alphabetic ordering for new sections in MAINTAINERS
- Clean remaining PRNG driver header
Changes since v5:
- Hash functions now keep partial hash states in sunxi_ss structures
- Use of spinlock instead of mutex
- Remove the static sunxi_ss structures by using container of
- Add export/import functions
- replace lots of writel by writesl
- replace lots of readl by readsl
Changes since v4:
- Rework all mutex path
- Use ahash_request_ctx() in hash functions
- Major rework of hash functions for solving mutex problems
- Split sunxi_req_ctx in two since ciphers now use struct sunxi_tfm_ctx
- Hash functions now test FIFO space register
Changes since v3:
- Remove all algorithms options from Kconfig, so now only one module is used
- Add the sunxi_ss_cipher function to unify mode calculation
- Remove the sunxi_cipher_exit empty function
- Add some missing mutex_unlock()
- Drop PRNG support, I wait for more comment on its results before re-enabling it.
Changes since v2:
- Fix Makefile and Kconfig for static kernel.
Changes since v1:
- annotate ss->base as __iomem
- regroup all mutex in the ss_ctx structure
- splited driver in 7 modules (core md5 sha1 aes des 3des prng) in sunxi-ss directory
- use dev_exit_p() for .remove
- added missing CRYPTO_BLKCIPHER dep in Kconfig
- use ahash instead of shash
- use ablkcipher instead of blkcipher
- use crypto_rng_ctx instead of crypto_tfm_ctx
- set seed as an u32
- drop useless comment decoration
- drop useless debug
- ss_ctx is now a static pointer and whole structure being allocated
- fix the platform_get_resource/devm_ioremap_resource pattern
- invert getting die id and configuring clock
- set clock value as a const unsigned long
- add MODULE_ALIAS
- use define names more consistency (SS_xxx)
- fix PRNG errors
- respell SS to Security System in DT documentation
On Fri, Jul 17, 2015 at 04:39:37PM +0200, LABBE Corentin wrote:
> 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 same datasheet for SS than A20
> - A23 speak about a security system but without precisions
> - A80 and A83T datasheet speak about a security system with more functions
> (SHA224/SHA256/RSA/CRC), they will be supported in a separate driver.
All applied. Thanks a lot!
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Mon, Jul 20, 2015 at 04:10:50PM +0800, Herbert Xu wrote:
> On Fri, Jul 17, 2015 at 04:39:37PM +0200, LABBE Corentin wrote:
> > 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 same datasheet for SS than A20
> > - A23 speak about a security system but without precisions
> > - A80 and A83T datasheet speak about a security system with more functions
> > (SHA224/SHA256/RSA/CRC), they will be supported in a separate driver.
>
> All applied. Thanks a lot!
All applied, DT bits included?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Mon, Jul 20, 2015 at 10:18:36AM +0200, Maxime Ripard wrote:
> On Mon, Jul 20, 2015 at 04:10:50PM +0800, Herbert Xu wrote:
> > On Fri, Jul 17, 2015 at 04:39:37PM +0200, LABBE Corentin wrote:
> > > 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 same datasheet for SS than A20
> > > - A23 speak about a security system but without precisions
> > > - A80 and A83T datasheet speak about a security system with more functions
> > > (SHA224/SHA256/RSA/CRC), they will be supported in a separate driver.
> >
> > All applied. Thanks a lot!
>
> All applied, DT bits included?
Yes.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Mon, Jul 20, 2015 at 04:20:57PM +0800, Herbert Xu wrote:
> On Mon, Jul 20, 2015 at 10:18:36AM +0200, Maxime Ripard wrote:
> > On Mon, Jul 20, 2015 at 04:10:50PM +0800, Herbert Xu wrote:
> > > On Fri, Jul 17, 2015 at 04:39:37PM +0200, LABBE Corentin wrote:
> > > > 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 same datasheet for SS than A20
> > > > - A23 speak about a security system but without precisions
> > > > - A80 and A83T datasheet speak about a security system with more functions
> > > > (SHA224/SHA256/RSA/CRC), they will be supported in a separate driver.
> > >
> > > All applied. Thanks a lot!
> >
> > All applied, DT bits included?
>
> Yes.
I thought you needed at least my Acked-by for that, but
whatever... How are we supposed to handle subsequent DT patches that
should be merged through arm-soc then?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
On Tue, Jul 21, 2015 at 02:38:47PM +0200, Maxime Ripard wrote:
> I thought you needed at least my Acked-by for that, but
> whatever... How are we supposed to handle subsequent DT patches that
> should be merged through arm-soc then?
What subsequent patches are you referring to? The changes in
this series are fairly self-contained so it should be unlikely
to cause serious merge conflicts.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, Jul 21, 2015 at 08:50:14PM +0800, Herbert Xu wrote:
> On Tue, Jul 21, 2015 at 02:38:47PM +0200, Maxime Ripard wrote:
> > I thought you needed at least my Acked-by for that, but
> > whatever... How are we supposed to handle subsequent DT patches that
> > should be merged through arm-soc then?
>
> What subsequent patches are you referring to? The changes in
> this series are fairly self-contained so it should be unlikely
> to cause serious merge conflicts.
Enabling it in other boards / SoCs, and/or any change that might
conflict with this one.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com