Linux cryptographic layer development
 help / color / mirror / Atom feed
* caam - IV source for IPsec decryption
From: Horia Ioan Geanta Neag @ 2016-08-26  7:40 UTC (permalink / raw)
  To: Herbert Xu; +Cc: linux-crypto@vger.kernel.org

Herbert,

Commits
7021b2e1cddd "esp4: Switch to new AEAD interface"
000ae7b2690e "esp6: Switch to new AEAD interface"
removed the following:
	/* Get ivec. This can be wrong, check against another impls. */
	iv = esph->enc_data;
from IPsec decryption - esp{4,6}_input(),
so the IV in req->iv received by the implementer is no longer valid.

Thus, the load of IV in caam driver - caamalg.c, init_authenc_job():
        if (ivsize && (is_rfc3686 || !(alg->caam.geniv && encrypt)))
                append_load_as_imm(desc, req->iv, ivsize,
                                   LDST_CLASS_1_CCB |
                                   LDST_SRCDST_BYTE_CONTEXT |
                                   (ivoffset << LDST_OFFSET_SHIFT));
is not suited for case mentioned above.

Instead, the IV should be read from the req->src scatterlist
(which consists of assoc data, iv, ciphertext).
Please let me know if this is accurate, so I could prepare a fix.

Thanks,
Horia

^ permalink raw reply

* [PATCH v3 0/8] hwrng: amd: rework of the amd hwrng driver
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin

Changes since v2:
 - split the latest patch in 4
Changes since v1:
 - Keep the hwrng name as "amd"

LABBE Corentin (8):
  hwrng: amd: Fix style problem with blank line
  hwrng: amd: use the BIT macro
  hwrng: amd: Be consitent with the driver name
  hwrng: amd: Remove asm/io.h
  hwrng: amd: release_region must be called after hwrng_unregister
  hwrng: amd: Replace global variable with private struct
  hwrng: amd: Access hardware via ioread32/iowrite32
  hwrng: amd: Convert to new hwrng read() API

 drivers/char/hw_random/amd-rng.c | 150 +++++++++++++++++++++++++--------------
 1 file changed, 96 insertions(+), 54 deletions(-)

-- 
2.7.3

^ permalink raw reply

* [PATCH v3 8/8] hwrng: amd: Convert to new hwrng read() API
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>

This patch convert the hwrng interface used by amd768-rng to its new API
by replacing data_read()/data_present() by read().

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 47 ++++++++++++++++++++++++----------------
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index bfa14b9..9959c76 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -58,27 +58,37 @@ struct amd768_priv {
 	u32 pmbase;
 };
 
-static int amd_rng_data_present(struct hwrng *rng, int wait)
+static int amd_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
 {
+	u32 *data = buf;
 	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
-	int data, i;
-
-	for (i = 0; i < 20; i++) {
-		data = !!(ioread32(priv->iobase + RNGDONE) & 1);
-		if (data || !wait)
-			break;
-		udelay(10);
+	size_t read = 0;
+	/* We will wait at maximum one time per read */
+	int timeout = max / 4 + 1;
+
+	/*
+	 * RNG data is available when RNGDONE is set to 1
+	 * New random numbers are generated approximately 128 microseconds
+	 * after RNGDATA is read
+	 */
+	while (read < max) {
+		if (ioread32(priv->iobase + RNGDONE) == 0) {
+			if (wait) {
+				/* Delay given by datasheet */
+				usleep_range(128, 196);
+				if (timeout-- == 0)
+					return read;
+			} else {
+				return 0;
+			}
+		} else {
+			*data = ioread32(priv->iobase + RNGDATA);
+			data++;
+			read += 4;
+		}
 	}
-	return data;
-}
-
-static int amd_rng_data_read(struct hwrng *rng, u32 *data)
-{
-	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
-
-	*data = ioread32(priv->iobase + RNGDATA);
 
-	return 4;
+	return read;
 }
 
 static int amd_rng_init(struct hwrng *rng)
@@ -111,8 +121,7 @@ static struct hwrng amd_rng = {
 	.name		= "amd",
 	.init		= amd_rng_init,
 	.cleanup	= amd_rng_cleanup,
-	.data_present	= amd_rng_data_present,
-	.data_read	= amd_rng_data_read,
+	.read		= amd_rng_read,
 };
 
 static int __init mod_init(void)
-- 
2.7.3

^ permalink raw reply related

* [PATCH v3 7/8] hwrng: amd: Access hardware via ioread32/iowrite32
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>

Instead of accessing hw directly via pmbase, it's better to
access after ioport_map() via ioread32/iowrite32.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 31 +++++++++++++++++++++++++------
 1 file changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 4ef94e9..bfa14b9 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -32,6 +32,11 @@
 
 #define DRV_NAME "AMD768-HWRNG"
 
+#define RNGDATA		0x00
+#define RNGDONE		0x04
+#define PMBASE_OFFSET	0xF0
+#define PMBASE_SIZE	8
+
 /*
  * Data for PCI driver interface
  *
@@ -48,6 +53,7 @@ static const struct pci_device_id pci_tbl[] = {
 MODULE_DEVICE_TABLE(pci, pci_tbl);
 
 struct amd768_priv {
+	void __iomem *iobase;
 	struct pci_dev *pcidev;
 	u32 pmbase;
 };
@@ -58,7 +64,7 @@ static int amd_rng_data_present(struct hwrng *rng, int wait)
 	int data, i;
 
 	for (i = 0; i < 20; i++) {
-		data = !!(inl(priv->pmbase + 0xF4) & 1);
+		data = !!(ioread32(priv->iobase + RNGDONE) & 1);
 		if (data || !wait)
 			break;
 		udelay(10);
@@ -70,7 +76,7 @@ static int amd_rng_data_read(struct hwrng *rng, u32 *data)
 {
 	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
 
-	*data = inl(priv->pmbase + 0xF0);
+	*data = ioread32(priv->iobase + RNGDATA);
 
 	return 4;
 }
@@ -138,12 +144,20 @@ found:
 	if (!priv)
 		return -ENOMEM;
 
-	if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
+	if (!request_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE, DRV_NAME)) {
 		dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
 			pmbase + 0xF0);
 		err = -EBUSY;
 		goto out;
 	}
+
+	priv->iobase = ioport_map(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+	if (!priv->iobase) {
+		pr_err(DRV_NAME "Cannot map ioport\n");
+		err = -EINVAL;
+		goto err_iomap;
+	}
+
 	amd_rng.priv = (unsigned long)priv;
 	priv->pmbase = pmbase;
 	priv->pcidev = pdev;
@@ -152,11 +166,14 @@ found:
 	err = hwrng_register(&amd_rng);
 	if (err) {
 		pr_err(DRV_NAME " registering failed (%d)\n", err);
-		release_region(pmbase + 0xF0, 8);
-		goto out;
+		goto err_hwrng;
 	}
 	return 0;
 
+err_hwrng:
+	ioport_unmap(priv->iobase);
+err_iomap:
+	release_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
 out:
 	kfree(priv);
 	return err;
@@ -170,7 +187,9 @@ static void __exit mod_exit(void)
 
 	hwrng_unregister(&amd_rng);
 
-	release_region(priv->pmbase + 0xF0, 8);
+	ioport_unmap(priv->iobase);
+
+	release_region(priv->pmbase + PMBASE_OFFSET, PMBASE_SIZE);
 
 	kfree(priv);
 }
-- 
2.7.3

^ permalink raw reply related

* [PATCH v3 6/8] hwrng: amd: Replace global variable with private struct
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>

Instead of having two global variable, it's better to use a
private struct. This will permit to remove amd_pdev variable

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 57 ++++++++++++++++++++++++++--------------
 1 file changed, 38 insertions(+), 19 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 383e197..4ef94e9 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -47,15 +47,18 @@ static const struct pci_device_id pci_tbl[] = {
 };
 MODULE_DEVICE_TABLE(pci, pci_tbl);
 
-static struct pci_dev *amd_pdev;
+struct amd768_priv {
+	struct pci_dev *pcidev;
+	u32 pmbase;
+};
 
 static int amd_rng_data_present(struct hwrng *rng, int wait)
 {
-	u32 pmbase = (u32)rng->priv;
+	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
 	int data, i;
 
 	for (i = 0; i < 20; i++) {
-		data = !!(inl(pmbase + 0xF4) & 1);
+		data = !!(inl(priv->pmbase + 0xF4) & 1);
 		if (data || !wait)
 			break;
 		udelay(10);
@@ -65,35 +68,37 @@ static int amd_rng_data_present(struct hwrng *rng, int wait)
 
 static int amd_rng_data_read(struct hwrng *rng, u32 *data)
 {
-	u32 pmbase = (u32)rng->priv;
+	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
 
-	*data = inl(pmbase + 0xF0);
+	*data = inl(priv->pmbase + 0xF0);
 
 	return 4;
 }
 
 static int amd_rng_init(struct hwrng *rng)
 {
+	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
 	u8 rnen;
 
-	pci_read_config_byte(amd_pdev, 0x40, &rnen);
+	pci_read_config_byte(priv->pcidev, 0x40, &rnen);
 	rnen |= BIT(7);	/* RNG on */
-	pci_write_config_byte(amd_pdev, 0x40, rnen);
+	pci_write_config_byte(priv->pcidev, 0x40, rnen);
 
-	pci_read_config_byte(amd_pdev, 0x41, &rnen);
+	pci_read_config_byte(priv->pcidev, 0x41, &rnen);
 	rnen |= BIT(7);	/* PMIO enable */
-	pci_write_config_byte(amd_pdev, 0x41, rnen);
+	pci_write_config_byte(priv->pcidev, 0x41, rnen);
 
 	return 0;
 }
 
 static void amd_rng_cleanup(struct hwrng *rng)
 {
+	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
 	u8 rnen;
 
-	pci_read_config_byte(amd_pdev, 0x40, &rnen);
+	pci_read_config_byte(priv->pcidev, 0x40, &rnen);
 	rnen &= ~BIT(7);	/* RNG off */
-	pci_write_config_byte(amd_pdev, 0x40, rnen);
+	pci_write_config_byte(priv->pcidev, 0x40, rnen);
 }
 
 static struct hwrng amd_rng = {
@@ -110,6 +115,7 @@ static int __init mod_init(void)
 	struct pci_dev *pdev = NULL;
 	const struct pci_device_id *ent;
 	u32 pmbase;
+	struct amd768_priv *priv;
 
 	for_each_pci_dev(pdev) {
 		ent = pci_match_id(pci_tbl, pdev);
@@ -117,24 +123,30 @@ static int __init mod_init(void)
 			goto found;
 	}
 	/* Device not found. */
-	goto out;
+	return -ENODEV;
 
 found:
 	err = pci_read_config_dword(pdev, 0x58, &pmbase);
 	if (err)
-		goto out;
-	err = -EIO;
+		return err;
+
 	pmbase &= 0x0000FF00;
 	if (pmbase == 0)
-		goto out;
+		return -EIO;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
 	if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
 		dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
 			pmbase + 0xF0);
 		err = -EBUSY;
 		goto out;
 	}
-	amd_rng.priv = (unsigned long)pmbase;
-	amd_pdev = pdev;
+	amd_rng.priv = (unsigned long)priv;
+	priv->pmbase = pmbase;
+	priv->pcidev = pdev;
 
 	pr_info(DRV_NAME " detected\n");
 	err = hwrng_register(&amd_rng);
@@ -143,17 +155,24 @@ found:
 		release_region(pmbase + 0xF0, 8);
 		goto out;
 	}
+	return 0;
+
 out:
+	kfree(priv);
 	return err;
 }
 
 static void __exit mod_exit(void)
 {
-	u32 pmbase = (unsigned long)amd_rng.priv;
+	struct amd768_priv *priv;
+
+	priv = (struct amd768_priv *)amd_rng.priv;
 
 	hwrng_unregister(&amd_rng);
 
-	release_region(pmbase + 0xF0, 8);
+	release_region(priv->pmbase + 0xF0, 8);
+
+	kfree(priv);
 }
 
 module_init(mod_init);
-- 
2.7.3

^ permalink raw reply related

* [PATCH v3 5/8] hwrng: amd: release_region must be called after hwrng_unregister
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>

The driver release the memory region before being sure that nobody use
it.

This patch made hwrng_unregister ran before any release was done.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index de82fe3..383e197 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -151,8 +151,9 @@ static void __exit mod_exit(void)
 {
 	u32 pmbase = (unsigned long)amd_rng.priv;
 
-	release_region(pmbase + 0xF0, 8);
 	hwrng_unregister(&amd_rng);
+
+	release_region(pmbase + 0xF0, 8);
 }
 
 module_init(mod_init);
-- 
2.7.3

^ permalink raw reply related

* [PATCH v3 4/8] hwrng: amd: Remove asm/io.h
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>

checkpatch complains about <asm/io.h> used instead of linux/io.h.
In fact it is not needed.
This patch remove it, and in the process, alphabetize the other headers.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 93157af..de82fe3 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -24,12 +24,11 @@
  * warranty of any kind, whether express or implied.
  */
 
-#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/pci.h>
-#include <linux/hw_random.h>
-#include <linux/delay.h>
-#include <asm/io.h>
 
 #define DRV_NAME "AMD768-HWRNG"
 
-- 
2.7.3

^ permalink raw reply related

* [PATCH v3 3/8] hwrng: amd: Be consitent with the driver name
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>

The driver name is displayed each time differently.
This patch make use of the same name everywhere.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index d0042f5..93157af 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -31,7 +31,7 @@
 #include <linux/delay.h>
 #include <asm/io.h>
 
-#define PFX	KBUILD_MODNAME ": "
+#define DRV_NAME "AMD768-HWRNG"
 
 /*
  * Data for PCI driver interface
@@ -128,8 +128,8 @@ found:
 	pmbase &= 0x0000FF00;
 	if (pmbase == 0)
 		goto out;
-	if (!request_region(pmbase + 0xF0, 8, "AMD HWRNG")) {
-		dev_err(&pdev->dev, "AMD HWRNG region 0x%x already in use!\n",
+	if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
+		dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
 			pmbase + 0xF0);
 		err = -EBUSY;
 		goto out;
@@ -137,11 +137,10 @@ found:
 	amd_rng.priv = (unsigned long)pmbase;
 	amd_pdev = pdev;
 
-	pr_info("AMD768 RNG detected\n");
+	pr_info(DRV_NAME " detected\n");
 	err = hwrng_register(&amd_rng);
 	if (err) {
-		pr_err(PFX "RNG registering failed (%d)\n",
-		       err);
+		pr_err(DRV_NAME " registering failed (%d)\n", err);
 		release_region(pmbase + 0xF0, 8);
 		goto out;
 	}
-- 
2.7.3

^ permalink raw reply related

* [PATCH v3 2/8] hwrng: amd: use the BIT macro
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>

This patch add usage of the BIT() macro

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 45b7965..d0042f5 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -78,11 +78,11 @@ static int amd_rng_init(struct hwrng *rng)
 	u8 rnen;
 
 	pci_read_config_byte(amd_pdev, 0x40, &rnen);
-	rnen |= (1 << 7);	/* RNG on */
+	rnen |= BIT(7);	/* RNG on */
 	pci_write_config_byte(amd_pdev, 0x40, rnen);
 
 	pci_read_config_byte(amd_pdev, 0x41, &rnen);
-	rnen |= (1 << 7);	/* PMIO enable */
+	rnen |= BIT(7);	/* PMIO enable */
 	pci_write_config_byte(amd_pdev, 0x41, rnen);
 
 	return 0;
@@ -93,7 +93,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
 	u8 rnen;
 
 	pci_read_config_byte(amd_pdev, 0x40, &rnen);
-	rnen &= ~(1 << 7);	/* RNG off */
+	rnen &= ~BIT(7);	/* RNG off */
 	pci_write_config_byte(amd_pdev, 0x40, rnen);
 }
 
-- 
2.7.3

^ permalink raw reply related

* [PATCH v3 1/8] hwrng: amd: Fix style problem with blank line
From: LABBE Corentin @ 2016-08-26 11:11 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472209896-17197-1-git-send-email-clabbe.montjoie@gmail.com>

Some blank line are unncessary, and one is missing after declaration.
This patch fix thoses style problems.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 48f6a83..45b7965 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -31,10 +31,8 @@
 #include <linux/delay.h>
 #include <asm/io.h>
 
-
 #define PFX	KBUILD_MODNAME ": "
 
-
 /*
  * Data for PCI driver interface
  *
@@ -52,7 +50,6 @@ MODULE_DEVICE_TABLE(pci, pci_tbl);
 
 static struct pci_dev *amd_pdev;
 
-
 static int amd_rng_data_present(struct hwrng *rng, int wait)
 {
 	u32 pmbase = (u32)rng->priv;
@@ -100,7 +97,6 @@ static void amd_rng_cleanup(struct hwrng *rng)
 	pci_write_config_byte(amd_pdev, 0x40, rnen);
 }
 
-
 static struct hwrng amd_rng = {
 	.name		= "amd",
 	.init		= amd_rng_init,
@@ -109,7 +105,6 @@ static struct hwrng amd_rng = {
 	.data_read	= amd_rng_data_read,
 };
 
-
 static int __init mod_init(void)
 {
 	int err = -ENODEV;
@@ -157,6 +152,7 @@ out:
 static void __exit mod_exit(void)
 {
 	u32 pmbase = (unsigned long)amd_rng.priv;
+
 	release_region(pmbase + 0xF0, 8);
 	hwrng_unregister(&amd_rng);
 }
-- 
2.7.3

^ permalink raw reply related

* [PATCH] fix:caam:ctrl:add missing header dependencies
From: Baoyou Xie @ 2016-08-26  9:56 UTC (permalink / raw)
  To: herbert, davem
  Cc: arnd, baoyou.xie, tudor-dan.ambarus, linux-crypto, linux-kernel,
	xie.baoyou

We get 1 warning when biuld kernel with W=1:
drivers/crypto/caam/ctrl.c:398:5: warning: no previous prototype for 'caam_get_era' [-Wmissing-prototypes]

In fact, this function is declared in drivers/crypto/caam/ctrl.h,
so this patch add missing header dependencies.

Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
 drivers/crypto/caam/ctrl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 0ec112e..46e72ed 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -14,6 +14,7 @@
 #include "jr.h"
 #include "desc_constr.h"
 #include "error.h"
+#include "ctrl.h"
 
 bool caam_little_end;
 EXPORT_SYMBOL(caam_little_end);
-- 
2.7.4

^ permalink raw reply related

* Re: [PATCH v2 5/5] hwrng: amd: Rework of the amd768-hwrng driver
From: LABBE Corentin @ 2016-08-26  8:38 UTC (permalink / raw)
  To: Jason Cooper; +Cc: mpm, herbert, linux-crypto, linux-kernel
In-Reply-To: <20160825145638.GD10637@io.lakedaemon.net>

On Thu, Aug 25, 2016 at 02:56:38PM +0000, Jason Cooper wrote:
> Hi Corentin,
> 
> On Thu, Aug 25, 2016 at 02:16:35PM +0200, LABBE Corentin wrote:
> > This patch convert the hwrng interface used by amd768-rng to its new API
> > by replacing data_read()/data_present() by read().
> > 
> > Furthermore, Instead of having two global variable, it's better to use a
> > private struct. This will permit to remove amd_pdev variable.
> > 
> > Finally, Instead of accessing hw directly via pmbase, it's better to
> > access after ioport_map() via ioread32/iowrite32.
> 
> I was going to recommend a better $subject line, but now I see why it's
> vague. :(  I would recommend breaking this patch up into three:
> 
>   hwrng: amd - Access hardware via ioread32/iowrite32
>   hwrng: amd - Replace global variable with private struct
>   hwrng: amd - Convert to new hwrng read() API
> 

That was my first idea, but believed that it wasnt worth it.

Anyway I will do it.

Regards
LABBE Corentin

^ permalink raw reply

* sha1_mb broken
From: Stephan Mueller @ 2016-08-26  1:15 UTC (permalink / raw)
  To: linux-crypto

Hi,

I tried to execute tests with sha1_mb.

The execution simply stalls when invoking a digest operation -- i.e. the 
digest operation does not finish. After some time after invoking the hashing 
operation, the following log appears (note, the kccavs_* functions are my test 
code; that test code works perfectly well with all other hash 
implementations):

[  140.426026] INFO: rcu_sched detected stalls on CPUs/tasks:
[  140.426719] 	2-...: (1 GPs behind) idle=9c3/140000000000000/0 
softirq=2680/2707 fqs=14762 
[  140.427024] 	(detected by 0, t=60002 jiffies, g=655, c=654, q=35)
[  140.427024] Task dump for CPU 2:
[  140.427024] cavs_driver     R  running task        0   945    862 
0x00000008
[  140.427024]  ffffffff9b78d965 ffffa527b8bfa640 ffffa527bb505940 
ffffa52775c20c50
[  140.427024]  ffffa527bc300000 ffffa527b93d2a80 ffffa527bb857e00 
ffffa527bc2ffd78
[  140.427024]  ffffa527b93d2ac8 ffffa527bc2ffcc0 ffffffff9b78dfc8 
ffffa527bc2ffd70
[  140.427024] Call Trace:
[  140.427024]  [<ffffffff9b78d965>] ? __schedule+0x245/0x690
[  140.427024]  [<ffffffff9b78dfc8>] ? preempt_schedule_common+0x18/0x30
[  140.427024]  [<ffffffff9b791a68>] ? _raw_spin_lock_irq+0x28/0x30
[  140.427024]  [<ffffffff9b78ed98>] ? wait_for_completion_interruptible
+0x28/0x180
[  140.427024]  [<ffffffffc028541c>] ? sha1_mb_async_digest+0x6c/0x70 
[sha1_mb]
[  140.427024]  [<ffffffff9b3b1129>] ? crypto_ahash_op+0x29/0x70
[  140.427024]  [<ffffffffc0270148>] ? kccavs_test_ahash+0x198/0x2b0 
[kcapi_cavs]
[  140.427024]  [<ffffffffc026e20a>] ? kccavs_data_read+0xda/0x160 
[kcapi_cavs]
[  140.427024]  [<ffffffff9b370964>] ? full_proxy_read+0x54/0x90
[  140.427024]  [<ffffffff9b208088>] ? __vfs_read+0x28/0x110
[  140.427024]  [<ffffffff9b38a2c0>] ? security_file_permission+0xa0/0xc0
[  140.427024]  [<ffffffff9b20850e>] ? rw_verify_area+0x4e/0xb0
[  140.427024]  [<ffffffff9b208606>] ? vfs_read+0x96/0x130
[  140.427024]  [<ffffffff9b2099f6>] ? SyS_read+0x46/0xa0
[  140.427024]  [<ffffffff9b791cb6>] ? entry_SYSCALL_64_fastpath+0x1e/0xa8



Ciao
Stephan

^ permalink raw reply

* Re: Entropy sources
From: H. Peter Anvin @ 2016-08-26  0:20 UTC (permalink / raw)
  To: Sandy Harris; +Cc: Jeffrey Walton, linux-crypto, LKML, Theodore Ts'o
In-Reply-To: <CACXcFmk8DWOxu+=J3i06bSvEW3tp_O2cxHLGdCuXTJROZ=hysA@mail.gmail.com>

On 08/25/16 16:35, Sandy Harris wrote:
> On Thu, Aug 25, 2016 at 5:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> 
>> The network stack is a good source of entropy, *once it is online*.
>> However, the most serious case is while the machine is still booting,
>> when the network will not have enabled yet.
>>
>>         -hpa
> 
> One possible solution is at:
> https://github.com/sandy-harris/maxwell
> 
> A small (< 700 lines) daemon that gets entropy from timer imprecision
> and variations in time for arithmetic (cache misses, interrupts, etc.)
> and pumps it into /dev/random. Make it the first userspace program
> started and all should be covered. Directory above includes a PDF doc
> with detailed rationale and some discussion of alternate solutions.
> 
> Of course if you are dealing with a system-on-a-chip or low-end
> embedded CPU & the timer is really inadequate, this will not work
> well. Conceivably well enough, but we could not know that without
> detailed analysis for each chip in question.
> 

A lot of this is exactly the same thing /dev/random already does in
kernel space.  I have already in the past expressed skepticism toward
this approach, because a lot of the analysis done has simply been bogus.

	-hpa

^ permalink raw reply

* Re: Entropy sources (was: /dev/random - a new approach)
From: Sandy Harris @ 2016-08-25 23:35 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Jeffrey Walton, linux-crypto, LKML, Theodore Ts'o
In-Reply-To: <f57f675f-a914-4c72-f32a-4091e547905f@zytor.com>

On Thu, Aug 25, 2016 at 5:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:

> The network stack is a good source of entropy, *once it is online*.
> However, the most serious case is while the machine is still booting,
> when the network will not have enabled yet.
>
>         -hpa

One possible solution is at:
https://github.com/sandy-harris/maxwell

A small (< 700 lines) daemon that gets entropy from timer imprecision
and variations in time for arithmetic (cache misses, interrupts, etc.)
and pumps it into /dev/random. Make it the first userspace program
started and all should be covered. Directory above includes a PDF doc
with detailed rationale and some discussion of alternate solutions.

Of course if you are dealing with a system-on-a-chip or low-end
embedded CPU & the timer is really inadequate, this will not work
well. Conceivably well enough, but we could not know that without
detailed analysis for each chip in question.

^ permalink raw reply

* Re: Entropy sources (was: /dev/random - a new approach)
From: H. Peter Anvin @ 2016-08-25 21:30 UTC (permalink / raw)
  To: noloader; +Cc: linux-crypto, linux-kernel
In-Reply-To: <CAH8yC8nZyAZT2OiRXgT=CBfQ4RSw-E1uZaQvKuQZ9BDYuPmGvA@mail.gmail.com>

On 08/20/16 22:37, Jeffrey Walton wrote:
>>
>> The biggest problem there is that the timer interrupt adds *no* entropy
>> unless there is a source of asynchronicity in the system.  On PCs,
>> traditionally the timer has been run from a completely different crystal
>> (14.31818 MHz) than the CPU, which is the ideal situation, but if they
>> are run off the same crystal and run in lockstep, there is very little
>> if anything there.  On some systems, the timer may even *be* the only
>> source of time, and the entropy truly is zero.
> 
> It seems like a networked computer should have an abundance on entropy
> available from the network stack. Every common case I can come up with
> includes a networked computer. If a handheld is outside of coverage,
> then it probably does not have the randomness demands because it can't
> communicate (i.e., TCP sequence numbers, key agreement, etc).
> 
> In fact, there are at least two papers that use bits from the network stack:
> 

The network stack is a good source of entropy, *once it is online*.
However, the most serious case is while the machine is still booting,
when the network will not have enabled yet.

	-hpa

^ permalink raw reply

* Re: Git bisected regression for ipsec/aead
From: Sowmini Varadhan @ 2016-08-25 15:45 UTC (permalink / raw)
  To: Herbert Xu; +Cc: linux-crypto, joshua.a.hay, steffen.klassert
In-Reply-To: <20160825084951.GA11496@gondor.apana.org.au>

On (08/25/16 16:49), Herbert Xu wrote:
> This bisection doesn't make much sense as this patch just causes
> cryptd to be used a little more more frequently.  But it does
> point the finger at cryptd.
    :
> So we have list corruption here, possibly caused by use-after-free.
> I did spot one bug in the AEAD cryptd path where we end up using
> the wrong tfm to track refcnt.
> 
> Does this patch help?

Unfortunately no, I still see the panic.

--Sowmini

^ permalink raw reply

* Re: [PATCH v2 5/5] hwrng: amd: Rework of the amd768-hwrng driver
From: Jason Cooper @ 2016-08-25 14:56 UTC (permalink / raw)
  To: LABBE Corentin; +Cc: mpm, herbert, linux-crypto, linux-kernel
In-Reply-To: <1472127395-32195-6-git-send-email-clabbe.montjoie@gmail.com>

Hi Corentin,

On Thu, Aug 25, 2016 at 02:16:35PM +0200, LABBE Corentin wrote:
> This patch convert the hwrng interface used by amd768-rng to its new API
> by replacing data_read()/data_present() by read().
> 
> Furthermore, Instead of having two global variable, it's better to use a
> private struct. This will permit to remove amd_pdev variable.
> 
> Finally, Instead of accessing hw directly via pmbase, it's better to
> access after ioport_map() via ioread32/iowrite32.

I was going to recommend a better $subject line, but now I see why it's
vague. :(  I would recommend breaking this patch up into three:

  hwrng: amd - Access hardware via ioread32/iowrite32
  hwrng: amd - Replace global variable with private struct
  hwrng: amd - Convert to new hwrng read() API

thx,

Jason.

^ permalink raw reply

* Re: [PATCH] hwrng: pasemi_rng.c: Migrate to managed API
From: PrasannaKumar Muralidharan @ 2016-08-25 13:25 UTC (permalink / raw)
  To: LABBE Corentin
  Cc: olof, mpm, Herbert Xu, linuxppc-dev, linux-crypto, linux-kernel
In-Reply-To: <20160825121546.GA25650@Red>

> I will propose to use devm_ioremap_resource() instead for removing this hardcoded 0x100, but i cannot find any user of this driver in any dts. (And so cannot check that this 0x100 is given in any DT resource node)
>
> Is this normal ?

I wanted to use devm_ioremap_resource but could not find DT entry
required for this driver in any of the .dts files. So did not change
that. I could not find any dts/dtsi for this platform. So I assume
that the dtb is not present in the kernel, dtb is supplied by the
bootloader. I may be wrong in this. Can anyone confirm this?

Regards,
PrasannaKumar

^ permalink raw reply

* [PATCH] crypto: FIPS - allow tests to be disabled in FIPS mode
From: Stephan Mueller @ 2016-08-25 13:15 UTC (permalink / raw)
  To: herbert; +Cc: linux-crypto, Tapas Sarangi

In FIPS mode, additional restrictions may apply. If these restrictions
are violated, the kernel will panic(). This patch allows test vectors
for symmetric ciphers to be marked as to be skipped in FIPS mode.

Together with the patch, the XTS test vectors where the AES key is
identical to the tweak key is disabled in FIPS mode. This test vector
violates the FIPS requirement that both keys must be different.

Reported-by: Tapas Sarangi <TSarangi@trustwave.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/testmgr.c | 9 +++++++++
 crypto/testmgr.h | 4 ++++
 2 files changed, 13 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c2a8bd3..0b01c3d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1008,6 +1008,9 @@ static int test_cipher(struct crypto_cipher *tfm, int enc,
 		if (template[i].np)
 			continue;
 
+		if (fips_enabled && template[i].fips_skip)
+			continue;
+
 		j++;
 
 		ret = -EINVAL;
@@ -1112,6 +1115,9 @@ static int __test_skcipher(struct crypto_skcipher *tfm, int enc,
 		if (template[i].np && !template[i].also_non_np)
 			continue;
 
+		if (fips_enabled && template[i].fips_skip)
+			continue;
+
 		if (template[i].iv)
 			memcpy(iv, template[i].iv, ivsize);
 		else
@@ -1198,6 +1204,9 @@ static int __test_skcipher(struct crypto_skcipher *tfm, int enc,
 		if (!template[i].np)
 			continue;
 
+		if (fips_enabled && template[i].fips_skip)
+			continue;
+
 		if (template[i].iv)
 			memcpy(iv, template[i].iv, ivsize);
 		else
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index acb6bbf..e64a4ef 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -59,6 +59,7 @@ struct hash_testvec {
  * @tap:	How to distribute data in @np SGs
  * @also_non_np: 	if set to 1, the test will be also done without
  * 			splitting data in @np SGs
+ * @fips_skip:	Skip the test vector in FIPS mode
  */
 
 struct cipher_testvec {
@@ -75,6 +76,7 @@ struct cipher_testvec {
 	unsigned char klen;
 	unsigned short ilen;
 	unsigned short rlen;
+	bool fips_skip;
 };
 
 struct aead_testvec {
@@ -18224,6 +18226,7 @@ static struct cipher_testvec aes_xts_enc_tv_template[] = {
 			  "\x00\x00\x00\x00\x00\x00\x00\x00"
 			  "\x00\x00\x00\x00\x00\x00\x00\x00",
 		.klen   = 32,
+		.fips_skip = 1,
 		.iv     = "\x00\x00\x00\x00\x00\x00\x00\x00"
 			  "\x00\x00\x00\x00\x00\x00\x00\x00",
 		.input  = "\x00\x00\x00\x00\x00\x00\x00\x00"
@@ -18566,6 +18569,7 @@ static struct cipher_testvec aes_xts_dec_tv_template[] = {
 			  "\x00\x00\x00\x00\x00\x00\x00\x00"
 			  "\x00\x00\x00\x00\x00\x00\x00\x00",
 		.klen   = 32,
+		.fips_skip = 1,
 		.iv     = "\x00\x00\x00\x00\x00\x00\x00\x00"
 			  "\x00\x00\x00\x00\x00\x00\x00\x00",
 		.input = "\x91\x7c\xf6\x9e\xbd\x68\xb2\xec"
-- 
2.7.4

^ permalink raw reply related

* [PATCH v2 2/5] hwrng: amd: use the BIT macro
From: LABBE Corentin @ 2016-08-25 12:16 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472127395-32195-1-git-send-email-clabbe.montjoie@gmail.com>

This patch add usage of the BIT() macro

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 45b7965..d0042f5 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -78,11 +78,11 @@ static int amd_rng_init(struct hwrng *rng)
 	u8 rnen;
 
 	pci_read_config_byte(amd_pdev, 0x40, &rnen);
-	rnen |= (1 << 7);	/* RNG on */
+	rnen |= BIT(7);	/* RNG on */
 	pci_write_config_byte(amd_pdev, 0x40, rnen);
 
 	pci_read_config_byte(amd_pdev, 0x41, &rnen);
-	rnen |= (1 << 7);	/* PMIO enable */
+	rnen |= BIT(7);	/* PMIO enable */
 	pci_write_config_byte(amd_pdev, 0x41, rnen);
 
 	return 0;
@@ -93,7 +93,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
 	u8 rnen;
 
 	pci_read_config_byte(amd_pdev, 0x40, &rnen);
-	rnen &= ~(1 << 7);	/* RNG off */
+	rnen &= ~BIT(7);	/* RNG off */
 	pci_write_config_byte(amd_pdev, 0x40, rnen);
 }
 
-- 
2.7.3

^ permalink raw reply related

* [PATCH v2 3/5] hwrng: amd: Be consitent with the driver name
From: LABBE Corentin @ 2016-08-25 12:16 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472127395-32195-1-git-send-email-clabbe.montjoie@gmail.com>

The driver name is displayed each time differently.
This patch make use of the same name everywhere.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index d0042f5..93157af 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -31,7 +31,7 @@
 #include <linux/delay.h>
 #include <asm/io.h>
 
-#define PFX	KBUILD_MODNAME ": "
+#define DRV_NAME "AMD768-HWRNG"
 
 /*
  * Data for PCI driver interface
@@ -128,8 +128,8 @@ found:
 	pmbase &= 0x0000FF00;
 	if (pmbase == 0)
 		goto out;
-	if (!request_region(pmbase + 0xF0, 8, "AMD HWRNG")) {
-		dev_err(&pdev->dev, "AMD HWRNG region 0x%x already in use!\n",
+	if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
+		dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
 			pmbase + 0xF0);
 		err = -EBUSY;
 		goto out;
@@ -137,11 +137,10 @@ found:
 	amd_rng.priv = (unsigned long)pmbase;
 	amd_pdev = pdev;
 
-	pr_info("AMD768 RNG detected\n");
+	pr_info(DRV_NAME " detected\n");
 	err = hwrng_register(&amd_rng);
 	if (err) {
-		pr_err(PFX "RNG registering failed (%d)\n",
-		       err);
+		pr_err(DRV_NAME " registering failed (%d)\n", err);
 		release_region(pmbase + 0xF0, 8);
 		goto out;
 	}
-- 
2.7.3

^ permalink raw reply related

* [PATCH v2 5/5] hwrng: amd: Rework of the amd768-hwrng driver
From: LABBE Corentin @ 2016-08-25 12:16 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472127395-32195-1-git-send-email-clabbe.montjoie@gmail.com>

This patch convert the hwrng interface used by amd768-rng to its new API
by replacing data_read()/data_present() by read().

Furthermore, Instead of having two global variable, it's better to use a
private struct. This will permit to remove amd_pdev variable.

Finally, Instead of accessing hw directly via pmbase, it's better to
access after ioport_map() via ioread32/iowrite32.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 151 +++++++++++++++++++++++++--------------
 1 file changed, 99 insertions(+), 52 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index de82fe3..785bc3e 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -32,6 +32,14 @@
 
 #define DRV_NAME "AMD768-HWRNG"
 
+#define GEN_CFG_REG1	0x40
+#define GEN_CFG_REG2	0x41
+#define SMIO_SPACEPTR	0x58
+#define RNGDATA		0x00
+#define RNGDONE		0x04
+#define PMBASE_OFFSET	0xF0
+#define PMBASE_SIZE	8
+
 /*
  * Data for PCI driver interface
  *
@@ -39,6 +47,7 @@
  * PCI ids via MODULE_DEVICE_TABLE.  We do not actually
  * register a pci_driver, because someone else might one day
  * want to register another driver on the same PCI id.
+ * Like i2c-amd756
  */
 static const struct pci_device_id pci_tbl[] = {
 	{ PCI_VDEVICE(AMD, 0x7443), 0, },
@@ -47,112 +56,150 @@ static const struct pci_device_id pci_tbl[] = {
 };
 MODULE_DEVICE_TABLE(pci, pci_tbl);
 
-static struct pci_dev *amd_pdev;
+struct amd768_priv {
+	void __iomem *iobase;
+	struct pci_dev *pcidev;
+	u32 pmbase;
+};
 
-static int amd_rng_data_present(struct hwrng *rng, int wait)
+static int amd_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
 {
-	u32 pmbase = (u32)rng->priv;
-	int data, i;
-
-	for (i = 0; i < 20; i++) {
-		data = !!(inl(pmbase + 0xF4) & 1);
-		if (data || !wait)
-			break;
-		udelay(10);
+	u32 *data = buf;
+	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
+	size_t read = 0;
+	/* We will wait at maximum one time per read */
+	int timeout = max / 4 + 1;
+
+	/*
+	 * RNG data is available when RNGDONE is set to 1
+	 * New random numbers are generated approximately 128 microseconds
+	 * after RNGDATA is read
+	 */
+	while (read < max) {
+		if (ioread32(priv->iobase + RNGDONE) == 0) {
+			if (wait) {
+				/* Delay given by datasheet */
+				usleep_range(128, 196);
+				if (timeout-- == 0)
+					return read;
+			} else {
+				return 0;
+			}
+		} else {
+			*data = ioread32(priv->iobase + RNGDATA);
+			data++;
+			read += 4;
+		}
 	}
-	return data;
-}
-
-static int amd_rng_data_read(struct hwrng *rng, u32 *data)
-{
-	u32 pmbase = (u32)rng->priv;
 
-	*data = inl(pmbase + 0xF0);
-
-	return 4;
+	return read;
 }
 
 static int amd_rng_init(struct hwrng *rng)
 {
 	u8 rnen;
+	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
 
-	pci_read_config_byte(amd_pdev, 0x40, &rnen);
+	pci_read_config_byte(priv->pcidev, GEN_CFG_REG1, &rnen);
 	rnen |= BIT(7);	/* RNG on */
-	pci_write_config_byte(amd_pdev, 0x40, rnen);
+	pci_write_config_byte(priv->pcidev, GEN_CFG_REG1, rnen);
 
-	pci_read_config_byte(amd_pdev, 0x41, &rnen);
+	pci_read_config_byte(priv->pcidev, GEN_CFG_REG2, &rnen);
 	rnen |= BIT(7);	/* PMIO enable */
-	pci_write_config_byte(amd_pdev, 0x41, rnen);
-
+	pci_write_config_byte(priv->pcidev, GEN_CFG_REG2, rnen);
 	return 0;
 }
 
 static void amd_rng_cleanup(struct hwrng *rng)
 {
 	u8 rnen;
+	struct amd768_priv *priv = (struct amd768_priv *)rng->priv;
 
-	pci_read_config_byte(amd_pdev, 0x40, &rnen);
+	pci_read_config_byte(priv->pcidev, GEN_CFG_REG1, &rnen);
 	rnen &= ~BIT(7);	/* RNG off */
-	pci_write_config_byte(amd_pdev, 0x40, rnen);
+	pci_write_config_byte(priv->pcidev, GEN_CFG_REG1, rnen);
 }
 
 static struct hwrng amd_rng = {
 	.name		= "amd",
+	.read		= amd_rng_read,
 	.init		= amd_rng_init,
 	.cleanup	= amd_rng_cleanup,
-	.data_present	= amd_rng_data_present,
-	.data_read	= amd_rng_data_read,
 };
 
-static int __init mod_init(void)
+static int mod_init(void)
 {
-	int err = -ENODEV;
+	int err;
 	struct pci_dev *pdev = NULL;
 	const struct pci_device_id *ent;
 	u32 pmbase;
+	struct amd768_priv *priv;
 
 	for_each_pci_dev(pdev) {
 		ent = pci_match_id(pci_tbl, pdev);
 		if (ent)
 			goto found;
 	}
-	/* Device not found. */
-	goto out;
-
+	return -ENODEV;
 found:
-	err = pci_read_config_dword(pdev, 0x58, &pmbase);
+
+	err = pci_read_config_dword(pdev, SMIO_SPACEPTR, &pmbase);
 	if (err)
-		goto out;
-	err = -EIO;
+		return err;
+
 	pmbase &= 0x0000FF00;
-	if (pmbase == 0)
-		goto out;
-	if (!request_region(pmbase + 0xF0, 8, DRV_NAME)) {
-		dev_err(&pdev->dev, DRV_NAME " region 0x%x already in use!\n",
-			pmbase + 0xF0);
-		err = -EBUSY;
-		goto out;
+
+	priv = kzalloc(sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	if (!request_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE, DRV_NAME)) {
+		pr_err(DRV_NAME "region 0x%x already in use!\n", pmbase);
+		goto err_pmbase;
+	}
+
+	priv->iobase = ioport_map(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+	if (!priv->iobase) {
+		pr_err(DRV_NAME "Cannot map ioport\n");
+		err = -EINVAL;
+		goto err_iomap;
 	}
-	amd_rng.priv = (unsigned long)pmbase;
-	amd_pdev = pdev;
+
+	amd_rng.priv = (unsigned long)priv;
+	priv->pmbase = pmbase;
+	priv->pcidev = pdev;
 
 	pr_info(DRV_NAME " detected\n");
+
 	err = hwrng_register(&amd_rng);
 	if (err) {
-		pr_err(DRV_NAME " registering failed (%d)\n", err);
-		release_region(pmbase + 0xF0, 8);
-		goto out;
+		pr_err(DRV_NAME "Cannot register HWRNG %d\n", err);
+		goto err_hwrng;
 	}
-out:
+	return 0;
+
+err_hwrng:
+	ioport_unmap(priv->iobase);
+err_iomap:
+	release_region(pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+err_pmbase:
+	kfree(priv);
 	return err;
 }
 
-static void __exit mod_exit(void)
+static void mod_exit(void)
 {
-	u32 pmbase = (unsigned long)amd_rng.priv;
+	struct amd768_priv *priv;
+
+	priv = (struct amd768_priv *)amd_rng.priv;
 
-	release_region(pmbase + 0xF0, 8);
 	hwrng_unregister(&amd_rng);
+
+	ioport_unmap(priv->iobase);
+
+	release_region(priv->pmbase + PMBASE_OFFSET, PMBASE_SIZE);
+
+	kfree(priv);
 }
 
 module_init(mod_init);
-- 
2.7.3

^ permalink raw reply related

* [PATCH v2 4/5] hwrng: amd: Remove asm/io.h
From: LABBE Corentin @ 2016-08-25 12:16 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472127395-32195-1-git-send-email-clabbe.montjoie@gmail.com>

checkpatch complains about <asm/io.h> used instead of linux/io.h.
In fact it is not needed.
This patch remove it, and in the process, alphabetize the other headers.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 93157af..de82fe3 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -24,12 +24,11 @@
  * warranty of any kind, whether express or implied.
  */
 
-#include <linux/module.h>
+#include <linux/delay.h>
+#include <linux/hw_random.h>
 #include <linux/kernel.h>
+#include <linux/module.h>
 #include <linux/pci.h>
-#include <linux/hw_random.h>
-#include <linux/delay.h>
-#include <asm/io.h>
 
 #define DRV_NAME "AMD768-HWRNG"
 
-- 
2.7.3

^ permalink raw reply related

* [PATCH v2 1/5] hwrng: amd: Fix style problem with blank line
From: LABBE Corentin @ 2016-08-25 12:16 UTC (permalink / raw)
  To: mpm, herbert, linux-crypto; +Cc: linux-kernel, LABBE Corentin
In-Reply-To: <1472127395-32195-1-git-send-email-clabbe.montjoie@gmail.com>

Some blank line are unncessary, and one is missing after declaration.
This patch fix thoses style problems.

Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
 drivers/char/hw_random/amd-rng.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/char/hw_random/amd-rng.c b/drivers/char/hw_random/amd-rng.c
index 48f6a83..45b7965 100644
--- a/drivers/char/hw_random/amd-rng.c
+++ b/drivers/char/hw_random/amd-rng.c
@@ -31,10 +31,8 @@
 #include <linux/delay.h>
 #include <asm/io.h>
 
-
 #define PFX	KBUILD_MODNAME ": "
 
-
 /*
  * Data for PCI driver interface
  *
@@ -52,7 +50,6 @@ MODULE_DEVICE_TABLE(pci, pci_tbl);
 
 static struct pci_dev *amd_pdev;
 
-
 static int amd_rng_data_present(struct hwrng *rng, int wait)
 {
 	u32 pmbase = (u32)rng->priv;
@@ -100,7 +97,6 @@ static void amd_rng_cleanup(struct hwrng *rng)
 	pci_write_config_byte(amd_pdev, 0x40, rnen);
 }
 
-
 static struct hwrng amd_rng = {
 	.name		= "amd",
 	.init		= amd_rng_init,
@@ -109,7 +105,6 @@ static struct hwrng amd_rng = {
 	.data_read	= amd_rng_data_read,
 };
 
-
 static int __init mod_init(void)
 {
 	int err = -ENODEV;
@@ -157,6 +152,7 @@ out:
 static void __exit mod_exit(void)
 {
 	u32 pmbase = (unsigned long)amd_rng.priv;
+
 	release_region(pmbase + 0xF0, 8);
 	hwrng_unregister(&amd_rng);
 }
-- 
2.7.3

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox