aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/crypto/caam/regs.h (follow)
AgeCommit message (Collapse)AuthorFilesLines
2022-05-23crypto: caam - determine whether CAAM supports blob encap/decapAhmad Fatoum1-1/+3
Depending on SoC variant, a CAAM may be available, but with some futures fused out. The LS1028A (non-E) SoC is one such SoC and while it indicates BLOB support, BLOB operations will ultimately fail, because there is no AES support. Add a new blob_present member to reflect whether both BLOB support and the AES support it depends on is available. These will be used in a follow-up commit to allow blob driver initialization to error out on SoCs without the necessary hardware support instead of failing at runtime with a cryptic caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected. Co-developed-by: Michael Walle <michael@walle.cc> Signed-off-by: Michael Walle <michael@walle.cc> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
2021-09-24crypto: caam - disable pkc for non-E SoCsMichael Walle1-0/+3
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 <michael@walle.cc> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-07-31crypto: caam - remove deadcode on 32-bit platformsFranck LENORMAND1-3/+8
When building on a platform with a 32bit DMA address, taking the upper 32 bits makes no sense. Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com> Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-03-30crypto: caam - enable prediction resistance in HRWNGAndrey Smirnov1-1/+3
Instantiate CAAM RNG with prediction resistance enabled to improve its quality (with PR on DRNG is forced to reseed from TRNG every time random data is generated). Management Complex firmware with version lower than 10.20.0 doesn't provide prediction resistance support. Consider this and only instantiate rng when mc f/w version is lower. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Andrei Botila <andrei.botila@nxp.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-imx@nxp.com Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2020-03-30crypto: caam - invalidate entropy register during RNG initializationAndrey Smirnov1-1/+2
In order to make sure that we always use non-stale entropy data, change the code to invalidate entropy register during RNG initialization. Signed-off-by: Aymen Sghaier <aymen.sghaier@nxp.com> Signed-off-by: Vipul Kumar <vipul_kumar@mentor.com> [andrew.smirnov@gmail.com ported to upstream kernel, rewrote commit msg] Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Iuliana Prodan <iuliana.prodan@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-imx@nxp.com Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-30crypto: caam - select DMA address size at runtimeAndrey Smirnov1-10/+30
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 <andrew.smirnov@gmail.com> Cc: Chris Spencer <christopher.spencer@sea.co.uk> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-30crypto: caam - don't hardcode inpentry sizeAndrey Smirnov1-0/+9
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 <andrew.smirnov@gmail.com> Cc: Chris Spencer <christopher.spencer@sea.co.uk> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-30crypto: caam - drop explicit usage of struct jr_outentryAndrey Smirnov1-4/+36
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 <andrew.smirnov@gmail.com> Cc: Chris Spencer <christopher.spencer@sea.co.uk> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-30crypto: caam - move cpu_to_caam_dma() selection to runtimeAndrey Smirnov1-7/+15
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 <andrew.smirnov@gmail.com> Cc: Chris Spencer <christopher.spencer@sea.co.uk> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-30crypto: caam - drop 64-bit only wr/rd_reg64()Andrey Smirnov1-19/+0
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 <andrew.smirnov@gmail.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Cc: Chris Spencer <christopher.spencer@sea.co.uk> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-30crypto: caam - use ioread64*_hi_lo in rd_reg64Andrey Smirnov1-5/+13
Following the same transformation logic as outlined in previous commit converting wr_reg64, convert rd_reg64 to use helpers from <linux/io-64-nonatomic-hi-lo.h> first. No functional change intended. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Cc: Chris Spencer <christopher.spencer@sea.co.uk> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-30crytpo: caam - make use of iowrite64*_hi_lo in wr_reg64Andrey Smirnov1-5/+9
In order to be able to unify 64 and 32 bit implementations of wr_reg64, let's convert it to use helpers from <linux/io-64-nonatomic-hi-lo.h> 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 <linux/io-64-nonatomic-hi-lo.h> 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 <andrew.smirnov@gmail.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Cc: Chris Spencer <christopher.spencer@sea.co.uk> Cc: Cory Tusar <cory.tusar@zii.aero> Cc: Chris Healy <cphealy@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Horia Geantă <horia.geanta@nxp.com> Cc: Aymen Sghaier <aymen.sghaier@nxp.com> Cc: Leonard Crestez <leonard.crestez@nxp.com> Cc: linux-crypto@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-08-09crypto: caam/qi - fix error handling in ERN handlerHoria Geantă1-0/+1
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: <stable@vger.kernel.org> # v5.1+ Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend support") Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-05-09Revert "crypto: caam/jr - Remove extra memory barrier during job ring dequeue"Herbert Xu1-8/+0
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 <herbert@gondor.apana.org.au>
2019-04-25crypto: caam/jr - update gcm detection logicHoria Geantă1-0/+3
GCM detection logic has to change for two reasons: -some CAAM instantiations with Era < 10, even though they have AES LP, they now support GCM mode -Era 10 upwards, there is a dedicated bit in AESA_VERSION[AESA_MISC] field for GCM support For Era 9 and earlier, all AES accelerator versions support GCM, except for AES LP (CHAVID_LS[AESVID]=3) with revision CRNR[AESRN] < 8. For Era 10 and later, bit 9 of the AESA_VERSION register should be used to detect GCM support in AES accelerator. Note: caam/qi and caam/qi2 are drivers for QI (Queue Interface), which is used in DPAA-based SoCs; for now, we rely on CAAM having an AES HP and this AES accelerator having support for GCM. Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Reviewed-by: Iuliana Prodan <iuliana.prodan@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-04-18crypto: caam/jr - Remove extra memory barrier during job ring dequeueVakul Garg1-0/+8
In function caam_jr_dequeue(), a full memory barrier is used before writing response job ring's register to signal removal of the completed job. Therefore for writing the register, we do not need another write memory barrier. Hence it is removed by replacing the call to wr_reg32() with a newly defined function wr_reg32_relaxed(). Signed-off-by: Vakul Garg <vakul.garg@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-11-16crypto: caam - add register map changes cf. Era 10Horia Geantă1-10/+64
Era 10 changes the register map. The updates that affect the drivers: -new version registers are added -DBG_DBG[deco_state] field is moved to a new register - DBG_EXEC[19:16] @ 8_0E3Ch. Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-09-21crypto: caam - add Queue Interface v2 error codesHoria Geantă1-0/+2
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ă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-09-21crypto: caam - fix implicit casts in endianness helpersHoria Geantă1-14/+14
Fix the following sparse endianness warnings: drivers/crypto/caam/regs.h:95:1: sparse: incorrect type in return expression (different base types) @@ expected unsigned int @@ got restricted __le32unsigned int @@ drivers/crypto/caam/regs.h:95:1: expected unsigned int drivers/crypto/caam/regs.h:95:1: got restricted __le32 [usertype] <noident> drivers/crypto/caam/regs.h:95:1: sparse: incorrect type in return expression (different base types) @@ expected unsigned int @@ got restricted __be32unsigned int @@ drivers/crypto/caam/regs.h:95:1: expected unsigned int drivers/crypto/caam/regs.h:95:1: got restricted __be32 [usertype] <noident> drivers/crypto/caam/regs.h:92:1: sparse: cast to restricted __le32 drivers/crypto/caam/regs.h:92:1: sparse: cast to restricted __be32 Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-04-21crypto: caam - allow retrieving 'era' from registerFabio Estevam1-0/+6
The 'era' information can be retrieved from CAAM registers, so introduce a caam_get_era_from_hw() function that gets it via register reads in case the 'fsl,sec-era' property is not passed in the device tree. This function is based on the U-Boot implementation from drivers/crypto/fsl/sec.c Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Tested-by: Breno Lima <breno.lima@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-09-20crypto: caam - fix LS1021A support on ARMv7 multiplatform kernelHoria Geantă1-31/+28
When built using multi_v7_defconfig, driver does not work on LS1021A: [...] caam 1700000.crypto: can't identify CAAM ipg clk: -2 caam: probe of 1700000.crypto failed with error -2 [...] It turns out we have to detect at runtime whether driver is running on an i.MX platform or not. Cc: <stable@vger.kernel.org> Fixes: 6c3af9559352 ("crypto: caam - add support for LS1021A") Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-08-03crypto: caam/jr - add support for DPAA2 partsHoria Geantă1-0/+1
Add support for using the caam/jr backend on DPAA2-based SoCs. These have some particularities we have to account for: -HW S/G format is different -Management Complex (MC) firmware initializes / manages (partially) the CAAM block: MCFGR, QI enablement in QICTL, RNG Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-10-02crypto: caam - treat SGT address pointer as u64Tudor Ambarus1-0/+8
Even for i.MX, CAAM is able to use address pointers greater than 32 bits, the address pointer field being interpreted as a double word. Enforce u64 address pointer in the sec4_sg_entry struct. This patch fixes the SGT address pointer endianness issue for 32bit platforms where core endianness != caam endianness. Signed-off-by: Tudor Ambarus <tudor-dan.ambarus@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-06-20crypto: caam - fix misspelled upper_32_bitsArnd Bergmann1-2/+2
An endianess fix mistakenly used higher_32_bits() instead of upper_32_bits(), and that doesn't exist: drivers/crypto/caam/desc_constr.h: In function 'append_ptr': drivers/crypto/caam/desc_constr.h:84:75: error: implicit declaration of function 'higher_32_bits' [-Werror=implicit-function-declaration] *offset = cpu_to_caam_dma(ptr); Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness") Reviewed-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-05-31crypto: caam - handle core endianness != caam endiannessHoria Geantă1-50/+101
There are SoCs like LS1043A where CAAM endianness (BE) does not match the default endianness of the core (LE). Moreover, there are requirements for the driver to handle cases like CPU_BIG_ENDIAN=y on ARM-based SoCs. This requires for a complete rewrite of the I/O accessors. PPC-specific accessors - {in,out}_{le,be}XX - are replaced with generic ones - io{read,write}[be]XX. Endianness is detected dynamically (at runtime) to allow for multiplatform kernels, for e.g. running the same kernel image on LS1043A (BE CAAM) and LS2080A (LE CAAM) armv8-based SoCs. While here: debugfs entries need to take into consideration the endianness of the core when displaying data. Add the necessary glue code so the entries remain the same, but they are properly read, regardless of the core and/or SEC endianness. Note: pdb.h fixes only what is currently being used (IPsec). Reviewed-by: Tudor Ambarus <tudor-dan.ambarus@nxp.com> Signed-off-by: Horia Geantă <horia.geanta@nxp.com> Signed-off-by: Alex Porosanu <alexandru.porosanu@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-01-25crypto: caam - enable LARGE_BURST for enhancing DMA transactions sizeHoria Geant?1-1/+2
Increasing CAAM DMA engine transaction size either -reduces the number of required transactions or -adds the ability to transfer more data with same transaction count Signed-off-by: Horia Geant? <horia.geanta@nxp.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-08-18crypto: caam - add support for LS1021AHoria Geant?1-4/+15
LS1021A is a QorIQ SoC having little endian CAAM. There are a few differences b/w QorIQ and i.MX from CAAM perspective: 1. i.MX platforms are somewhat special wrt. 64-bit registers: -big endian format at 64-bit level: MSW at address+0 and LSW at address+4 -little endian format at 32-bit level (within MSW and LSW) and thus need special handling. 2. No CCM (clock controller module) for QorIQ. No CAAM clocks to enable / disable. A new Kconfig option - CRYPTO_DEV_FSL_CAAM_LE - is added to indicate CAAM is little endian (*). It is hidden from the user (to avoid misconfiguration); when adding support for a new platform with LE CAAM, either the Kconfig needs to be updated or the corresponding defconfig needs to indicate that CAAM is LE. (*) Using a DT property to provide CAAM endianness would not allow for the ifdeffery. In order to keep changes to a minimum, the following changes are postponed: -endianness fix of the last word in the S/G (rsvd2, bpid, offset), fields are always 0 anyway; -S/G format fix for i.MX7 (yes, i.MX7 support was not added yet, but still...) Signed-off-by: Horia Geant? <horia.geanta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-08-10crypto: caam - Detect hardware features during algorithm registrationVictoria Milhoan1-3/+13
Register only algorithms supported by CAAM hardware, using the CHA version and instantiation registers to identify hardware capabilities. Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com> Tested-by: Horia Geantă <horia.geanta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-08-10crypto: caam - Add setbits32/clrbits32/clrsetbits primitives for ARM compatibilityVictoria Milhoan1-0/+23
Add set/clear 32-bit primitives for compatibility with ARM devices since the primitives were previously only defined for the Power architecture. Signed-off-by: Victoria Milhoan <vicki.milhoan@freescale.com> Tested-by: Horia Geantă <horia.geanta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-07-20crypto: caam - fix snooping for write transactionsHoria Geant?1-0/+6
HW coherency won't work properly for CAAM write transactions if AWCACHE is left to default (POR) value - 4'b0001. It has to be programmed to 4'b0010, i.e. AXI3 Cacheable bit set. For platforms that have HW coherency support: -PPC-based: the update has no effect; CAAM coherency already works due to the IOMMU (PAMU) driver setting the correct memory coherency attributes -ARM-based: the update fixes cache coherency issues, since IOMMU (SMMU) driver is not programmed to behave similar to PAMU Signed-off-by: Horia Geant? <horia.geanta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-18crypto: caam - fix non-64-bit write/read accessSteffen Trumtrar1-19/+19
The patch crypto: caam - Add definition of rd/wr_reg64 for little endian platform added support for little endian platforms to the CAAM driver. Namely a write and read function for 64 bit registers. The only user of this functions is the Job Ring driver (drivers/crypto/caam/jr.c). It uses the functions to set the DMA addresses for the input/output rings. However, at least in the default configuration, the least significant 32 bits are always in the base+0x0004 address; independent of the endianness of the bytes itself. That means the addresses do not change with the system endianness. DMA addresses are only 32 bits wide on non-64-bit systems, writing the upper 32 bits of this value to the register for the least significant bits results in the DMA address being set to 0. Fix this by always writing the registers in the same way. Suggested-by: Russell King <linux@arm.linux.org.uk> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-09-15crypto: caam - Dynamic allocation of addresses for various memory blocks in CAAM.Nitesh Narayan Lal1-30/+8
CAAM's memory is broken into following address blocks: Block Included Registers 0 General Registers 1-4 Job ring registers 6 RTIC registers 7 QI registers 8 DECO and CCB Size of the above stated blocks varies in various platforms. The block size can be 4K or 64K. The block size can be dynamically determined by reading CTPR register in CAAM. This patch initializes the block addresses dynamically based on the value read from this register. Signed-off-by: Ruchika Gupta <r66431@freescale.com> Signed-off-by: Nitesh Narayan Lal <b44382@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-08-25crypto: caam - enable raw data instead of von Neumann dataAlex Porosanu1-0/+10
The sampling of the oscillator can be done in multiple modes for generating the entropy value. By default, this is set to von Neumann. This patch changes the sampling to raw data, since it has been discovered that the generated entropy has a better 'quality'. Signed-off-by: Alex Porosanu <alexandru.porosanu@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-08-25crypto: caam - change starting entropy delay valueAlex Porosanu1-1/+1
The entropy delay (the length in system clocks of each entropy sample) for the RNG4 block of CAAM is dependent on the frequency of the SoC. By elaborate methods, it has been determined that a good starting value for all platforms integrating the CAAM IP is 3200. Using a higher value has additional benefit of speeding up the process of instantiating the RNG, since the entropy delay will be increased and instantiation of the RNG state handles will be reattempted by the driver. If the starting value is low, for certain platforms, this can lead to a quite lengthy process. This patch changes the starting value of the length of the entropy sample to 3200 system clocks. In addition to this change, the attempted entropy delay values are now printed on the console upon initialization of the RNG block. While here, a safeguard for yielding the processor was added for ensuring that in very adverse cases, the CPU isn't hogged by the instantiation loop. Signed-off-by: Alex Porosanu <alexandru.porosanu@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-08-25crypto: caam - disable RNG oscillator maximum frequency checkAlex Porosanu1-0/+1
The rtfrqmax & rtfrqmin set the bounds of the expected frequency of the oscillator, when SEC runs at its maximum frequency. For certain platforms (f.i. T2080), the oscillator is very fast and thus if the SEC runs at a lower than normal frequency, the ring oscillator is incorrectly detected as being out of bounds. This patch effectively disables the maximum frequency check, by setting a high enough maximum allowable frequency for the oscillator. The reasoning behind this is that usually a broken oscillator will run too slow (i.e. not run at all) rather than run too fast. Signed-off-by: Alex Porosanu <alexandru.porosanu@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-25crypto: caam - Add definition of rd/wr_reg64 for little endian platformRuchika Gupta1-0/+16
CAAM IP has certain 64 bit registers . 32 bit architectures cannot force atomic-64 operations. This patch adds definition of these atomic-64 operations for little endian platforms. The definitions which existed previously were for big endian platforms. Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-25crypto: caam - Configuration for platforms with virtualization enabled in CAAMRuchika Gupta1-2/+16
For platforms with virtualization enabled 1. The job ring registers can be written to only is the job ring has been started i.e STARTR bit in JRSTART register is 1 2. For DECO's under direct software control, with virtualization enabled PL, BMT, ICID and SDID values need to be provided. These are provided by selecting a Job ring in start mode whose parameters would be used for the DECO access programming. Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-25crypto: caam - Correct definition of registers in memory mapRuchika Gupta1-33/+38
Some registers like SECVID, CHAVID, CHA Revision Number, CTPR were defined as 64 bit resgisters. The IP provides a DWT bit(Double word Transpose) to transpose the two words when a double word register is accessed. However setting this bit would also affect the operation of job descriptors as well as other registers which are truly double word in nature. So, for the IP to work correctly on big-endian as well as little-endian SoC's, change is required to access all 32 bit registers as 32 bit quantities. Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-02-27crypto: caam - writel() arguments are swappedDan Carpenter1-2/+2
My guess is that this little endian configuration is never found in real life, but if it were then the writel() arguments are in the wrong order so the driver would crash immediately. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-09-13crypto: caam - enable instantiation of all RNG4 state handlesAlex Porosanu1-1/+6
RNG4 block contains multiple (i.e. 2) state handles that can be initialized. This patch adds the necessary code for detecting which of the two state handles has been instantiated by another piece of software e.g. u-boot and instantiate the other one (or both if none was instantiated). Only the state handle(s) instantiated by this driver will be deinstantiated when removing the module. Signed-off-by: Alex Porosanu <alexandru.porosanu@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-09-13crypto: caam - fix RNG4 instantiationAlex Porosanu1-2/+5
The RNG4 block in CAAM needs to be 'seeded' first before being used for generating pseudo-random data. The 'seeding' is done by getting entropy from the TRNG ring oscillator. The RTFRQMAX register controls the maximum allowable number of samples that can be aquired during an entropy sample. Depending on the clock at which the RNG4 block (and for that matter the SEC block) runs, it's possible that a hard-coded value for the maximum frequency is inadequate, i.e. more samples than needed are taken. This is an error, and thus the RNG4 block doesn't get initialized. The patch attempts to alleviate this issue by trying with progressivly larger frequencies, until the number of samples is adequate. This patch also fixes how a descriptor is deemed as being finished: instead of checking the VALID field in the DECO debug register, it makes sure that the DECO is idle, by checking the DECO state field of the said register. Signed-off-by: Alex Porosanu <alexandru.porosanu@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-08-01crypto: caam - RNG instantiation by directly programming DECORuchika Gupta1-1/+11
Remove the dependency of RNG instantiation on Job Ring. Now RNG instantiation for devices with RNG version > 4 is done by directly programming DECO 0. Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-05-14crypto: caam - FIX RNG init for RNG greater than equal to 4Ruchika Gupta1-1/+41
For SEC including a RNG block version >= 4, special initialization must occur before any descriptor that uses RNG block can be submitted. This initialization is required not only for SEC with version greater than 5.0, but for SEC with RNG version >=4. There may be a case where RNG has already been instantiated by u-boot or boot ROM code.In such SoCs, if RNG is initialized again SEC would returns "Instantiation error". Hence, the initialization status of RNG4 should be also checked before doing RNG init. Signed-off-by: Ruchika Gupta <ruchika.gupta@freescale.com> Signed-off-by: Alex Porosanu <alexandru.porosanu@freescale.com> Signed-off-by: Andy Fleming <afleming@freescale.com> Reviewed-by: Vakul Garg <vakul@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-03-22crypto: caam - set RDB bit in security configuration registerVakul Garg1-1/+3
This change is required for post SEC-5.0 devices which have RNG4. Setting RDB in security configuration register allows CAAM to use the "Random Data Buffer" to be filled by a single request. The Random Data Buffer is large enough for ten packets to get their IVs from a single request. If the Random Data Buffer is not enabled, then each IV causes a separate request, and RNG4 hardware cannot keep up resulting in lower IPSEC throughput if random IVs are used. Signed-off-by: Vakul Garg <vakul@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-11crypto: caam - ERA retrieval and printing for SEC deviceAlex Porosanu1-0/+6
This patch adds support for retrieving and printing of SEC ERA information. It is useful for knowing beforehand what features exist from the SEC point of view on a certain SoC. Only era-s 1 to 4 are currently supported; other eras will appear as unknown. Signed-off-by: Alex Porosanu <alexandru.porosanu@freescale.com> - rebased onto current cryptodev master - made caam_eras static Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-06-27crypto: caam - add support for SEC v5.x RNG4Kim Phillips1-2/+30
The SEC v4.x' RNGB h/w block self-initialized. RNG4, available on SEC versions 5 and beyond, is based on a different standard that requires manual initialization. Also update any new errors From the SEC v5.2 reference manual: The SEC v5.2's RNG4 unit reuses some error IDs, thus the addition of rng_err_id_list over the CHA-independent err_id_list. Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-12-20crypto: caam - remove DECO access initialization codeKim Phillips1-1/+0
Access to the SEC4 DECOs (DEscriptor COntrollers) (for debug purposes) isn't supported or used, and its register access initialization code erroneously makes illegal i/o accesses that show up as errors when run under simulation. Remove it until proper support (via DECORR) is added. Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-05-03crypto: caam - fix queue interface detectionKim Phillips1-1/+1
The presence of a h/w Queue Interface would fail due to this cut-n-paste snafu. Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-03-27crypto: caam - Add support for the Freescale SEC4/CAAMKim Phillips1-0/+663
The SEC4 supercedes the SEC2.x/3.x as Freescale's Integrated Security Engine. Its programming model is incompatible with all prior versions of the SEC (talitos). The SEC4 is also known as the Cryptographic Accelerator and Assurance Module (CAAM); this driver is named caam. This initial submission does not include support for Data Path mode operation - AEAD descriptors are submitted via the job ring interface, while the Queue Interface (QI) is enabled for use by others. Only AEAD algorithms are implemented at this time, for use with IPsec. Many thanks to the Freescale STC team for their contributions to this driver. Signed-off-by: Steve Cornelius <sec@pobox.com> Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>