kernel/linux.git/drivers/crypto/caam/qi.c, branch v6.3

crypto: caam - Fix edesc/iv ordering mixup

2023-02-28T08:30:58+00:00

The attempt to add DMA alignment padding by moving IV to the front of edesc was completely broken as it didn't change the places where edesc was freed. It's also wrong as the IV may still share a cache-line with the edesc. Fix this by restoring the original layout and simply reserving enough memmory so that the IV is on a DMA cache-line by itself. Reported-by: Meenakshi Aggarwal Fixes: 199354d7fb6e ("crypto: caam - Remove GFP_DMA and add DMA alignment padding") Signed-off-by: Herbert Xu

crypto: caam - Remove GFP_DMA and add DMA alignment padding

2023-01-06T09:15:47+00:00

GFP_DMA does not guarantee that the returned memory is aligned for DMA. It should be removed where it is superfluous. However, kmalloc may start returning DMA-unaligned memory in future so fix this by adding the alignment by hand. Signed-off-by: Herbert Xu

crypto: caam/qi2 - switch to netif_napi_add_tx_weight()

2022-07-15T08:43:21+00:00

caam has its own special NAPI weights. It's also a crypto device so presumably it can't be used for packet Rx. Switch to the (new) correct API. Signed-off-by: Jakub Kicinski Signed-off-by: Herbert Xu

crypto: caam - drop unexpected word 'a' in comments

2022-06-30T07:56:57+00:00

Drop the unexpected word 'a' in the comments that need to be dropped * This is a a cache of buffers, from which the users of CAAM QI driver --> * This is a cache of buffers, from which the users of CAAM QI driver Signed-off-by: Jiang Jian Reviewed-by: Gaurav Jain Signed-off-by: Herbert Xu

crypto: caam: Replace in_irq() usage.

2020-11-04T01:41:38+00:00

The driver uses in_irq() + in_serving_softirq() magic to decide if NAPI scheduling is required or packet processing. The usage of in_*() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Use the `sched_napi' argument passed by the callback. It is set true if called from the interrupt handler and NAPI should be scheduled. Signed-off-by: Sebastian Andrzej Siewior Cc: Aymen Sghaier Cc: Herbert Xu Cc: Li Yang Reviewed-by: Horia Geantă Signed-off-by: Jakub Kicinski Reviewed-by: Madalin Bucur Tested-by: Camelia Groza

soc/fsl/qbman: Add an argument to signal if NAPI processing is required.

2020-11-04T01:41:03+00:00

dpaa_eth_napi_schedule() and caam_qi_napi_schedule() schedule NAPI if invoked from: - Hard interrupt context - Any context which is not serving soft interrupts Any context which is not serving soft interrupts includes hard interrupts so the in_irq() check is redundant. caam_qi_napi_schedule() has a comment about this: /* * In case of threaded ISR, for RT kernels in_irq() does not return * appropriate value, so use in_serving_softirq to distinguish between * softirq and irq contexts. */ if (in_irq() || !in_serving_softirq()) This has nothing to do with RT. Even on a non RT kernel force threaded interrupts run obviously in thread context and therefore in_irq() returns false when invoked from the handler. The extension of the in_irq() check with !in_serving_softirq() was there when the drivers were added, but in the out of tree FSL BSP the original condition was in_irq() which got extended due to failures on RT. The usage of in_xxx() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. Right he is, the above construct is clearly showing why. The following callchains have been analyzed to end up in dpaa_eth_napi_schedule(): qman_p_poll_dqrr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() portal_isr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() Both need to schedule NAPI. The crypto part has another code path leading up to this: kill_fq() empty_retired_fq() qman_p_poll_dqrr() __poll_portal_fast() fq->cb.dqrr() dpaa_eth_napi_schedule() kill_fq() is called from task context and ends up scheduling NAPI, but that's pointless and an unintended side effect of the !in_serving_softirq() check. The code path: caam_qi_poll() -> qman_p_poll_dqrr() is invoked from NAPI and I *assume* from crypto's NAPI device and not from qbman's NAPI device. I *guess* it is okay to skip scheduling NAPI (because this is what happens now) but could be changed if it is wrong due to `budget' handling. Add an argument to __poll_portal_fast() which is true if NAPI needs to be scheduled. This requires propagating the value to the caller including `qman_cb_dqrr' typedef which is used by the dpaa and the crypto driver. Signed-off-by: Sebastian Andrzej Siewior Cc: Aymen Sghaier Cc: Herbert XS Cc: Li Yang Reviewed-by: Horia Geantă Signed-off-by: Jakub Kicinski Reviewed-by: Madalin Bucur Tested-by: Camelia Groza

crypto: caam - Move debugfs fops into standalone file

2020-08-21T04:47:49+00:00

Currently the debugfs fops are defined in caam/intern.h. This causes problems because it creates identical static functions and variables in multiple files. It also creates warnings when those files don't use the fops. This patch moves them into a standalone file, debugfs.c. It also removes unnecessary uses of ifdefs on CONFIG_DEBUG_FS. Signed-off-by: Herbert Xu [Moved most of debugfs-related operations into debugfs.c.] Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam/qi - optimize frame queue cleanup

2020-02-13T09:05:25+00:00

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:30+00:00

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