1. 08 Apr, 2015 6 commits
  2. 07 Apr, 2015 2 commits
  3. 03 Apr, 2015 1 commit
    • Lokesh Vutla's avatar
      crypto: omap-sham - Add the offset of sg page to vaddr · 13cf394c
      Lokesh Vutla authored
      kmap_atomic() gives only the page address of the input page.
      Driver should take care of adding the offset of the scatterlist
      within the page to the returned page address.
      omap-sham driver is not adding the offset to page and directly operates
      on the return vale of kmap_atomic(), because of which the following
      error comes when running crypto tests:
      00000000: d9 a1 1b 7c aa 90 3b aa 11 ab cb 25 00 b8 ac bf
      [    2.338169] 00000010: c1 39 cd ff 48 d0 a8 e2 2b fa 33 a1
      [    2.344008] alg: hash: Chunking test 1 failed for omap-sha256
      So adding the scatterlist offset to vaddr.
      Signed-off-by: Lokesh Vutla's avatarLokesh Vutla <lokeshvutla@ti.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  4. 01 Apr, 2015 9 commits
  5. 23 Mar, 2015 6 commits
  6. 18 Mar, 2015 1 commit
  7. 17 Mar, 2015 3 commits
    • Herbert Xu's avatar
      linux-next: build failure after merge of the crypto tree · 7094e8ea
      Herbert Xu authored
      crypto: img-hash - Add missing semicolon to fix build error
      There is a missing semicolon after MODULE_DEVICE_TABLE.
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Andre Wolokita's avatar
      hwrng: omap - Change RNG_CONFIG_REG to RNG_CONTROL_REG in init · 656d7e7e
      Andre Wolokita authored
      omap4_rng_init() checks bit 10 of the RNG_CONFIG_REG to determine whether
      the RNG is already running before performing any initiliasation. This is not
      the correct register to check, as the enable bit is in RNG_CONFIG_CONTROL.
      Read from RNG_CONTROL_REG instead.
      Signed-off-by: default avatarAndre Wolokita <Andre.Wolokita@analog.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
    • Andre Wolokita's avatar
      hwrng: omap - Change RNG_CONFIG_REG to RNG_CONTROL_REG when checking and disabling TRNG · 1a5addfe
      Andre Wolokita authored
      In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to determine
      whether the RNG is running. This is suspicious firstly due to the use of
      RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written to
      RNG_CONTROL_REG after configuration of the FROs. Similar suspicious logic is
      repeated in omap4_rng_cleanup() when RNG_CONTROL_REG masked with
      RNG_CONTROL_ENABLE_TRNG_MASK is read, the same mask bit is cleared, and then
      written to RNG_CONFIG_REG. Unless the TRNG is enabled with one bit in RNG_CONTROL
      and disabled with another in RNG_CONFIG and these bits are mirrored in some way,
      I believe that the TRNG is not really shutting off.
      Apart from the strange logic, I have reason to suspect that the OMAP4 related
      code in this driver is driving an Inside Secure IP hardware RNG and strongly
      suspect that bit 10 of RNG_CONFIG_REG is one of the bits configuring the
      sampling rate of the FROs. This option is by default set to 0 and is not being
      set anywhere in omap-rng.c. Reading this bit during omap4_rng_init() will
      always return 0. It will remain 0 because ~(value of TRNG_MASK in control) will
      always be 0, because the TRNG is never shut off. This is of course presuming
      that the OMAP4 features the Inside Secure IP.
      I'm interested in knowing what the guys at TI think about this, as only they
      can confirm or deny the detailed structure of these registers.
      Signed-off-by: default avatarAndre Wolokita <Andre.Wolokita@analog.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
  8. 16 Mar, 2015 7 commits
  9. 12 Mar, 2015 2 commits
  10. 11 Mar, 2015 3 commits