1. 18 Aug, 2023 5 commits
    • Yue Haibing's avatar
      crypto: allwinner - Remove unused function declarations · 64dd341e
      Yue Haibing authored
      Commit 06f751b6 ("crypto: allwinner - Add sun8i-ce Crypto Engine")
      declared but never implemented sun8i_ce_enqueue().
      Commit 56f6d5ae ("crypto: sun8i-ce - support hash algorithms")
      declared but never implemented sun8i_ce_hash().
      Commit f08fcced ("crypto: allwinner - Add sun8i-ss cryptographic offloader")
      declared but never implemented sun8i_ss_enqueue().
      Signed-off-by: default avatarYue Haibing <yuehaibing@huawei.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      64dd341e
    • Horia Geantă's avatar
      crypto: caam/jr - fix shared IRQ line handling · 23d422a4
      Horia Geantă authored
      There are cases when the interrupt status register (JRINTR) is non-zero,
      even though:
      1. An interrupt was generated, but it was masked OR
      2. There was no interrupt generated at all
      for the corresponding job ring.
      
      1. The case when interrupt is masked (JRCFGR_LS[IMSK]=1b'1)
      while other events have happened and are being accounted for, e.g.
      -JRINTR[HALT]=2b'10 - input job ring underwent a flush of all on-going
      jobs and processing of still-existing jobs (sitting in the ring) has been
      halted
      -JRINTR[HALT]=2b'01 - input job ring is currently undergoing a flush
      -JRINTR[ENTER_FAIL]=1b'1 - SecMon / SNVS transitioned to FAIL MODE
      It doesn't matter whether these events would assert the interrupt signal
      or not, interrupt is anyhow masked.
      
      2. The case when interrupt is not masked (JRCFGR_LS[IMSK]=1b'0), however
      the events accounted for in JRINTR do not generate interrupts, e.g.:
      -JRINTR[HALT]=2b'01
      -JRINTR[ENTER_FAIL]=1b'1 and JRCFGR_MS[FAIL_MODE]=1b'0
      
      Currently in these cases, when the JR interrupt handler is invoked (as a
      consequence of JR sharing the interrupt line with other devices - e.g.
      the two JRs on i.MX7ULP) it continues execution instead of returning
      IRQ_NONE.
      This could lead to situations like interrupt handler clearing JRINTR (and
      thus also the JRINTR[HALT] field) while corresponding job ring is
      suspended and then that job ring failing on resume path, due to expecting
      JRINTR[HALT]=b'10 and reading instead JRINTR[HALT]=b'00.
      
      Fix this by checking status of JRINTR[JRI] in the JR interrupt handler.
      If JRINTR[JRI]=1b'0, there was no interrupt generated for this JR and
      handler must return IRQ_NONE.
      Signed-off-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarMeenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
      Reviewed-by: default avatarGaurav Jain <gaurav.jain@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      23d422a4
    • Iuliana Prodan's avatar
      crypto: caam - increase the domain of write memory barrier to full system · e47e6d2a
      Iuliana Prodan authored
      In caam_jr_enqueue, under heavy DDR load, smp_wmb() or dma_wmb()
      fail to make the input ring be updated before the CAAM starts
      reading it. So, CAAM will process, again, an old descriptor address
      and will put it in the output ring. This will make caam_jr_dequeue()
      to fail, since this old descriptor is not in the software ring.
      To fix this, use wmb() which works on the full system instead of
      inner/outer shareable domains.
      Signed-off-by: default avatarIuliana Prodan <iuliana.prodan@nxp.com>
      Signed-off-by: default avatarMeenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
      Reviewed-by: default avatarGaurav Jain <gaurav.jain@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e47e6d2a
    • Gaurav Jain's avatar
      crypto: caam - fix unchecked return value error · e3068520
      Gaurav Jain authored
      error:
      Unchecked return value (CHECKED_RETURN)
      check_return: Calling sg_miter_next without checking return value
      
      fix:
      added check if(!sg_miter_next)
      
      Fixes: 8a2a0dd3 ("crypto: caam - strip input zeros from RSA input buffer")
      Signed-off-by: default avatarGaurav Jain <gaurav.jain@nxp.com>
      Signed-off-by: default avatarMeenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
      Reviewed-by: default avatarGaurav Jain <gaurav.jain@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e3068520
    • Arnd Bergmann's avatar
      crypto: caam - fix PM operations definition · b52c8c72
      Arnd Bergmann authored
      The newly added PM operations use the deprecated SIMPLE_DEV_PM_OPS() macro,
      causing a warning in some configurations:
      
      drivers/crypto/caam/ctrl.c:828:12: error: 'caam_ctrl_resume' defined but not used [-Werror=unused-function]
        828 | static int caam_ctrl_resume(struct device *dev)
            |            ^~~~~~~~~~~~~~~~
      drivers/crypto/caam/ctrl.c:818:12: error: 'caam_ctrl_suspend' defined but not used [-Werror=unused-function]
        818 | static int caam_ctrl_suspend(struct device *dev)
            |            ^~~~~~~~~~~~~~~~~
      drivers/crypto/caam/jr.c:732:12: error: 'caam_jr_resume' defined but not used [-Werror=unused-function]
        732 | static int caam_jr_resume(struct device *dev)
            |            ^~~~~~~~~~~~~~
      drivers/crypto/caam/jr.c:687:12: error: 'caam_jr_suspend' defined but not used [-Werror=unused-function]
        687 | static int caam_jr_suspend(struct device *dev)
            |            ^~~~~~~~~~~~~~~
      
      Use the normal DEFINE_SIMPLE_DEV_PM_OPS() variant now, and use pm_ptr() to
      completely eliminate the structure in configs without CONFIG_PM.
      
      Fixes: 322d7475 ("crypto: caam - add power management support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarMeenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b52c8c72
  2. 11 Aug, 2023 12 commits
  3. 05 Aug, 2023 1 commit
  4. 04 Aug, 2023 6 commits
  5. 28 Jul, 2023 10 commits
  6. 22 Jul, 2023 6 commits