On 06/11/2015 07:59 PM, Herbert Xu wrote:
+int crypto_akcipher_setkey(struct crypto_akcipher *tfm,
+ const struct public_key *pkey)
+{
+ if (tfm-pkey)
+ akcipher_free_key(tfm-pkey);
+
+ return akcipher_clone_key(tfm, pkey);
+}
No please do not expose
-Original Message-
From: Suravee Suthikulpanit [mailto:suravee.suthikulpa...@amd.com]
Sent: Wednesday, June 10, 2015 9:39 PM
To: r...@rjwysocki.net; l...@kernel.org; catalin.mari...@arm.com;
will.dea...@arm.com; thomas.lenda...@amd.com;
herb...@gondor.apana.org.au; da...@davemloft.net;
On Thu, Jun 11, 2015 at 11:50:06PM -0700, Tadeusz Struk wrote:
Should I make it MPI[] rather than void *
It should be in encoded format since only the algorithms should
be decoding it. Otherwise you have craziness where RSA-specific
knowledge is placed into x509_cert_parser.c to parse RSA
Hello,
This patch series adds a new driver supporting Marvell's CESA IP.
This driver addresses some limitations of the existing one.
From a performance and CPU load point of view the most important
limitation in the existing driver is the lack of DMA support, thus
preventing us from chaining
From: Arnaud Ebalard a...@natisbad.org
Add support for SHA256 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not
We are about to add a new driver to support new features like using the
TDMA engine to offload the CPU.
Orion, Dove and Kirkwood platforms are already using the mv_cesa driver,
but Orion SoCs do not embed the TDMA engine, which means we will have to
differentiate them if we want to get TDMA
From: Arnaud Ebalard a...@natisbad.org
Add the Kirkwood and Dove SoC descriptions, and control the allhwsupport
module parameter to avoid probing the CESA IP when the old CESA driver is
enabled (unless it is explicitly requested to do so).
Signed-off-by: Arnaud Ebalard a...@natisbad.org
From: Arnaud Ebalard a...@natisbad.org
Add support for Triple-DES operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
Add DT bindings documentation for the new marvell-cesa driver.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
.../devicetree/bindings/crypto/marvell-cesa.txt| 45 ++
1 file changed, 45 insertions(+)
create mode 100644
Add the Orion SoC description, and select this implementation by default
to support non-DT probing: Orion is the only platform where non-DT boards
are declaring the CESA block.
Control the allhwsupport module parameter to avoid probing the CESA IP when
the old CESA driver is enabled (unless it is
The old and new marvell CESA drivers both support Orion and Kirkwood SoCs.
Add a module parameter to choose whether these SoCs should be attached to
the new or the old driver.
The default policy is to keep attaching those IPs to the old driver if it
is enabled, until we decide the new CESA driver
Add support for DES operations.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Signed-off-by: Arnaud Ebalard a...@natisbad.org
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
drivers/crypto/marvell/cipher.c | 150
From: Arnaud Ebalard a...@natisbad.org
Add support for MD5 operations.
Signed-off-by: Arnaud Ebalard a...@natisbad.org
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/crypto/marvell/cesa.c | 2 +
drivers/crypto/marvell/cesa.h | 2 +
On Dove platforms, the crypto engine requires a clock. Document this
clocks property in the mv_cesa bindings doc.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
Documentation/devicetree/bindings/crypto/mv_cesa.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git
On Thu, Jun 04, 2015 at 06:58:06PM +0300, Peter Ujfalusi wrote:
Vinod,
On 06/02/2015 03:55 PM, Vinod Koul wrote:
On Fri, May 29, 2015 at 05:32:50PM +0300, Peter Ujfalusi wrote:
On 05/29/2015 01:18 PM, Vinod Koul wrote:
On Fri, May 29, 2015 at 11:42:27AM +0200, Geert Uytterhoeven wrote:
On 06/12/2015 09:21 AM, Stephan Mueller wrote:
+void *mpi_get_buffer(MPI a, unsigned *nbytes, int *sign)
+{
+ uint8_t *buf, *p;
+ int n, ret;
+
+ if (!nbytes)
+ return NULL;
+
+ n = mpi_get_size(a);
Shouldn't n be unsigned int?
You are right,
The '__init aesni_init()' function calls the '__exit crypto_fpu_exit()'
function directly. Since they are in different sections, this generates
a warning.
make CONFIG_DEBUG_SECTION_MISMATCH=y
...
WARNING: arch/x86/crypto/aesni-intel.o(.init.text+0x12b): Section
mismatch in reference from
Am Donnerstag, 11. Juni 2015, 12:05:38 schrieb Tadeusz Struk:
Hi Tadeusz,
+ */
+void *mpi_get_buffer(MPI a, unsigned *nbytes, int *sign)
+{
+ uint8_t *buf, *p;
+ int n, ret;
+
+ if (!nbytes)
+ return NULL;
+
+ n = mpi_get_size(a);
Shouldn't n be unsigned
Move the contents of the include/linux/nx842.h header file into the
drivers/crypto/nx/nx-842.h header file. Remove the nx842.h header
file and its entry in the MAINTAINERS file.
The include/linux/nx842.h header originally was there because the
crypto/842.c driver needed it to communicate with
Now that the crypto/842.c driver does only software 842 comp/decomp,
and the hardware crypto compressor for 842-nx is located in
drivers/crypto/nx with the NX 842 hw driver, there's no reason for
the nx842.h header to be located in include/linux/ anymore; nobody
should use the NX 842 hw driver
Replace the NX842_MEM_COMPRESS define with a function that returns the
specific platform driver's required working memory size.
The common nx-842.c driver refuses to load if there is no platform
driver present, so instead of defining an approximate working memory
size that's the maximum
On 06/11/2015 07:42 PM, Herbert Xu wrote:
The testmgr code can mark an entire cipher implementation as fips_allowed=1
as
already done for RSA. However, unlike with the other ciphers, that flag
must
go in conjunction with the used key sizes.
For FIPS mode, the following
23 matches
Mail list logo
