1. 13 9月, 2016 2 次提交
  2. 07 9月, 2016 2 次提交
  3. 18 7月, 2016 1 次提交
  4. 24 6月, 2016 1 次提交
  5. 07 6月, 2016 1 次提交
  6. 03 5月, 2016 1 次提交
  7. 01 2月, 2016 1 次提交
  8. 17 12月, 2015 1 次提交
  9. 08 7月, 2015 4 次提交
  10. 01 4月, 2015 1 次提交
    • V
      crypto: omap-aes - Fix support for unequal lengths · 6d7e7e02
      Vutla, Lokesh 提交于
      For cases where total length of an input SGs is not same as
      length of the input data for encryption, omap-aes driver
      crashes. This happens in the case when IPsec is trying to use
      omap-aes driver.
      
      To avoid this, we copy all the pages from the input SG list
      into a contiguous buffer and prepare a single element SG list
      for this buffer with length as the total bytes to crypt, which is
      similar thing that is done in case of unaligned lengths.
      
      Fixes: 6242332f ("crypto: omap-aes - Add support for cases of unaligned lengths")
      Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6d7e7e02
  11. 26 1月, 2015 1 次提交
  12. 20 10月, 2014 1 次提交
  13. 10 3月, 2014 1 次提交
  14. 05 12月, 2013 1 次提交
  15. 30 10月, 2013 1 次提交
  16. 24 9月, 2013 1 次提交
  17. 21 8月, 2013 12 次提交
  18. 05 6月, 2013 1 次提交
    • J
      crypto: omap-aes - Don't idle/start AES device between Encrypt operations · a3485e68
      Joel A Fernandes 提交于
      Calling runtime PM API for every block causes serious perf hit to
      crypto operations that are done on a long buffer.
      As crypto is performed on a page boundary, encrypting large buffers can
      cause a series of crypto operations divided by page. The runtime PM API
      is also called those many times.
      
      We call runtime_pm_get_sync only at beginning on the session (cra_init)
      and runtime_pm_put at the end. This result in upto a 50% speedup as below.
      This doesn't make the driver to keep the system awake as runtime get/put
      is only called during a crypto session which completes usually quickly.
      
      Before:
      root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
      Doing aes-128-cbc for 3s on 16 size blocks: 13310 aes-128-cbc's in 0.01s
      Doing aes-128-cbc for 3s on 64 size blocks: 13040 aes-128-cbc's in 0.04s
      Doing aes-128-cbc for 3s on 256 size blocks: 9134 aes-128-cbc's in 0.03s
      Doing aes-128-cbc for 3s on 1024 size blocks: 8939 aes-128-cbc's in 0.01s
      Doing aes-128-cbc for 3s on 8192 size blocks: 4299 aes-128-cbc's in 0.00s
      
      After:
      root@beagleboard:~# time -v openssl speed -evp aes-128-cbc
      Doing aes-128-cbc for 3s on 16 size blocks: 18911 aes-128-cbc's in 0.02s
      Doing aes-128-cbc for 3s on 64 size blocks: 18878 aes-128-cbc's in 0.02s
      Doing aes-128-cbc for 3s on 256 size blocks: 11878 aes-128-cbc's in 0.10s
      Doing aes-128-cbc for 3s on 1024 size blocks: 11538 aes-128-cbc's in 0.05s
      Doing aes-128-cbc for 3s on 8192 size blocks: 4857 aes-128-cbc's in 0.03s
      
      While at it, also drop enter and exit pr_debugs, in related code. tracers
      can be used for that.
      
      Tested on a Beaglebone (AM335x SoC) board.
      Signed-off-by: NJoel A Fernandes <joelagnel@ti.com>
      Acked-by: NKevin Hilman <khilman@linaro.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      a3485e68
  19. 24 5月, 2013 1 次提交
  20. 10 3月, 2013 2 次提交
  21. 20 1月, 2013 3 次提交
    • M
      crypto: omap-aes - Add CTR algorithm Support · f9fb69e7
      Mark A. Greer 提交于
      The OMAP3 and OMAP4/AM33xx versions of the AES crypto
      module support the CTR algorithm in addition to ECB
      and CBC that the OMAP2 version of the module supports.
      
      So, OMAP2 and OMAP3 share a common register set but
      OMAP3 supports CTR while OMAP2 doesn't.  OMAP4/AM33XX
      uses a different register set from OMAP2/OMAP3 and
      also supports CTR.
      
      To add this support, use the platform_data introduced
      in an ealier commit to hold the list of algorithms
      supported by the current module.  The probe routine
      will use that list to register the correct algorithms.
      
      Note: The code being integrated is from the TI AM33xx SDK
      and was written by Greg Turner <gkmturner@gmail.com> and
      Herman Schuurman (current email unknown) while at TI.
      
      CC: Greg Turner <gkmturner@gmail.com>
      CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
      Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      f9fb69e7
    • M
      crypto: omap-aes - Add OMAP4/AM33XX AES Support · 0d35583a
      Mark A. Greer 提交于
      Add support for the OMAP4 version of the AES module
      that is present on OMAP4 and AM33xx SoCs.
      
      The modules have several differences including register
      offsets and how DMA is triggered.  To handle these
      differences, a platform_data structure is defined and
      contains routine pointers, register offsets, and bit
      offsets within registers.  OMAP2/OMAP3-specific routines
      are suffixed with '_omap2' and OMAP4/AM33xx routines are
      suffixed with '_omap4'.
      
      Note: The code being integrated is from the TI AM33xx SDK
      and was written by Greg Turner <gkmturner@gmail.com> and
      Herman Schuurman (current email unknown) while at TI.
      
      CC: Greg Turner <gkmturner@gmail.com>
      CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
      Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d35583a
    • M
      crypto: omap-aes - Convert to dma_request_slave_channel_compat() · b4b87a93
      Mark A. Greer 提交于
      Use the dma_request_slave_channel_compat() call instead of
      the dma_request_channel() call to request a DMA channel.
      This allows the omap-aes driver use different DMA engines.
      
      CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
      Signed-off-by: NMark A. Greer <mgreer@animalcreek.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      b4b87a93