linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v1 0/2] hwrng: npcm: add NPCM RNG driver support
@ 2019-08-28 16:26 Tomer Maimon
  2019-08-28 16:26 ` [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation Tomer Maimon
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Tomer Maimon @ 2019-08-28 16:26 UTC (permalink / raw)
  To: mpm, herbert, arnd, gregkh, robh+dt, mark.rutland, avifishman70,
	tali.perry1, venture, yuenn, benjaminfair, sumit.garg,
	jens.wiklander, vkoul, tglx, joel
  Cc: devicetree, linux-kernel, linux-crypto, openbmc, Tomer Maimon

This patch set adds Randon Number Generator (RNG) support 
for the Nuvoton NPCM Baseboard Management Controller (BMC).

The RNG driver we use power consumption when the RNG 
is not required.

The NPCM RNG driver tested on NPCM750 evaluation board.

Tomer Maimon (2):
  dt-binding: hwrng: add NPCM RNG documentation
  hwrng: npcm: add NPCM RNG driver

 .../bindings/rng/nuvoton,npcm-rng.txt         |  17 ++
 drivers/char/hw_random/Kconfig                |  13 ++
 drivers/char/hw_random/Makefile               |   1 +
 drivers/char/hw_random/npcm-rng.c             | 207 ++++++++++++++++++
 4 files changed, 238 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
 create mode 100644 drivers/char/hw_random/npcm-rng.c

-- 
2.18.0


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation
  2019-08-28 16:26 [PATCH v1 0/2] hwrng: npcm: add NPCM RNG driver support Tomer Maimon
@ 2019-08-28 16:26 ` Tomer Maimon
  2019-08-29 10:49   ` Daniel Thompson
  2019-08-28 16:26 ` [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver Tomer Maimon
  2019-08-30 22:47 ` Milton Miller II
  2 siblings, 1 reply; 11+ messages in thread
From: Tomer Maimon @ 2019-08-28 16:26 UTC (permalink / raw)
  To: mpm, herbert, arnd, gregkh, robh+dt, mark.rutland, avifishman70,
	tali.perry1, venture, yuenn, benjaminfair, sumit.garg,
	jens.wiklander, vkoul, tglx, joel
  Cc: devicetree, linux-kernel, linux-crypto, openbmc, Tomer Maimon

Added device tree binding documentation for Nuvoton BMC
NPCM Random Number Generator (RNG).

Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
 .../bindings/rng/nuvoton,npcm-rng.txt           | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt

diff --git a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
new file mode 100644
index 000000000000..a697b4425fb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
@@ -0,0 +1,17 @@
+NPCM SoC Random Number Generator
+
+Required properties:
+- compatible  : "nuvoton,npcm750-rng" for the NPCM7XX BMC.
+- reg         : Specifies physical base address and size of the registers.
+
+Optional property:
+- quality : estimated number of bits of true entropy per 1024 bits
+			read from the rng.
+			If this property is not defined, it defaults to 1000.
+
+Example:
+
+rng: rng@f000b000 {
+	compatible = "nuvoton,npcm750-rng";
+	reg = <0xf000b000 0x8>;
+};
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver
  2019-08-28 16:26 [PATCH v1 0/2] hwrng: npcm: add NPCM RNG driver support Tomer Maimon
  2019-08-28 16:26 ` [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation Tomer Maimon
@ 2019-08-28 16:26 ` Tomer Maimon
  2019-08-29 10:47   ` Daniel Thompson
  2019-08-30 22:47 ` Milton Miller II
  2 siblings, 1 reply; 11+ messages in thread
From: Tomer Maimon @ 2019-08-28 16:26 UTC (permalink / raw)
  To: mpm, herbert, arnd, gregkh, robh+dt, mark.rutland, avifishman70,
	tali.perry1, venture, yuenn, benjaminfair, sumit.garg,
	jens.wiklander, vkoul, tglx, joel
  Cc: devicetree, linux-kernel, linux-crypto, openbmc, Tomer Maimon

Add Nuvoton NPCM BMC Random Number Generator(RNG) driver.

Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
 drivers/char/hw_random/Kconfig    |  13 ++
 drivers/char/hw_random/Makefile   |   1 +
 drivers/char/hw_random/npcm-rng.c | 207 ++++++++++++++++++++++++++++++
 3 files changed, 221 insertions(+)
 create mode 100644 drivers/char/hw_random/npcm-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 59f25286befe..87a1c30e7958 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -440,6 +440,19 @@ config HW_RANDOM_OPTEE
 
 	  If unsure, say Y.
 
+config HW_RANDOM_NPCM
+	tristate "NPCM Random Number Generator support"
+	depends on ARCH_NPCM || COMPILE_TEST
+	default HW_RANDOM
+	help
+ 	  This driver provides support for the Random Number
+	  Generator hardware available in Nuvoton NPCM SoCs.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called npcm-rng.
+
+ 	  If unsure, say Y.
+
 endif # HW_RANDOM
 
 config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 7c9ef4a7667f..17b6d4e6d591 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_HW_RANDOM_MTK)	+= mtk-rng.o
 obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o
 obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o
 obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o
+obj-$(CONFIG_HW_RANDOM_NPCM) += npcm-rng.o
diff --git a/drivers/char/hw_random/npcm-rng.c b/drivers/char/hw_random/npcm-rng.c
new file mode 100644
index 000000000000..5b4b1b6cb362
--- /dev/null
+++ b/drivers/char/hw_random/npcm-rng.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2019 Nuvoton Technology corporation.
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/init.h>
+#include <linux/random.h>
+#include <linux/err.h>
+#include <linux/platform_device.h>
+#include <linux/hw_random.h>
+#include <linux/delay.h>
+#include <linux/of_irq.h>
+#include <linux/pm_runtime.h>
+
+#define NPCM_RNGCS_REG		0x00	/* Control and status register */
+#define NPCM_RNGD_REG		0x04	/* Data register */
+#define NPCM_RNGMODE_REG	0x08	/* Mode register */
+
+#define NPCM_RNG_CLK_SET_25MHZ	GENMASK(4, 3) /* 20-25 MHz */
+#define NPCM_RNG_DATA_VALID	BIT(1)
+#define NPCM_RNG_ENABLE		BIT(0)
+#define NPCM_RNG_M1ROSEL	BIT(1)
+
+#define NPCM_RNG_TIMEOUT_POLL	20
+
+#define to_npcm_rng(p)	container_of(p, struct npcm_rng, rng)
+
+struct npcm_rng {
+	void __iomem *base;
+	struct hwrng rng;
+};
+
+static int npcm_rng_init(struct hwrng *rng)
+{
+	struct npcm_rng *priv = to_npcm_rng(rng);
+	u32 val;
+
+	val = readl(priv->base + NPCM_RNGCS_REG);
+	val |= NPCM_RNG_ENABLE;
+	writel(val, priv->base + NPCM_RNGCS_REG);
+
+	return 0;
+}
+
+static void npcm_rng_cleanup(struct hwrng *rng)
+{
+	struct npcm_rng *priv = to_npcm_rng(rng);
+	u32 val;
+
+	val = readl(priv->base + NPCM_RNGCS_REG);
+	val &= ~NPCM_RNG_ENABLE;
+	writel(val, priv->base + NPCM_RNGCS_REG);
+}
+
+static bool npcm_rng_wait_ready(struct hwrng *rng, bool wait)
+{
+	struct npcm_rng *priv = to_npcm_rng(rng);
+	int timeout_cnt = 0;
+	int ready;
+
+	ready = readl(priv->base + NPCM_RNGCS_REG) & NPCM_RNG_DATA_VALID;
+	while ((ready == 0) && (timeout_cnt < NPCM_RNG_TIMEOUT_POLL)) {
+		usleep_range(500, 1000);
+		ready = readl(priv->base + NPCM_RNGCS_REG) &
+			NPCM_RNG_DATA_VALID;
+		timeout_cnt++;
+	}
+
+	return !!ready;
+}
+
+static int npcm_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+	struct npcm_rng *priv = to_npcm_rng(rng);
+	int retval = 0;
+
+	pm_runtime_get_sync((struct device *)priv->rng.priv);
+
+	while (max >= sizeof(u32)) {
+		if (!npcm_rng_wait_ready(rng, wait))
+			break;
+
+		*(u32 *)buf = readl(priv->base + NPCM_RNGD_REG);
+		retval += sizeof(u32);
+		buf += sizeof(u32);
+		max -= sizeof(u32);
+	}
+
+	pm_runtime_mark_last_busy((struct device *)priv->rng.priv);
+	pm_runtime_put_sync_autosuspend((struct device *)priv->rng.priv);
+
+	return retval || !wait ? retval : -EIO;
+}
+
+static int npcm_rng_probe(struct platform_device *pdev)
+{
+	struct npcm_rng *priv;
+	struct resource *res;
+	u32 quality;
+	int ret;
+
+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	priv->base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(priv->base))
+		return PTR_ERR(priv->base);
+
+	priv->rng.name = pdev->name;
+#ifndef CONFIG_PM
+	priv->rng.init = npcm_rng_init;
+	priv->rng.cleanup = npcm_rng_cleanup;
+#endif
+	priv->rng.read = npcm_rng_read;
+	priv->rng.priv = (unsigned long)&pdev->dev;
+	if (of_property_read_u32(pdev->dev.of_node, "quality", &quality))
+		priv->rng.quality = 1000;
+	else
+		priv->rng.quality = quality;
+
+	writel(NPCM_RNG_M1ROSEL, priv->base + NPCM_RNGMODE_REG);
+#ifndef CONFIG_PM
+	writel(NPCM_RNG_CLK_SET_25MHZ, priv->base + NPCM_RNGCS_REG);
+#else
+	writel(NPCM_RNG_CLK_SET_25MHZ | NPCM_RNG_ENABLE,
+	       priv->base + NPCM_RNGCS_REG);
+#endif
+
+	ret = devm_hwrng_register(&pdev->dev, &priv->rng);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to register rng device: %d\n",
+			ret);
+		return ret;
+	}
+
+	dev_set_drvdata(&pdev->dev, priv);
+	pm_runtime_set_autosuspend_delay(&pdev->dev, 100);
+	pm_runtime_use_autosuspend(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	dev_info(&pdev->dev, "Random Number Generator Probed\n");
+
+	return 0;
+}
+
+static int npcm_rng_remove(struct platform_device *pdev)
+{
+	struct npcm_rng *priv = platform_get_drvdata(pdev);
+
+	hwrng_unregister(&priv->rng);
+	pm_runtime_disable(&pdev->dev);
+	pm_runtime_set_suspended(&pdev->dev);
+
+	return 0;
+}
+
+#ifdef CONFIG_PM
+static int npcm_rng_runtime_suspend(struct device *dev)
+{
+	struct npcm_rng *priv = dev_get_drvdata(dev);
+
+	npcm_rng_cleanup(&priv->rng);
+
+	return 0;
+}
+
+static int npcm_rng_runtime_resume(struct device *dev)
+{
+	struct npcm_rng *priv = dev_get_drvdata(dev);
+
+	return npcm_rng_init(&priv->rng);
+}
+#endif
+
+static const struct dev_pm_ops npcm_rng_pm_ops = {
+	SET_RUNTIME_PM_OPS(npcm_rng_runtime_suspend,
+			   npcm_rng_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+};
+
+static const struct of_device_id rng_dt_id[] = {
+	{ .compatible = "nuvoton,npcm750-rng",  },
+	{},
+};
+MODULE_DEVICE_TABLE(of, rng_dt_id);
+
+static struct platform_driver npcm_rng_driver = {
+	.driver = {
+		.name		= "npcm-rng",
+		.pm		= &npcm_rng_pm_ops,
+		.owner		= THIS_MODULE,
+		.of_match_table = of_match_ptr(rng_dt_id),
+	},
+	.probe		= npcm_rng_probe,
+	.remove		= npcm_rng_remove,
+};
+
+module_platform_driver(npcm_rng_driver);
+
+MODULE_DESCRIPTION("Nuvoton NPCM Random Number Generator Driver");
+MODULE_AUTHOR("Tomer Maimon <tomer.maimon@nuvoton.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver
  2019-08-28 16:26 ` [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver Tomer Maimon
@ 2019-08-29 10:47   ` Daniel Thompson
       [not found]     ` <CAP6Zq1jXUhKjwBHiDKiKcpt_PiJQA61z2SUNg4_LztcnMMJ-Ng@mail.gmail.com>
  0 siblings, 1 reply; 11+ messages in thread
From: Daniel Thompson @ 2019-08-29 10:47 UTC (permalink / raw)
  To: Tomer Maimon
  Cc: mpm, herbert, arnd, gregkh, robh+dt, mark.rutland, avifishman70,
	tali.perry1, venture, yuenn, benjaminfair, sumit.garg,
	jens.wiklander, vkoul, tglx, joel, devicetree, linux-kernel,
	linux-crypto, openbmc

On Wed, Aug 28, 2019 at 07:26:17PM +0300, Tomer Maimon wrote:
> Add Nuvoton NPCM BMC Random Number Generator(RNG) driver.
> 
> Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> ---
>  drivers/char/hw_random/Kconfig    |  13 ++
>  drivers/char/hw_random/Makefile   |   1 +
>  drivers/char/hw_random/npcm-rng.c | 207 ++++++++++++++++++++++++++++++
>  3 files changed, 221 insertions(+)
>  create mode 100644 drivers/char/hw_random/npcm-rng.c
> 
> diff --git a/drivers/char/hw_random/npcm-rng.c b/drivers/char/hw_random/npcm-rng.c
> new file mode 100644
> index 000000000000..5b4b1b6cb362
> --- /dev/null
> +++ b/drivers/char/hw_random/npcm-rng.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (c) 2019 Nuvoton Technology corporation.
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/init.h>
> +#include <linux/random.h>
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/hw_random.h>
> +#include <linux/delay.h>
> +#include <linux/of_irq.h>
> +#include <linux/pm_runtime.h>
> +
> +#define NPCM_RNGCS_REG		0x00	/* Control and status register */
> +#define NPCM_RNGD_REG		0x04	/* Data register */
> +#define NPCM_RNGMODE_REG	0x08	/* Mode register */
> +
> +#define NPCM_RNG_CLK_SET_25MHZ	GENMASK(4, 3) /* 20-25 MHz */
> +#define NPCM_RNG_DATA_VALID	BIT(1)
> +#define NPCM_RNG_ENABLE		BIT(0)
> +#define NPCM_RNG_M1ROSEL	BIT(1)
> +
> +#define NPCM_RNG_TIMEOUT_POLL	20

Might be better to define this in real-world units (such as
milliseconds) since the timeout is effectively the longest time the
hardware can take to generate 4 bytes.

> +
> +#define to_npcm_rng(p)	container_of(p, struct npcm_rng, rng)
> +
> +struct npcm_rng {
> +	void __iomem *base;
> +	struct hwrng rng;
> +};
> +
> +static int npcm_rng_init(struct hwrng *rng)
> +{
> +	struct npcm_rng *priv = to_npcm_rng(rng);
> +	u32 val;
> +
> +	val = readl(priv->base + NPCM_RNGCS_REG);
> +	val |= NPCM_RNG_ENABLE;
> +	writel(val, priv->base + NPCM_RNGCS_REG);
> +
> +	return 0;
> +}
> +
> +static void npcm_rng_cleanup(struct hwrng *rng)
> +{
> +	struct npcm_rng *priv = to_npcm_rng(rng);
> +	u32 val;
> +
> +	val = readl(priv->base + NPCM_RNGCS_REG);
> +	val &= ~NPCM_RNG_ENABLE;
> +	writel(val, priv->base + NPCM_RNGCS_REG);
> +}
> +
> +static bool npcm_rng_wait_ready(struct hwrng *rng, bool wait)
> +{
> +	struct npcm_rng *priv = to_npcm_rng(rng);
> +	int timeout_cnt = 0;
> +	int ready;
> +
> +	ready = readl(priv->base + NPCM_RNGCS_REG) & NPCM_RNG_DATA_VALID;
> +	while ((ready == 0) && (timeout_cnt < NPCM_RNG_TIMEOUT_POLL)) {
> +		usleep_range(500, 1000);
> +		ready = readl(priv->base + NPCM_RNGCS_REG) &
> +			NPCM_RNG_DATA_VALID;
> +		timeout_cnt++;
> +	}
> +
> +	return !!ready;
> +}

This looks like an open-coded version of readl_poll_timeout()... better
to use the library function.

Also the sleep looks a bit long to me. What is the generation rate of
the peripheral? Most RNG drivers have short intervals between data
generation so they use delays rather than sleeps (a.k.a.
readl_poll_timeout_atomic() ).


> +
> +static int npcm_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> +	struct npcm_rng *priv = to_npcm_rng(rng);
> +	int retval = 0;
> +
> +	pm_runtime_get_sync((struct device *)priv->rng.priv);
> +
> +	while (max >= sizeof(u32)) {
> +		if (!npcm_rng_wait_ready(rng, wait))
> +			break;

The code as currently written does not honour the wait parameter (e.g.
it sleeps even when wait is false).


> +
> +		*(u32 *)buf = readl(priv->base + NPCM_RNGD_REG);
> +		retval += sizeof(u32);
> +		buf += sizeof(u32);
> +		max -= sizeof(u32);
> +	}
> +
> +	pm_runtime_mark_last_busy((struct device *)priv->rng.priv);
> +	pm_runtime_put_sync_autosuspend((struct device *)priv->rng.priv);
> +
> +	return retval || !wait ? retval : -EIO;
> +}
> +
> +static int npcm_rng_probe(struct platform_device *pdev)
> +{
> +	struct npcm_rng *priv;
> +	struct resource *res;
> +	u32 quality;
> +	int ret;
> +
> +	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> +	if (!priv)
> +		return -ENOMEM;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	priv->base = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(priv->base))
> +		return PTR_ERR(priv->base);
> +
> +	priv->rng.name = pdev->name;
> +#ifndef CONFIG_PM
> +	priv->rng.init = npcm_rng_init;
> +	priv->rng.cleanup = npcm_rng_cleanup;
> +#endif
> +	priv->rng.read = npcm_rng_read;
> +	priv->rng.priv = (unsigned long)&pdev->dev;
> +	if (of_property_read_u32(pdev->dev.of_node, "quality", &quality))
> +		priv->rng.quality = 1000;
> +	else
> +		priv->rng.quality = quality;
> +
> +	writel(NPCM_RNG_M1ROSEL, priv->base + NPCM_RNGMODE_REG);
> +#ifndef CONFIG_PM
> +	writel(NPCM_RNG_CLK_SET_25MHZ, priv->base + NPCM_RNGCS_REG);
> +#else
> +	writel(NPCM_RNG_CLK_SET_25MHZ | NPCM_RNG_ENABLE,
> +	       priv->base + NPCM_RNGCS_REG);
> +#endif

If this initialization was moved to npcm_rng_init() then there would be
no need for the additional ifdefing. It would also get rid of the
(potentially slow) readl calls on the PM wakeup path.


> +
> +	ret = devm_hwrng_register(&pdev->dev, &priv->rng);
> +	if (ret) {
> +		dev_err(&pdev->dev, "Failed to register rng device: %d\n",
> +			ret);
> +		return ret;
> +	}
> +
> +	dev_set_drvdata(&pdev->dev, priv);
> +	pm_runtime_set_autosuspend_delay(&pdev->dev, 100);
> +	pm_runtime_use_autosuspend(&pdev->dev);
> +	pm_runtime_enable(&pdev->dev);
> +
> +	dev_info(&pdev->dev, "Random Number Generator Probed\n");

Does the user need to know this every time we boot? There are lots of
debug tools we can bring to bear if they are worried the device
isn't probing.


Daniel.


> +
> +	return 0;
> +}
> +
> +static int npcm_rng_remove(struct platform_device *pdev)
> +{
> +	struct npcm_rng *priv = platform_get_drvdata(pdev);
> +
> +	hwrng_unregister(&priv->rng);
> +	pm_runtime_disable(&pdev->dev);
> +	pm_runtime_set_suspended(&pdev->dev);
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +static int npcm_rng_runtime_suspend(struct device *dev)
> +{
> +	struct npcm_rng *priv = dev_get_drvdata(dev);
> +
> +	npcm_rng_cleanup(&priv->rng);
> +
> +	return 0;
> +}
> +
> +static int npcm_rng_runtime_resume(struct device *dev)
> +{
> +	struct npcm_rng *priv = dev_get_drvdata(dev);
> +
> +	return npcm_rng_init(&priv->rng);
> +}
> +#endif
> +
> +static const struct dev_pm_ops npcm_rng_pm_ops = {
> +	SET_RUNTIME_PM_OPS(npcm_rng_runtime_suspend,
> +			   npcm_rng_runtime_resume, NULL)
> +	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> +				pm_runtime_force_resume)
> +};
> +
> +static const struct of_device_id rng_dt_id[] = {
> +	{ .compatible = "nuvoton,npcm750-rng",  },
> +	{},
> +};
> +MODULE_DEVICE_TABLE(of, rng_dt_id);
> +
> +static struct platform_driver npcm_rng_driver = {
> +	.driver = {
> +		.name		= "npcm-rng",
> +		.pm		= &npcm_rng_pm_ops,
> +		.owner		= THIS_MODULE,
> +		.of_match_table = of_match_ptr(rng_dt_id),
> +	},
> +	.probe		= npcm_rng_probe,
> +	.remove		= npcm_rng_remove,
> +};
> +
> +module_platform_driver(npcm_rng_driver);
> +
> +MODULE_DESCRIPTION("Nuvoton NPCM Random Number Generator Driver");
> +MODULE_AUTHOR("Tomer Maimon <tomer.maimon@nuvoton.com>");
> +MODULE_LICENSE("GPL v2");
> -- 
> 2.18.0
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation
  2019-08-28 16:26 ` [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation Tomer Maimon
@ 2019-08-29 10:49   ` Daniel Thompson
  0 siblings, 0 replies; 11+ messages in thread
From: Daniel Thompson @ 2019-08-29 10:49 UTC (permalink / raw)
  To: Tomer Maimon
  Cc: mpm, herbert, arnd, gregkh, robh+dt, mark.rutland, avifishman70,
	tali.perry1, venture, yuenn, benjaminfair, sumit.garg,
	jens.wiklander, vkoul, tglx, joel, devicetree, linux-kernel,
	linux-crypto, openbmc

On Wed, Aug 28, 2019 at 07:26:16PM +0300, Tomer Maimon wrote:
> Added device tree binding documentation for Nuvoton BMC
> NPCM Random Number Generator (RNG).
> 
> Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> ---
>  .../bindings/rng/nuvoton,npcm-rng.txt           | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> 
> diff --git a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> new file mode 100644
> index 000000000000..a697b4425fb3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> @@ -0,0 +1,17 @@
> +NPCM SoC Random Number Generator
> +
> +Required properties:
> +- compatible  : "nuvoton,npcm750-rng" for the NPCM7XX BMC.
> +- reg         : Specifies physical base address and size of the registers.
> +
> +Optional property:
> +- quality : estimated number of bits of true entropy per 1024 bits
> +			read from the rng.
> +			If this property is not defined, it defaults to 1000.

Having a controllable quality implies that the numeric quality of the
peripheral changes when it is stamped out on different SoCs (otherwise
the driver can confidently set the quality without needing any hint
from the DT). Is that really true here?


Daniel.

> +
> +Example:
> +
> +rng: rng@f000b000 {
> +	compatible = "nuvoton,npcm750-rng";
> +	reg = <0xf000b000 0x8>;
> +};
> -- 
> 2.18.0
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re:  [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver
  2019-08-28 16:26 [PATCH v1 0/2] hwrng: npcm: add NPCM RNG driver support Tomer Maimon
  2019-08-28 16:26 ` [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation Tomer Maimon
  2019-08-28 16:26 ` [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver Tomer Maimon
@ 2019-08-30 22:47 ` Milton Miller II
  2 siblings, 0 replies; 11+ messages in thread
From: Milton Miller II @ 2019-08-30 22:47 UTC (permalink / raw)
  To: Tomer Maimon
  Cc: mpm, herbert, arnd, gregkh, robh+dt, mark.rutland, avifishman70,
	tali.perry1, venture, yuenn, benjaminfair, sumit.garg,
	jens.wiklander, vkoul, tglx, joel, devicetree, openbmc,
	linux-kernel, linux-crypto

On August 28th around 11:28AM in some timezone, Tomer Maimon wrote

>Add Nuvoton NPCM BMC Random Number Generator(RNG) driver.
>
>Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
>---
> drivers/char/hw_random/Kconfig    |  13 ++
> drivers/char/hw_random/Makefile   |   1 +
> drivers/char/hw_random/npcm-rng.c | 207
>++++++++++++++++++++++++++++++
> 3 files changed, 221 insertions(+)
> create mode 100644 drivers/char/hw_random/npcm-rng.c
>
>diff --git a/drivers/char/hw_random/Kconfig
>b/drivers/char/hw_random/Kconfig
>index 59f25286befe..87a1c30e7958 100644
>--- a/drivers/char/hw_random/Kconfig
>+++ b/drivers/char/hw_random/Kconfig
>@@ -440,6 +440,19 @@ config HW_RANDOM_OPTEE
> 
> 	  If unsure, say Y.
> 
>+config HW_RANDOM_NPCM
>+	tristate "NPCM Random Number Generator support"
>+	depends on ARCH_NPCM || COMPILE_TEST
>+	default HW_RANDOM
>+	help
>+ 	  This driver provides support for the Random Number
>+	  Generator hardware available in Nuvoton NPCM SoCs.
>+
>+	  To compile this driver as a module, choose M here: the
>+	  module will be called npcm-rng.
>+
>+ 	  If unsure, say Y.
>+
> endif # HW_RANDOM
> 
> config UML_RANDOM
>diff --git a/drivers/char/hw_random/Makefile
>b/drivers/char/hw_random/Makefile
>index 7c9ef4a7667f..17b6d4e6d591 100644
>--- a/drivers/char/hw_random/Makefile
>+++ b/drivers/char/hw_random/Makefile
>@@ -39,3 +39,4 @@ obj-$(CONFIG_HW_RANDOM_MTK)	+= mtk-rng.o
> obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o
> obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o
> obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o
>+obj-$(CONFIG_HW_RANDOM_NPCM) += npcm-rng.o
>diff --git a/drivers/char/hw_random/npcm-rng.c
>b/drivers/char/hw_random/npcm-rng.c
>new file mode 100644
>index 000000000000..5b4b1b6cb362
>--- /dev/null
>+++ b/drivers/char/hw_random/npcm-rng.c
>@@ -0,0 +1,207 @@
>+// SPDX-License-Identifier: GPL-2.0
>+// Copyright (c) 2019 Nuvoton Technology corporation.
>+
>+#include <linux/kernel.h>
>+#include <linux/module.h>
>+#include <linux/io.h>
>+#include <linux/iopoll.h>
>+#include <linux/init.h>
>+#include <linux/random.h>
>+#include <linux/err.h>
>+#include <linux/platform_device.h>
>+#include <linux/hw_random.h>
>+#include <linux/delay.h>
>+#include <linux/of_irq.h>
>+#include <linux/pm_runtime.h>
>+
>+#define NPCM_RNGCS_REG		0x00	/* Control and status register */
>+#define NPCM_RNGD_REG		0x04	/* Data register */
>+#define NPCM_RNGMODE_REG	0x08	/* Mode register */
>+
>+#define NPCM_RNG_CLK_SET_25MHZ	GENMASK(4, 3) /* 20-25 MHz */
>+#define NPCM_RNG_DATA_VALID	BIT(1)
>+#define NPCM_RNG_ENABLE		BIT(0)
>+#define NPCM_RNG_M1ROSEL	BIT(1)
>+
>+#define NPCM_RNG_TIMEOUT_POLL	20
>+
>+#define to_npcm_rng(p)	container_of(p, struct npcm_rng, rng)
>+
>+struct npcm_rng {
>+	void __iomem *base;
>+	struct hwrng rng;
>+};
>+
>+static int npcm_rng_init(struct hwrng *rng)
>+{
>+	struct npcm_rng *priv = to_npcm_rng(rng);
>+	u32 val;
>+
>+	val = readl(priv->base + NPCM_RNGCS_REG);
>+	val |= NPCM_RNG_ENABLE;
>+	writel(val, priv->base + NPCM_RNGCS_REG);
>+
>+	return 0;
>+}
>+
>+static void npcm_rng_cleanup(struct hwrng *rng)
>+{
>+	struct npcm_rng *priv = to_npcm_rng(rng);
>+	u32 val;
>+
>+	val = readl(priv->base + NPCM_RNGCS_REG);
>+	val &= ~NPCM_RNG_ENABLE;
>+	writel(val, priv->base + NPCM_RNGCS_REG);
>+}
>+
>+static bool npcm_rng_wait_ready(struct hwrng *rng, bool wait)
>+{
>+	struct npcm_rng *priv = to_npcm_rng(rng);
>+	int timeout_cnt = 0;
>+	int ready;
>+
>+	ready = readl(priv->base + NPCM_RNGCS_REG) & NPCM_RNG_DATA_VALID;

You should honor the wait paramter here.

>+	while ((ready == 0) && (timeout_cnt < NPCM_RNG_TIMEOUT_POLL)) {
>+		usleep_range(500, 1000);
>+		ready = readl(priv->base + NPCM_RNGCS_REG) &
>+			NPCM_RNG_DATA_VALID;
>+		timeout_cnt++;
>+	}
>+
>+	return !!ready;
>+}
>+
>+static int npcm_rng_read(struct hwrng *rng, void *buf, size_t max,
>bool wait)
>+{
>+	struct npcm_rng *priv = to_npcm_rng(rng);
>+	int retval = 0;
>+
>+	pm_runtime_get_sync((struct device *)priv->rng.priv);
>+
>+	while (max >= sizeof(u32)) {
>+		if (!npcm_rng_wait_ready(rng, wait))
>+			break;
>+
>+		*(u32 *)buf = readl(priv->base + NPCM_RNGD_REG);
>+		retval += sizeof(u32);
>+		buf += sizeof(u32);
>+		max -= sizeof(u32);
>+	}
>+
>+	pm_runtime_mark_last_busy((struct device *)priv->rng.priv);
>+	pm_runtime_put_sync_autosuspend((struct device *)priv->rng.priv);
>+
>+	return retval || !wait ? retval : -EIO;

So you are doing pm get/put around each rng data sample.

Have you characterized the time to enable to the time to get a sample
and compared to the pm runtime sync parameters?

Do you get any data if you set non-blocking wait above?


>+}
>+
>+static int npcm_rng_probe(struct platform_device *pdev)
>+{
>+	struct npcm_rng *priv;
>+	struct resource *res;
>+	u32 quality;
>+	int ret;
>+
>+	priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
>+	if (!priv)
>+		return -ENOMEM;
>+
>+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>+	priv->base = devm_ioremap_resource(&pdev->dev, res);
>+	if (IS_ERR(priv->base))
>+		return PTR_ERR(priv->base);
>+
>+	priv->rng.name = pdev->name;
>+#ifndef CONFIG_PM
>+	priv->rng.init = npcm_rng_init;
>+	priv->rng.cleanup = npcm_rng_cleanup;

so npcm_rng_init and npcm_rng_cleanup are unused if !CONFIG_PM.  No warnings?

>+#endif
>+	priv->rng.read = npcm_rng_read;
>+	priv->rng.priv = (unsigned long)&pdev->dev;
>+	if (of_property_read_u32(pdev->dev.of_node, "quality", &quality))
>+		priv->rng.quality = 1000;
>+	else
>+		priv->rng.quality = quality;
>+
>+	writel(NPCM_RNG_M1ROSEL, priv->base + NPCM_RNGMODE_REG);
>+#ifndef CONFIG_PM
>+	writel(NPCM_RNG_CLK_SET_25MHZ, priv->base + NPCM_RNGCS_REG);
>+#else
>+	writel(NPCM_RNG_CLK_SET_25MHZ | NPCM_RNG_ENABLE,
>+	       priv->base + NPCM_RNGCS_REG);
>+#endif

I am assuming these are safe to always set and the clock will
bein range?

Did you test without CONFIG_PM ? Looks like the ifndev should be
ifdef otherwise the enable will never be set.

Can you use a local variable for this value that is chosen by
the config instead of ifdef'ing the code?



>+
>+	ret = devm_hwrng_register(&pdev->dev, &priv->rng);
>+	if (ret) {
>+		dev_err(&pdev->dev, "Failed to register rng device: %d\n",
>+			ret);
>+		return ret;
>+	}
>+
>+	dev_set_drvdata(&pdev->dev, priv);
>+	pm_runtime_set_autosuspend_delay(&pdev->dev, 100);
>+	pm_runtime_use_autosuspend(&pdev->dev);
>+	pm_runtime_enable(&pdev->dev);
>+
>+	dev_info(&pdev->dev, "Random Number Generator Probed\n");
>+
>+	return 0;
>+}
>+
>+static int npcm_rng_remove(struct platform_device *pdev)
>+{
>+	struct npcm_rng *priv = platform_get_drvdata(pdev);
>+
>+	hwrng_unregister(&priv->rng);
>+	pm_runtime_disable(&pdev->dev);
>+	pm_runtime_set_suspended(&pdev->dev);
>+
>+	return 0;
>+}
>+
>+#ifdef CONFIG_PM
>+static int npcm_rng_runtime_suspend(struct device *dev)
>+{
>+	struct npcm_rng *priv = dev_get_drvdata(dev);
>+
>+	npcm_rng_cleanup(&priv->rng);
>+
>+	return 0;
>+}
>+
>+static int npcm_rng_runtime_resume(struct device *dev)
>+{
>+	struct npcm_rng *priv = dev_get_drvdata(dev);
>+
>+	return npcm_rng_init(&priv->rng);
>+}
>+#endif
>+
>+static const struct dev_pm_ops npcm_rng_pm_ops = {
>+	SET_RUNTIME_PM_OPS(npcm_rng_runtime_suspend,
>+			   npcm_rng_runtime_resume, NULL)
>+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>+				pm_runtime_force_resume)
>+};
>+
>+static const struct of_device_id rng_dt_id[] = {
>+	{ .compatible = "nuvoton,npcm750-rng",  },
>+	{},
>+};
>+MODULE_DEVICE_TABLE(of, rng_dt_id);
>+
>+static struct platform_driver npcm_rng_driver = {
>+	.driver = {
>+		.name		= "npcm-rng",
>+		.pm		= &npcm_rng_pm_ops,
>+		.owner		= THIS_MODULE,
>+		.of_match_table = of_match_ptr(rng_dt_id),
>+	},
>+	.probe		= npcm_rng_probe,
>+	.remove		= npcm_rng_remove,
>+};
>+
>+module_platform_driver(npcm_rng_driver);
>+
>+MODULE_DESCRIPTION("Nuvoton NPCM Random Number Generator Driver");
>+MODULE_AUTHOR("Tomer Maimon <tomer.maimon@nuvoton.com>");
>+MODULE_LICENSE("GPL v2");
>-- 
>2.18.0
>
>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver
       [not found]     ` <CAP6Zq1jXUhKjwBHiDKiKcpt_PiJQA61z2SUNg4_LztcnMMJ-Ng@mail.gmail.com>
@ 2019-09-09 15:10       ` Daniel Thompson
       [not found]         ` <CAP6Zq1jZWap+BYoEZ3Hzni-0fxa1xAw2B8tGYHxuFbP0Lz0wpw@mail.gmail.com>
  0 siblings, 1 reply; 11+ messages in thread
From: Daniel Thompson @ 2019-09-09 15:10 UTC (permalink / raw)
  To: Tomer Maimon
  Cc: mpm, herbert, Arnd Bergmann, Greg KH, Rob Herring, Mark Rutland,
	Avi Fishman, Tali Perry, Patrick Venture, Nancy Yuen,
	Benjamin Fair, sumit.garg, jens.wiklander, vkoul,
	Thomas Gleixner, Joel Stanley, devicetree,
	Linux Kernel Mailing List, linux-crypto, OpenBMC Maillist

On Mon, Sep 09, 2019 at 05:31:30PM +0300, Tomer Maimon wrote:
> Hi Daniel,
> 
> appreciate your comments and sorry for the late reply
> 
> On Thu, 29 Aug 2019 at 13:47, Daniel Thompson <daniel.thompson@linaro.org>
> wrote:
> 
> > On Wed, Aug 28, 2019 at 07:26:17PM +0300, Tomer Maimon wrote:
> > > Add Nuvoton NPCM BMC Random Number Generator(RNG) driver.
> > >
> > > Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> > > ---
> > >  drivers/char/hw_random/Kconfig    |  13 ++
> > >  drivers/char/hw_random/Makefile   |   1 +
> > >  drivers/char/hw_random/npcm-rng.c | 207 ++++++++++++++++++++++++++++++
> > >  3 files changed, 221 insertions(+)
> > >  create mode 100644 drivers/char/hw_random/npcm-rng.c
> > >
> > > diff --git a/drivers/char/hw_random/npcm-rng.c
> > b/drivers/char/hw_random/npcm-rng.c
> > > new file mode 100644
> > > index 000000000000..5b4b1b6cb362
> > > --- /dev/null
> > > +++ b/drivers/char/hw_random/npcm-rng.c
> > > @@ -0,0 +1,207 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +// Copyright (c) 2019 Nuvoton Technology corporation.
> > > +
> > > +#include <linux/kernel.h>
> > > +#include <linux/module.h>
> > > +#include <linux/io.h>
> > > +#include <linux/iopoll.h>
> > > +#include <linux/init.h>
> > > +#include <linux/random.h>
> > > +#include <linux/err.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/hw_random.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/of_irq.h>
> > > +#include <linux/pm_runtime.h>
> > > +
> > > +#define NPCM_RNGCS_REG               0x00    /* Control and status
> > register */
> > > +#define NPCM_RNGD_REG                0x04    /* Data register */
> > > +#define NPCM_RNGMODE_REG     0x08    /* Mode register */
> > > +
> > > +#define NPCM_RNG_CLK_SET_25MHZ       GENMASK(4, 3) /* 20-25 MHz */
> > > +#define NPCM_RNG_DATA_VALID  BIT(1)
> > > +#define NPCM_RNG_ENABLE              BIT(0)
> > > +#define NPCM_RNG_M1ROSEL     BIT(1)
> > > +
> > > +#define NPCM_RNG_TIMEOUT_POLL        20
> >
> > Might be better to define this in real-world units (such as
> > milliseconds) since the timeout is effectively the longest time the
> > hardware can take to generate 4 bytes.
> >
> > > +
> > > +#define to_npcm_rng(p)       container_of(p, struct npcm_rng, rng)
> > > +
> > > +struct npcm_rng {
> > > +     void __iomem *base;
> > > +     struct hwrng rng;
> > > +};
> > > +
> > > +static int npcm_rng_init(struct hwrng *rng)
> > > +{
> > > +     struct npcm_rng *priv = to_npcm_rng(rng);
> > > +     u32 val;
> > > +
> > > +     val = readl(priv->base + NPCM_RNGCS_REG);
> > > +     val |= NPCM_RNG_ENABLE;
> > > +     writel(val, priv->base + NPCM_RNGCS_REG);
> > > +
> > > +     return 0;
> > > +}
> > > +
> > > +static void npcm_rng_cleanup(struct hwrng *rng)
> > > +{
> > > +     struct npcm_rng *priv = to_npcm_rng(rng);
> > > +     u32 val;
> > > +
> > > +     val = readl(priv->base + NPCM_RNGCS_REG);
> > > +     val &= ~NPCM_RNG_ENABLE;
> > > +     writel(val, priv->base + NPCM_RNGCS_REG);
> > > +}
> > > +
> > > +static bool npcm_rng_wait_ready(struct hwrng *rng, bool wait)
> > > +{
> > > +     struct npcm_rng *priv = to_npcm_rng(rng);
> > > +     int timeout_cnt = 0;
> > > +     int ready;
> > > +
> > > +     ready = readl(priv->base + NPCM_RNGCS_REG) & NPCM_RNG_DATA_VALID;
> > > +     while ((ready == 0) && (timeout_cnt < NPCM_RNG_TIMEOUT_POLL)) {
> > > +             usleep_range(500, 1000);
> > > +             ready = readl(priv->base + NPCM_RNGCS_REG) &
> > > +                     NPCM_RNG_DATA_VALID;
> > > +             timeout_cnt++;
> > > +     }
> > > +
> > > +     return !!ready;
> > > +}
> >
> > This looks like an open-coded version of readl_poll_timeout()... better
> > to use the library function.
> >
> > Also the sleep looks a bit long to me. What is the generation rate of
> > the peripheral? Most RNG drivers have short intervals between data
> > generation so they use delays rather than sleeps (a.k.a.
> > readl_poll_timeout_atomic() ).
>
> the HWRNG generate byte of random data in a few milliseconds so it is
> better to use the sleep command.

That's fine, just use readl_poll_timeout() then.


> > > +
> > > +static int npcm_rng_read(struct hwrng *rng, void *buf, size_t max, bool
> > wait)
> > > +{
> > > +     struct npcm_rng *priv = to_npcm_rng(rng);
> > > +     int retval = 0;
> > > +
> > > +     pm_runtime_get_sync((struct device *)priv->rng.priv);
> > > +
> > > +     while (max >= sizeof(u32)) {
> > > +             if (!npcm_rng_wait_ready(rng, wait))
> > > +                     break;
> >
> > The code as currently written does not honour the wait parameter (e.g.
> > it sleeps even when wait is false).
> >
> >
> > > +
> > > +             *(u32 *)buf = readl(priv->base + NPCM_RNGD_REG);
> > > +             retval += sizeof(u32);
> > > +             buf += sizeof(u32);
> > > +             max -= sizeof(u32);
> > > +     }
> > > +
> > > +     pm_runtime_mark_last_busy((struct device *)priv->rng.priv);
> > > +     pm_runtime_put_sync_autosuspend((struct device *)priv->rng.priv);
> > > +
> > > +     return retval || !wait ? retval : -EIO;
> > > +}
> > > +
> > > +static int npcm_rng_probe(struct platform_device *pdev)
> > > +{
> > > +     struct npcm_rng *priv;
> > > +     struct resource *res;
> > > +     u32 quality;
> > > +     int ret;
> > > +
> > > +     priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > > +     if (!priv)
> > > +             return -ENOMEM;
> > > +
> > > +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > +     priv->base = devm_ioremap_resource(&pdev->dev, res);
> > > +     if (IS_ERR(priv->base))
> > > +             return PTR_ERR(priv->base);
> > > +
> > > +     priv->rng.name = pdev->name;
> > > +#ifndef CONFIG_PM
> > > +     priv->rng.init = npcm_rng_init;
> > > +     priv->rng.cleanup = npcm_rng_cleanup;
> > > +#endif
> > > +     priv->rng.read = npcm_rng_read;
> > > +     priv->rng.priv = (unsigned long)&pdev->dev;
> > > +     if (of_property_read_u32(pdev->dev.of_node, "quality", &quality))
> > > +             priv->rng.quality = 1000;
> > > +     else
> > > +             priv->rng.quality = quality;
> > > +
> > > +     writel(NPCM_RNG_M1ROSEL, priv->base + NPCM_RNGMODE_REG);
> > > +#ifndef CONFIG_PM
> > > +     writel(NPCM_RNG_CLK_SET_25MHZ, priv->base + NPCM_RNGCS_REG);
> > > +#else
> > > +     writel(NPCM_RNG_CLK_SET_25MHZ | NPCM_RNG_ENABLE,
> > > +            priv->base + NPCM_RNGCS_REG);
> > > +#endif
> >
> > If this initialization was moved to npcm_rng_init() then there would be
> > no need for the additional ifdefing. It would also get rid of the
> > (potentially slow) readl calls on the PM wakeup path.
> >
> 
> But when the Kernel have PM configuration than the priv->rng.init is not
> set and
> *add_early_randomness* function is called. for the *add_early_randomness*
> success
> the hwrng need to enabled in the probe.

Sorry but I don't understand this reply.

When CONFIG_PM is enabled then the probe function does not currently set
NPCM_RNG_ENABLE; instead is relies on npcm_rng_init() being called by
the PM logic (as part of pm_runtime_get_sync() ).

Given the code *already* relies on npcm_rng_init() being called by the
PM logic why does it matter if additional init is put there?


Daniel.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver
       [not found]         ` <CAP6Zq1jZWap+BYoEZ3Hzni-0fxa1xAw2B8tGYHxuFbP0Lz0wpw@mail.gmail.com>
@ 2019-09-10 11:29           ` Daniel Thompson
  0 siblings, 0 replies; 11+ messages in thread
From: Daniel Thompson @ 2019-09-10 11:29 UTC (permalink / raw)
  To: Tomer Maimon
  Cc: mpm, herbert, Arnd Bergmann, Greg KH, Rob Herring, Mark Rutland,
	Avi Fishman, Tali Perry, Patrick Venture, Nancy Yuen,
	Benjamin Fair, sumit.garg, jens.wiklander, vkoul,
	Thomas Gleixner, Joel Stanley, devicetree,
	Linux Kernel Mailing List, linux-crypto, OpenBMC Maillist

On Tue, Sep 10, 2019 at 01:52:35PM +0300, Tomer Maimon wrote:
> Hi Daniel,
> 
> Thanks for your prompt reply,
> 
> 
> 
> On Mon, 9 Sep 2019 at 18:10, Daniel Thompson <daniel.thompson@linaro.org>
> wrote:
> 
> > On Mon, Sep 09, 2019 at 05:31:30PM +0300, Tomer Maimon wrote:
> > > Hi Daniel,
> > >
> > > appreciate your comments and sorry for the late reply
> > >
> > > On Thu, 29 Aug 2019 at 13:47, Daniel Thompson <
> > daniel.thompson@linaro.org>
> > > wrote:
> > >
> > > > On Wed, Aug 28, 2019 at 07:26:17PM +0300, Tomer Maimon wrote:
> > > > > Add Nuvoton NPCM BMC Random Number Generator(RNG) driver.
> > > > >
> > > > > Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> > > > > ---
> > > > >  drivers/char/hw_random/Kconfig    |  13 ++
> > > > >  drivers/char/hw_random/Makefile   |   1 +
> > > > >  drivers/char/hw_random/npcm-rng.c | 207
> > ++++++++++++++++++++++++++++++
> > > > >  3 files changed, 221 insertions(+)
> > > > >  create mode 100644 drivers/char/hw_random/npcm-rng.c
> > > > >
> > > > > diff --git a/drivers/char/hw_random/npcm-rng.c
> > > > b/drivers/char/hw_random/npcm-rng.c
> > > > > new file mode 100644
> > > > > index 000000000000..5b4b1b6cb362
> > > > > --- /dev/null
> > > > > +++ b/drivers/char/hw_random/npcm-rng.c
> > > > > @@ -0,0 +1,207 @@
> > > > > +// SPDX-License-Identifier: GPL-2.0
> > > > > +// Copyright (c) 2019 Nuvoton Technology corporation.
> > > > > +
> > > > > +#include <linux/kernel.h>
> > > > > +#include <linux/module.h>
> > > > > +#include <linux/io.h>
> > > > > +#include <linux/iopoll.h>
> > > > > +#include <linux/init.h>
> > > > > +#include <linux/random.h>
> > > > > +#include <linux/err.h>
> > > > > +#include <linux/platform_device.h>
> > > > > +#include <linux/hw_random.h>
> > > > > +#include <linux/delay.h>
> > > > > +#include <linux/of_irq.h>
> > > > > +#include <linux/pm_runtime.h>
> > > > > +
> > > > > +#define NPCM_RNGCS_REG               0x00    /* Control and status
> > > > register */
> > > > > +#define NPCM_RNGD_REG                0x04    /* Data register */
> > > > > +#define NPCM_RNGMODE_REG     0x08    /* Mode register */
> > > > > +
> > > > > +#define NPCM_RNG_CLK_SET_25MHZ       GENMASK(4, 3) /* 20-25 MHz */
> > > > > +#define NPCM_RNG_DATA_VALID  BIT(1)
> > > > > +#define NPCM_RNG_ENABLE              BIT(0)
> > > > > +#define NPCM_RNG_M1ROSEL     BIT(1)
> > > > > +
> > > > > +#define NPCM_RNG_TIMEOUT_POLL        20
> > > >
> > > > Might be better to define this in real-world units (such as
> > > > milliseconds) since the timeout is effectively the longest time the
> > > > hardware can take to generate 4 bytes.
> > > >
> > > > > +
> > > > > +#define to_npcm_rng(p)       container_of(p, struct npcm_rng, rng)
> > > > > +
> > > > > +struct npcm_rng {
> > > > > +     void __iomem *base;
> > > > > +     struct hwrng rng;
> > > > > +};
> > > > > +
> > > > > +static int npcm_rng_init(struct hwrng *rng)
> > > > > +{
> > > > > +     struct npcm_rng *priv = to_npcm_rng(rng);
> > > > > +     u32 val;
> > > > > +
> > > > > +     val = readl(priv->base + NPCM_RNGCS_REG);
> > > > > +     val |= NPCM_RNG_ENABLE;
> > > > > +     writel(val, priv->base + NPCM_RNGCS_REG);
> > > > > +
> > > > > +     return 0;
> > > > > +}
> > > > > +
> > > > > +static void npcm_rng_cleanup(struct hwrng *rng)
> > > > > +{
> > > > > +     struct npcm_rng *priv = to_npcm_rng(rng);
> > > > > +     u32 val;
> > > > > +
> > > > > +     val = readl(priv->base + NPCM_RNGCS_REG);
> > > > > +     val &= ~NPCM_RNG_ENABLE;
> > > > > +     writel(val, priv->base + NPCM_RNGCS_REG);
> > > > > +}
> > > > > +
> > > > > +static bool npcm_rng_wait_ready(struct hwrng *rng, bool wait)
> > > > > +{
> > > > > +     struct npcm_rng *priv = to_npcm_rng(rng);
> > > > > +     int timeout_cnt = 0;
> > > > > +     int ready;
> > > > > +
> > > > > +     ready = readl(priv->base + NPCM_RNGCS_REG) &
> > NPCM_RNG_DATA_VALID;
> > > > > +     while ((ready == 0) && (timeout_cnt < NPCM_RNG_TIMEOUT_POLL)) {
> > > > > +             usleep_range(500, 1000);
> > > > > +             ready = readl(priv->base + NPCM_RNGCS_REG) &
> > > > > +                     NPCM_RNG_DATA_VALID;
> > > > > +             timeout_cnt++;
> > > > > +     }
> > > > > +
> > > > > +     return !!ready;
> > > > > +}
> > > >
> > > > This looks like an open-coded version of readl_poll_timeout()... better
> > > > to use the library function.
> > > >
> > > > Also the sleep looks a bit long to me. What is the generation rate of
> > > > the peripheral? Most RNG drivers have short intervals between data
> > > > generation so they use delays rather than sleeps (a.k.a.
> > > > readl_poll_timeout_atomic() ).
> > >
> > > the HWRNG generate byte of random data in a few milliseconds so it is
> > > better to use the sleep command.
> >
> > That's fine, just use readl_poll_timeout() then.
> >
> >
> > > > > +
> > > > > +static int npcm_rng_read(struct hwrng *rng, void *buf, size_t max,
> > bool
> > > > wait)
> > > > > +{
> > > > > +     struct npcm_rng *priv = to_npcm_rng(rng);
> > > > > +     int retval = 0;
> > > > > +
> > > > > +     pm_runtime_get_sync((struct device *)priv->rng.priv);
> > > > > +
> > > > > +     while (max >= sizeof(u32)) {
> > > > > +             if (!npcm_rng_wait_ready(rng, wait))
> > > > > +                     break;
> > > >
> > > > The code as currently written does not honour the wait parameter (e.g.
> > > > it sleeps even when wait is false).
> > > >
> > > >
> > > > > +
> > > > > +             *(u32 *)buf = readl(priv->base + NPCM_RNGD_REG);
> > > > > +             retval += sizeof(u32);
> > > > > +             buf += sizeof(u32);
> > > > > +             max -= sizeof(u32);
> > > > > +     }
> > > > > +
> > > > > +     pm_runtime_mark_last_busy((struct device *)priv->rng.priv);
> > > > > +     pm_runtime_put_sync_autosuspend((struct device
> > *)priv->rng.priv);
> > > > > +
> > > > > +     return retval || !wait ? retval : -EIO;
> > > > > +}
> > > > > +
> > > > > +static int npcm_rng_probe(struct platform_device *pdev)
> > > > > +{
> > > > > +     struct npcm_rng *priv;
> > > > > +     struct resource *res;
> > > > > +     u32 quality;
> > > > > +     int ret;
> > > > > +
> > > > > +     priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > > > > +     if (!priv)
> > > > > +             return -ENOMEM;
> > > > > +
> > > > > +     res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > > > +     priv->base = devm_ioremap_resource(&pdev->dev, res);
> > > > > +     if (IS_ERR(priv->base))
> > > > > +             return PTR_ERR(priv->base);
> > > > > +
> > > > > +     priv->rng.name = pdev->name;
> > > > > +#ifndef CONFIG_PM
> > > > > +     priv->rng.init = npcm_rng_init;
> > > > > +     priv->rng.cleanup = npcm_rng_cleanup;
> > > > > +#endif
> > > > > +     priv->rng.read = npcm_rng_read;
> > > > > +     priv->rng.priv = (unsigned long)&pdev->dev;
> > > > > +     if (of_property_read_u32(pdev->dev.of_node, "quality",
> > &quality))
> > > > > +             priv->rng.quality = 1000;
> > > > > +     else
> > > > > +             priv->rng.quality = quality;
> > > > > +
> > > > > +     writel(NPCM_RNG_M1ROSEL, priv->base + NPCM_RNGMODE_REG);
> > > > > +#ifndef CONFIG_PM
> > > > > +     writel(NPCM_RNG_CLK_SET_25MHZ, priv->base + NPCM_RNGCS_REG);
> > > > > +#else
> > > > > +     writel(NPCM_RNG_CLK_SET_25MHZ | NPCM_RNG_ENABLE,
> > > > > +            priv->base + NPCM_RNGCS_REG);
> > > > > +#endif
> > > >
> > > > If this initialization was moved to npcm_rng_init() then there would be
> > > > no need for the additional ifdefing. It would also get rid of the
> > > > (potentially slow) readl calls on the PM wakeup path.
> > > >
> > >
> > > But when the Kernel have PM configuration than the priv->rng.init is not
> > > set and
> > > *add_early_randomness* function is called. for the *add_early_randomness*
> > > success
> > > the hwrng need to enabled in the probe.
> >
> > Sorry but I don't understand this reply.
> >
> > When CONFIG_PM is enabled then the probe function does not currently set
> > NPCM_RNG_ENABLE; instead is relies on npcm_rng_init() being called by
> >
> 
> Sorry maybe I miss understood, but when the  CONFIG_PM enabled so the
> NPCM_RNG_ENABLE sets (the code use ifndef and not ifdef)
> *#ifndef CONFIG_PM*
>        writel(NPCM_RNG_CLK_SET_25MHZ, priv->base + NPCM_RNGCS_REG);
> #else (*CONFIG_PM enabled*)
>        writel(NPCM_RNG_CLK_SET_25MHZ | NPCM_RNG_ENABLE,
>               priv->base + NPCM_RNGCS_REG);
> #endif
> 
> And the hwrng needed to be enabled to run *add_early_randomness *function
> successfully.
> 
> If the hwrng driver will relay on PM logic to enable the hwrng will be
> disable when *add_early_randomness *function is called.
> 
> the PM logic (as part of pm_runtime_get_sync() ).

I ended up reading my mail out of order and replied to the v2 patch.

The question is *why* the driver doesn't resume properly when adding
early randomness! I think it is because the hwrng_register() is being
called before PM runtime is enabled.


Daniel.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation
  2019-08-12 23:36   ` Rob Herring
@ 2019-08-18  7:26     ` Avi Fishman
  0 siblings, 0 replies; 11+ messages in thread
From: Avi Fishman @ 2019-08-18  7:26 UTC (permalink / raw)
  To: Rob Herring
  Cc: Tomer Maimon, mpm, herbert, Arnd Bergmann, Greg Kroah-Hartman,
	Mark Rutland, Tali Perry, Patrick Venture, Nancy Yuen,
	Benjamin Fair, sumit.garg, jens.wiklander, vkoul,
	Thomas Gleixner, Joel Stanley, devicetree,
	Linux Kernel Mailing List, linux-crypto, OpenBMC Maillist

On Tue, Aug 13, 2019 at 2:36 AM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jul 22, 2019 at 06:02:40PM +0300, Tomer Maimon wrote:
> > Added device tree binding documentation for Nuvoton BMC
> > NPCM Random Number Generator (RNG).
> >
> > Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> > ---
> >  .../bindings/rng/nuvoton,npcm-rng.txt           | 17 +++++++++++++++++
> >  1 file changed, 17 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> >
> > diff --git a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> > new file mode 100644
> > index 000000000000..a697b4425fb3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> > @@ -0,0 +1,17 @@
> > +NPCM SoC Random Number Generator
> > +
> > +Required properties:
> > +- compatible  : "nuvoton,npcm750-rng" for the NPCM7XX BMC.
> > +- reg         : Specifies physical base address and size of the registers.
> > +
> > +Optional property:
> > +- quality : estimated number of bits of true entropy per 1024 bits
> > +                     read from the rng.
> > +                     If this property is not defined, it defaults to 1000.
>
> This would need a vendor prefix, however, I think it should be implied
> by the compatible string. It is fixed per SoC, right?

Tomer is on vacation, so I answer instead:
This value is the same for all our SoC flavor that contains this RNG HW.


-- 
Regards,
Avi

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation
  2019-07-22 15:02 ` [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation Tomer Maimon
@ 2019-08-12 23:36   ` Rob Herring
  2019-08-18  7:26     ` Avi Fishman
  0 siblings, 1 reply; 11+ messages in thread
From: Rob Herring @ 2019-08-12 23:36 UTC (permalink / raw)
  To: Tomer Maimon
  Cc: mpm, herbert, arnd, gregkh, mark.rutland, avifishman70,
	tali.perry1, venture, yuenn, benjaminfair, sumit.garg,
	jens.wiklander, vkoul, tglx, joel, devicetree, linux-kernel,
	linux-crypto, openbmc

On Mon, Jul 22, 2019 at 06:02:40PM +0300, Tomer Maimon wrote:
> Added device tree binding documentation for Nuvoton BMC
> NPCM Random Number Generator (RNG).
> 
> Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
> ---
>  .../bindings/rng/nuvoton,npcm-rng.txt           | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> 
> diff --git a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> new file mode 100644
> index 000000000000..a697b4425fb3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
> @@ -0,0 +1,17 @@
> +NPCM SoC Random Number Generator
> +
> +Required properties:
> +- compatible  : "nuvoton,npcm750-rng" for the NPCM7XX BMC.
> +- reg         : Specifies physical base address and size of the registers.
> +
> +Optional property:
> +- quality : estimated number of bits of true entropy per 1024 bits
> +			read from the rng.
> +			If this property is not defined, it defaults to 1000.

This would need a vendor prefix, however, I think it should be implied 
by the compatible string. It is fixed per SoC, right?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation
  2019-07-22 15:02 [PATCH v1 0/2] hwrng: npcm: add NPCM RNG driver support Tomer Maimon
@ 2019-07-22 15:02 ` Tomer Maimon
  2019-08-12 23:36   ` Rob Herring
  0 siblings, 1 reply; 11+ messages in thread
From: Tomer Maimon @ 2019-07-22 15:02 UTC (permalink / raw)
  To: mpm, herbert, arnd, gregkh, robh+dt, mark.rutland, avifishman70,
	tali.perry1, venture, yuenn, benjaminfair, sumit.garg,
	jens.wiklander, vkoul, tglx, joel
  Cc: devicetree, linux-kernel, linux-crypto, openbmc, Tomer Maimon

Added device tree binding documentation for Nuvoton BMC
NPCM Random Number Generator (RNG).

Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
---
 .../bindings/rng/nuvoton,npcm-rng.txt           | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt

diff --git a/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
new file mode 100644
index 000000000000..a697b4425fb3
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/nuvoton,npcm-rng.txt
@@ -0,0 +1,17 @@
+NPCM SoC Random Number Generator
+
+Required properties:
+- compatible  : "nuvoton,npcm750-rng" for the NPCM7XX BMC.
+- reg         : Specifies physical base address and size of the registers.
+
+Optional property:
+- quality : estimated number of bits of true entropy per 1024 bits
+			read from the rng.
+			If this property is not defined, it defaults to 1000.
+
+Example:
+
+rng: rng@f000b000 {
+	compatible = "nuvoton,npcm750-rng";
+	reg = <0xf000b000 0x8>;
+};
-- 
2.18.0


^ permalink raw reply related	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-09-10 11:29 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-28 16:26 [PATCH v1 0/2] hwrng: npcm: add NPCM RNG driver support Tomer Maimon
2019-08-28 16:26 ` [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation Tomer Maimon
2019-08-29 10:49   ` Daniel Thompson
2019-08-28 16:26 ` [PATCH v1 2/2] hwrng: npcm: add NPCM RNG driver Tomer Maimon
2019-08-29 10:47   ` Daniel Thompson
     [not found]     ` <CAP6Zq1jXUhKjwBHiDKiKcpt_PiJQA61z2SUNg4_LztcnMMJ-Ng@mail.gmail.com>
2019-09-09 15:10       ` Daniel Thompson
     [not found]         ` <CAP6Zq1jZWap+BYoEZ3Hzni-0fxa1xAw2B8tGYHxuFbP0Lz0wpw@mail.gmail.com>
2019-09-10 11:29           ` Daniel Thompson
2019-08-30 22:47 ` Milton Miller II
  -- strict thread matches above, loose matches on Subject: below --
2019-07-22 15:02 [PATCH v1 0/2] hwrng: npcm: add NPCM RNG driver support Tomer Maimon
2019-07-22 15:02 ` [PATCH v1 1/2] dt-binding: hwrng: add NPCM RNG documentation Tomer Maimon
2019-08-12 23:36   ` Rob Herring
2019-08-18  7:26     ` Avi Fishman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).