summaryrefslogtreecommitdiffstats
path: root/drivers/crypto/caam/regs.h
Commit message (Collapse)AuthorAgeFilesLines
* crypto: caam - treat SGT address pointer as u64Tudor Ambarus2016-10-021-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>
* crypto: caam - fix misspelled upper_32_bitsArnd Bergmann2016-06-201-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>
* crypto: caam - handle core endianness != caam endiannessHoria Geantă2016-05-311-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>
* crypto: caam - enable LARGE_BURST for enhancing DMA transactions sizeHoria Geant?2016-01-251-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>
* crypto: caam - add support for LS1021AHoria Geant?2015-08-181-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>
* crypto: caam - Detect hardware features during algorithm registrationVictoria Milhoan2015-08-101-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>
* crypto: caam - Add setbits32/clrbits32/clrsetbits primitives for ARM ↵Victoria Milhoan2015-08-101-0/+23
| | | | | | | | | | | compatibility 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>
* crypto: caam - fix snooping for write transactionsHoria Geant?2015-07-201-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>
* crypto: caam - fix non-64-bit write/read accessSteffen Trumtrar2015-06-181-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>
* crypto: caam - Dynamic allocation of addresses for various memory blocks in ↵Nitesh Narayan Lal2014-09-151-30/+8
| | | | | | | | | | | | | | | | | | | | CAAM. 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>
* crypto: caam - enable raw data instead of von Neumann dataAlex Porosanu2014-08-251-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>
* crypto: caam - change starting entropy delay valueAlex Porosanu2014-08-251-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>
* crypto: caam - disable RNG oscillator maximum frequency checkAlex Porosanu2014-08-251-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>
* crypto: caam - Add definition of rd/wr_reg64 for little endian platformRuchika Gupta2014-06-251-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>
* crypto: caam - Configuration for platforms with virtualization enabled in CAAMRuchika Gupta2014-06-251-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>
* crypto: caam - Correct definition of registers in memory mapRuchika Gupta2014-06-251-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>
* crypto: caam - writel() arguments are swappedDan Carpenter2014-02-271-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>
* crypto: caam - enable instantiation of all RNG4 state handlesAlex Porosanu2013-09-131-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>
* crypto: caam - fix RNG4 instantiationAlex Porosanu2013-09-131-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>
* crypto: caam - RNG instantiation by directly programming DECORuchika Gupta2013-08-011-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>
* crypto: caam - FIX RNG init for RNG greater than equal to 4Ruchika Gupta2013-05-141-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>
* crypto: caam - set RDB bit in security configuration registerVakul Garg2013-03-221-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>
* crypto: caam - ERA retrieval and printing for SEC deviceAlex Porosanu2012-07-111-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>
* crypto: caam - add support for SEC v5.x RNG4Kim Phillips2012-06-271-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>
* crypto: caam - remove DECO access initialization codeKim Phillips2011-12-201-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>
* crypto: caam - fix queue interface detectionKim Phillips2011-05-031-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>
* crypto: caam - Add support for the Freescale SEC4/CAAMKim Phillips2011-03-271-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>
OpenPOWER on IntegriCloud