kernel/linux.git/drivers/crypto/caam/error.c, branch v6.6.132

crypto: caam - add more RNG hw error codes

2020-07-31T08:25:28+00:00

In some cases, e.g. when TRNG is not properly configured, the RNG module could issue a "Hardware error" at runtime. "Continuos check" error is emitted when some of the BISTs fail. Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - make CAAM_PTR_SZ dynamic

2019-08-30T08:05:30+00:00

In order to be able to configure CAAM pointer size at run-time, which needed to support i.MX8MQ, which is 64-bit SoC with 32-bit pointer size, convert CAAM_PTR_SZ to refer to a global variable of the same name ("caam_ptr_sz") and adjust the rest of the code accordingly. No functional change intended. Signed-off-by: Andrey Smirnov Cc: Chris Spencer Cc: Cory Tusar Cc: Chris Healy Cc: Lucas Stach Cc: Horia Geantă Cc: Aymen Sghaier Cc: Leonard Crestez Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu

crypto: caam - fix return code in completion callbacks

2019-08-09T05:11:45+00:00

Modify drive to provide a valid errno (and not the HW error ID) to the user, via completion callbacks. A "valid errno" is currently not explicitly mentioned in the docs, however the error code is expected to match the one returned by the generic SW implementation. Note: in most error cases caam/qi and caam/qi2 returned -EIO; align all caam drivers to return -EINVAL. While here, ratelimit prints triggered by fuzz testing, such that console is not flooded. Signed-off-by: Horia Geantă Signed-off-by: Iuliana Prodan Signed-off-by: Herbert Xu

crypto: caam/qi - fix error handling in ERN handler

2019-08-09T05:11:44+00:00

ERN handler calls the caam/qi frontend "done" callback with a status of -EIO. This is incorrect, since the callback expects a status value meaningful for the crypto engine - hence the cryptic messages like the one below: platform caam_qi: 15: unknown error source Fix this by providing the callback with: -the status returned by the crypto engine (fd[status]) in case it contains an error, OR -a QI "No error" code otherwise; this will trigger the message: platform caam_qi: 50000000: Queue Manager Interface: No error which is fine, since QMan driver provides details about the cause of failure Cc: # v5.1+ Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend support") Signed-off-by: Horia Geantă Reviewed-by: Iuliana Prodan Signed-off-by: Herbert Xu

crypto: caam - print messages in caam_dump_sg at debug level

2019-05-30T07:35:45+00:00

caam_dump_sg() is only compiled in when DEBUG is defined, hence the messages are debug messages. Remove the @level argument from caam_dump_sg() and print all messages at debug level. Signed-off-by: Sascha Hauer Signed-off-by: Herbert Xu

crypto: caam - fix caam_dump_sg that iterates through scatterlist

2019-05-09T05:17:56+00:00

Fix caam_dump_sg by correctly determining the next scatterlist entry in the list. Fixes: 5ecf8ef9103c ("crypto: caam - fix sg dump") Signed-off-by: Iuliana Prodan Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - fix spelling mistake "cannote" -> "cannot"

2019-04-25T07:38:12+00:00

There is a spelling mistake in an error message in the qi_error_list array. Fix this. Signed-off-by: Colin Ian King Reviewed-by: Mukesh Ojha Signed-off-by: Herbert Xu

crypto: caam - move shared symbols in a common location

2019-01-11T06:16:55+00:00

There are several issues with symbols shared b/w: -caam/jr and caam/qi drivers on one hand -caam/qi2 driver on the other hand Commit 52813ab24959 ("crypto: caam/qi2 - avoid double export") fixed some of them, however compilation still fails for CRYPTO_DEV_FSL_CAAM=m and CRYPTO_DEV_FSL_DPAA2_CAAM=y. Another issue is related to dependency cycles reported by depmod when CRYPTO_DEV_FSL_CAAM=n and CRYPTO_DEV_FSL_DPAA2_CAAM=m, as mentioned in 82c7b351be3f ("Revert "arm64: defconfig: Enable FSL_MC_BUS and FSL_MC_DPIO"") To fix all these, move the symbols shared by these drivers in a common location. The only existing possibility is error.c file (note that naming doesn't help and should probably change). Fixes: 52813ab24959 ("crypto: caam/qi2 - avoid double export") Reported-by: Arnd Bergmann Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam/qi2 - add DPAA2-CAAM driver

2018-09-21T05:24:51+00:00

Add CAAM driver that works using the DPSECI backend, i.e. manages DPSECI DPAA2 objects sitting on the Management Complex (MC) fsl-mc bus. Data transfers (crypto requests) are sent/received to/from CAAM crypto engine via Queue Interface (v2), this being similar to existing caam/qi. OTOH, configuration/setup (obtaining virtual queue IDs, authorization etc.) is done by sending commands to the MC f/w. Note that the CAAM accelerator included in DPAA2 platforms still has Job Rings. However, the driver being added does not handle access via this backend. Kconfig & Makefile are updated such that DPAA2-CAAM (a.k.a. "caam/qi2") driver does not depend on caam/jr or caam/qi backends - which rely on platform bus support (ctrl.c). Support for the following aead and authenc algorithms is also added in this patch: -aead: gcm(aes) rfc4106(gcm(aes)) rfc4543(gcm(aes)) -authenc: authenc(hmac({md5,sha*}),cbc({aes,des,des3_ede})) echainiv(authenc(hmac({md5,sha*}),cbc({aes,des,des3_ede}))) authenc(hmac({md5,sha*}),rfc3686(ctr(aes)) seqiv(authenc(hmac({md5,sha*}),rfc3686(ctr(aes))) Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - add Queue Interface v2 error codes

2018-09-21T05:24:51+00:00

Add support to translate error codes returned by QI v2, i.e. Queue Interface present on DataPath Acceleration Architecture v2 (DPAA2). Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu