kernel.git/drivers/crypto/caam/regs.h, branch linux-5.4.y

crypto: caam - disable pkc for non-E SoCs

2021-11-17T08:48:34Z

[ Upstream commit f20311cc9c58052e0b215013046cbf390937910c ] On newer CAAM versions, not all accelerators are disabled if the SoC is a non-E variant. While the driver checks most of the modules for availability, there is one - PKHA - which sticks out. On non-E variants it is still reported as available, that is the number of instances is non-zero, but it has limited functionality. In particular it doesn't support encryption and decryption, but just signing and verifying. This is indicated by a bit in the PKHA_MISC field. Take this bit into account if we are checking for availability. This will the following error: [ 8.167817] caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected. Tested on an NXP LS1028A (non-E) SoC. Fixes: d239b10d4ceb ("crypto: caam - add register map changes cf. Era 10") Signed-off-by: Michael Walle Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: caam - select DMA address size at runtime

2019-08-30T08:05:30Z

i.MX8 mScale SoC still use 32-bit addresses in its CAAM implmentation, so we can't rely on sizeof(dma_addr_t) to detemine CAAM pointer size. Convert the code to query CTPR and MCFGR for that during driver probing. 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 - don't hardcode inpentry size

2019-08-30T08:05:30Z

Using dma_addr_t for elements of JobR input ring is not appropriate on all 64-bit SoCs, some of which, like i.MX8MQ, use only 32-bit wide pointers there. Convert all of the code to use explicit helper function that can be later extended to support i.MX8MQ. 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 - drop explicit usage of struct jr_outentry

2019-08-30T08:05:30Z

Using struct jr_outentry to specify the layout of JobR output ring is not appropriate for all 64-bit SoC, since some of them, like i.MX8MQ, use 32-bit pointers there which doesn't match 64-bit dma_addr_t. Convert existing code to use explicit helper functions to access any of the JobR output ring elements, so that the support for i.MX8MQ can be added later. 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 - move cpu_to_caam_dma() selection to runtime

2019-08-30T08:05:30Z

Instead of selecting the implementation of cpu_to_caam_dma()/caam_dma_to_cpu() at build time using the preprocessor, convert the code to do that at run-time using IS_ENABLED macro. This is needed to add support for i.MX8MQ. 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 - drop 64-bit only wr/rd_reg64()

2019-08-30T08:05:29Z

Since 32-bit of both wr_reg64 and rd_reg64 now use 64-bit IO helpers, these functions should no longer be necessary. No functional change intended. Signed-off-by: Andrey Smirnov Reviewed-by: Horia Geantă 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 - use ioread64*_hi_lo in rd_reg64

2019-08-30T08:05:29Z

Following the same transformation logic as outlined in previous commit converting wr_reg64, convert rd_reg64 to use helpers from first. No functional change intended. Signed-off-by: Andrey Smirnov Reviewed-by: Horia Geantă 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

crytpo: caam - make use of iowrite64*_hi_lo in wr_reg64

2019-08-30T08:05:29Z

In order to be able to unify 64 and 32 bit implementations of wr_reg64, let's convert it to use helpers from first. Here are the steps of the transformation: 1. Inline wr_reg32 helpers: if (!caam_imx && caam_little_end) { if (caam_little_end) { iowrite32(data >> 32, (u32 __iomem *)(reg) + 1); iowrite32(data, (u32 __iomem *)(reg)); } else { iowrite32be(data >> 32, (u32 __iomem *)(reg) + 1); iowrite32be(data, (u32 __iomem *)(reg)); } } else { if (caam_little_end) { iowrite32(data >> 32, (u32 __iomem *)(reg)); iowrite32(data, (u32 __iomem *)(reg) + 1); } else { iowrite32be(data >> 32, (u32 __iomem *)(reg)); iowrite32be(data, (u32 __iomem *)(reg) + 1); } } 2. Transfrom the conditionals such that the check for 'caam_little_end' is at the top level: if (caam_little_end) { if (!caam_imx) { iowrite32(data >> 32, (u32 __iomem *)(reg) + 1); iowrite32(data, (u32 __iomem *)(reg)); } else { iowrite32(data >> 32, (u32 __iomem *)(reg)); iowrite32(data, (u32 __iomem *)(reg) + 1); } } else { iowrite32be(data >> 32, (u32 __iomem *)(reg)); iowrite32be(data, (u32 __iomem *)(reg) + 1); } 3. Invert the check for !caam_imx: if (caam_little_end) { if (caam_imx) { iowrite32(data >> 32, (u32 __iomem *)(reg)); iowrite32(data, (u32 __iomem *)(reg) + 1); } else { iowrite32(data >> 32, (u32 __iomem *)(reg) + 1); iowrite32(data, (u32 __iomem *)(reg)); } } else { iowrite32be(data >> 32, (u32 __iomem *)(reg)); iowrite32be(data, (u32 __iomem *)(reg) + 1); } 4. Make use of iowrite64* helpers from if (caam_little_end) { if (caam_imx) { iowrite32(data >> 32, (u32 __iomem *)(reg)); iowrite32(data, (u32 __iomem *)(reg) + 1); } else { iowrite64(data, reg); } } else { iowrite64be(data, reg); } No functional change intended. Signed-off-by: Andrey Smirnov Reviewed-by: Horia Geantă 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/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

Revert "crypto: caam/jr - Remove extra memory barrier during job ring dequeue"

2019-05-09T05:20:48Z

This reverts commit bbfcac5ff5f26aafa51935a62eb86b6eacfe8a49. It caused a crash regression on powerpc: https://lore.kernel.org/linux-crypto/87pnp2aflz.fsf@concordia.ellerman.id.au/ Signed-off-by: Herbert Xu