kernel.git/drivers/crypto/talitos.h, branch linux-4.9.y

crypto: talitos - add new crypto modes

2015-12-04T14:29:56Z

This patch adds the following algorithms to the talitos driver: * ecb(aes) * ctr(aes) * ecb(des) * cbc(des) * ecb(des3_ede) Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu

crypto: talitos - Prevent panic in probe error path

2015-08-10T15:19:05Z

The probe error path for this driver, for all intents and purposes, is the talitos_remove() function due to the common "goto err_out". Without this patch applied, talitos_remove() will panic under these two conditions: 1. If the RNG device hasn't been registered via talitos_register_rng() prior to entry into talitos_remove(), then the attempt to unregister the RNG "device" will cause a panic. 2. If the priv->chan array has not been allocated prior to entry into talitos_remove(), then the per-channel FIFO cleanup will panic because of the dereference of that NULL "array". Both of the above scenarios occur if talitos_probe_irq() fails. This patch resolves issue #1 by introducing a boolean to mask the hwrng_unregister() call in talitos_unregister_rng() if RNG device registration was unsuccessful. It resolves issue #2 by checking that priv->chan is not NULL in the per-channel FIFO cleanup for loop. Signed-off-by: Aaron Sierra Signed-off-by: Herbert Xu

crypto: talitos - Remove zero_entry static initializer

2015-08-04T09:41:33Z

Compiling the talitos driver with my GCC 4.3.1 e500v2 cross-compiler resulted in a failed build due to the anonymous union/structures introduced in this commit: crypto: talitos - enhanced talitos_desc struct for SEC1 The build error was: drivers/crypto/talitos.h:56: error: unknown field 'len' specified in initializer drivers/crypto/talitos.h:56: warning: missing braces around initializer drivers/crypto/talitos.h:56: warning: (near initialization for 'zero_entry.') drivers/crypto/talitos.h:57: error: unknown field 'j_extent' specified in initializer drivers/crypto/talitos.h:58: error: unknown field 'eptr' specified in initializer drivers/crypto/talitos.h:58: warning: excess elements in struct initializer drivers/crypto/talitos.h:58: warning: (near initialization for 'zero_entry') make[2]: *** [drivers/crypto/talitos.o] Error 1 make[1]: *** [drivers/crypto] Error 2 make: *** [drivers] Error 2 This patch eliminates the errors by relying on the C standard's implicit assignment of zero to static variables. Signed-off-by: Aaron Sierra Signed-off-by: Herbert Xu

crypto: talitos - implement scatter/gather copy for SEC1

2015-04-21T01:14:42Z

SEC1 doesn't support scatter/gather, SEC1 doesn't handle link tables. Therefore, for SEC1 we have to do it by SW. For that, we reserve space at the end of the extended descriptor, in lieu of the space reserved for the link tables on SEC2, and we perform sg_copy() when preparing the descriptors We also adapt the max buffer size which is only 32k on SEC1 while it is 64k on SEC2+ Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu

crypto: talitos - adapt interrupts and reset functions to SEC1

2015-04-21T01:14:42Z

This patch adapts the interrupts handling and reset function for SEC1. On SEC1, registers are almost similar to SEC2+, but bits are sometimes located at different places. So we need to define TALITOS1 and TALITOS2 versions of some fields, and manage according to whether it is SEC1 or SEC2. On SEC1, only one interrupt vector is dedicated to the SEC, so only interrupt_4ch is needed. On SEC1, interrupts are enabled by clearing related bits in IMR, while on SEC2, interrupts are enabled by seting the bits in IMR. SEC1 also performs parity verification in the DES Unit. We have to disable this feature because the test vectors provided in the kernel have parity errors. In reset functions, only SEC2 supports continuation after error. For SEC1, we have to reset in all cases. For errors handling, SEC2+ names have been kept, but displayed text have been amended to reflect exact meaning on SEC1. Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu

crypto: talitos - base address for Execution Units

2015-04-21T01:14:42Z

SEC 1.0, 1.2 and 2.x+ have different EU base addresses, so we need to define pointers for each EU in the driver private data structure. The proper address is set by the probe function depending on the SEC type, in order to provide access to the proper address. Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu

crypto: talitos - adaptation of talitos_submit() for SEC1

2015-04-21T01:14:42Z

SEC1 descriptor is a bit different to SEC2+ descriptor. talitos_submit() will have to copy hdr field into hdr1 field and send the descriptor starting at hdr1 up to next_desc. For SEC2, it remains unchanged and next_desc is just ignored. Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu

crypto: talitos - Add a feature to tag SEC1

2015-04-21T01:14:41Z

We add a new feature in the features field, to mark compatible "fsl,sec1.0" We also define a helper function called has_ftr_sec1() to help functions quickly determine if they are running on SEC1 or SEC2+. When only SEC1 or SEC2 is compiled in, has_ftr_sec1() return trivial corresponding value. If both are compiled in, feature field is checked. Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu

crypto: talitos - enhanced talitos_desc struct for SEC1

2015-04-21T01:14:40Z

This patch enhances the talitos_desc struct with fields for SEC1. SEC1 has only one header field, and has a 'next_desc' field in addition. This mixed descriptor will continue to fit SEC2, and for SEC1 we will recopy hdr value into hdr1 value in talitos_submit() Signed-off-by: Christophe Leroy Signed-off-by: Herbert Xu

crypto: talitos - add sha224, sha384 and sha512 to existing AEAD algorithms

2012-07-11T03:08:29Z

With this, now all combinations of CBC: AES, 3DES-EDE with HMAC: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 are supported. Signed-off-by: Horia Geanta Signed-off-by: Herbert Xu