Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 2月, 2017 3 次提交
  3. 03 2月, 2017 1 次提交
    • C
      crypto: atmel-authenc - add support to authenc(hmac(shaX), Y(aes)) modes · 89a82ef8
      由 Cyrille Pitchen 提交于 
      This patchs allows to combine the AES and SHA hardware accelerators on
some Atmel SoCs. Doing so, AES blocks are only written to/read from the
AES hardware. Those blocks are also transferred from the AES to the SHA
accelerator internally, without additionnal accesses to the system busses.

Hence, the AES and SHA accelerators work in parallel to process all the
data blocks, instead of serializing the process by (de)crypting those
blocks first then authenticating them after like the generic
crypto/authenc.c driver does.

Of course, both the AES and SHA hardware accelerators need to be available
before we can start to process the data blocks. Hence we use their crypto
request queue to synchronize both drivers.
Signed-off-by: NCyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      89a82ef8
  5. 23 1月, 2017 1 次提交
  7. 13 1月, 2017 2 次提交
  9. 27 12月, 2016 1 次提交
  11. 16 12月, 2016 1 次提交
    • G
      crypto: add virtio-crypto driver · dbaf0624
      由 Gonglei 提交于 
      This patch introduces virtio-crypto driver for Linux Kernel.

The virtio crypto device is a virtual cryptography device
as well as a kind of virtual hardware accelerator for
virtual machines. The encryption anddecryption requests
are placed in the data queue and are ultimately handled by
thebackend crypto accelerators. The second queue is the
control queue used to create or destroy sessions for
symmetric algorithms and will control some advanced features
in the future. The virtio crypto device provides the following
cryptoservices: CIPHER, MAC, HASH, and AEAD.

For more information about virtio-crypto device, please see:
  http://qemu-project.org/Features/VirtioCrypto

CC: Michael S. Tsirkin <mst@redhat.com>
CC: Cornelia Huck <cornelia.huck@de.ibm.com>
CC: Stefan Hajnoczi <stefanha@redhat.com>
CC: Herbert Xu <herbert@gondor.apana.org.au>
CC: Halil Pasic <pasic@linux.vnet.ibm.com>
CC: David S. Miller <davem@davemloft.net>
CC: Zeng Xin <xin.zeng@intel.com>
Signed-off-by: NGonglei <arei.gonglei@huawei.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      dbaf0624
  13. 13 9月, 2016 1 次提交
  15. 19 8月, 2016 1 次提交
  17. 15 6月, 2016 1 次提交
  19. 03 5月, 2016 1 次提交
  21. 20 4月, 2016 1 次提交
  23. 15 4月, 2016 1 次提交
  25. 05 4月, 2016 2 次提交
  27. 28 2月, 2016 1 次提交
  29. 06 2月, 2016 1 次提交
  31. 01 2月, 2016 1 次提交
  33. 18 1月, 2016 1 次提交
  35. 23 12月, 2015 1 次提交
  37. 22 12月, 2015 1 次提交
  39. 27 11月, 2015 1 次提交
  41. 23 11月, 2015 1 次提交
    • A
      crypto: atmel: fix bogus select · 56b85c9d
      由 Arnd Bergmann 提交于 
      The Atmel at91 crypto driver unconditionally selects AT_HDMAC,
which results in a Kconfig warning if that driver is not enabled:

warning: (CRYPTO_DEV_ATMEL_AES) selects AT_HDMAC which has unmet direct dependencies (DMADEVICES && ARCH_AT91)

The crypto driver itself does not actually have a dependency
on a particular dma engine, other than this being the one that
is used in at91.

Removing the 'select' gets rid of the warning, but can cause
the driver to be unusable if the HDMAC is not enabled at the
same time. To work around that, this patch clarifies the runtime
dependency to be 'AT_HDMAC || AT_XDMAC', but adds an alternative
for COMPILE_TEST, which lets the driver get build on all systems.

The ARCH_AT91 dependency is implied by AT_XDMAC || AT_HDMAC now
and no longer needs to be listed separately.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      56b85c9d
  43. 14 10月, 2015 1 次提交
    • A
      crypto: mxs-dcp - mxs-dcp is an stmp device · dc97fa02
      由 Arnd Bergmann 提交于 
      The mxs-dcp driver relies on the stmp_reset_block() helper function, which
is provided by CONFIG_STMP_DEVICE. This symbol is always set on MXS,
but the driver can now also be built for MXC (i.MX6), which results
in a built error if no other driver selects STMP_DEVICE:

drivers/built-in.o: In function `mxs_dcp_probe':
vf610-ocotp.c:(.text+0x3df302): undefined reference to `stmp_reset_block'

This adds the 'select', like all other stmp drivers have it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: a2712e6c ("crypto: mxs-dcp - Allow MXS_DCP to be used on MX6SL")
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      dc97fa02
  45. 08 10月, 2015 1 次提交
  47. 21 9月, 2015 1 次提交
  49. 10 9月, 2015 1 次提交
  51. 20 7月, 2015 1 次提交
  53. 22 6月, 2015 1 次提交
  55. 19 6月, 2015 3 次提交
    • B
      crypto: marvell/cesa - add TDMA support · db509a45
      由 Boris BREZILLON 提交于 
      The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).

Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      db509a45
    • B
      crypto: marvell/cesa - add a new driver for Marvell's CESA · f63601fd
      由 Boris BREZILLON 提交于 
      The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.

This commit introduce the base infrastructure allowing us to add support
for DMA optimization.
It also includes support for one hash (SHA1) and one cipher (AES)
algorithm, and enable those features on the Armada 370 SoC.

Other algorithms and platforms will be added later on.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      f63601fd
    • B
      crypto: mv_cesa - use gen_pool to reserve the SRAM memory region · 51b44fc8
      由 Boris BREZILLON 提交于 
      The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.

This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine

The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.

To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.

Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      51b44fc8
  57. 18 6月, 2015 1 次提交
    • H
      crypto: drivers - Fix Kconfig selects · 596103cf
      由 Herbert Xu 提交于 
      This patch fixes a number of problems in crypto driver Kconfig
entries:

1. Select BLKCIPHER instead of BLKCIPHER2.  The latter is internal
and should not be used outside of the crypto API itself.
2. Do not select ALGAPI unless you use a legacy type like
CRYPTO_ALG_TYPE_CIPHER.
3. Select the algorithm type that you are implementing, e.g., AEAD.
4. Do not select generic C code such as CBC/ECB unless you use them
as a fallback.
5. Remove default n since that is the default default.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      596103cf
  59. 16 6月, 2015 1 次提交
  61. 11 5月, 2015 1 次提交
  63. 24 4月, 2015 1 次提交
  65. 21 4月, 2015 1 次提交
  67. 23 3月, 2015 1 次提交