[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55269C05.2060401@gmail.com>
Date: Thu, 09 Apr 2015 17:34:29 +0200
From: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To: Boris Brezillon <boris.brezillon@...e-electrons.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
"David S. Miller" <davem@...emloft.net>,
linux-crypto@...r.kernel.org
CC: Rob Herring <robh+dt@...nel.org>, Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>, devicetree@...r.kernel.org,
Tawfik Bayouk <tawfik@...vell.com>,
Lior Amsalem <alior@...vell.com>,
Nadav Haklai <nadavh@...vell.com>,
Eran Ben-Avi <benavi@...vell.com>,
Thomas Petazzoni <info@...e-electrons.com>,
Gregory CLEMENT <gregory.clement@...e-electrons.com>,
Jason Cooper <jason@...edaemon.net>,
Andrew Lunn <andrew@...n.ch>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Arnaud Ebalard <arno@...isbad.org>
Subject: Re: [PATCH 0/2] crypto: add new driver for Marvell CESA
On 09.04.2015 16:58, Boris Brezillon wrote:
> This is an attempt to replace the mv_cesa driver by a new one to address
> some limitations of the existing driver.
> From a performance and CPU load point of view the most important
> limitation is the lack of DMA support, thus preventing us from chaining
> crypto operations.
>
> I know we usually try to adapt existing drivers instead of replacing them
> by new ones, but after trying to refactor the mv_cesa driver I realized it
> would take longer than writing an new one from scratch.
Boris,
if you include a bunch of performance measurements, I guess it will help
you to get an agreement of replacing the driver instead of reworking it.
> Here are the main features brought by this new driver:
> - support for armada SoCs (up to 38x) while keeping support for older ones
> (Orion and Kirkwood)
Unfortunately, the list above is missing Dove SoCs which also have a
CESA engine with TDMA support. I checked the registers _very_ quickly
but it seems that they are compatible with Kirkwood's CESA.
> - DMA mode to offload the CPU in case of intensive crypto usage
> - new algorithms: SHA256, DES and 3DES
>
[...]
> Boris Brezillon (2):
> crypto: add new driver for Marvell CESA
> crypto: marvell/CESA: update DT bindings documentation
IMHO, the patch set should be split up in:
- new core driver
- add support for TDMA on platforms that support it
- new cipher algorithms
- removal of old mv_cesa
I'd love to test on Dove, but time still is very limited. I guess the
patches will receive another round anyway, maybe I find some until the
final version.
Sebastian
> .../devicetree/bindings/crypto/mv_cesa.txt | 50 +-
> drivers/crypto/Kconfig | 2 +
> drivers/crypto/Makefile | 2 +-
> drivers/crypto/marvell/Makefile | 1 +
> drivers/crypto/marvell/cesa.c | 539 ++++++++
> drivers/crypto/marvell/cesa.h | 802 ++++++++++++
> drivers/crypto/marvell/cipher.c | 761 +++++++++++
> drivers/crypto/marvell/hash.c | 1349 ++++++++++++++++++++
> drivers/crypto/marvell/tdma.c | 223 ++++
> drivers/crypto/mv_cesa.c | 1193 -----------------
> drivers/crypto/mv_cesa.h | 150 ---
> 11 files changed, 3716 insertions(+), 1356 deletions(-)
> create mode 100644 drivers/crypto/marvell/Makefile
> create mode 100644 drivers/crypto/marvell/cesa.c
> create mode 100644 drivers/crypto/marvell/cesa.h
> create mode 100644 drivers/crypto/marvell/cipher.c
> create mode 100644 drivers/crypto/marvell/hash.c
> create mode 100644 drivers/crypto/marvell/tdma.c
> delete mode 100644 drivers/crypto/mv_cesa.c
> delete mode 100644 drivers/crypto/mv_cesa.h
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists