[PATCH 1/2] crypto: sahara - add support for i.MX53
The Sahara on the i.MX53 is of version 4. Add support for probing the
device.
Signed-off-by: Steffen Trumtrar
---
.../devicetree/bindings/crypto/fsl-imx-sahara.txt | 2 +-
drivers/crypto/sahara.c | 17 ++---
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
index 5c65ecc..e8a35c7 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
@@ -1,5 +1,5 @@
Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
-Currently only i.MX27 is supported.
+Currently only i.MX27 and i.MX53 are supported.
Required properties:
- compatible : Should be "fsl,-sahara"
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 164e1ec..85df5b5 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -24,10 +24,12 @@
#include
#include
#include
+#include
#include
#define SAHARA_NAME "sahara"
#define SAHARA_VERSION_3 3
+#define SAHARA_VERSION_4 4
#define SAHARA_TIMEOUT_MS 1000
#define SAHARA_MAX_HW_DESC 2
#define SAHARA_MAX_HW_LINK 20
@@ -860,6 +862,7 @@ static struct platform_device_id sahara_platform_ids[] = {
MODULE_DEVICE_TABLE(platform, sahara_platform_ids);
static struct of_device_id sahara_dt_ids[] = {
+ { .compatible = "fsl,imx53-sahara" },
{ .compatible = "fsl,imx27-sahara" },
{ /* sentinel */ }
};
@@ -971,10 +974,18 @@ static int sahara_probe(struct platform_device *pdev)
clk_prepare_enable(dev->clk_ahb);
version = sahara_read(dev, SAHARA_REG_VERSION);
- if (version != SAHARA_VERSION_3) {
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx27-sahara")) {
+ if (version != SAHARA_VERSION_3)
+ err = -ENODEV;
+ } else if (of_device_is_compatible(pdev->dev.of_node,
+ "fsl,imx53-sahara")) {
+ if (((version >> 8) & 0xff) != SAHARA_VERSION_4)
+ err = -ENODEV;
+ version = (version >> 8) & 0xff;
+ }
+ if (err == -ENODEV) {
dev_err(&pdev->dev, "SAHARA version %d not supported\n",
- version);
- err = -ENODEV;
+ version);
goto err_algs;
}
--
2.1.0.rc1
--
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 2/2] crypto: sahara - add support for SHA1/256
Add support for the MDHA unit in the SAHARA core.
The MDHA can generate hash digests for MD5 and SHA1 in version 3 and
additionally SHA224 and SHA256 in version 4.
Add the SHA1 and SHA256 algorithms to the driver.
The implementation was tested with the in-kernel testmgr on i.MX27 and
i.MX53.
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/sahara.c | 637 ++--
1 file changed, 617 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 85df5b5..05be949 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -15,6 +15,10 @@
#include
#include
+#include
+#include
+#include
+#include
#include
#include
@@ -27,6 +31,9 @@
#include
#include
+#define SHA_BUFFER_LEN PAGE_SIZE
+#define SAHARA_MAX_SHA_BLOCK_SIZE SHA256_BLOCK_SIZE
+
#define SAHARA_NAME "sahara"
#define SAHARA_VERSION_3 3
#define SAHARA_VERSION_4 4
@@ -52,8 +59,26 @@
#define SAHARA_HDR_CHA_MDHA(2 << 28)
#define SAHARA_HDR_PARITY_BIT (1 << 31)
+#define SAHARA_HDR_MDHA_SET_MODE_MD_KEY0x2088
+#define SAHARA_HDR_MDHA_SET_MODE_HASH 0x208D
+#define SAHARA_HDR_MDHA_HASH 0xA085
+#define SAHARA_HDR_MDHA_STORE_DIGEST 0x2082
+#define SAHARA_HDR_MDHA_ALG_SHA1 0
+#define SAHARA_HDR_MDHA_ALG_MD51
+#define SAHARA_HDR_MDHA_ALG_SHA256 2
+#define SAHARA_HDR_MDHA_ALG_SHA224 3
+#define SAHARA_HDR_MDHA_PDATA (1 << 2)
+#define SAHARA_HDR_MDHA_HMAC (1 << 3)
+#define SAHARA_HDR_MDHA_INIT (1 << 5)
+#define SAHARA_HDR_MDHA_IPAD (1 << 6)
+#define SAHARA_HDR_MDHA_OPAD (1 << 7)
+#define SAHARA_HDR_MDHA_SWAP (1 << 8)
+#define SAHARA_HDR_MDHA_MAC_FULL (1 << 9)
+#define SAHARA_HDR_MDHA_SSL(1 << 10)
+
/* SAHARA can only process one request at a time */
#define SAHARA_QUEUE_LENGTH1
+#define SAHARA_CHANS 2
#define SAHARA_REG_VERSION 0x00
#define SAHARA_REG_DAR 0x04
@@ -121,28 +146,58 @@ struct sahara_hw_link {
struct sahara_ctx {
struct sahara_dev *dev;
unsigned long flags;
+ unsigned int first;
+ unsigned int last;
+ unsigned int active;
+
+ /* AES-specific context */
int keylen;
u8 key[AES_KEYSIZE_128];
struct crypto_ablkcipher *fallback;
+
+ /* SHA-specific context */
+ struct crypto_shash *shash_fallback;
+};
+
+enum sahara_chan {
+ SAHARA_CHAN_SHA = 0,
+ SAHARA_CHAN_AES = 1,
};
struct sahara_aes_reqctx {
unsigned long mode;
};
+struct sahara_sha_reqctx {
+ unsigned int mode;
+ unsigned int digest_size;
+ unsigned int context_size;
+ u8 buf[SAHARA_MAX_SHA_BLOCK_SIZE];
+ unsigned int buf_cnt;
+ unsigned int hash_rem;
+ struct sg_table data_sg;
+ struct scatterlist buf_sg;
+ unsigned int sg_in_idx;
+ unsigned int result_idx;
+};
+
struct sahara_dev {
struct device *device;
+ unsigned intversion;
void __iomem*regs_base;
struct clk *clk_ipg;
struct clk *clk_ahb;
struct sahara_ctx *ctx;
+ struct sahara_sha_reqctx*rctx;
spinlock_t lock;
- struct crypto_queue queue;
+ struct crypto_queue queue[SAHARA_CHANS];
unsigned long flags;
+ unsigned intskha;
+ unsigned intmdha;
- struct tasklet_struct done_task;
- struct tasklet_struct queue_task;
+ struct tasklet_struct done_task[SAHARA_CHANS];
+ struct tasklet_struct queue_task[SAHARA_CHANS];
struct sahara_hw_desc *hw_desc[SAHARA_MAX_HW_DESC];
dma_addr_t hw_phys_desc[SAHARA_MAX_HW_DESC];
@@ -153,10 +208,13 @@ struct sahara_dev {
u8 *iv_base;
dma_addr_t iv_phys_base;
+ u8 *context_base;
+ dma_addr_t context_phys_base;
+
struct sahara_hw_link *hw_link[SAHARA_MAX_HW_LINK];
dma_addr_t hw_phys_link[SAHARA_MAX_HW_LINK];
- struct ablkcipher_request *req;
+ struct crypto_async_request *req[SAHARA_CHANS];
size_t total;
struct scatterlist *in_sg;
unsigned intnb_in_sg;
@@ -416,9 +474,40 @@ static void sahara_aes_done_task(unsigned long data)
clear_bit(FLAGS_BUSY, &dev->flags);
spin_unlock(&dev->lock);
- dev->req->base.complete(&dev->req->base, dev->error);
+ dev->skha = 0;
+ dev->req[SAHARA_CHAN_AES]->complete(dev->req[SAHARA_CHAN_AES],
+ dev->error);
}
+static void
Re: [PATCH 2/2] crypto: sahara - add support for SHA1/256
Hi!
On Fri, Aug 29, 2014 at 09:44:42PM +0800, Herbert Xu wrote:
> On Mon, Aug 18, 2014 at 03:13:39PM +0200, Steffen Trumtrar wrote:
> >
> > +struct sahara_sha_reqctx {
> > + unsigned int mode;
> > + unsigned int digest_size;
> > + unsigned int context_size;
> > + u8 buf[SAHARA_MAX_SHA_BLOCK_SIZE];
> > + unsigned int buf_cnt;
> > + unsigned int hash_rem;
> > + struct sg_table data_sg;
> > + struct scatterlist buf_sg;
> > + unsigned int sg_in_idx;
> > + unsigned int result_idx;
> > +};
>
> So where is the hash state stored?
>
The hash state is stored in the context_base variable in sahara_dev.
Freescale calls it context in their driver (the only source of information
I have to develop a GPL driver).
To simplify the driver I allocated the context also as dma_alloc_coherent,
same as the key_base for AES.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 2/2] crypto: sahara - add support for SHA1/256
Add support for the MDHA unit in the SAHARA core.
The MDHA can generate hash digests for MD5 and SHA1 in version 3 and
additionally SHA224 and SHA256 in version 4.
Add the SHA1 and SHA256 algorithms to the driver.
The implementation was tested with the in-kernel testmgr on i.MX27 and
i.MX53.
Signed-off-by: Steffen Trumtrar
---
Changes since v1:
- save context in the sahara_ctx struct
- reworked the scatterlist/remainder calculation
drivers/crypto/sahara.c | 689 ++--
1 file changed, 669 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 85df5b5aba2b..a4cfe1cba659 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -15,6 +15,10 @@
#include
#include
+#include
+#include
+#include
+#include
#include
#include
@@ -27,6 +31,9 @@
#include
#include
+#define SHA_BUFFER_LEN PAGE_SIZE
+#define SAHARA_MAX_SHA_BLOCK_SIZE SHA256_BLOCK_SIZE
+
#define SAHARA_NAME "sahara"
#define SAHARA_VERSION_3 3
#define SAHARA_VERSION_4 4
@@ -52,8 +59,26 @@
#define SAHARA_HDR_CHA_MDHA(2 << 28)
#define SAHARA_HDR_PARITY_BIT (1 << 31)
+#define SAHARA_HDR_MDHA_SET_MODE_MD_KEY0x2088
+#define SAHARA_HDR_MDHA_SET_MODE_HASH 0x208D
+#define SAHARA_HDR_MDHA_HASH 0xA085
+#define SAHARA_HDR_MDHA_STORE_DIGEST 0x2082
+#define SAHARA_HDR_MDHA_ALG_SHA1 0
+#define SAHARA_HDR_MDHA_ALG_MD51
+#define SAHARA_HDR_MDHA_ALG_SHA256 2
+#define SAHARA_HDR_MDHA_ALG_SHA224 3
+#define SAHARA_HDR_MDHA_PDATA (1 << 2)
+#define SAHARA_HDR_MDHA_HMAC (1 << 3)
+#define SAHARA_HDR_MDHA_INIT (1 << 5)
+#define SAHARA_HDR_MDHA_IPAD (1 << 6)
+#define SAHARA_HDR_MDHA_OPAD (1 << 7)
+#define SAHARA_HDR_MDHA_SWAP (1 << 8)
+#define SAHARA_HDR_MDHA_MAC_FULL (1 << 9)
+#define SAHARA_HDR_MDHA_SSL(1 << 10)
+
/* SAHARA can only process one request at a time */
#define SAHARA_QUEUE_LENGTH1
+#define SAHARA_CHANS 2
#define SAHARA_REG_VERSION 0x00
#define SAHARA_REG_DAR 0x04
@@ -121,28 +146,57 @@ struct sahara_hw_link {
struct sahara_ctx {
struct sahara_dev *dev;
unsigned long flags;
+ unsigned int first;
+ unsigned int last;
+ unsigned int active;
+
+ /* AES-specific context */
int keylen;
u8 key[AES_KEYSIZE_128];
struct crypto_ablkcipher *fallback;
+
+ /* SHA-specific context */
+ struct crypto_shash *shash_fallback;
+ u8 context[SHA256_DIGEST_SIZE + 4];
+};
+
+enum sahara_chan {
+ SAHARA_CHAN_SHA = 0,
+ SAHARA_CHAN_AES = 1,
};
struct sahara_aes_reqctx {
unsigned long mode;
};
+struct sahara_sha_reqctx {
+ unsigned intmode;
+ unsigned intdigest_size;
+ unsigned intcontext_size;
+ u8 buf[SAHARA_MAX_SHA_BLOCK_SIZE];
+ u8 rembuf[SAHARA_MAX_SHA_BLOCK_SIZE];
+ unsigned intbuf_cnt;
+ unsigned intsg_in_idx;
+ unsigned intresult_idx;
+};
+
struct sahara_dev {
struct device *device;
+ unsigned intversion;
void __iomem*regs_base;
struct clk *clk_ipg;
struct clk *clk_ahb;
struct sahara_ctx *ctx;
+ struct sahara_sha_reqctx*rctx;
spinlock_t lock;
- struct crypto_queue queue;
+ struct crypto_queue queue[SAHARA_CHANS];
unsigned long flags;
+ unsigned intskha;
+ unsigned intmdha;
- struct tasklet_struct done_task;
- struct tasklet_struct queue_task;
+ struct tasklet_struct done_task[SAHARA_CHANS];
+ struct tasklet_struct queue_task[SAHARA_CHANS];
struct sahara_hw_desc *hw_desc[SAHARA_MAX_HW_DESC];
dma_addr_t hw_phys_desc[SAHARA_MAX_HW_DESC];
@@ -153,12 +207,17 @@ struct sahara_dev {
u8 *iv_base;
dma_addr_t iv_phys_base;
+ u8 *context_base;
+ dma_addr_t context_phys_base;
+
struct sahara_hw_link *hw_link[SAHARA_MAX_HW_LINK];
dma_addr_t hw_phys_link[SAHARA_MAX_HW_LINK];
- struct ablkcipher_request *req;
+ struct crypto_async_request *req[SAHARA_CHANS];
size_t total;
struct scatterlist *in_sg;
+ struct scatterlist in_sg_chain[2];
+ boolin_sg_chained;
unsigned intnb_in_sg;
struct scatterlist *out_sg;
unsigned intnb_out_sg;
@@
[PATCH v2 1/2] crypto: sahara - add support for i.MX53
The Sahara on the i.MX53 is of version 4. Add support for probing the
device.
Signed-off-by: Steffen Trumtrar
---
.../devicetree/bindings/crypto/fsl-imx-sahara.txt | 2 +-
drivers/crypto/sahara.c | 17 ++---
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
index 5c65eccd0e56..e8a35c71e947 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
@@ -1,5 +1,5 @@
Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
-Currently only i.MX27 is supported.
+Currently only i.MX27 and i.MX53 are supported.
Required properties:
- compatible : Should be "fsl,-sahara"
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 164e1ec624e3..85df5b5aba2b 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -24,10 +24,12 @@
#include
#include
#include
+#include
#include
#define SAHARA_NAME "sahara"
#define SAHARA_VERSION_3 3
+#define SAHARA_VERSION_4 4
#define SAHARA_TIMEOUT_MS 1000
#define SAHARA_MAX_HW_DESC 2
#define SAHARA_MAX_HW_LINK 20
@@ -860,6 +862,7 @@ static struct platform_device_id sahara_platform_ids[] = {
MODULE_DEVICE_TABLE(platform, sahara_platform_ids);
static struct of_device_id sahara_dt_ids[] = {
+ { .compatible = "fsl,imx53-sahara" },
{ .compatible = "fsl,imx27-sahara" },
{ /* sentinel */ }
};
@@ -971,10 +974,18 @@ static int sahara_probe(struct platform_device *pdev)
clk_prepare_enable(dev->clk_ahb);
version = sahara_read(dev, SAHARA_REG_VERSION);
- if (version != SAHARA_VERSION_3) {
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx27-sahara")) {
+ if (version != SAHARA_VERSION_3)
+ err = -ENODEV;
+ } else if (of_device_is_compatible(pdev->dev.of_node,
+ "fsl,imx53-sahara")) {
+ if (((version >> 8) & 0xff) != SAHARA_VERSION_4)
+ err = -ENODEV;
+ version = (version >> 8) & 0xff;
+ }
+ if (err == -ENODEV) {
dev_err(&pdev->dev, "SAHARA version %d not supported\n",
- version);
- err = -ENODEV;
+ version);
goto err_algs;
}
--
2.1.0
--
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 0/2] crypto: sahara - SHA1/256 support
Hi! This series adds support for the SAHARA crypto module on i.MX53 in 1/2 and than adds support for SHA1/256 in 2/2. Changes since last version: - save the hash state in the sahara request struct - fixed the hash remainder calculation Regards, Steffen Steffen Trumtrar (2): crypto: sahara - add support for i.MX53 crypto: sahara - add support for SHA1/256 .../devicetree/bindings/crypto/fsl-imx-sahara.txt | 2 +- drivers/crypto/sahara.c| 706 - 2 files changed, 684 insertions(+), 24 deletions(-) -- 2.1.0 -- 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 2/2] crypto: sahara - add support for SHA1/256
Hi! On Tue, Oct 07, 2014 at 10:02:01AM +0800, Herbert Xu wrote: > On Mon, Oct 06, 2014 at 04:43:45PM +0200, Steffen Trumtrar wrote: > > Add support for the MDHA unit in the SAHARA core. > > The MDHA can generate hash digests for MD5 and SHA1 in version 3 and > > additionally SHA224 and SHA256 in version 4. > > > > Add the SHA1 and SHA256 algorithms to the driver. > > > > The implementation was tested with the in-kernel testmgr on i.MX27 and > > i.MX53. > > > > Signed-off-by: Steffen Trumtrar > > --- > > Changes since v1: > > - save context in the sahara_ctx struct > > This is still wrong since the context needs to be stored in the > request. Otherwise multiple requests will corrupt each other's > state. > :-( Okay. What would I have to do to test if it works correctly? I tested this with AF_ALG from userspace and opened two file descriptors and wrote to them in turns. Wouldn't that produce multiple requests? > Also please implement export/import. > I will have to look into that. Thank you for you review. Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 2/2] crypto: sahara - add support for SHA1/256
Hi! On Fri, Oct 24, 2014 at 09:41:27PM +0800, Herbert Xu wrote: > On Tue, Oct 07, 2014 at 08:47:05AM +0200, Steffen Trumtrar wrote: > > > > > This is still wrong since the context needs to be stored in the > > > request. Otherwise multiple requests will corrupt each other's > > > state. > > > > > > > :-( Okay. > > > > What would I have to do to test if it works correctly? > > > > I tested this with AF_ALG from userspace and opened two file descriptors > > and wrote to them in turns. Wouldn't that produce multiple requests? > > It should if you're not finalising the result. Can you show me > your test program? > In the mean time I worked on the code a bit more and will send out a v3 in a second. And I think I now understand your concern and have already changed the code accordingly. Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v3 1/3] crypto: sahara - initialize spinlock
The driver uses a spinlock, but never initializes it. Fix this. Signed-off-by: Steffen Trumtrar --- drivers/crypto/sahara.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c index 164e1ec624e3..6fb16fe7eea5 100644 --- a/drivers/crypto/sahara.c +++ b/drivers/crypto/sahara.c @@ -956,6 +956,8 @@ static int sahara_probe(struct platform_device *pdev) crypto_init_queue(&dev->queue, SAHARA_QUEUE_LENGTH); + spin_lock_init(&dev->lock); + dev_ptr = dev; tasklet_init(&dev->queue_task, sahara_aes_queue_task, -- 2.1.1 -- 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 v3 0/3] crypto: sahara - SHA1/256 support
Hi! Changes since v2: - added a patch to fix a bug with the spinlock - save the context in the request - made the code threadsafe Regards, Steffen Steffen Trumtrar (3): crypto: sahara - initialize spinlock crypto: sahara - add support for i.MX53 crypto: sahara - add support for SHA1/256 .../devicetree/bindings/crypto/fsl-imx-sahara.txt | 2 +- drivers/crypto/sahara.c| 731 - 2 files changed, 709 insertions(+), 24 deletions(-) -- 2.1.1 -- 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 v3 3/3] crypto: sahara - add support for SHA1/256
Add support for the MDHA unit in the SAHARA core.
The MDHA can generate hash digests for MD5 and SHA1 in version 3 and
additionally SHA224 and SHA256 in version 4.
Add the SHA1 and SHA256 algorithms to the driver.
The implementation was tested with the in-kernel testmgr and a userspace
testprogram using AF_ALG with+without pthreads on i.MX53.
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/sahara.c | 712 ++--
1 file changed, 692 insertions(+), 20 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 1782fc47335f..f9a1d61cc419 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -15,6 +15,10 @@
#include
#include
+#include
+#include
+#include
+#include
#include
#include
@@ -27,6 +31,9 @@
#include
#include
+#define SHA_BUFFER_LEN PAGE_SIZE
+#define SAHARA_MAX_SHA_BLOCK_SIZE SHA256_BLOCK_SIZE
+
#define SAHARA_NAME "sahara"
#define SAHARA_VERSION_3 3
#define SAHARA_VERSION_4 4
@@ -39,6 +46,8 @@
#define FLAGS_CBC BIT(1)
#define FLAGS_NEW_KEY BIT(3)
#define FLAGS_BUSY 4
+#define FLAGS_SKHA 5
+#define FLAGS_MDHA 6
#define SAHARA_HDR_BASE0x0080
#define SAHARA_HDR_SKHA_ALG_AES0
@@ -52,8 +61,26 @@
#define SAHARA_HDR_CHA_MDHA(2 << 28)
#define SAHARA_HDR_PARITY_BIT (1 << 31)
+#define SAHARA_HDR_MDHA_SET_MODE_MD_KEY0x2088
+#define SAHARA_HDR_MDHA_SET_MODE_HASH 0x208D
+#define SAHARA_HDR_MDHA_HASH 0xA085
+#define SAHARA_HDR_MDHA_STORE_DIGEST 0x2082
+#define SAHARA_HDR_MDHA_ALG_SHA1 0
+#define SAHARA_HDR_MDHA_ALG_MD51
+#define SAHARA_HDR_MDHA_ALG_SHA256 2
+#define SAHARA_HDR_MDHA_ALG_SHA224 3
+#define SAHARA_HDR_MDHA_PDATA (1 << 2)
+#define SAHARA_HDR_MDHA_HMAC (1 << 3)
+#define SAHARA_HDR_MDHA_INIT (1 << 5)
+#define SAHARA_HDR_MDHA_IPAD (1 << 6)
+#define SAHARA_HDR_MDHA_OPAD (1 << 7)
+#define SAHARA_HDR_MDHA_SWAP (1 << 8)
+#define SAHARA_HDR_MDHA_MAC_FULL (1 << 9)
+#define SAHARA_HDR_MDHA_SSL(1 << 10)
+
/* SAHARA can only process one request at a time */
#define SAHARA_QUEUE_LENGTH1
+#define SAHARA_CHANS 2
#define SAHARA_REG_VERSION 0x00
#define SAHARA_REG_DAR 0x04
@@ -121,28 +148,58 @@ struct sahara_hw_link {
struct sahara_ctx {
struct sahara_dev *dev;
unsigned long flags;
+ unsigned int first;
+ unsigned int last;
+ unsigned int active;
+
+ /* AES-specific context */
int keylen;
u8 key[AES_KEYSIZE_128];
struct crypto_ablkcipher *fallback;
+
+ /* SHA-specific context */
+ struct crypto_shash *shash_fallback;
+ u8 context[SHA256_DIGEST_SIZE + 4];
+};
+
+enum sahara_chan {
+ SAHARA_CHAN_SHA = 0,
+ SAHARA_CHAN_AES = 1,
};
struct sahara_aes_reqctx {
unsigned long mode;
};
+struct sahara_sha_reqctx {
+ unsigned intmode;
+ unsigned intdigest_size;
+ unsigned intcontext_size;
+ u8 buf[SAHARA_MAX_SHA_BLOCK_SIZE];
+ u8 rembuf[SAHARA_MAX_SHA_BLOCK_SIZE];
+ unsigned intbuf_cnt;
+ unsigned intsg_in_idx;
+ struct scatterlist *in_sg;
+ struct scatterlist in_sg_chain[2];
+ boolin_sg_chained;
+ size_t total;
+};
+
struct sahara_dev {
struct device *device;
+ unsigned intversion;
void __iomem*regs_base;
struct clk *clk_ipg;
struct clk *clk_ahb;
struct sahara_ctx *ctx;
+ struct sahara_sha_reqctx*rctx;
spinlock_t lock;
- struct crypto_queue queue;
+ struct crypto_queue queue[SAHARA_CHANS];
unsigned long flags;
- struct tasklet_struct done_task;
- struct tasklet_struct queue_task;
+ struct tasklet_struct done_task[SAHARA_CHANS];
+ struct tasklet_struct queue_task[SAHARA_CHANS];
struct sahara_hw_desc *hw_desc[SAHARA_MAX_HW_DESC];
dma_addr_t hw_phys_desc[SAHARA_MAX_HW_DESC];
@@ -153,10 +210,13 @@ struct sahara_dev {
u8 *iv_base;
dma_addr_t iv_phys_base;
+ u8 *context_base;
+ dma_addr_t context_phys_base;
+
struct sahara_hw_link *hw_link[SAHARA_MAX_HW_LINK];
dma_addr_t hw_phys_link[SAHARA_MAX_HW_LINK];
- struct ablkcipher_request *req;
+ struct crypto_async_request *req[SAHARA_CHANS];
size_t
[PATCH v3 2/3] crypto: sahara - add support for i.MX53
The Sahara on the i.MX53 is of version 4. Add support for probing the
device.
Signed-off-by: Steffen Trumtrar
---
.../devicetree/bindings/crypto/fsl-imx-sahara.txt | 2 +-
drivers/crypto/sahara.c | 17 ++---
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
index 5c65eccd0e56..e8a35c71e947 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
@@ -1,5 +1,5 @@
Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
-Currently only i.MX27 is supported.
+Currently only i.MX27 and i.MX53 are supported.
Required properties:
- compatible : Should be "fsl,-sahara"
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 6fb16fe7eea5..1782fc47335f 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -24,10 +24,12 @@
#include
#include
#include
+#include
#include
#define SAHARA_NAME "sahara"
#define SAHARA_VERSION_3 3
+#define SAHARA_VERSION_4 4
#define SAHARA_TIMEOUT_MS 1000
#define SAHARA_MAX_HW_DESC 2
#define SAHARA_MAX_HW_LINK 20
@@ -860,6 +862,7 @@ static struct platform_device_id sahara_platform_ids[] = {
MODULE_DEVICE_TABLE(platform, sahara_platform_ids);
static struct of_device_id sahara_dt_ids[] = {
+ { .compatible = "fsl,imx53-sahara" },
{ .compatible = "fsl,imx27-sahara" },
{ /* sentinel */ }
};
@@ -973,10 +976,18 @@ static int sahara_probe(struct platform_device *pdev)
clk_prepare_enable(dev->clk_ahb);
version = sahara_read(dev, SAHARA_REG_VERSION);
- if (version != SAHARA_VERSION_3) {
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx27-sahara")) {
+ if (version != SAHARA_VERSION_3)
+ err = -ENODEV;
+ } else if (of_device_is_compatible(pdev->dev.of_node,
+ "fsl,imx53-sahara")) {
+ if (((version >> 8) & 0xff) != SAHARA_VERSION_4)
+ err = -ENODEV;
+ version = (version >> 8) & 0xff;
+ }
+ if (err == -ENODEV) {
dev_err(&pdev->dev, "SAHARA version %d not supported\n",
- version);
- err = -ENODEV;
+ version);
goto err_algs;
}
--
2.1.1
--
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 v4 0/4] crypto: sahara - SHA support
Hi! This series adds support for - i.MX53 support - SHA1/256 to the SAHARA driver. - Version 4 is a major overhaul of the previous versions. The tasklet/watchdog implementation of the driver is replaced by a kthread and completions. This makes sure, that only one request is queued into the device and makes sure that the requests from user-space processes are correctly enqueued into the queue. This means, that the queue is responsible for sequentializing accesses from userspace. - The request is now saved into the sahara_sha_reqctx Regards, Steffen Steffen Trumtrar (4): crypto: sahara - fix spinlock initialization crypto: sahara - add support for i.MX53 crypto: sahara - replace tasklets with kthread crypto: sahara - add support for SHA1/256 .../devicetree/bindings/crypto/fsl-imx-sahara.txt | 2 +- drivers/crypto/sahara.c| 794 ++--- 2 files changed, 704 insertions(+), 92 deletions(-) -- 2.1.3 -- 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 v4 4/4] crypto: sahara - add support for SHA1/256
Add support for the MDHA unit in the SAHARA core.
The MDHA can generate hash digests for MD5 and SHA1 in version 3 and
additionally SHA224 and SHA256 in version 4.
Add the SHA1 and SHA256 algorithms to the driver.
The implementation was tested with the in-kernel testmgr and a userspace
testprogram using AF_ALG with+without upto 128 pthreads on each AES and
SHA256 on i.MX53.
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/sahara.c | 626 +++-
1 file changed, 621 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 04d3b4309e4c..579f539e5975 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -3,6 +3,7 @@
*
* Support for SAHARA cryptographic accelerator.
*
+ * Copyright (c) 2014 Steffen Trumtrar
* Copyright (c) 2013 Vista Silicon S.L.
* Author: Javier Martin
*
@@ -15,6 +16,10 @@
#include
#include
+#include
+#include
+#include
+#include
#include
#include
@@ -29,6 +34,9 @@
#include
#include
+#define SHA_BUFFER_LEN PAGE_SIZE
+#define SAHARA_MAX_SHA_BLOCK_SIZE SHA256_BLOCK_SIZE
+
#define SAHARA_NAME "sahara"
#define SAHARA_VERSION_3 3
#define SAHARA_VERSION_4 4
@@ -53,6 +61,23 @@
#define SAHARA_HDR_CHA_MDHA(2 << 28)
#define SAHARA_HDR_PARITY_BIT (1 << 31)
+#define SAHARA_HDR_MDHA_SET_MODE_MD_KEY0x2088
+#define SAHARA_HDR_MDHA_SET_MODE_HASH 0x208D
+#define SAHARA_HDR_MDHA_HASH 0xA085
+#define SAHARA_HDR_MDHA_STORE_DIGEST 0x2082
+#define SAHARA_HDR_MDHA_ALG_SHA1 0
+#define SAHARA_HDR_MDHA_ALG_MD51
+#define SAHARA_HDR_MDHA_ALG_SHA256 2
+#define SAHARA_HDR_MDHA_ALG_SHA224 3
+#define SAHARA_HDR_MDHA_PDATA (1 << 2)
+#define SAHARA_HDR_MDHA_HMAC (1 << 3)
+#define SAHARA_HDR_MDHA_INIT (1 << 5)
+#define SAHARA_HDR_MDHA_IPAD (1 << 6)
+#define SAHARA_HDR_MDHA_OPAD (1 << 7)
+#define SAHARA_HDR_MDHA_SWAP (1 << 8)
+#define SAHARA_HDR_MDHA_MAC_FULL (1 << 9)
+#define SAHARA_HDR_MDHA_SSL(1 << 10)
+
/* SAHARA can only process one request at a time */
#define SAHARA_QUEUE_LENGTH1
@@ -121,15 +146,58 @@ struct sahara_hw_link {
struct sahara_ctx {
unsigned long flags;
+
+ /* AES-specific context */
int keylen;
u8 key[AES_KEYSIZE_128];
struct crypto_ablkcipher *fallback;
+
+ /* SHA-specific context */
+ struct crypto_shash *shash_fallback;
};
struct sahara_aes_reqctx {
unsigned long mode;
};
+/*
+ * struct sahara_sha_reqctx - private data per request
+ * @buf: holds data for requests smaller than block_size
+ * @rembuf: used to prepare one block_size-aligned request
+ * @context: hw-specific context for request. Digest is extracted from this
+ * @mode: specifies what type of hw-descriptor needs to be built
+ * @digest_size: length of digest for this request
+ * @context_size: length of hw-context for this request.
+ *Always digest_size + 4
+ * @buf_cnt: number of bytes saved in buf
+ * @sg_in_idx: number of hw links
+ * @in_sg: scatterlist for input data
+ * @in_sg_chain: scatterlists for chained input data
+ * @in_sg_chained: specifies if chained scatterlists are used or not
+ * @total: total number of bytes for transfer
+ * @last: is this the last block
+ * @first: is this the first block
+ * @active: inside a transfer
+ */
+struct sahara_sha_reqctx {
+ u8 buf[SAHARA_MAX_SHA_BLOCK_SIZE];
+ u8 rembuf[SAHARA_MAX_SHA_BLOCK_SIZE];
+ u8 context[SHA256_DIGEST_SIZE + 4];
+ struct mutexmutex;
+ unsigned intmode;
+ unsigned intdigest_size;
+ unsigned intcontext_size;
+ unsigned intbuf_cnt;
+ unsigned intsg_in_idx;
+ struct scatterlist *in_sg;
+ struct scatterlist in_sg_chain[2];
+ boolin_sg_chained;
+ size_t total;
+ unsigned intlast;
+ unsigned intfirst;
+ unsigned intactive;
+};
+
struct sahara_dev {
struct device *device;
unsigned intversion;
@@ -154,6 +222,9 @@ struct sahara_dev {
u8 *iv_base;
dma_addr_t iv_phys_base;
+ u8 *context_base;
+ dma_addr_t context_phys_base;
+
struct sahara_hw_link *hw_link[SAHARA_MAX_HW_LINK];
dma_addr_t hw_phys_link[SAHARA_MAX_HW_LINK];
@@ -707,6 +778,316 @@ static void sahara_aes_cra_exit(struct crypto_tfm *tfm)
ctx->fallback = NULL;
}
+static u32 sahara_sha_init_hdr(struct sahara_dev *dev,
+
[PATCH v4 1/4] crypto: sahara - fix spinlock initialization
The driver uses a spinlock, but never initializes it. Fix this. Signed-off-by: Steffen Trumtrar --- drivers/crypto/sahara.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c index 164e1ec624e3..6fb16fe7eea5 100644 --- a/drivers/crypto/sahara.c +++ b/drivers/crypto/sahara.c @@ -956,6 +956,8 @@ static int sahara_probe(struct platform_device *pdev) crypto_init_queue(&dev->queue, SAHARA_QUEUE_LENGTH); + spin_lock_init(&dev->lock); + dev_ptr = dev; tasklet_init(&dev->queue_task, sahara_aes_queue_task, -- 2.1.3 -- 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 v4 3/4] crypto: sahara - replace tasklets with kthread
In preparation for SHA support, replace the tasklets with a kthread that
manages one crypto_queue for the core.
As the Sahara can only process one AES or SHA request at a time, we make
sure that the queue serializes all requests from userspace. Instead of a
watchdog timer we now use a completion mechanism in the queue manager
thread.
This makes the control flow more obvious and guarantees, that only one
request is dequeued until the completion is completed.
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/sahara.c | 152 +---
1 file changed, 66 insertions(+), 86 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 55c0d2bea426..04d3b4309e4c 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -22,7 +22,9 @@
#include
#include
#include
+#include
#include
+#include
#include
#include
#include
@@ -38,7 +40,6 @@
#define FLAGS_ENCRYPT BIT(0)
#define FLAGS_CBC BIT(1)
#define FLAGS_NEW_KEY BIT(3)
-#define FLAGS_BUSY 4
#define SAHARA_HDR_BASE0x0080
#define SAHARA_HDR_SKHA_ALG_AES0
@@ -119,7 +120,6 @@ struct sahara_hw_link {
};
struct sahara_ctx {
- struct sahara_dev *dev;
unsigned long flags;
int keylen;
u8 key[AES_KEYSIZE_128];
@@ -136,15 +136,15 @@ struct sahara_dev {
void __iomem*regs_base;
struct clk *clk_ipg;
struct clk *clk_ahb;
+ struct mutexqueue_mutex;
+ struct task_struct *kthread;
+ struct completion dma_completion;
struct sahara_ctx *ctx;
spinlock_t lock;
struct crypto_queue queue;
unsigned long flags;
- struct tasklet_struct done_task;
- struct tasklet_struct queue_task;
-
struct sahara_hw_desc *hw_desc[SAHARA_MAX_HW_DESC];
dma_addr_t hw_phys_desc[SAHARA_MAX_HW_DESC];
@@ -157,7 +157,6 @@ struct sahara_dev {
struct sahara_hw_link *hw_link[SAHARA_MAX_HW_LINK];
dma_addr_t hw_phys_link[SAHARA_MAX_HW_LINK];
- struct ablkcipher_request *req;
size_t total;
struct scatterlist *in_sg;
unsigned intnb_in_sg;
@@ -165,7 +164,6 @@ struct sahara_dev {
unsigned intnb_out_sg;
u32 error;
- struct timer_list watchdog;
};
static struct sahara_dev *dev_ptr;
@@ -404,34 +402,6 @@ static void sahara_dump_links(struct sahara_dev *dev)
dev_dbg(dev->device, "\n");
}
-static void sahara_aes_done_task(unsigned long data)
-{
- struct sahara_dev *dev = (struct sahara_dev *)data;
-
- dma_unmap_sg(dev->device, dev->out_sg, dev->nb_out_sg,
- DMA_TO_DEVICE);
- dma_unmap_sg(dev->device, dev->in_sg, dev->nb_in_sg,
- DMA_FROM_DEVICE);
-
- spin_lock(&dev->lock);
- clear_bit(FLAGS_BUSY, &dev->flags);
- spin_unlock(&dev->lock);
-
- dev->req->base.complete(&dev->req->base, dev->error);
-}
-
-static void sahara_watchdog(unsigned long data)
-{
- struct sahara_dev *dev = (struct sahara_dev *)data;
- unsigned int err = sahara_read(dev, SAHARA_REG_ERRSTATUS);
- unsigned int stat = sahara_read(dev, SAHARA_REG_STATUS);
-
- sahara_decode_status(dev, stat);
- sahara_decode_error(dev, err);
- dev->error = -ETIMEDOUT;
- sahara_aes_done_task(data);
-}
-
static int sahara_hw_descriptor_create(struct sahara_dev *dev)
{
struct sahara_ctx *ctx = dev->ctx;
@@ -515,9 +485,6 @@ static int sahara_hw_descriptor_create(struct sahara_dev
*dev)
sahara_dump_descriptors(dev);
sahara_dump_links(dev);
- /* Start processing descriptor chain. */
- mod_timer(&dev->watchdog,
- jiffies + msecs_to_jiffies(SAHARA_TIMEOUT_MS));
sahara_write(dev, dev->hw_phys_desc[0], SAHARA_REG_DAR);
return 0;
@@ -532,37 +499,19 @@ unmap_in:
return -EINVAL;
}
-static void sahara_aes_queue_task(unsigned long data)
+static int sahara_aes_process(struct ablkcipher_request *req)
{
- struct sahara_dev *dev = (struct sahara_dev *)data;
- struct crypto_async_request *async_req, *backlog;
+ struct sahara_dev *dev = dev_ptr;
struct sahara_ctx *ctx;
struct sahara_aes_reqctx *rctx;
- struct ablkcipher_request *req;
int ret;
- spin_lock(&dev->lock);
- backlog = crypto_get_backlog(&dev->queue);
- async_req = crypto_dequeue_request(&dev->queue);
- if (!async_req)
- clear_bit(FLAGS_BUSY, &dev->flags);
- spin_unlock(&dev->lock);
-
- if (!async_req)
- return;
-
-
[PATCH v4 2/4] crypto: sahara - add support for i.MX53
The Sahara on the i.MX53 is of version 4. Add support for probing the
device.
Signed-off-by: Steffen Trumtrar
---
.../devicetree/bindings/crypto/fsl-imx-sahara.txt| 2 +-
drivers/crypto/sahara.c | 20 +---
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
index 5c65eccd0e56..e8a35c71e947 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-sahara.txt
@@ -1,5 +1,5 @@
Freescale SAHARA Cryptographic Accelerator included in some i.MX chips.
-Currently only i.MX27 is supported.
+Currently only i.MX27 and i.MX53 are supported.
Required properties:
- compatible : Should be "fsl,-sahara"
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 6fb16fe7eea5..55c0d2bea426 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -24,10 +24,12 @@
#include
#include
#include
+#include
#include
#define SAHARA_NAME "sahara"
#define SAHARA_VERSION_3 3
+#define SAHARA_VERSION_4 4
#define SAHARA_TIMEOUT_MS 1000
#define SAHARA_MAX_HW_DESC 2
#define SAHARA_MAX_HW_LINK 20
@@ -130,6 +132,7 @@ struct sahara_aes_reqctx {
struct sahara_dev {
struct device *device;
+ unsigned intversion;
void __iomem*regs_base;
struct clk *clk_ipg;
struct clk *clk_ahb;
@@ -860,6 +863,7 @@ static struct platform_device_id sahara_platform_ids[] = {
MODULE_DEVICE_TABLE(platform, sahara_platform_ids);
static struct of_device_id sahara_dt_ids[] = {
+ { .compatible = "fsl,imx53-sahara" },
{ .compatible = "fsl,imx27-sahara" },
{ /* sentinel */ }
};
@@ -973,13 +977,23 @@ static int sahara_probe(struct platform_device *pdev)
clk_prepare_enable(dev->clk_ahb);
version = sahara_read(dev, SAHARA_REG_VERSION);
- if (version != SAHARA_VERSION_3) {
+ if (of_device_is_compatible(pdev->dev.of_node, "fsl,imx27-sahara")) {
+ if (version != SAHARA_VERSION_3)
+ err = -ENODEV;
+ } else if (of_device_is_compatible(pdev->dev.of_node,
+ "fsl,imx53-sahara")) {
+ if (((version >> 8) & 0xff) != SAHARA_VERSION_4)
+ err = -ENODEV;
+ version = (version >> 8) & 0xff;
+ }
+ if (err == -ENODEV) {
dev_err(&pdev->dev, "SAHARA version %d not supported\n",
- version);
- err = -ENODEV;
+ version);
goto err_algs;
}
+ dev->version = version;
+
sahara_write(dev, SAHARA_CMD_RESET | SAHARA_CMD_MODE_BATCH,
SAHARA_REG_CMD);
sahara_write(dev, SAHARA_CONTROL_SET_THROTTLE(0) |
--
2.1.3
--
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
[QUESTION] How is the backlog supposed to be used?
Hi all!
I have a question regarding the use of the backlog in a driver
using the crypto API.
In my driver ("crypto: sahara - SHA support") I had a problem with
using the backlog when I am using more than one thread to enqueue
the requests and have a queue depth of 1. What happens is, that I
run into the backlog and then complete the request twice, if I do
it like all the other drivers. Random example:
backlog = crypto_get_backlog(&sdcp->queue[chan]);
arq = crypto_dequeue_request(&sdcp->queue[chan]);
if (backlog)
backlog->complete(backlog, -EINPROGRESS);
Everything works fine if I do not complete the request from the
backlog, but instead complete the request when it is due.
Alternative: make the queue deeper like some drivers have it.
If the queue is deeper than I have threads, it works, because
the requests never get onto the backlog.
So, how is the queue intended to be used? What is a correct max_depth?
Do I need to complete the requests from the backlog or not?
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 v4 0/4] crypto: sahara - SHA support
On Wed, Dec 03, 2014 at 10:34:16PM +0800, Herbert Xu wrote: > On Mon, Dec 01, 2014 at 01:26:30PM +0100, Steffen Trumtrar wrote: > > Hi! > > > > This series adds support for > > - i.MX53 support > > - SHA1/256 > > to the SAHARA driver. > > > > - Version 4 is a major overhaul of the previous versions. > > The tasklet/watchdog implementation of the driver is replaced by a kthread > > and completions. This makes sure, that only one request is queued into > > the device and makes sure that the requests from user-space processes are > > correctly enqueued into the queue. This means, that the queue is > > responsible > > for sequentializing accesses from userspace. > > > > - The request is now saved into the sahara_sha_reqctx > > All applied to cryptodev. Nice work Steffen, thanks! \o/ Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 2/2] crypto: sahara - fix AES descriptor create
The AES implementation still assumes, that the hw_desc[0] has a valid
key as long as no new key needs to be set; consequentialy it always
sets the AES key header for the first descriptor and puts data into
the second one (hw_desc[1]).
Change this to only update the key in the hardware, when a new key is
to be set and use the first descriptor for data otherwise.
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/sahara.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index d488d97fcee3..84397e0ad647 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -479,6 +479,7 @@ static int sahara_hw_descriptor_create(struct sahara_dev
*dev)
struct scatterlist *sg;
int ret;
int i, j;
+ int idx = 0;
/* Copy new key if necessary */
if (ctx->flags & FLAGS_NEW_KEY) {
@@ -486,17 +487,20 @@ static int sahara_hw_descriptor_create(struct sahara_dev
*dev)
ctx->flags &= ~FLAGS_NEW_KEY;
if (dev->flags & FLAGS_CBC) {
- dev->hw_desc[0]->len1 = AES_BLOCK_SIZE;
- dev->hw_desc[0]->p1 = dev->iv_phys_base;
+ dev->hw_desc[idx]->len1 = AES_BLOCK_SIZE;
+ dev->hw_desc[idx]->p1 = dev->iv_phys_base;
} else {
- dev->hw_desc[0]->len1 = 0;
- dev->hw_desc[0]->p1 = 0;
+ dev->hw_desc[idx]->len1 = 0;
+ dev->hw_desc[idx]->p1 = 0;
}
- dev->hw_desc[0]->len2 = ctx->keylen;
- dev->hw_desc[0]->p2 = dev->key_phys_base;
- dev->hw_desc[0]->next = dev->hw_phys_desc[1];
+ dev->hw_desc[idx]->len2 = ctx->keylen;
+ dev->hw_desc[idx]->p2 = dev->key_phys_base;
+ dev->hw_desc[idx]->next = dev->hw_phys_desc[1];
+
+ dev->hw_desc[idx]->hdr = sahara_aes_key_hdr(dev);
+
+ idx++;
}
- dev->hw_desc[0]->hdr = sahara_aes_key_hdr(dev);
dev->nb_in_sg = sahara_sg_length(dev->in_sg, dev->total);
dev->nb_out_sg = sahara_sg_length(dev->out_sg, dev->total);
@@ -520,7 +524,7 @@ static int sahara_hw_descriptor_create(struct sahara_dev
*dev)
}
/* Create input links */
- dev->hw_desc[1]->p1 = dev->hw_phys_link[0];
+ dev->hw_desc[idx]->p1 = dev->hw_phys_link[0];
sg = dev->in_sg;
for (i = 0; i < dev->nb_in_sg; i++) {
dev->hw_link[i]->len = sg->length;
@@ -534,7 +538,7 @@ static int sahara_hw_descriptor_create(struct sahara_dev
*dev)
}
/* Create output links */
- dev->hw_desc[1]->p2 = dev->hw_phys_link[i];
+ dev->hw_desc[idx]->p2 = dev->hw_phys_link[i];
sg = dev->out_sg;
for (j = i; j < dev->nb_out_sg + i; j++) {
dev->hw_link[j]->len = sg->length;
@@ -548,10 +552,10 @@ static int sahara_hw_descriptor_create(struct sahara_dev
*dev)
}
/* Fill remaining fields of hw_desc[1] */
- dev->hw_desc[1]->hdr = sahara_aes_data_link_hdr(dev);
- dev->hw_desc[1]->len1 = dev->total;
- dev->hw_desc[1]->len2 = dev->total;
- dev->hw_desc[1]->next = 0;
+ dev->hw_desc[idx]->hdr = sahara_aes_data_link_hdr(dev);
+ dev->hw_desc[idx]->len1 = dev->total;
+ dev->hw_desc[idx]->len2 = dev->total;
+ dev->hw_desc[idx]->next = 0;
sahara_dump_descriptors(dev);
sahara_dump_links(dev);
--
2.1.4
--
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 1/2] crypto: sahara - use the backlog
With commit
7e77bdebff5cb1e9876c561f69710b9ab8fa1f7e crypto: af_alg - fix backlog
handling
in place, the backlog works under all circumstances where it previously failed,
atleast
for the sahara driver. Use it.
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/sahara.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 290a7f0a681f..d488d97fcee3 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -1092,15 +1092,20 @@ static int sahara_queue_manage(void *data)
{
struct sahara_dev *dev = (struct sahara_dev *)data;
struct crypto_async_request *async_req;
+ struct crypto_async_request *backlog;
int ret = 0;
do {
__set_current_state(TASK_INTERRUPTIBLE);
mutex_lock(&dev->queue_mutex);
+ backlog = crypto_get_backlog(&dev->queue);
async_req = crypto_dequeue_request(&dev->queue);
mutex_unlock(&dev->queue_mutex);
+ if (backlog)
+ backlog->complete(backlog, -EINPROGRESS);
+
if (async_req) {
if (crypto_tfm_alg_type(async_req->tfm) ==
CRYPTO_ALG_TYPE_AHASH) {
--
2.1.4
--
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: Sahara performance on i.MX53
Hi! On Mon, Apr 27, 2015 at 07:16:22PM +0200, Martin Fuzzey wrote: > Hi, > > I've been trying the Sahara crypto module on i.MX53 [mainline 3.19 > kernel + b251638c46a (crypto: sahara - use the backlog)] > > I tested using dm-crypt with AES-128: > cryptsetup -v --key-size=128 luksFormat /dev/mmcblk0p7 > cryptsetup luksOpen /dev/mmcblk0p7 cryptotest > > dd if=/dev/mapper/cryptotest of=/dev/null bs=1M count=100 > > > CPU Freq (MHz) Time (s) WITHOUT SaharaTime (s) WITH Sahara > 1200 3.26 5.34 > 1000 3.26 5.62 > 8004.0 6.24 > 4007.72 9.86 > 16618.42 18.87 > > I was hoping for something better. > There is a reduction in CPU usage as expected but the performance > figures aren't looking very good. > As this is in kernel use by dm-crypt cryptodev or af_alg aren't involved. > > Has anyone else done any measurements? > Yes. My measurements wheren't overwhelming either. :-( The problem with the Sahara is: NDAs. So, I am Jon Snow and know nothing :-( Everything I do know, is from the Freescale kernel git repo. Maybe I missed something. The FSL driver is very cryptic if you ask me; so it is absolutely possible. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 v4 2/3] ARM: i.MX25: add scc module to dtsi
Add the Security Controller (SCC) module to the dtsi.
Signed-off-by: Steffen Trumtrar
---
arch/arm/boot/dts/imx25.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 6b1f4bbe6ec6..af6af8741fe5 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -420,6 +420,15 @@
interrupts = <41>;
};
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
+
esdhc1: esdhc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
--
2.7.0
--
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 v4 3/3] crypto: add basic driver for the MXC SCC
According to the Freescale GPL driver code, there are two different Security Controller (SCC) versions: SCC and SCC2. The SCC is found on older i.MX SoCs, e.g. the i.MX25. This is the version implemented and tested here. As there is no publicly available documentation for this IP core, all information about this unit is gathered from the GPL'ed driver from Freescale. Signed-off-by: Steffen Trumtrar --- Changes in v4: - copy back IV on exit - rebase to v4.6-rc1 Changes in v3: - don't just unlock mutex in mxc_scc_ablkcipher_next, but also return, too - replace mutex with bool to make lookdep happy Changes in v2: - minor code cleanups - mxc_scc_ablkcipher_next: complete request with error before mutex_unlock drivers/crypto/Kconfig | 9 + drivers/crypto/Makefile | 1 + drivers/crypto/mxc-scc.c | 761 +++ 3 files changed, 771 insertions(+) create mode 100644 drivers/crypto/mxc-scc.c diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 477fffdb4f49..ac62c28277da 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -340,6 +340,15 @@ config CRYPTO_DEV_SAHARA This option enables support for the SAHARA HW crypto accelerator found in some Freescale i.MX chips. +config CRYPTO_DEV_MXC_SCC + tristate "Support for Freescale Security Controller (SCC)" + depends on ARCH_MXC && OF + select CRYPTO_BLKCIPHER + select CRYPTO_DES + help + This option enables support for the Security Controller (SCC) + found in Freescale i.MX25 chips. + config CRYPTO_DEV_S5P tristate "Support for Samsung S5PV210/Exynos crypto accelerator" depends on ARCH_S5PV210 || ARCH_EXYNOS diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 713de9d11148..3c6432dd09d9 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/ obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o +obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/ diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c new file mode 100644 index ..5b714a8acd35 --- /dev/null +++ b/drivers/crypto/mxc-scc.c @@ -0,0 +1,761 @@ +/* + * Copyright (C) 2016 Pengutronix, Steffen Trumtrar + * + * The driver is based on information gathered from + * drivers/mxc/security/mxc_scc.c which can be found in + * the Freescale linux-2.6-imx.git in the imx_2.6.35_maintain branch. + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* Secure Memory (SCM) registers */ +#define SCC_SCM_RED_START 0x +#define SCC_SCM_BLACK_START0x0004 +#define SCC_SCM_LENGTH 0x0008 +#define SCC_SCM_CTRL 0x000C +#define SCC_SCM_STATUS 0x0010 +#define SCC_SCM_ERROR_STATUS 0x0014 +#define SCC_SCM_INTR_CTRL 0x0018 +#define SCC_SCM_CFG0x001C +#define SCC_SCM_INIT_VECTOR_0 0x0020 +#define SCC_SCM_INIT_VECTOR_1 0x0024 +#define SCC_SCM_RED_MEMORY 0x0400 +#define SCC_SCM_BLACK_MEMORY 0x0800 + +/* Security Monitor (SMN) Registers */ +#define SCC_SMN_STATUS 0x1000 +#define SCC_SMN_COMMAND0x1004 +#define SCC_SMN_SEQ_START 0x1008 +#define SCC_SMN_SEQ_END0x100C +#define SCC_SMN_SEQ_CHECK 0x1010 +#define SCC_SMN_BIT_COUNT 0x1014 +#define SCC_SMN_BITBANK_INC_SIZE 0x1018 +#define SCC_SMN_BITBANK_DECREMENT 0x101C +#define SCC_SMN_COMPARE_SIZE 0x1020 +#define SCC_SMN_PLAINTEXT_CHECK0x1024 +#define SCC_SMN_CIPHERTEXT_CHECK 0x1028 +#define SCC_SMN_TIMER_IV 0x102C +#define SCC_SMN_TIMER_CONTROL 0x1030 +#define SCC_SMN_DEBUG_DETECT_STAT 0x1034 +#define SCC_SMN_TIMER 0x1038 + +#define SCC_SCM_CTRL_START_CIPHER BIT(2) +#define SCC_SCM_CTRL_CBC_MODE BIT(1) +#define SCC_SCM_CTRL_DECRYPT_MODE BIT(0) + +#define SCC_SCM_STATUS_LEN_ERR BIT(12) +#define SCC_SCM_STATUS_SMN_UNBLOCKED BIT(11) +#define SCC_SCM_S
[PATCH v4 1/3] Documentation: devicetree: add Freescale SCC bindings
Add documentation for the Freescale Security Controller (SCC)
found on i.MX25 SoCs.
Signed-off-by: Steffen Trumtrar
Acked-by: Rob Herring
---
Changes in v2:
- add clocks to required properties
- add Acked-by
.../devicetree/bindings/crypto/fsl-imx-scc.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
new file mode 100644
index ..7aad448e8a36
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
@@ -0,0 +1,21 @@
+Freescale Security Controller (SCC)
+
+Required properties:
+- compatible : Should be "fsl,imx25-scc".
+- reg : Should contain register location and length.
+- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
+- interrupt-names : Should specify the names "scm" and "smn" for the
+ SCM IRQ and SMN IRQ.
+- clocks: Should contain the clock driving the SCC core.
+- clock-names: Should be set to "ipg".
+
+Example:
+
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
--
2.7.0
--
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 v5 2/3] ARM: i.MX25: add scc module to dtsi
Add the Security Controller (SCC) module to the dtsi.
Signed-off-by: Steffen Trumtrar
---
arch/arm/boot/dts/imx25.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 6b1f4bbe6ec6..af6af8741fe5 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -420,6 +420,15 @@
interrupts = <41>;
};
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
+
esdhc1: esdhc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
--
2.7.0
--
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 v5 1/3] Documentation: devicetree: add Freescale SCC bindings
Add documentation for the Freescale Security Controller (SCC)
found on i.MX25 SoCs.
Signed-off-by: Steffen Trumtrar
Acked-by: Rob Herring
---
Changes in v2:
- add clocks to required properties
- add Acked-by
.../devicetree/bindings/crypto/fsl-imx-scc.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
new file mode 100644
index ..7aad448e8a36
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
@@ -0,0 +1,21 @@
+Freescale Security Controller (SCC)
+
+Required properties:
+- compatible : Should be "fsl,imx25-scc".
+- reg : Should contain register location and length.
+- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
+- interrupt-names : Should specify the names "scm" and "smn" for the
+ SCM IRQ and SMN IRQ.
+- clocks: Should contain the clock driving the SCC core.
+- clock-names: Should be set to "ipg".
+
+Example:
+
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
--
2.7.0
--
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 v5 3/3] crypto: add basic driver for the MXC SCC
According to the Freescale GPL driver code, there are two different Security Controller (SCC) versions: SCC and SCC2. The SCC is found on older i.MX SoCs, e.g. the i.MX25. This is the version implemented and tested here. As there is no publicly available documentation for this IP core, all information about this unit is gathered from the GPL'ed driver from Freescale. Signed-off-by: Steffen Trumtrar --- Changes in v5: - fix bug in mxc_scc_ablkcipher_req_complete call Changes in v4: - copy back IV on exit - rebase to v4.6-rc1 Changes in v3: - don't just unlock mutex in mxc_scc_ablkcipher_next, but also return, too - replace mutex with bool to make lookdep happy Changes in v2: - minor code cleanups - mxc_scc_ablkcipher_next: complete request with error before mutex_unlock drivers/crypto/Kconfig | 9 + drivers/crypto/Makefile | 1 + drivers/crypto/mxc-scc.c | 762 +++ 3 files changed, 772 insertions(+) create mode 100644 drivers/crypto/mxc-scc.c diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 477fffdb4f49..ac62c28277da 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -340,6 +340,15 @@ config CRYPTO_DEV_SAHARA This option enables support for the SAHARA HW crypto accelerator found in some Freescale i.MX chips. +config CRYPTO_DEV_MXC_SCC + tristate "Support for Freescale Security Controller (SCC)" + depends on ARCH_MXC && OF + select CRYPTO_BLKCIPHER + select CRYPTO_DES + help + This option enables support for the Security Controller (SCC) + found in Freescale i.MX25 chips. + config CRYPTO_DEV_S5P tristate "Support for Samsung S5PV210/Exynos crypto accelerator" depends on ARCH_S5PV210 || ARCH_EXYNOS diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 713de9d11148..3c6432dd09d9 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/ obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o +obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/ diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c new file mode 100644 index ..38b01bf141d3 --- /dev/null +++ b/drivers/crypto/mxc-scc.c @@ -0,0 +1,762 @@ +/* + * Copyright (C) 2016 Pengutronix, Steffen Trumtrar + * + * The driver is based on information gathered from + * drivers/mxc/security/mxc_scc.c which can be found in + * the Freescale linux-2.6-imx.git in the imx_2.6.35_maintain branch. + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* Secure Memory (SCM) registers */ +#define SCC_SCM_RED_START 0x +#define SCC_SCM_BLACK_START0x0004 +#define SCC_SCM_LENGTH 0x0008 +#define SCC_SCM_CTRL 0x000C +#define SCC_SCM_STATUS 0x0010 +#define SCC_SCM_ERROR_STATUS 0x0014 +#define SCC_SCM_INTR_CTRL 0x0018 +#define SCC_SCM_CFG0x001C +#define SCC_SCM_INIT_VECTOR_0 0x0020 +#define SCC_SCM_INIT_VECTOR_1 0x0024 +#define SCC_SCM_RED_MEMORY 0x0400 +#define SCC_SCM_BLACK_MEMORY 0x0800 + +/* Security Monitor (SMN) Registers */ +#define SCC_SMN_STATUS 0x1000 +#define SCC_SMN_COMMAND0x1004 +#define SCC_SMN_SEQ_START 0x1008 +#define SCC_SMN_SEQ_END0x100C +#define SCC_SMN_SEQ_CHECK 0x1010 +#define SCC_SMN_BIT_COUNT 0x1014 +#define SCC_SMN_BITBANK_INC_SIZE 0x1018 +#define SCC_SMN_BITBANK_DECREMENT 0x101C +#define SCC_SMN_COMPARE_SIZE 0x1020 +#define SCC_SMN_PLAINTEXT_CHECK0x1024 +#define SCC_SMN_CIPHERTEXT_CHECK 0x1028 +#define SCC_SMN_TIMER_IV 0x102C +#define SCC_SMN_TIMER_CONTROL 0x1030 +#define SCC_SMN_DEBUG_DETECT_STAT 0x1034 +#define SCC_SMN_TIMER 0x1038 + +#define SCC_SCM_CTRL_START_CIPHER BIT(2) +#define SCC_SCM_CTRL_CBC_MODE BIT(1) +#define SCC_SCM_CTRL_DECRYPT_MODE BIT(0) + +#define SCC_SCM_STATUS_LEN_ERR BIT(12) +#define
[BUG?] crypto: caam: little/big endianness on ARM vs PPC
Hi!
I'm working on CAAM support for the ARM-based i.MX6 SoCs. The current
drivers/crypto/caam driver only works for PowerPC AFAIK.
Actually, there isn't that much to do, to get support for the i.MX6 but
one patch breaks the driver severely:
commit ef94b1d834aace7101de77c3a7c2631b9ae9c5f6
crypto: caam - Add definition of rd/wr_reg64 for little endian platform
This patch adds
+#ifdef __LITTLE_ENDIAN
+static inline void wr_reg64(u64 __iomem *reg, u64 data)
+{
+ wr_reg32((u32 __iomem *)reg + 1, (data & 0xull) >> 32);
+ wr_reg32((u32 __iomem *)reg, data & 0xull);
+}
The wr_reg64 function is only used in one place in the drivers/crypto/caam/jr.c
driver: to write the dma_addr_t to the register. Without that patch everything
works fine on ARM (little endian, 32bit), with that patch the driver will write
0's into the register that holds the DMA address (the numerically-higher) ->
kernel hangs.
Also, from my understanding, the comment above the defines, stating that you
have to first write the numerically-lower and then the numerically-higher
address
on 32bit systems doesn't match with the implementation.
What I don't know/understand is if this makes any sense for any PowerPC
implementation.
So, the question is, how to fix this? I'd prefer to do it directly in the jr
driver
instead of the ifdef-ery.
Something like
if (sizeof(dma_addr_t) == sizeof(u32))
wr_reg32(&jrp->rregs->inpring_base + 1, inpbusaddr);
else if (sizeof(dma_addr_t) == sizeof(u64))
wr_reg64(...)
or just go by DT compatible and then remove the inline function definitions.
As far as I can tell, the compatible wouldn't be needed for anything else in the
jr driver, so maybe that is not optimal. On the other hand the sizeof(..)
solution would only catch little endian on 32bit and not big endian (?!)
I however don't know what combinations actually *have* to be caught, as I don't
know, which exist.
So, what do you think people?
Thanks,
Steffen Trumtrar
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: [BUG?] crypto: caam: little/big endianness on ARM vs PPC
Hi!
On Mon, Jun 15, 2015 at 05:28:16PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jun 15, 2015 at 05:59:07PM +0200, Steffen Trumtrar wrote:
> > I'm working on CAAM support for the ARM-based i.MX6 SoCs. The current
> > drivers/crypto/caam driver only works for PowerPC AFAIK.
> > Actually, there isn't that much to do, to get support for the i.MX6 but
> > one patch breaks the driver severely:
> >
> > commit ef94b1d834aace7101de77c3a7c2631b9ae9c5f6
> > crypto: caam - Add definition of rd/wr_reg64 for little endian platform
>
> You're not the only one who's hitting problems with this - Jon Nettleton
> has been working on it recently.
>
> The way this has been done is fairly yucky to start with: several things
> about it are particularly horrid. The first is the repetitive code
> for the BE and LE cases, when all that's actually different is the
> register order between the two code cases.
>
> The second thing is the excessive use of masking - I'm pretty sure the
> compiler won't complain with the below.
>
> diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
> index 378ddc17f60e..ba0fa630a25d 100644
> --- a/drivers/crypto/caam/regs.h
> +++ b/drivers/crypto/caam/regs.h
> @@ -84,34 +84,28 @@
> #endif
>
> #ifndef CONFIG_64BIT
> -#ifdef __BIG_ENDIAN
> -static inline void wr_reg64(u64 __iomem *reg, u64 data)
> -{
> - wr_reg32((u32 __iomem *)reg, (data & 0xull) >> 32);
> - wr_reg32((u32 __iomem *)reg + 1, data & 0xull);
> -}
> -
> -static inline u64 rd_reg64(u64 __iomem *reg)
> -{
> - return (((u64)rd_reg32((u32 __iomem *)reg)) << 32) |
> - ((u64)rd_reg32((u32 __iomem *)reg + 1));
> -}
> +#if defined(__BIG_ENDIAN)
> +#define REG64_HI32(reg) ((u32 __iomem *)(reg))
> +#define REG64_LO32(reg) ((u32 __iomem *)(reg) + 1)
> +#elif defined(__LITTLE_ENDIAN)
> +#define REG64_HI32(reg) ((u32 __iomem *)(reg) + 1)
> +#define REG64_LO32(reg) ((u32 __iomem *)(reg))
> #else
> -#ifdef __LITTLE_ENDIAN
> +#error Broken endian?
> +#endif
> +
> static inline void wr_reg64(u64 __iomem *reg, u64 data)
> {
> - wr_reg32((u32 __iomem *)reg + 1, (data & 0xull) >> 32);
> - wr_reg32((u32 __iomem *)reg, data & 0xull);
> + wr_reg32(REG64_HI32(reg), data >> 32);
> + wr_reg32(REG64_LO32(reg), data);
> }
>
> static inline u64 rd_reg64(u64 __iomem *reg)
> {
> - return (((u64)rd_reg32((u32 __iomem *)reg + 1)) << 32) |
> - ((u64)rd_reg32((u32 __iomem *)reg));
> + return ((u64)rd_reg32(REG64_HI32(reg))) << 32 |
> + rd_reg32(REG64_LO32(reg));
> }
> #endif
> -#endif
> -#endif
>
> /*
> * jr_outentry
>
> The second issue is that apparently, the register order doesn't actually
> change for LE devices - in other words, the byte order within each register
> does change, but they aren't a 64-bit register, they're two separate 32-bit
> registers. So, they should always be written as such.
>
> So, I'd get rid of the #if defined(__BIG_ENDIAN) stuff and instead have:
>
> +/*
> + * The DMA address register is a pair of 32-bit registers, and should
> + * always be accessed as such.
> + */
> +#define REG64_HI32(reg) ((u32 __iomem *)(reg))
> +#define REG64_LO32(reg) ((u32 __iomem *)(reg) + 1)
>
Thanks for all your explanations (in the other mail, too).
I, personally, like this approach the best; at least in the current state
of the driver.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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] crypto: caam - fix non-64-bit write/read access
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
Signed-off-by: Steffen Trumtrar
---
This patch is only compile-tested for PowerPC and tested on ARM.
According to the datasheets for i.MX6 and P1010 this should be correct, though.
drivers/crypto/caam/regs.h | 38 +++---
1 file changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 378ddc17f60e..672c97489505 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -83,35 +83,35 @@
#endif
#endif
+/*
+ * The only users of these wr/rd_reg64 functions is the Job Ring (JR).
+ * The DMA address registers in the JR are a pair of 32-bit registers.
+ * The layout is:
+ *
+ *base + 0x : most-significant 32 bits
+ *base + 0x0004 : least-significant 32 bits
+ *
+ * The 32-bit version of this core therefore has to write to base + 0x0004
+ * to set the 32-bit wide DMA address. This seems to be independent of the
+ * endianness of the written/read data.
+ */
+
#ifndef CONFIG_64BIT
-#ifdef __BIG_ENDIAN
-static inline void wr_reg64(u64 __iomem *reg, u64 data)
-{
- wr_reg32((u32 __iomem *)reg, (data & 0xull) >> 32);
- wr_reg32((u32 __iomem *)reg + 1, data & 0xull);
-}
+#define REG64_MS32(reg) ((u32 __iomem *)(reg))
+#define REG64_LS32(reg) ((u32 __iomem *)(reg) + 1)
-static inline u64 rd_reg64(u64 __iomem *reg)
-{
- return (((u64)rd_reg32((u32 __iomem *)reg)) << 32) |
- ((u64)rd_reg32((u32 __iomem *)reg + 1));
-}
-#else
-#ifdef __LITTLE_ENDIAN
static inline void wr_reg64(u64 __iomem *reg, u64 data)
{
- wr_reg32((u32 __iomem *)reg + 1, (data & 0xull) >> 32);
- wr_reg32((u32 __iomem *)reg, data & 0xull);
+ wr_reg32(REG64_MS32(reg), data >> 32);
+ wr_reg32(REG64_LS32(reg), data);
}
static inline u64 rd_reg64(u64 __iomem *reg)
{
- return (((u64)rd_reg32((u32 __iomem *)reg + 1)) << 32) |
- ((u64)rd_reg32((u32 __iomem *)reg));
+ return ((u64)rd_reg32(REG64_MS32(reg)) << 32 |
+ (u64)rd_reg32(REG64_LS32(reg)));
}
#endif
-#endif
-#endif
/*
* jr_outentry
--
2.1.4
--
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: [BUG?] crypto: caam: little/big endianness on ARM vs PPC
Hi! On Tue, Jun 16, 2015 at 03:27:54AM +, Victoria Milhoan wrote: > All, > > Freescale has been adding i.MX6 support to the CAAM driver and testing on > both i.MX6 and QorIQ platforms. The patch series is now available for review. > Your feedback for the provided patches is appreciated. > Could you maybe bounce me that thread? I can't find it in a format that allows me to reply to the patches. Thanks, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 RFC 06/11] crypto: caam - Enable MXC devices to select CAAM driver in Kconfig
On Mon, Jun 15, 2015 at 04:52:54PM -0700, Victoria Milhoan wrote: > From: Steve Cornelius > > Allow CAAM to be selected in the kernel for Freescale i.MX6 devices if > ARCH_MXC is enabled. > > Signed-off-by: Steve Cornelius > Signed-off-by: Victoria Milhoan > --- > drivers/crypto/caam/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig > index e7555ff..bc9aa07 100644 > --- a/drivers/crypto/caam/Kconfig > +++ b/drivers/crypto/caam/Kconfig > @@ -1,6 +1,6 @@ > config CRYPTO_DEV_FSL_CAAM > tristate "Freescale CAAM-Multicore driver backend" > - depends on FSL_SOC > + depends on FSL_SOC || ARCH_MXC Is this right? Are there other i.MX that have the CAAM IP core? Sounds like it should be SOC_IMX6 instead. Regards, Steffen -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 RFC 05/11] crypto: caam - Add cache coherency support to Freescale CAAM scatterlist implementation
On Mon, Jun 15, 2015 at 04:52:53PM -0700, Victoria Milhoan wrote:
> Add cache coherency support to the CAAM scatterlist implementation.
>
> Signed-off-by: Victoria Milhoan
> ---
> drivers/crypto/caam/sg_sw_sec4.h | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/crypto/caam/sg_sw_sec4.h
> b/drivers/crypto/caam/sg_sw_sec4.h
> index 6365585..6730b01 100644
> --- a/drivers/crypto/caam/sg_sw_sec4.h
> +++ b/drivers/crypto/caam/sg_sw_sec4.h
> @@ -91,9 +91,14 @@ static int dma_map_sg_chained(struct device *dev, struct
> scatterlist *sg,
> {
> if (unlikely(chained)) {
> int i;
> + struct scatterlist *tsg = sg;
> +
> + /* We use a local copy of the sg pointer to avoid moving the
> + * head of the list pointed to by sg as we wall the list.
> + */
> for (i = 0; i < nents; i++) {
> - dma_map_sg(dev, sg, 1, dir);
> - sg = sg_next(sg);
> + dma_map_sg(dev, tsg, 1, dir);
> + tsg = scatterwalk_sg_next(tsg);
> }
> } else {
> dma_map_sg(dev, sg, nents, dir);
> @@ -106,6 +111,9 @@ static int dma_unmap_sg_chained(struct device *dev,
> struct scatterlist *sg,
> unsigned int nents, enum dma_data_direction dir,
> bool chained)
> {
> + if ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL))
> + dma_sync_sg_for_cpu(dev, sg, nents, dir);
> +
> if (unlikely(chained)) {
> int i;
> for (i = 0; i < nents; i++) {
You don't need to sync here, because you unmap it directly afterwards.
Regards,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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 RFC 01/11] crypto: caam - Add cache coherency support
On Mon, Jun 15, 2015 at 04:52:49PM -0700, Victoria Milhoan wrote:
> Freescale i.MX6 ARM platforms do not support hardware cache coherency. This
> patch adds cache coherency support to the CAAM driver.
>
> Signed-off-by: Victoria Milhoan
> ---
> drivers/crypto/caam/caamhash.c | 28 +--
> drivers/crypto/caam/caamrng.c| 10 +-
> drivers/crypto/caam/jr.c | 42
> +++-
> drivers/crypto/caam/key_gen.c| 4 +++-
> drivers/crypto/caam/sg_sw_sec4.h | 1 +
> 5 files changed, 72 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
> index ba0532e..1662c65 100644
> --- a/drivers/crypto/caam/caamhash.c
> +++ b/drivers/crypto/caam/caamhash.c
> @@ -500,6 +500,7 @@ static int hash_digest_key(struct caam_hash_ctx *ctx,
> const u8 *key_in,
> #endif
> }
> dma_unmap_single(jrdev, src_dma, *keylen, DMA_TO_DEVICE);
> + dma_sync_single_for_cpu(jrdev, dst_dma, digestsize, DMA_FROM_DEVICE);
> dma_unmap_single(jrdev, dst_dma, digestsize, DMA_FROM_DEVICE);
>
> *keylen = digestsize;
> @@ -608,8 +609,11 @@ static inline void ahash_unmap(struct device *dev,
> if (edesc->src_nents)
> dma_unmap_sg_chained(dev, req->src, edesc->src_nents,
>DMA_TO_DEVICE, edesc->chained);
> - if (edesc->dst_dma)
> + if (edesc->dst_dma) {
> + dma_sync_single_for_cpu(dev, edesc->dst_dma, dst_len,
> + DMA_FROM_DEVICE);
> dma_unmap_single(dev, edesc->dst_dma, dst_len, DMA_FROM_DEVICE);
> + }
>
> if (edesc->sec4_sg_bytes)
> dma_unmap_single(dev, edesc->sec4_sg_dma,
> @@ -624,8 +628,12 @@ static inline void ahash_unmap_ctx(struct device *dev,
> struct caam_hash_ctx *ctx = crypto_ahash_ctx(ahash);
> struct caam_hash_state *state = ahash_request_ctx(req);
>
> - if (state->ctx_dma)
> + if (state->ctx_dma) {
> + if ((flag == DMA_FROM_DEVICE) || (flag == DMA_BIDIRECTIONAL))
> + dma_sync_single_for_cpu(dev, state->ctx_dma,
> + ctx->ctx_len, flag);
> dma_unmap_single(dev, state->ctx_dma, ctx->ctx_len, flag);
> + }
> ahash_unmap(dev, edesc, req, dst_len);
> }
Unneeded syncing, dma_unmap does it as long as it is not told otherwise.
(...)
> diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
> index 26a544b..a8c4af9 100644
> --- a/drivers/crypto/caam/caamrng.c
> +++ b/drivers/crypto/caam/caamrng.c
> @@ -80,9 +80,12 @@ static struct caam_rng_ctx *rng_ctx;
>
> static inline void rng_unmap_buf(struct device *jrdev, struct buf_data *bd)
> {
> - if (bd->addr)
> + if (bd->addr) {
> + dma_sync_single_for_cpu(jrdev, bd->addr, RN_BUF_SIZE,
> + DMA_FROM_DEVICE);
> dma_unmap_single(jrdev, bd->addr, RN_BUF_SIZE,
>DMA_FROM_DEVICE);
> + }
> }
>
dito
> static inline void rng_unmap_ctx(struct caam_rng_ctx *ctx)
> @@ -108,6 +111,10 @@ static void rng_done(struct device *jrdev, u32 *desc,
> u32 err, void *context)
>
> atomic_set(&bd->empty, BUF_NOT_EMPTY);
> complete(&bd->filled);
> +
> + /* Buffer refilled, invalidate cache */
> + dma_sync_single_for_cpu(jrdev, bd->addr, RN_BUF_SIZE, DMA_FROM_DEVICE);
> +
This seems to be okay, though.
> #ifdef DEBUG
> print_hex_dump(KERN_ERR, "rng refreshed buf@: ",
> DUMP_PREFIX_ADDRESS, 16, 4, bd->buf, RN_BUF_SIZE, 1);
> @@ -211,6 +218,7 @@ static inline int rng_create_sh_desc(struct caam_rng_ctx
> *ctx)
> print_hex_dump(KERN_ERR, "rng shdesc@: ", DUMP_PREFIX_ADDRESS, 16, 4,
> desc, desc_bytes(desc), 1);
> #endif
> +
> return 0;
> }
>
> diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
> index b8b5d47..a693bf7 100644
> --- a/drivers/crypto/caam/jr.c
> +++ b/drivers/crypto/caam/jr.c
> @@ -168,6 +168,9 @@ static void caam_jr_dequeue(unsigned long devarg)
> void (*usercall)(struct device *dev, u32 *desc, u32 status, void *arg);
> u32 *userdesc, userstatus;
> void *userarg;
> + dma_addr_t outbusaddr;
> +
> + outbusaddr = rd_reg64(&jrp->rregs->outring_base);
>
> while (rd_reg32(&jrp->rregs->outring_used)) {
>
> @@ -177,10 +180,19 @@ static void caam_jr_dequeue(unsigned long devarg)
>
> sw_idx = tail = jrp->tail;
> hw_idx = jrp->out_ring_read_index;
> + dma_sync_single_for_cpu(dev, outbusaddr,
> + sizeof(struct jr_outentry) * JOBR_DEPTH,
> + DMA_FROM_DEVICE);
>
This one and ...
(...)
> @@ -321,7 +346,7 @@ int caam_jr_enqueue(struct device *dev, u32 *desc,
> struct caam_drv_private_jr *jrp = dev_get_drvdata(de
[RFC] crypto: caam - add red blobifier
Signed-off-by: Steffen Trumtrar
---
drivers/crypto/caam/Kconfig| 9 +
drivers/crypto/caam/Makefile | 1 +
drivers/crypto/caam/blob_gen.c | 528 +
3 files changed, 538 insertions(+)
create mode 100644 drivers/crypto/caam/blob_gen.c
diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
index e7555ff4cafd..329fab7ba4f7 100644
--- a/drivers/crypto/caam/Kconfig
+++ b/drivers/crypto/caam/Kconfig
@@ -99,6 +99,15 @@ config CRYPTO_DEV_FSL_CAAM_AHASH_API
To compile this as a module, choose M here: the module
will be called caamhash.
+config CRYPTO_DEV_FSL_CAAM_BLOB_GEN
+ tristate "CAAM Blob Generator (EXPERIMENTAL)"
+ depends on CRYPTO_DEV_FSL_CAAM
+ default n
+ help
+ Selecting this will enable the CAAM red blob generator.
+ This module will take a chunk of data via sysfs and returns
+ an encrypted red blob. The inverse is also possible.
+
config CRYPTO_DEV_FSL_CAAM_RNG_API
tristate "Register caam device for hwrng API"
depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 550758a333e7..359ef3b97fdf 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
+obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN) += blob_gen.o
caam-objs := ctrl.o
caam_jr-objs := jr.o key_gen.o error.o
diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c
new file mode 100644
index ..9c2a02c2882a
--- /dev/null
+++ b/drivers/crypto/caam/blob_gen.c
@@ -0,0 +1,528 @@
+/*
+ * Copyright (C) 2015 Pengutronix, Steffen Trumtrar
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include "compat.h"
+#include "intern.h"
+#include "desc.h"
+#include "desc_constr.h"
+#include "error.h"
+#include "jr.h"
+
+enum access_rights {
+ KERNEL,
+ KERNEL_EVM,
+ USERSPACE,
+};
+
+struct blob_priv {
+ struct device *jrdev;
+ struct device dev;
+ u32 *desc;
+ u8 __iomem *red_blob;
+ u8 __iomem *modifier;
+ u8 __iomem *output;
+ bool busy;
+ enum access_rights access;
+ unsigned int payload_size;
+ struct bin_attribute *blob;
+ struct bin_attribute *payload;
+ struct caam_drv_private *ctrlpriv;
+};
+
+struct blob_job_result {
+ int err;
+ struct completion completion;
+};
+
+static struct platform_device *pdev;
+
+static void blob_job_done(struct device *dev, u32 *desc, u32 err, void
*context)
+{
+ struct blob_job_result *res = context;
+
+#ifdef DEBUG
+ dev_err(dev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
+#endif
+
+ if (err)
+ caam_jr_strstatus(dev, err);
+
+ res->err = err;
+
+ complete(&res->completion);
+}
+
+/*
+ * Upon completion, desc points to a buffer containing a CAAM job
+ * descriptor which encapsulates data into an externally-storable
+ * blob.
+ */
+#define INITIAL_DESCSZ 16
+#define BLOB_OVERHEAD (32 + 16)
+#define KEYMOD_LENGTH 16
+#define RED_BLOB_LENGTH64
+#define MAX_BLOB_LEN 4096
+
+/*
+ * Generate a blob with the following format:
+ * Format: Normal format (Test format only for testing)
+ * Contents: General data (aka red blob)
+ * Security State: Secure State (Non-Secure for testing)
+ * Memory Types: General memory
+ */
+static int blob_encap_blob(struct blob_priv *priv, u8 *keymod, u8 *input,
+ u8 *output, u16 length)
+{
+ u32 *desc;
+ struct device *jrdev = priv->jrdev;
+ dma_addr_t dma_keymod;
+ dma_addr_t dma_in;
+ dma_addr_t dma_out;
+ struct blob_job_result testres;
+ int ret;
+
+ desc = kmalloc(CAAM_CMD_SZ * 5 + CAAM_PTR_SZ * 5, GFP_KERNEL | GFP_DMA);
+ if (!desc) {
+ dev_err(jrdev, "unable to allocate desc\n");
+ return -ENOMEM;
+ }
+
+ dma_keymod = dma_map_single(jrdev, keymod, KEYMOD_LENGTH,
DMA_TO_DEVICE);
+ if (dma_mapping_error(jrdev, dma_keymod)) {
+ dev_err(jrdev, "unable to map keymod buffer\n");
+ ret = -ENOMEM;
+ goto out_free;
+ }
+
+ dma_in = dma_map_single(jrdev, input, length - BLOB_OVERHEAD,
+ DMA_TO_DEVICE);
+ if (dma_mapping_error(jrdev, dma_in)) {
[RFC] i.MX6 CAAM blob generator for IMA/EVM initialization
Hi! The RFC Patch attached after this cover letter is mostly for illustration purposes, so please don't waste too much time reviewing the code ;-) For context I'll try to describe the problem that this patch tries to solve. I need to be able to boot an EVM signed (and dongled) rootfs. The CAAM on the i.MX6 has support for an OTP key and can en/decrypt data. It also has a feature for generating red blobs: basically a chunk of data, that is encrypted with the OTP key, which can be saved on some medium as a secret to decrypt the EVM HMAC secret for one specific device. To open the rootfs, the secret is handed from the bootloader to the kernel as a base64 encoded string via the cmdline to an initramfs. In the initramfs the sysfs file "modifier" is set to something starting with "kernel:evm" and the base64 string is written to the sysfs file "blob". The CAAM than decodes the red blob and, in case of "kernel:evm", initializes the EVM or otherwise writes the result to "payload" if the modifier starts with "user:". Therefore a blob that was generated for EVM never leaves the kernel on decryption. Generation of blobs goes like: echoing "modifier" to something and echoing the payload to "payload". The red blob can than be read from "blob". So, the sysfs interface is not the best option, I guess. The question is: What is the right approach for a setup like this? I need to: - be able to encrypt the secret and store it somewhere - to load the stored secret and decrypt it later - initialize IMA/EVM with the secret Would something like - security/keys/encrypted-keys/encrypted.c be the correct approach? Thanks, Steffen Steffen Trumtrar (1): crypto: caam - add red blobifier drivers/crypto/caam/Kconfig| 9 + drivers/crypto/caam/Makefile | 1 + drivers/crypto/caam/blob_gen.c | 528 + 3 files changed, 538 insertions(+) create mode 100644 drivers/crypto/caam/blob_gen.c -- 2.6.1 -- 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: [Linux-ima-user] [RFC] i.MX6 CAAM blob generator for IMA/EVM initialization
Hi! Mimi Zohar writes: > On Mon, 2015-11-09 at 16:18 +0100, Steffen Trumtrar wrote: >> Hi! >> >> The RFC Patch attached after this cover letter is mostly for illustration >> purposes, so please don't waste too much time reviewing the code ;-) >> >> For context I'll try to describe the problem that this patch tries to solve. >> >> I need to be able to boot an EVM signed (and dongled) rootfs. The CAAM on >> the i.MX6 has support for an OTP key and can en/decrypt data. >> It also has a feature for generating red blobs: basically a chunk of data, >> that is encrypted with the OTP key, which can be saved on some medium as a >> secret to decrypt the EVM HMAC secret for one specific device. >> >> To open the rootfs, the secret is handed from the bootloader to the kernel >> as a base64 encoded string via the cmdline to an initramfs. >> In the initramfs the sysfs file "modifier" is set to something starting with >> "kernel:evm" and the base64 string is written to the sysfs file "blob". >> The CAAM than decodes the red blob and, in case of "kernel:evm", initializes >> the EVM or otherwise writes the result to "payload" if the modifier starts >> with "user:". Therefore a blob that was generated for EVM never leaves the >> kernel on decryption. >> Generation of blobs goes like: echoing "modifier" to something and echoing >> the payload to "payload". The red blob can than be read from "blob". >> >> >> So, the sysfs interface is not the best option, I guess. The question is: >> What is the right approach for a setup like this? >> I need to: >> - be able to encrypt the secret and store it somewhere >> - to load the stored secret and decrypt it later >> - initialize IMA/EVM with the secret >> >> Would something like >> - security/keys/encrypted-keys/encrypted.c >> be the correct approach? > > Instead of using the CAAM for OTP encrypting/decrypting, can it be used > to load the EVM key directly? Dmitry's patches, which will be > upstreamed in 4.5 > https://git.kernel.org/cgit/linux/kernel/git/zohar/linux-integrity.git/log/?h=for-next-4.5? >adds support for a crypto device to directly load the EVM key. > The patches look good and I use them for loading the EVM key from the CAAM driver. But I still need the OTP decryption functionality. The key data that I hand to evm_set_key must be device specific but I don't want to use the fused OTP in the CAAM directly. The OTP is used to protect multiple random keys. Therefore I need to generate encrypted blobs that I can store on some unsecure memory (EEPROM, NAND,...) and be able to hand that later back to the CAAM module, to then get back an IMA/EVM, ecryptfs, $something key. > FYI, the EVM key is an encrypted key, which encrypts/decrypts either a > trusted or user type key. > So the normal approach would be to have a key in the kernel keyring and decrypt it with the key loaded with evm_set_key? Can I somehow use the keyring framework as an abstraction around my blobbing/deblobbing functionality? So that the "keyring" calls into the crypto driver to decrypt the data and uses the crypto driver to encrypt the keys when I want to "dump" them? Thanks, Steffen -- Pengutronix e.K. | Steffen Trumtrar| Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 1/3] Documentation: devicetree: add Freescale SCC bindings
Add documentation for the Freescale Security Controller (SCC)
found on i.MX25 SoCs.
Signed-off-by: Steffen Trumtrar
---
.../devicetree/bindings/crypto/fsl-imx-scc.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
new file mode 100644
index ..9a15ab8da94f
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
@@ -0,0 +1,17 @@
+Freescale Security Controller (SCC)
+
+Required properties:
+- compatible : Should be "fsl,imx25-scc".
+- reg : Should contain register location and length.
+- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
+
+Example:
+
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
--
2.7.0.rc3
--
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 3/3] crypto: add basic driver for the MXC SCC
According to the Freescale GPL driver code, there are two different Security Controller (SCC) versions: SCC and SCC2. The SCC is found on older i.MX SoCs, e.g. the i.MX25. This is the version implemented and tested here. As there is no publicly available documentation for this IP core, all information about this unit is gathered from the GPL'ed driver from Freescale. Signed-off-by: Steffen Trumtrar --- drivers/crypto/Kconfig | 9 + drivers/crypto/Makefile | 1 + drivers/crypto/mxc-scc.c | 756 +++ 3 files changed, 766 insertions(+) create mode 100644 drivers/crypto/mxc-scc.c diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 07d494276aad..ece3e231ee4d 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -339,6 +339,15 @@ config CRYPTO_DEV_SAHARA This option enables support for the SAHARA HW crypto accelerator found in some Freescale i.MX chips. +config CRYPTO_DEV_MXC_SCC + tristate "Support for Freescale Security Controller (SCC)" + depends on ARCH_MXC && OF + select CRYPTO_BLKCIPHER + select CRYPTO_DES + help + This option enables support for the Security Controller (SCC) + found in Freescale i.MX25 chips. + config CRYPTO_DEV_S5P tristate "Support for Samsung S5PV210/Exynos crypto accelerator" depends on ARCH_S5PV210 || ARCH_EXYNOS diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 713de9d11148..3c6432dd09d9 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/ obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o +obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/ diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c new file mode 100644 index ..f8cc00d1d92e --- /dev/null +++ b/drivers/crypto/mxc-scc.c @@ -0,0 +1,756 @@ +/* + * Copyright (C) 2016 Pengutronix, Steffen Trumtrar + * + * The driver is based on information gathered from + * drivers/mxc/security/mxc_scc.c which can be found in + * the Freescale linux-2.6-imx.git in the imx_2.6.35_maintain branch. + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* Secure Memory (SCM) registers */ +#define SCC_SCM_RED_START 0x +#define SCC_SCM_BLACK_START0x0004 +#define SCC_SCM_LENGTH 0x0008 +#define SCC_SCM_CTRL 0x000C +#define SCC_SCM_STATUS 0x0010 +#define SCC_SCM_ERROR_STATUS 0x0014 +#define SCC_SCM_INTR_CTRL 0x0018 +#define SCC_SCM_CFG0x001C +#define SCC_SCM_INIT_VECTOR_0 0x0020 +#define SCC_SCM_INIT_VECTOR_1 0x0024 +#define SCC_SCM_RED_MEMORY 0x0400 +#define SCC_SCM_BLACK_MEMORY 0x0800 + +/* Security Monitor (SMN) Registers */ +#define SCC_SMN_STATUS 0x1000 +#define SCC_SMN_COMMAND0x1004 +#define SCC_SMN_SEQ_START 0x1008 +#define SCC_SMN_SEQ_END0x100C +#define SCC_SMN_SEQ_CHECK 0x1010 +#define SCC_SMN_BIT_COUNT 0x1014 +#define SCC_SMN_BITBANK_INC_SIZE 0x1018 +#define SCC_SMN_BITBANK_DECREMENT 0x101C +#define SCC_SMN_COMPARE_SIZE 0x1020 +#define SCC_SMN_PLAINTEXT_CHECK0x1024 +#define SCC_SMN_CIPHERTEXT_CHECK 0x1028 +#define SCC_SMN_TIMER_IV 0x102C +#define SCC_SMN_TIMER_CONTROL 0x1030 +#define SCC_SMN_DEBUG_DETECT_STAT 0x1034 +#define SCC_SMN_TIMER 0x1038 + +#define SCC_SCM_CTRL_START_CIPHER BIT(2) +#define SCC_SCM_CTRL_CBC_MODE BIT(1) +#define SCC_SCM_CTRL_DECRYPT_MODE BIT(0) + +#define SCC_SCM_STATUS_LEN_ERR BIT(12) +#define SCC_SCM_STATUS_SMN_UNBLOCKED BIT(11) +#define SCC_SCM_STATUS_CIPHERING_DONE BIT(10) +#define SCC_SCM_STATUS_ZEROIZING_DONE BIT(9) +#define SCC_SCM_STATUS_INTR_STATUS BIT(8) +#define SCC_SCM_STATUS_SEC_KEY BIT(7) +#define SCC_SCM_STATUS_INTERNAL_ERRBIT(6) +#define SCC_SCM_STATUS_BAD_SEC_KEY BIT(5) +#define SCC_SCM_STATUS_ZEROIZE_FAILBIT(4) +#define SCC_SCM_STATUS_SMN_BLOCKED BIT(3)
[PATCH 2/3] ARM: i.MX25: add scc module to dtsi
Add the Security Controller (SCC) module to the dtsi.
Signed-off-by: Steffen Trumtrar
---
arch/arm/boot/dts/imx25.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cde329e9b9e3..73118aba4cc4 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -397,6 +397,15 @@
interrupts = <41>;
};
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
+
esdhc1: esdhc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
--
2.7.0.rc3
--
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 1/3] Documentation: devicetree: add Freescale SCC bindings
Hi!
Shawn Guo writes:
> On Thu, Feb 11, 2016 at 03:04:43PM +0100, Steffen Trumtrar wrote:
>> Add documentation for the Freescale Security Controller (SCC)
>> found on i.MX25 SoCs.
>>
>> Signed-off-by: Steffen Trumtrar
>> ---
>> .../devicetree/bindings/crypto/fsl-imx-scc.txt | 17
>> +
>> 1 file changed, 17 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
>> b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
>> new file mode 100644
>> index ..9a15ab8da94f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
>> @@ -0,0 +1,17 @@
>> +Freescale Security Controller (SCC)
>> +
>> +Required properties:
>> +- compatible : Should be "fsl,imx25-scc".
>> +- reg : Should contain register location and length.
>> +- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
>> +
>> +Example:
>> +
>> +scc: crypto@53fac000 {
>> +compatible = "fsl,imx25-scc";
>> +reg = <0x53fac000 0x4000>;
>> +clocks = <&clks 111>;
>> +clock-names = "ipg";
>
> Shouldn't these two be mentioned in properties list above too?
>
What is the current policy on clocks in bindings? There are some with
and some without.
Of course I can add them to the required properties if necessary.
Thanks,
Steffen
--
Pengutronix e.K. | Steffen Trumtrar|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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/3] Documentation: devicetree: add Freescale SCC bindings
Add documentation for the Freescale Security Controller (SCC)
found on i.MX25 SoCs.
Signed-off-by: Steffen Trumtrar
Acked-by: Rob Herring
---
Changes since v1:
- add clocks to required properties
- add Acked-by
.../devicetree/bindings/crypto/fsl-imx-scc.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
new file mode 100644
index ..7aad448e8a36
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
@@ -0,0 +1,21 @@
+Freescale Security Controller (SCC)
+
+Required properties:
+- compatible : Should be "fsl,imx25-scc".
+- reg : Should contain register location and length.
+- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
+- interrupt-names : Should specify the names "scm" and "smn" for the
+ SCM IRQ and SMN IRQ.
+- clocks: Should contain the clock driving the SCC core.
+- clock-names: Should be set to "ipg".
+
+Example:
+
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
--
2.7.0
--
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 2/3] ARM: i.MX25: add scc module to dtsi
Add the Security Controller (SCC) module to the dtsi.
Signed-off-by: Steffen Trumtrar
---
arch/arm/boot/dts/imx25.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cde329e9b9e3..73118aba4cc4 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -397,6 +397,15 @@
interrupts = <41>;
};
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
+
esdhc1: esdhc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
--
2.7.0
--
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 3/3] crypto: add basic driver for the MXC SCC
According to the Freescale GPL driver code, there are two different Security Controller (SCC) versions: SCC and SCC2. The SCC is found on older i.MX SoCs, e.g. the i.MX25. This is the version implemented and tested here. As there is no publicly available documentation for this IP core, all information about this unit is gathered from the GPL'ed driver from Freescale. Signed-off-by: Steffen Trumtrar --- Changes since v1: - minor code cleanups (double newlines, unnecessary parentesis, ...) - mxc_scc_ablkcipher_next: complete request with error before mutex_unlock drivers/crypto/Kconfig | 9 + drivers/crypto/Makefile | 1 + drivers/crypto/mxc-scc.c | 746 +++ 3 files changed, 756 insertions(+) create mode 100644 drivers/crypto/mxc-scc.c diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 07d494276aad..ece3e231ee4d 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -339,6 +339,15 @@ config CRYPTO_DEV_SAHARA This option enables support for the SAHARA HW crypto accelerator found in some Freescale i.MX chips. +config CRYPTO_DEV_MXC_SCC + tristate "Support for Freescale Security Controller (SCC)" + depends on ARCH_MXC && OF + select CRYPTO_BLKCIPHER + select CRYPTO_DES + help + This option enables support for the Security Controller (SCC) + found in Freescale i.MX25 chips. + config CRYPTO_DEV_S5P tristate "Support for Samsung S5PV210/Exynos crypto accelerator" depends on ARCH_S5PV210 || ARCH_EXYNOS diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 713de9d11148..3c6432dd09d9 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/ obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o +obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/ diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c new file mode 100644 index ..8f27f8720413 --- /dev/null +++ b/drivers/crypto/mxc-scc.c @@ -0,0 +1,746 @@ +/* + * Copyright (C) 2016 Pengutronix, Steffen Trumtrar + * + * The driver is based on information gathered from + * drivers/mxc/security/mxc_scc.c which can be found in + * the Freescale linux-2.6-imx.git in the imx_2.6.35_maintain branch. + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* Secure Memory (SCM) registers */ +#define SCC_SCM_RED_START 0x +#define SCC_SCM_BLACK_START0x0004 +#define SCC_SCM_LENGTH 0x0008 +#define SCC_SCM_CTRL 0x000C +#define SCC_SCM_STATUS 0x0010 +#define SCC_SCM_ERROR_STATUS 0x0014 +#define SCC_SCM_INTR_CTRL 0x0018 +#define SCC_SCM_CFG0x001C +#define SCC_SCM_INIT_VECTOR_0 0x0020 +#define SCC_SCM_INIT_VECTOR_1 0x0024 +#define SCC_SCM_RED_MEMORY 0x0400 +#define SCC_SCM_BLACK_MEMORY 0x0800 + +/* Security Monitor (SMN) Registers */ +#define SCC_SMN_STATUS 0x1000 +#define SCC_SMN_COMMAND0x1004 +#define SCC_SMN_SEQ_START 0x1008 +#define SCC_SMN_SEQ_END0x100C +#define SCC_SMN_SEQ_CHECK 0x1010 +#define SCC_SMN_BIT_COUNT 0x1014 +#define SCC_SMN_BITBANK_INC_SIZE 0x1018 +#define SCC_SMN_BITBANK_DECREMENT 0x101C +#define SCC_SMN_COMPARE_SIZE 0x1020 +#define SCC_SMN_PLAINTEXT_CHECK0x1024 +#define SCC_SMN_CIPHERTEXT_CHECK 0x1028 +#define SCC_SMN_TIMER_IV 0x102C +#define SCC_SMN_TIMER_CONTROL 0x1030 +#define SCC_SMN_DEBUG_DETECT_STAT 0x1034 +#define SCC_SMN_TIMER 0x1038 + +#define SCC_SCM_CTRL_START_CIPHER BIT(2) +#define SCC_SCM_CTRL_CBC_MODE BIT(1) +#define SCC_SCM_CTRL_DECRYPT_MODE BIT(0) + +#define SCC_SCM_STATUS_LEN_ERR BIT(12) +#define SCC_SCM_STATUS_SMN_UNBLOCKED BIT(11) +#define SCC_SCM_STATUS_CIPHERING_DONE BIT(10) +#define SCC_SCM_STATUS_ZEROIZING_DONE BIT(9) +#define SCC_SCM_STATUS_INTR_STATUS BIT(8) +#define SCC_SCM_STATUS_SEC_KEY BIT(7) +#define SCC
[PATCH 2/3] ARM: i.MX25: add RNGC node to dtsi
Add a devicetree entry for the Random Number Generator Version C (RNGC).
Signed-off-by: Steffen Trumtrar
---
arch/arm/boot/dts/imx25.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cde329e9b9e3..ec44ed125057 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -397,6 +397,15 @@
interrupts = <41>;
};
+ rng: rng@53fb {
+ compatible = "fsl,imx25-rng";
+ reg = <0x53fb 0x4000>;
+ clocks = <&clks 109>;
+ clock-names = "ipg";
+ interrupts = <22>;
+ interrupt-names = "rng";
+ };
+
esdhc1: esdhc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
--
2.7.0
--
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 1/3] Documentation: devicetree: add Freescale RNGC binding
Add binding documentation for the Freescale RNGC found on
some i.MX2/3/5 SoCs.
Signed-off-by: Steffen Trumtrar
---
Documentation/devicetree/bindings/rng/mxc_rngc.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/mxc_rngc.txt
diff --git a/Documentation/devicetree/bindings/rng/mxc_rngc.txt
b/Documentation/devicetree/bindings/rng/mxc_rngc.txt
new file mode 100644
index ..e147a6dde40a
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mxc_rngc.txt
@@ -0,0 +1,16 @@
+Freescale RNGC (Random Number Generator Version C)
+
+Required properties:
+- compatible : Should be "fsl,imx25-rng"
+- reg : Offset and length of the register set of this block
+- interrupts : the interrupt number for the RNG block
+- clocks: should contain the RNG clk source
+
+Example:
+
+rng@53fb {
+ compatible = "fsl,imx25-rng";
+ reg = <0x53fb 0x4000>;
+ interrupts = <22>;
+ clocks = <&clks 109>;
+};
--
2.7.0
--
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 3/3] hwrng: mxc-fsl - add support for Freescale RNGC
The driver is ported from Freescales Linux git and can be found in the vendor/freescale/imx_2.6.35_maintain branch. According to that code, the RNGC is found on Freescales i.MX3/5 SoCs. The i.MX2x actually has an RNGB, which has no driver implementation in Freescales kernel. However as it turns out, the driver for the RNGC works fine on the (at least) i.MX25. So, they seem to be somewhat compatible. Signed-off-by: Steffen Trumtrar --- drivers/char/hw_random/Kconfig| 13 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/mxc-rngc.c | 400 ++ 3 files changed, 414 insertions(+) create mode 100644 drivers/char/hw_random/mxc-rngc.c diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig index dbf22719462f..9d6b5c42255b 100644 --- a/drivers/char/hw_random/Kconfig +++ b/drivers/char/hw_random/Kconfig @@ -255,6 +255,19 @@ config HW_RANDOM_MXC_RNGA If unsure, say Y. +config HW_RANDOM_MXC_RNGC + tristate "Freescale i.MX RNGC Random Number Generator" + depends on ARCH_MXC + default HW_RANDOM + ---help--- + This driver provides kernel-side support for the Random Number + Generator hardware found on some Freescale i.MX processors. + + To compile this driver as a module, choose M here: the + module will be called mxc-rngc. + + If unsure, say Y. + config HW_RANDOM_NOMADIK tristate "ST-Ericsson Nomadik Random Number Generator support" depends on ARCH_NOMADIK diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile index 5ad397635128..008463bcf662 100644 --- a/drivers/char/hw_random/Makefile +++ b/drivers/char/hw_random/Makefile @@ -20,6 +20,7 @@ obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o +obj-$(CONFIG_HW_RANDOM_MXC_RNGC) += mxc-rngc.o obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o obj-$(CONFIG_HW_RANDOM_PPC4XX) += ppc4xx-rng.o diff --git a/drivers/char/hw_random/mxc-rngc.c b/drivers/char/hw_random/mxc-rngc.c new file mode 100644 index ..e31d306dcacd --- /dev/null +++ b/drivers/char/hw_random/mxc-rngc.c @@ -0,0 +1,400 @@ +/* + * RNG driver for Freescale RNGC + * + * Copyright (C) 2008-2012 Freescale Semiconductor, Inc. + */ + +/* + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +/* + * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG) + * (c) Copyright 2003 Red Hat Inc + * + * derived from + * + * Hardware driver for the AMD 768 Random Number Generator (RNG) + * (c) Copyright 2001 Red Hat Inc + * + * derived from + * + * Hardware driver for Intel i810 Random Number Generator (RNG) + * Copyright 2000,2001 Jeff Garzik + * Copyright 2000,2001 Philipp Rumpf + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RNGC_VERSION_MAJOR3 3 + +#define RNGC_VERSION_ID0x +#define RNGC_COMMAND 0x0004 +#define RNGC_CONTROL 0x0008 +#define RNGC_STATUS0x000C +#define RNGC_ERROR 0x0010 +#define RNGC_FIFO 0x0014 +#define RNGC_VERIF_CTRL0x0020 +#define RNGC_OSC_CTRL_COUNT0x0028 +#define RNGC_OSC_COUNT 0x002C +#define RNGC_OSC_COUNT_STATUS 0x0030 + +#define RNGC_VERID_ZEROS_MASK 0x0f00 +#define RNGC_VERID_RNG_TYPE_MASK 0xf000 +#define RNGC_VERID_RNG_TYPE_SHIFT 28 +#define RNGC_VERID_CHIP_VERSION_MASK 0x00ff +#define RNGC_VERID_CHIP_VERSION_SHIFT 16 +#define RNGC_VERID_VERSION_MAJOR_MASK 0xff00 +#define RNGC_VERID_VERSION_MAJOR_SHIFT 8 +#define RNGC_VERID_VERSION_MINOR_MASK 0x00ff +#define RNGC_VERID_VERSION_MINOR_SHIFT 0 + +#define RNGC_CMD_ZEROS_MASK0xff8c +#define RNGC_CMD_SW_RST0x0040 +#define RNGC_CMD_CLR_ERR 0x0020 +#define RNGC_CMD_CLR_INT 0x0010 +#define RNGC_CMD_SEED 0x0002 +#define RNGC_CMD_SELF_TEST 0x0001 +
[PATCH v3 1/3] Documentation: devicetree: add Freescale SCC bindings
Add documentation for the Freescale Security Controller (SCC)
found on i.MX25 SoCs.
Signed-off-by: Steffen Trumtrar
Acked-by: Rob Herring
---
Changes in v2:
- add clocks to required properties
- add Acked-by
.../devicetree/bindings/crypto/fsl-imx-scc.txt | 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
diff --git a/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
new file mode 100644
index ..7aad448e8a36
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-imx-scc.txt
@@ -0,0 +1,21 @@
+Freescale Security Controller (SCC)
+
+Required properties:
+- compatible : Should be "fsl,imx25-scc".
+- reg : Should contain register location and length.
+- interrupts : Should contain interrupt numbers for SCM IRQ and SMN IRQ.
+- interrupt-names : Should specify the names "scm" and "smn" for the
+ SCM IRQ and SMN IRQ.
+- clocks: Should contain the clock driving the SCC core.
+- clock-names: Should be set to "ipg".
+
+Example:
+
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
--
2.7.0
--
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 v3 2/3] ARM: i.MX25: add scc module to dtsi
Add the Security Controller (SCC) module to the dtsi.
Signed-off-by: Steffen Trumtrar
---
arch/arm/boot/dts/imx25.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cde329e9b9e3..73118aba4cc4 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -397,6 +397,15 @@
interrupts = <41>;
};
+ scc: crypto@53fac000 {
+ compatible = "fsl,imx25-scc";
+ reg = <0x53fac000 0x4000>;
+ clocks = <&clks 111>;
+ clock-names = "ipg";
+ interrupts = <49>, <50>;
+ interrupt-names = "scm", "smn";
+ };
+
esdhc1: esdhc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
--
2.7.0
--
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 v3 3/3] crypto: add basic driver for the MXC SCC
According to the Freescale GPL driver code, there are two different Security Controller (SCC) versions: SCC and SCC2. The SCC is found on older i.MX SoCs, e.g. the i.MX25. This is the version implemented and tested here. As there is no publicly available documentation for this IP core, all information about this unit is gathered from the GPL'ed driver from Freescale. Signed-off-by: Steffen Trumtrar --- Changes in v3: - don't just unlock mutex in mxc_scc_ablkcipher_next, but also return, too - replace mutex with bool to make lockdep happy Changes in v2: - minor code cleanups - mxc_scc_ablkcipher_next: complete request with error before mutex_unlock drivers/crypto/Kconfig | 9 + drivers/crypto/Makefile | 1 + drivers/crypto/mxc-scc.c | 748 +++ 3 files changed, 758 insertions(+) create mode 100644 drivers/crypto/mxc-scc.c diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index 07d494276aad..ece3e231ee4d 100644 --- a/drivers/crypto/Kconfig +++ b/drivers/crypto/Kconfig @@ -339,6 +339,15 @@ config CRYPTO_DEV_SAHARA This option enables support for the SAHARA HW crypto accelerator found in some Freescale i.MX chips. +config CRYPTO_DEV_MXC_SCC + tristate "Support for Freescale Security Controller (SCC)" + depends on ARCH_MXC && OF + select CRYPTO_BLKCIPHER + select CRYPTO_DES + help + This option enables support for the Security Controller (SCC) + found in Freescale i.MX25 chips. + config CRYPTO_DEV_S5P tristate "Support for Samsung S5PV210/Exynos crypto accelerator" depends on ARCH_S5PV210 || ARCH_EXYNOS diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index 713de9d11148..3c6432dd09d9 100644 --- a/drivers/crypto/Makefile +++ b/drivers/crypto/Makefile @@ -23,6 +23,7 @@ obj-$(CONFIG_CRYPTO_DEV_PICOXCELL) += picoxcell_crypto.o obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/ obj-$(CONFIG_CRYPTO_DEV_S5P) += s5p-sss.o obj-$(CONFIG_CRYPTO_DEV_SAHARA) += sahara.o +obj-$(CONFIG_CRYPTO_DEV_MXC_SCC) += mxc-scc.o obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/ diff --git a/drivers/crypto/mxc-scc.c b/drivers/crypto/mxc-scc.c new file mode 100644 index ..d37c3a820063 --- /dev/null +++ b/drivers/crypto/mxc-scc.c @@ -0,0 +1,748 @@ +/* + * Copyright (C) 2016 Pengutronix, Steffen Trumtrar + * + * The driver is based on information gathered from + * drivers/mxc/security/mxc_scc.c which can be found in + * the Freescale linux-2.6-imx.git in the imx_2.6.35_maintain branch. + * + * 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. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +/* Secure Memory (SCM) registers */ +#define SCC_SCM_RED_START 0x +#define SCC_SCM_BLACK_START0x0004 +#define SCC_SCM_LENGTH 0x0008 +#define SCC_SCM_CTRL 0x000C +#define SCC_SCM_STATUS 0x0010 +#define SCC_SCM_ERROR_STATUS 0x0014 +#define SCC_SCM_INTR_CTRL 0x0018 +#define SCC_SCM_CFG0x001C +#define SCC_SCM_INIT_VECTOR_0 0x0020 +#define SCC_SCM_INIT_VECTOR_1 0x0024 +#define SCC_SCM_RED_MEMORY 0x0400 +#define SCC_SCM_BLACK_MEMORY 0x0800 + +/* Security Monitor (SMN) Registers */ +#define SCC_SMN_STATUS 0x1000 +#define SCC_SMN_COMMAND0x1004 +#define SCC_SMN_SEQ_START 0x1008 +#define SCC_SMN_SEQ_END0x100C +#define SCC_SMN_SEQ_CHECK 0x1010 +#define SCC_SMN_BIT_COUNT 0x1014 +#define SCC_SMN_BITBANK_INC_SIZE 0x1018 +#define SCC_SMN_BITBANK_DECREMENT 0x101C +#define SCC_SMN_COMPARE_SIZE 0x1020 +#define SCC_SMN_PLAINTEXT_CHECK0x1024 +#define SCC_SMN_CIPHERTEXT_CHECK 0x1028 +#define SCC_SMN_TIMER_IV 0x102C +#define SCC_SMN_TIMER_CONTROL 0x1030 +#define SCC_SMN_DEBUG_DETECT_STAT 0x1034 +#define SCC_SMN_TIMER 0x1038 + +#define SCC_SCM_CTRL_START_CIPHER BIT(2) +#define SCC_SCM_CTRL_CBC_MODE BIT(1) +#define SCC_SCM_CTRL_DECRYPT_MODE BIT(0) + +#define SCC_SCM_STATUS_LEN_ERR BIT(12) +#define SCC_SCM_STATUS_SMN_UNBLOCKED BIT(11) +#define SCC_SCM_STATUS_CIPHERING_DONE BIT(10) +#define SCC_SCM_STATUS_ZEROIZING_DONE BIT(9) +#defin
Re: [PATCH 3/3] hwrng: mxc-fsl - add support for Freescale RNGC
Hi!
On Tue, Mar 01, 2016 at 08:49:37AM +0100, Uwe Kleine-König wrote:
> Hello Fabio,
>
> On Mon, Feb 29, 2016 at 08:54:19PM -0300, Fabio Estevam wrote:
> > On Mon, Feb 29, 2016 at 6:38 PM, Uwe Kleine-König
> > wrote:
> > > On Mon, Feb 29, 2016 at 06:16:50PM -0300, Fabio Estevam wrote:
> > >> On Mon, Feb 29, 2016 at 12:52 PM, Steffen Trumtrar
> > >> wrote:
> > >>
> > >> > + ret = clk_prepare_enable(rngc->clk);
> > >> > + if (ret)
> > >> > + return ret;
> > >> > +
> > >> > + rngc->irq = platform_get_irq(pdev, 0);
> > >> > + if (!rngc->irq) {
> > >> > + dev_err(&pdev->dev, "FSL RNGC couldn't get irq\n");
> > >> > + clk_disable_unprepare(rngc->clk);
> > >> > +
> > >> > + return ret;
> > >>
> > >> You are returning the wrong error code here:
> > >>
> > >> Better do like this:
> > >>
> > >>rngc->irq = platform_get_irq(pdev, 0);
> > >>if (rngc->irq < 0) {
> > >
> > > rngc->irq is unsigned, so this is never true.
> > >
> > >>dev_err(&pdev->dev, "FSL RNGC couldn't get irq\n");
> > >>clk_disable_unprepare(rngc->clk);
> > >>return rngc->irq;
> > >>}
> > >
> > > So here comes my better approach:
> >
> > As irq is only used inside probe it can be removed from struct mxc_rngc.
>
> Good idea.
>
Actually it is currently used in the mxc_rngc_init function, but I think I can
just move the call there into the probe function and get rid of the irq in the
struct.
> > Or maybe like this:
> >
> > ret = platform_get_irq(pdev, 0);
> > if (ret < 0) {
> > dev_err(&pdev->dev, "FSL RNGC couldn't get irq\n");
> > clk_disable_unprepare(rngc->clk);
> > return ret;
> > }
>
This looks better, yes. I will change that, of course.
> Some people think platform_get_irq returning 0 should be handled as
> error.
And who is right? drivers/of/unittest.c checks for irq < 0 for example.
Thanks,
Steffen
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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/3] Documentation: devicetree: add Freescale RNGC binding
Add binding documentation for the Freescale RNGC found on
some i.MX2/3/5 SoCs.
Signed-off-by: Steffen Trumtrar
---
Documentation/devicetree/bindings/rng/mxc_rngc.txt | 16
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/mxc_rngc.txt
diff --git a/Documentation/devicetree/bindings/rng/mxc_rngc.txt
b/Documentation/devicetree/bindings/rng/mxc_rngc.txt
new file mode 100644
index ..e147a6dde40a
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/mxc_rngc.txt
@@ -0,0 +1,16 @@
+Freescale RNGC (Random Number Generator Version C)
+
+Required properties:
+- compatible : Should be "fsl,imx25-rng"
+- reg : Offset and length of the register set of this block
+- interrupts : the interrupt number for the RNG block
+- clocks: should contain the RNG clk source
+
+Example:
+
+rng@53fb {
+ compatible = "fsl,imx25-rng";
+ reg = <0x53fb 0x4000>;
+ interrupts = <22>;
+ clocks = <&trng_clk>;
+};
--
2.7.0
--
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 3/3] hwrng: mxc-fsl - add support for Freescale RNGC
The driver is ported from Freescales Linux git and can be found in the vendor/freescale/imx_2.6.35_maintain branch. According to that code, the RNGC is found on Freescales i.MX3/5 SoCs. The i.MX2x actually has an RNGB, which has no driver implementation in Freescales kernel. However as it turns out, the driver for the RNGC works fine on the (at least) i.MX25. So, they seem to be somewhat compatible. Signed-off-by: Steffen Trumtrar --- Changes in v2: - remove irq variable from private struct - move devm_request_irq from mxc_rngc_init to probe - return irq in case of error - handle irq 0 as error drivers/char/hw_random/Kconfig| 13 ++ drivers/char/hw_random/Makefile | 1 + drivers/char/hw_random/mxc-rngc.c | 398 ++ 3 files changed, 412 insertions(+) create mode 100644 drivers/char/hw_random/mxc-rngc.c diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig index dbf22719462f..9d6b5c42255b 100644 --- a/drivers/char/hw_random/Kconfig +++ b/drivers/char/hw_random/Kconfig @@ -255,6 +255,19 @@ config HW_RANDOM_MXC_RNGA If unsure, say Y. +config HW_RANDOM_MXC_RNGC + tristate "Freescale i.MX RNGC Random Number Generator" + depends on ARCH_MXC + default HW_RANDOM + ---help--- + This driver provides kernel-side support for the Random Number + Generator hardware found on some Freescale i.MX processors. + + To compile this driver as a module, choose M here: the + module will be called mxc-rngc. + + If unsure, say Y. + config HW_RANDOM_NOMADIK tristate "ST-Ericsson Nomadik Random Number Generator support" depends on ARCH_NOMADIK diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile index 5ad397635128..008463bcf662 100644 --- a/drivers/char/hw_random/Makefile +++ b/drivers/char/hw_random/Makefile @@ -20,6 +20,7 @@ obj-$(CONFIG_HW_RANDOM_PASEMI) += pasemi-rng.o obj-$(CONFIG_HW_RANDOM_VIRTIO) += virtio-rng.o obj-$(CONFIG_HW_RANDOM_TX4939) += tx4939-rng.o obj-$(CONFIG_HW_RANDOM_MXC_RNGA) += mxc-rnga.o +obj-$(CONFIG_HW_RANDOM_MXC_RNGC) += mxc-rngc.o obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o obj-$(CONFIG_HW_RANDOM_PPC4XX) += ppc4xx-rng.o diff --git a/drivers/char/hw_random/mxc-rngc.c b/drivers/char/hw_random/mxc-rngc.c new file mode 100644 index ..3a2a9b2ad7db --- /dev/null +++ b/drivers/char/hw_random/mxc-rngc.c @@ -0,0 +1,398 @@ +/* + * RNG driver for Freescale RNGC + * + * Copyright (C) 2008-2012 Freescale Semiconductor, Inc. + */ + +/* + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 or later at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +/* + * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG) + * (c) Copyright 2003 Red Hat Inc + * + * derived from + * + * Hardware driver for the AMD 768 Random Number Generator (RNG) + * (c) Copyright 2001 Red Hat Inc + * + * derived from + * + * Hardware driver for Intel i810 Random Number Generator (RNG) + * Copyright 2000,2001 Jeff Garzik + * Copyright 2000,2001 Philipp Rumpf + * + * This file is licensed under the terms of the GNU General Public + * License version 2. This program is licensed "as is" without any + * warranty of any kind, whether express or implied. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define RNGC_VERSION_MAJOR3 3 + +#define RNGC_VERSION_ID0x +#define RNGC_COMMAND 0x0004 +#define RNGC_CONTROL 0x0008 +#define RNGC_STATUS0x000C +#define RNGC_ERROR 0x0010 +#define RNGC_FIFO 0x0014 +#define RNGC_VERIF_CTRL0x0020 +#define RNGC_OSC_CTRL_COUNT0x0028 +#define RNGC_OSC_COUNT 0x002C +#define RNGC_OSC_COUNT_STATUS 0x0030 + +#define RNGC_VERID_ZEROS_MASK 0x0f00 +#define RNGC_VERID_RNG_TYPE_MASK 0xf000 +#define RNGC_VERID_RNG_TYPE_SHIFT 28 +#define RNGC_VERID_CHIP_VERSION_MASK 0x00ff +#define RNGC_VERID_CHIP_VERSION_SHIFT 16 +#define RNGC_VERID_VERSION_MAJOR_MASK 0xff00 +#define RNGC_VERID_VERSION_MAJOR_SHIFT 8 +#define RNGC_VERID_VERSION_MINOR_MASK 0x00ff +#define RNGC_VERID_VERSION_MINOR_SHIFT 0 + +#define RNGC_CMD_ZEROS_MASK0xff8c +#define RNGC_CMD_SW_RST0x0040 +#define RNGC_CMD_CLR_ERR 0x
[PATCH v2 2/3] ARM: i.MX25: add RNGC node to dtsi
Add a devicetree entry for the Random Number Generator Version C (RNGC).
Signed-off-by: Steffen Trumtrar
---
Changes in v2:
- remove interrupt-names from dtsi
arch/arm/boot/dts/imx25.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index cde329e9b9e3..ebf11d9f123e 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -397,6 +397,14 @@
interrupts = <41>;
};
+ rng: rng@53fb {
+ compatible = "fsl,imx25-rng";
+ reg = <0x53fb 0x4000>;
+ clocks = <&clks 109>;
+ clock-names = "ipg";
+ interrupts = <22>;
+ };
+
esdhc1: esdhc@53fb4000 {
compatible = "fsl,imx25-esdhc";
reg = <0x53fb4000 0x4000>;
--
2.7.0
--
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
