1. 15 Feb, 2018 1 commit
  2. 07 Oct, 2017 1 commit
  3. 18 Jul, 2017 1 commit
  4. 10 Jun, 2017 3 commits
  5. 22 Sep, 2016 1 commit
  6. 13 Sep, 2016 1 commit
  7. 07 Sep, 2016 2 commits
  8. 18 Jul, 2016 1 commit
  9. 03 May, 2016 2 commits
  10. 17 Dec, 2015 1 commit
  11. 14 Dec, 2015 1 commit
    • Sam Protsenko's avatar
      crypto: omap-des - Fix "schedule while atomic" bug · 50eca256
      Sam Protsenko authored
      When using DES module the next bug appears:
      
          BUG: scheduling while atomic: kworker/0:1/63/0x00000102
      
      With backtrace as follows:
      
      <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
      
      [<c0012294>] (dump_backtrace) from [<c00124ac>] (show_stack+0x18/0x1c)
      [<c0012494>] (show_stack) from [<c0752554>] (dump_stack+0x84/0xc4)
      [<c07524d0>] (dump_stack) from [<c0750218>] (__schedule_bug+0x54/0x64)
      [<c07501c4>] (__schedule_bug) from [<c07548a4>] (__schedule+0x4ac/0x53c)
      [<c07543f8>] (__schedule) from [<c075496c>] (schedule+0x38/0x88)
      [<c0754934>] (schedule) from [<c03c3984>] (rpm_resume+0x158/0x59c)
      [<c03c382c>] (rpm_resume) from [<c03c3e1c>] (__pm_runtime_resume+0x54/0x6c)
      [<c03c3dc8>] (__pm_runtime_resume) from [<c0568ff8>] (omap_des_handle_queue+0x154/0x7bc)
      [<c0568ea4>] (omap_des_handle_queue) from [<c05696b8>] (omap_des_crypt+0x58/0xbc)
      [<c0569660>] (omap_des_crypt) from [<c0569730>] (omap_des_cbc_decrypt+0x14/0x18)
      [<c056971c>] (omap_des_cbc_decrypt) from [<c0297534>] (authenc_verify_ahash_done+0xe0/0xe8)
      [<c0297454>] (authenc_verify_ahash_done) from [<c056a330>] (omap_sham_finish_req+0x58/0xa8)
      [<c056a2d8>] (omap_sham_finish_req) from [<c056b714>] (omap_sham_done_task+0x1c0/0x1e0)
      [<c056b554>] (omap_sham_done_task) from [<c003e53c>] (tasklet_action+0x80/0x118)
      [<c003e4bc>] (tasklet_action) from [<c003e740>] (__do_softirq+0x11c/0x260)
      [<c003e624>] (__do_softirq) from [<c003eb64>] (irq_exit+0xc0/0xfc)
      [<c003eaa4>] (irq_exit) from [<c000f1c4>] (handle_IRQ+0x4c/0x98)
      [<c000f178>] (handle_IRQ) from [<c0008568>] (gic_handle_irq+0x34/0x64)
      [<c0008534>] (gic_handle_irq) from [<c0758540>] (__irq_svc+0x40/0x70)
      
      <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< cut here >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
      
      Insight was seen in drivers/crypto/omap-sham.c driver.
      All credits for this patch go to Grygorii Strashko.
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      50eca256
  12. 06 Jul, 2015 1 commit
    • Vutla, Lokesh's avatar
      crypto: omap-des - Fix unmapping of dma channels · acb33cc5
      Vutla, Lokesh authored
      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 ]------------
      [    4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 check_unmap+0x710/0x9a0()
      [    4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0x00000000ab2ce000] [size=8 bytes]
      [    4.236785] Modules linked in:
      [    4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.39-02999-g1bc045a-dirty #182
      [    4.247918] [<c001678c>] (unwind_backtrace) from [<c0012574>] (show_stack+0x10/0x14)
      [    4.255710] [<c0012574>] (show_stack) from [<c05a37e8>] (dump_stack+0x84/0xb8)
      [    4.262977] [<c05a37e8>] (dump_stack) from [<c0046464>] (warn_slowpath_common+0x68/0x8c)
      [    4.271107] [<c0046464>] (warn_slowpath_common) from [<c004651c>] (warn_slowpath_fmt+0x30/0x40)
      [    4.279854] [<c004651c>] (warn_slowpath_fmt) from [<c02d50a4>] (check_unmap+0x710/0x9a0)
      [    4.287991] [<c02d50a4>] (check_unmap) from [<c02d5478>] (debug_dma_unmap_sg+0x90/0x19c)
      [    4.296128] [<c02d5478>] (debug_dma_unmap_sg) from [<c04a77d8>] (omap_des_done_task+0x1cc/0x3e4)
      [    4.304963] [<c04a77d8>] (omap_des_done_task) from [<c004a090>] (tasklet_action+0x84/0x124)
      [    4.313370] [<c004a090>] (tasklet_action) from [<c004a4ac>] (__do_softirq+0xf0/0x20c)
      [    4.321235] [<c004a4ac>] (__do_softirq) from [<c004a840>] (irq_exit+0x98/0xec)
      [    4.328500] [<c004a840>] (irq_exit) from [<c000f9ac>] (handle_IRQ+0x50/0xb0)
      [    4.335589] [<c000f9ac>] (handle_IRQ) from [<c0008688>] (gic_handle_irq+0x28/0x5c)
      
      Removing the duplicate call to dma_unmap_sg().
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarTomi Valkeinen <tomi.valkeinen@ti.com>
      Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      acb33cc5
  13. 26 Jan, 2015 1 commit
  14. 08 Jan, 2015 1 commit
  15. 20 Oct, 2014 1 commit
  16. 16 Apr, 2014 2 commits
  17. 10 Mar, 2014 2 commits
  18. 26 Feb, 2014 1 commit
  19. 05 Dec, 2013 1 commit
  20. 30 Oct, 2013 1 commit
  21. 23 Sep, 2013 1 commit
  22. 21 Aug, 2013 12 commits
  23. 05 Jun, 2013 1 commit
    • Joel A Fernandes's avatar
      crypto: omap-aes - Don't idle/start AES device between Encrypt operations · a3485e68
      Joel A Fernandes authored
      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: default avatarJoel A Fernandes <joelagnel@ti.com>
      Acked-by: default avatarKevin Hilman <khilman@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      a3485e68