1. 19 5月, 2011 3 次提交
  2. 18 5月, 2011 1 次提交
  3. 16 5月, 2011 1 次提交
  4. 11 5月, 2011 10 次提交
  5. 04 5月, 2011 12 次提交
  6. 03 5月, 2011 4 次提交
  7. 26 4月, 2011 4 次提交
  8. 08 4月, 2011 2 次提交
  9. 27 3月, 2011 3 次提交
    • J
      crypto: picoxcell - fix possible status FIFO overflow · 40bfc14f
      Jamie Iles 提交于
      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: NJamie Iles <jamie@jamieiles.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      40bfc14f
    • B
      crypto: padlock - Add SHA-1/256 module for VIA Nano · 0475add3
      Brilly Wu 提交于
      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: NBrilly Wu <brillywu@viatech.com.cn>
      Signed-off-by: NKary Jin <karyjin@viatech.com.cn>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0475add3
    • K
      crypto: caam - de-CHIP-ify device tree compatibles · 7dfc2179
      Kim Phillips 提交于
      - 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: NKim Phillips <kim.phillips@freescale.com>
      Cc: Kumar Gala <kumar.gala@freescale.com>
      Cc: Scott Wood <scottwood@freescale.com>
      Acked-off-by: NGrant Likely <grant.likely@secretlab.ca>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7dfc2179