Re: [PATCH V2 1/2] crypto: Add Imagination Technologies hw hash accelerator
On 01/28/15 00:56, Herbert Xu wrote: On Wed, Jan 28, 2015 at 12:29:29AM +, James Hartley wrote: - If it is mandatory to impement a fallback driver (because the potential users of the framework would not know only digest is supported?) Yes it is mandatory. If I need to implement fallback drivers, would the Niagra2 SPU driver be a good reference http://lxr.free-electrons.com/source/drivers/crypto/n2_core.c ? Yes it's a good example. Cheers, Great, I'll prepare a new patchset. For the previous patches I did some basic testing using the built in crypto manager tests, but these all pass without the fallback implemented - is there another more appropriate set of tests that you would recommend I use to verify that my implementation is correct? Thanks, James -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] crypto: Add Imagination Technologies hw hash accelerator
On Wed, Jan 28, 2015 at 12:29:29AM +, James Hartley wrote: > > - If it is mandatory to impement a fallback driver (because the > potential users of the framework would not know only digest is > supported?) Yes it is mandatory. > If I need to implement fallback drivers, would the Niagra2 SPU > driver be a good reference > http://lxr.free-electrons.com/source/drivers/crypto/n2_core.c ? Yes it's a good example. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] crypto: Add Imagination Technologies hw hash accelerator
On 01/28/15 00:01, James Hartley wrote:
> > +struct img_hash_request_ctx {
> > +struct img_hash_dev*hdev;
> > +u8 digest[SHA256_DIGEST_SIZE] __aligned(sizeof(u32));
> > +unsigned longflags;
> > +size_tdigsize;
> > +
> > +dma_addr_tdma_addr;
> > +size_tdma_ct;
> > +
> > +/* sg root */
> > +struct scatterlist*sgfirst;
> > +/* walk state */
> > +struct scatterlist*sg;
> > +size_tnents;
> > +size_toffset;
> > +unsigned inttotal;
> > +size_tsent;
> > +
> > +unsigned longop;
> > +
> > +size_tbufcnt;
> > +u8 buffer[0] __aligned(sizeof(u32)); };
>
> Unfortunately this is not consistent with our API since you're not
storing the
> non-final hash state in the request context.
>
> It appears that you're finalising every request. That means you can
only
> implement finup and digest. With finup you'll also need to be able
to import
> a non-final hash state. If the hardware cannot do that then you can
only
> implement digest.
>
> Everything else would have to be done by a fallback driver.
>
> So the question is can you obtain the non-final hash state from the
hardware
> and then reinsert it for the next operation?
I've looked into this and unfortunately the hardware cannot do that.
I'll spend some
time looking into what this means (I'm not the author of the driver,
so will need to
become a bit more familiar with it).
Hi Herbert,
Firstly apologies that there have been quite a few weeks since we last
discussed this driver!
I understand that because the HW does not support an initial hash state,
I can only implement digest, and not init, update and final. You
mentioned that I would have to do everything else using a fallback
driver - but I'm not clear on:
- If it is mandatory to impement a fallback driver (because the
potential users of the framework would not know only digest is supported?)
- or can I just remove the support for init update and final?
If I need to implement fallback drivers, would the Niagra2 SPU driver be
a good reference
http://lxr.free-electrons.com/source/drivers/crypto/n2_core.c ?
Thanks,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V2 1/2] crypto: Add Imagination Technologies hw hash accelerator
Hi Herbert, thanks for the review.
> -Original Message-
> From: devicetree-ow...@vger.kernel.org [mailto:devicetree-
> ow...@vger.kernel.org] On Behalf Of Herbert Xu
> Sent: 20 November 2014 14:22
> To: James Hartley
> Cc: da...@davemloft.net; grant.lik...@linaro.org; robh...@kernel.org;
> gre...@linuxfoundation.org; linux-crypto@vger.kernel.org;
> devicet...@vger.kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk;
> ga...@codeaurora.org; Ezequiel Garcia; abres...@chromium.org
> Subject: Re: [PATCH V2 1/2] crypto: Add Imagination Technologies hw hash
> accelerator
>
> On Tue, Nov 18, 2014 at 08:48:46PM +, James Hartley wrote:
> >
> > +struct img_hash_request_ctx {
> > + struct img_hash_dev *hdev;
> > + u8 digest[SHA256_DIGEST_SIZE] __aligned(sizeof(u32));
> > + unsigned long flags;
> > + size_t digsize;
> > +
> > + dma_addr_t dma_addr;
> > + size_t dma_ct;
> > +
> > + /* sg root */
> > + struct scatterlist *sgfirst;
> > + /* walk state */
> > + struct scatterlist *sg;
> > + size_t nents;
> > + size_t offset;
> > + unsigned inttotal;
> > + size_t sent;
> > +
> > + unsigned long op;
> > +
> > + size_t bufcnt;
> > + u8 buffer[0] __aligned(sizeof(u32)); };
>
> Unfortunately this is not consistent with our API since you're not storing the
> non-final hash state in the request context.
>
> It appears that you're finalising every request. That means you can only
> implement finup and digest. With finup you'll also need to be able to import
> a non-final hash state. If the hardware cannot do that then you can only
> implement digest.
>
> Everything else would have to be done by a fallback driver.
>
> So the question is can you obtain the non-final hash state from the hardware
> and then reinsert it for the next operation?
I've looked into this and unfortunately the hardware cannot do that. I'll
spend some
time looking into what this means (I'm not the author of the driver, so will
need to
become a bit more familiar with it).
>
> Cheers,
> --
> Email: Herbert Xu Home Page:
> http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in the
> body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
Thanks,
James.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] crypto: Add Imagination Technologies hw hash accelerator
On Tue, Nov 18, 2014 at 08:48:46PM +, James Hartley wrote:
>
> +struct img_hash_request_ctx {
> + struct img_hash_dev *hdev;
> + u8 digest[SHA256_DIGEST_SIZE] __aligned(sizeof(u32));
> + unsigned long flags;
> + size_t digsize;
> +
> + dma_addr_t dma_addr;
> + size_t dma_ct;
> +
> + /* sg root */
> + struct scatterlist *sgfirst;
> + /* walk state */
> + struct scatterlist *sg;
> + size_t nents;
> + size_t offset;
> + unsigned inttotal;
> + size_t sent;
> +
> + unsigned long op;
> +
> + size_t bufcnt;
> + u8 buffer[0] __aligned(sizeof(u32));
> +};
Unfortunately this is not consistent with our API since you're
not storing the non-final hash state in the request context.
It appears that you're finalising every request. That means
you can only implement finup and digest. With finup you'll
also need to be able to import a non-final hash state. If the
hardware cannot do that then you can only implement digest.
Everything else would have to be done by a fallback driver.
So the question is can you obtain the non-final hash state from
the hardware and then reinsert it for the next operation?
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2 1/2] crypto: Add Imagination Technologies hw hash accelerator
This adds support for the Imagination Technologies hash accelerator which provides hardware acceleratopm for SHA1 SHA224 SHA256 and MD5 hashes. Signed-off-by: James Hartley --- MAINTAINERS |5 + drivers/crypto/Kconfig| 14 + drivers/crypto/Makefile |1 + drivers/crypto/img-hash.c | 1061 + 4 files changed, 1081 insertions(+) create mode 100644 drivers/crypto/img-hash.c diff --git a/MAINTAINERS b/MAINTAINERS index 0662378..45a3b53 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4743,6 +4743,11 @@ S: Maintained F: drivers/iio/ F: drivers/staging/iio/ +IMAGINATION TECHNOLOGIES HASH ACCELERATOR DRIVER +M: James Hartley +S: Supported +F: drivers/crypto/img-hash.c + IKANOS/ADI EAGLE ADSL USB DRIVER M: Matthieu Castet M: Stanislaw Gruszka diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 2fb0fdf..ee43ba3 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -436,4 +436,18 @@ config CRYPTO_DEV_QCE hardware. To compile this driver as a module, choose M here. The module will be called qcrypto. +config CRYPTO_DEV_IMGTEC_HASH + tristate "Imagination Technologies hardware hash accelerator" + depends on MIPS || COMPILE_TEST + select CRYPTO_ALG_API + select CRYPTO_MD5 + select CRYPTO_SHA1 + select CRYPTO_SHA224 + select CRYPTO_SHA256 + select CRYPTO_HASH + help + This driver interfaces with the Imagination Technologies + hardware hash accelerator. Supporting MD5/SHA1/SHA224/SHA256 + hashing algorithms + endif # CRYPTO_HW diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 3924f93..1c34fff 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -6,6 +6,7 @@ obj-$(CONFIG_CRYPTO_DEV_CCP) += ccp/ obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam/ obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o +obj-$(CONFIG_CRYPTO_DEV_IMGTEC_HASH) += img-hash.o obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o obj-$(CONFIG_CRYPTO_DEV_MV_CESA) += mv_cesa.o obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o diff --git a/drivers/crypto/img-hash.c b/drivers/crypto/img-hash.c new file mode 100644 index 000..3ca6fce --- /dev/null +++ b/drivers/crypto/img-hash.c @@ -0,0 +1,1061 @@ +/* + * Copyright (c) 2014 Imagination Technologies + * Author: Will Thomas + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as published + * by the Free Software Foundation. + * + * Interface structure taken from omap-sham driver + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define CR_RESET 0 +#define CR_RESET_SET 1 +#define CR_RESET_UNSET 0 + +#define CR_MESSAGE_LENGTH_H0x4 +#define CR_MESSAGE_LENGTH_L0x8 + +#define CR_CONTROL 0xc +#define CR_CONTROL_BYTE_ORDER_3210 0 +#define CR_CONTROL_BYTE_ORDER_0123 1 +#define CR_CONTROL_BYTE_ORDER_2310 2 +#define CR_CONTROL_BYTE_ORDER_1032 3 +#define CR_CONTROL_BYTE_ORDER_SHIFT8 +#define CR_CONTROL_ALGO_MD50 +#define CR_CONTROL_ALGO_SHA1 1 +#define CR_CONTROL_ALGO_SHA224 2 +#define CR_CONTROL_ALGO_SHA256 3 + +#define CR_INTSTAT 0x10 +#define CR_INTENAB 0x14 +#define CR_INTCLEAR0x18 +#define CR_INT_RESULTS_AVAILABLE BIT(0) +#define CR_INT_NEW_RESULTS_SET BIT(1) +#define CR_INT_RESULT_READ_ERR BIT(2) +#define CR_INT_MESSAGE_WRITE_ERROR BIT(3) +#define CR_INT_STATUS BIT(8) + +#define CR_RESULT_QUEUE0x1c +#define CR_RSD00x40 +#define CR_CORE_REV0x50 +#define CR_CORE_DES1 0x60 +#define CR_CORE_DES2 0x70 + +#define DRIVER_FLAGS_BUSY BIT(0) +#define DRIVER_FLAGS_FINAL BIT(1) +#define DRIVER_FLAGS_DMA_ACTIVEBIT(2) +#define DRIVER_FLAGS_OUTPUT_READY BIT(3) +#define DRIVER_FLAGS_INIT BIT(4) +#define DRIVER_FLAGS_CPU BIT(5) +#define DRIVER_FLAGS_DMA_READY BIT(6) +#define DRIVER_FLAGS_ERROR BIT(7) +#define DRIVER_FLAGS_SGBIT(8) +#define DRIVER_FLAGS_FINUP BIT(9) +#define DRIVER_FLAGS_SHA1 BIT(18) +#define DRIVER_FLAGS_SHA224BIT(19) +#define DRIVER_FLAGS_SHA256BIT(20) +#define DRIVER_FLAGS_MD5 BIT(21) + +#define OP_UPDATE 1 +#define OP_FINAL 2 + +#define IMG_HASH_QUEUE_LENGTH 20 +#define IMG_HASH_DMA_THRESHOLD 64 + +#ifdef __LITTLE_ENDIAN +#define IMG_HASH_BYTE_ORDER(CR_CONTROL
