1. 13 Jan, 2015 4 commits
    • Allan, Bruce W's avatar
      crypto: qat - adf_ae_stop() is never called · fd98d692
      Allan, Bruce W authored
      In adf_dev_stop(), adf_ae_stop() is never called because adf_dev_started()
      will always return false since the ADF_STATUS_STARTED bit is cleared
      earlier in the function.
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Acked-by: default avatarTadeusz Struk <tadeusz.struk@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      fd98d692
    • Allan, Bruce W's avatar
      53bc0251
    • Allan, Bruce W's avatar
      crypto: qat - fix device reset flow · 22e4dda0
      Allan, Bruce W authored
      When the device needs a reset, e.g. when an uncorrectable PCIe AER event
      occurs, various services/data structures need to be cleaned up, the
      hardware reset and the services/data structures initialized and started.
      The code to perform the cleanup and initialization was not performed when
      a device reset was done.
      
      This patch moves some of the initialization code out of the .probe entry-
      point into a separate function that is now called during probe as well as
      after the hardware has been reset.  Similarly, a new function is added for
      first cleaning up these services/data structures prior to resetting.  The
      new functions are adf_dev_init() and adf_dev_shutdown(), respectively, for
      which there are already prototypes but no actual functions just yet and are
      now called when the device is reset and during probe/cleanup of the driver.
      The down and up flows via ioctl calls has similarly been updated.
      
      In addition, there are two other bugs in the reset flow - one in the logic
      for determining whether to schedule a device reset upon receiving an
      uncorrectable AER event which prevents the reset flow from being initiated,
      and another with clearing the status bit indicating a device is configured
      (when resetting the device the configuration remains across the reset so
      the bit should not be cleared, otherwise, the necessary services will not
      be re-started in adf_dev_start() after the reset - clear the bit only when
      actually deleting the configuration).
      Signed-off-by: default avatarBruce Allan <bruce.w.allan@intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      22e4dda0
    • Rabin Vincent's avatar
      crypto: testmgr - don't use interruptible wait in tests · 8a45ac12
      Rabin Vincent authored
      tcrypt/testmgr uses wait_for_completion_interruptible() everywhere when
      it waits for a request to be completed.  If it's interrupted, then the
      test is aborted and the request is freed.
      
      However, if any of these calls actually do get interrupted, the result
      will likely be a kernel crash, when the driver handles the now-freed
      request.  Use wait_for_completion() instead.
      Signed-off-by: default avatarRabin Vincent <rabin.vincent@axis.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      8a45ac12
  2. 08 Jan, 2015 4 commits
  3. 05 Jan, 2015 2 commits
  4. 04 Jan, 2015 1 commit
  5. 29 Dec, 2014 2 commits
    • Stephan Mueller's avatar
      crypto: algif_rng - enable RNG interface compilation · 2f375538
      Stephan Mueller authored
      Enable compilation of the RNG AF_ALG support and provide a Kconfig
      option to compile the RNG AF_ALG support.
      Signed-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      2f375538
    • Stephan Mueller's avatar
      crypto: algif_rng - add random number generator support · 5afdfd22
      Stephan Mueller authored
      This patch adds the random number generator support for AF_ALG.
      
      A random number generator's purpose is to generate data without
      requiring the caller to provide any data. Therefore, the AF_ALG
      interface handler for RNGs only implements a callback handler for
      recvmsg.
      
      The following parameters provided with a recvmsg are processed by the
      RNG callback handler:
      
      	* sock - to resolve the RNG context data structure accessing the
      	  RNG instance private to the socket
      
      	* len - this parameter allows userspace callers to specify how
      	  many random bytes the RNG shall produce and return. As the
      	  kernel context for the RNG allocates a buffer of 128 bytes to
      	  store random numbers before copying them to userspace, the len
      	  parameter is checked that it is not larger than 128. If a
      	  caller wants more random numbers, a new request for recvmsg
      	  shall be made.
      
      The size of 128 bytes is chose because of the following considerations:
      
      	* to increase the memory footprint of the kernel too much (note,
      	  that would be 128 bytes per open socket)
      
      	* 128 is divisible by any typical cryptographic block size an
      	  RNG may have
      
      	* A request for random numbers typically only shall supply small
      	  amount of data like for keys or IVs that should only require
      	  one invocation of the recvmsg function.
      
      Note, during instantiation of the RNG, the code checks whether the RNG
      implementation requires seeding. If so, the RNG is seeded with output
      from get_random_bytes.
      
      A fully working example using all aspects of the RNG interface is
      provided at http://www.chronox.de/libkcapi.htmlSigned-off-by: default avatarStephan Mueller <smueller@chronox.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5afdfd22
  6. 25 Dec, 2014 6 commits
  7. 23 Dec, 2014 5 commits
  8. 22 Dec, 2014 16 commits