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: 6c3af95593 ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
