wireguard-linux/drivers/crypto/caam/qi.c, branch jd/unified-crypt-queue

crypto: caam/qi - optimize frame queue cleanup

2020-02-13T09:05:25Z

Add reference counter incremented for each frame enqueued in CAAM and replace unconditional sleep in empty_caam_fq() with polling the reference counter. When CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y boot time on LS1043A platform with this optimization decreases from ~1100s to ~11s. Signed-off-by: Valentin Ciocoi Radulescu Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - use devres to de-initialize QI

2019-11-01T05:38:30Z

Use devres to de-initialize the QI and drop explicit de-initialization code in caam_remove(). Signed-off-by: Andrey Smirnov Reviewed-by: Horia Geantă Cc: Chris Healy Cc: Lucas Stach Cc: Horia Geantă Cc: Herbert Xu Cc: Iuliana Prodan 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:45Z

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:44Z

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/qi - fix address translations with IOMMU enabled

2019-05-23T06:01:04Z

When IOMMU is enabled, iova -> phys address translation should be performed using iommu_ops, not dma_to_phys(). Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam/qi - don't allocate an extra platform device

2019-05-23T06:01:04Z

Use the controller device for caam/qi instead of allocating a new platform device. This is needed as a preparation to add support for working behind an SMMU. A platform device allocated using platform_device_register_full() is not completely set up - most importantly .dma_configure() is not called. Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - avoid S/G table fetching for AEAD zero-length output

2019-05-23T06:01:03Z

When enabling IOMMU support, the following issue becomes visible in the AEAD zero-length case. Even though the output sequence length is set to zero, the crypto engine tries to prefetch 4 S/G table entries (since SGF bit is set in SEQ OUT PTR command - which is either generated in SW in case of caam/jr or in HW in case of caam/qi, caam/qi2). The DMA read operation will trigger an IOMMU fault since the address in the SEQ OUT PTR is "dummy" (set to zero / not obtained via DMA API mapping). 1. In case of caam/jr, avoid the IOMMU fault by clearing the SGF bit in SEQ OUT PTR command. 2. In case of caam/qi - setting address, bpid, length to zero for output entry in the compound frame has a special meaning (cf. CAAM RM): "Output frame = Unspecified, Input address = Y. A unspecified frame is indicated by an unused SGT entry (an entry in which the Address, Length, and BPID fields are all zero). SEC obtains output buffers from BMan as prescribed by the preheader." Since no output buffers are needed, modify the preheader by setting (ABS = 1, ADDBUF = 0): -"ABS = 1 means obtain the number of buffers in ADDBUF (0 or 1) from the pool POOL ID" -ADDBUF: "If ABS is set, ADD BUF specifies whether to allocate a buffer or not" 3. In case of caam/qi2, since engine: -does not support FLE[FMT]=2'b11 ("unused" entry) mentioned in DPAA2 RM -requires output entry to be present, even if not used the solution chosen is to leave output frame list entry zeroized. Fixes: 763069ba49d3 ("crypto: caam - handle zero-length AEAD output") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam/qi - Change a couple IS_ERR_OR_NULL() checks to IS_ERR()

2019-04-08T06:36:16Z

create_caam_req_fq() doesn't return NULL pointers so there is no need to check. The NULL checks are problematic because it's hard to say how a NULL return should be handled, so removing the checks is a nice cleanup. Signed-off-by: Dan Carpenter Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - remove redundant likely/unlikely annotation

2019-02-28T06:17:59Z

unlikely has already included in IS_ERR(), so just remove redundant likely/unlikely annotation. Signed-off-by: Chengguang Xu Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam/qi - simplify CGR allocation, freeing

2018-10-17T06:14:46Z

CGRs (Congestion Groups) have to be freed by the same CPU that initialized them. This is why currently the driver takes special measures; however, using set_cpus_allowed_ptr() is incorrect - as reported by Sebastian. Instead of the generic solution of replacing set_cpus_allowed_ptr() with work_on_cpu_safe(), we use the qman_delete_cgr_safe() QBMan API instead of qman_delete_cgr() - which internally takes care of proper CGR deletion. Link: https://lkml.kernel.org/r/20181005125443.dfhd2asqktm22ney@linutronix.de Reported-by: Sebastian Andrzej Siewior Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu