1. 19 May, 2011 3 commits
  2. 17 May, 2011 1 commit
  3. 16 May, 2011 1 commit
  4. 11 May, 2011 10 commits
  5. 04 May, 2011 12 commits
  6. 02 May, 2011 4 commits
  7. 26 Apr, 2011 4 commits
  8. 08 Apr, 2011 2 commits
  9. 27 Mar, 2011 3 commits
    • Jamie Iles's avatar
      crypto: picoxcell - fix possible status FIFO overflow · 40bfc14f
      Jamie Iles authored
      The SPAcc's have 2 equally sized FIFO's - a command FIFO and a status
      FIFO.  The command FIFO takes the requests that are to be performed and
      the status FIFO reports the results.  It is possible to get into the
      situation where there are more free spaces in the command FIFO than the
      status FIFO if we don't empty the status FIFO quickly enough resulting
      in a possible overflow of the status FIFO.  This can result in incorrect
      status being reported in the status FIFO.
      
      Make sure that when we are submitting requests the number of requests
      that have been dispatched but not yet popped from the status FIFO does
      not exceed the size of a single FIFO.
      Signed-off-by: default avatarJamie Iles <jamie@jamieiles.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      40bfc14f
    • Brilly Wu's avatar
      crypto: padlock - Add SHA-1/256 module for VIA Nano · 0475add3
      Brilly Wu authored
      Add new SHA-1/256 module that never needs any fallback and just calls the
      PadLock hardware instruction supported from VIA Nano processors to implement
      the "update" and "final" function.
      
      They are respectively named "sha1_alg_nano" and "sha256_alg_nano", and will
      be used on any VIA Nano processor or the later ones. On VIA C7 CPU, the
      "sha1_alg" and "sha256_alg" modules will still be used as before.
      Signed-off-by: default avatarBrilly Wu <brillywu@viatech.com.cn>
      Signed-off-by: default avatarKary Jin <karyjin@viatech.com.cn>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0475add3
    • Kim Phillips's avatar
      crypto: caam - de-CHIP-ify device tree compatibles · 7dfc2179
      Kim Phillips authored
      - all the integration parameters have been captured by the binding.
      - the block name really uniquely identifies this hardware.
      
      Some advocate putting SoC names everywhere in case software needs
      to work around some chip-specific bug, but more precise SoC
      information already exists in SVR, and board information already
      exists in the top-level device tree node.
      
      Note that sometimes the SoC name is a worse identifier than the
      block version, as the block version can change between revisions
      of the same SoC.
      
      As a matter of historical reference, neither SEC versions 2.x
      nor 3.x (driven by talitos) ever needed CHIP references.
      Signed-off-by: default avatarKim Phillips <kim.phillips@freescale.com>
      Cc: Kumar Gala <kumar.gala@freescale.com>
      Cc: Scott Wood <scottwood@freescale.com>
      Acked-off-by: default avatarGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7dfc2179