[PATCH 1/2] hwrng: Add support for ASPEED RNG

[PATCH 1/2] hwrng: Add support for ASPEED RNG

[Oscar A Perez]

This minimal driver adds support for the Hardware Random Number Generator
that comes with the AST2400/AST2500/AST2600 SOCs from AspeedTech.

The HRNG on these SOCs uses Ring Oscillators working together to generate
a stream of random bits that can be read by the platform via a 32bit data
register.

Signed-off-by: Oscar A Perez <linux@neuralgames.com>
---
 .../devicetree/bindings/rng/aspeed-rng.yaml   | 90 +++++++++++++++++++
 1 file changed, 90 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/aspeed-rng.yaml

diff --git a/Documentation/devicetree/bindings/rng/aspeed-rng.yaml b/Documentation/devicetree/bindings/rng/aspeed-rng.yaml
new file mode 100644
index 000000000000..06070ebe1c33
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/aspeed-rng.yaml
@@ -0,0 +1,90 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/rng/aspeed-rng.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+
+title: Bindings for Aspeed Hardware Random Number Generator
+
+
+maintainers:
+  - Oscar A Perez <linux@neuralgames.com>
+
+
+description: |
+  The HRNG on the AST2400/AST2500/AST2600 SOCs from AspeedTech  uses four Ring
+  Oscillators working together to generate a stream of random bits that can be
+  read by the platform via a 32bit data register every one microsecond.
+  All the platform has to do is to provide to the driver the 'quality' entropy
+  value, the  'mode' in which the combining  ROs will generate the  stream  of
+  random bits and, the 'period' value that is used as a wait-time between reads
+  from the 32bit data register.
+
+
+properties:
+  compatible:
+    oneOf:
+      - items:
+          - enum:
+              - aspeed,ast2400-rng
+              - aspeed,ast2500-rng
+              - aspeed,ast2600-rng
+
+
+  reg:
+    description:
+      Base address and length of the register set of this block.
+      Currently 'reg' must be eight bytes wide and 32-bit aligned.
+
+    maxItems: 1
+
+
+  period:
+    description:
+      Wait time in microseconds to be used between reads.
+      The RNG on these Aspeed SOCs generates 32bit of random data
+      every one microsecond. Choose between 1 and n microseconds.
+
+    maxItems: 1
+
+
+  mode:
+    description:
+      One of the eight modes in which the four internal ROs (Ring
+      Oscillators)  are combined to generate a stream  of random
+      bits. The default mode is seven which is the default method
+      of combining RO random bits on these Aspeed SOCs.
+
+    maxItems: 1
+
+
+  quality:
+    description:
+      Estimated number of bits of entropy per 1024 bits read from
+      the RNG.  Note that the default quality is zero which stops
+      this HRNG from automatically filling the kernel's entropy
+      pool with data.
+
+    maxItems: 1
+
+
+required:
+  - compatible
+  - reg
+  - period
+  - quality
+
+
+examples:
+  - |
+    rng: hwrng@1e6e2074 {
+         compatible = "aspeed,ast2500-rng";
+         reg = <0x1e6e2074 0x8>;
+         period = <4>;
+         quality = <128>;
+         mode = <0x7>;
+    };
+
+
+...
-- 
2.17.1

[PATCH 2/2] hwrng: Add support for ASPEED RNG

[Oscar A Perez]

This minimal driver adds support for the Hardware Random Number Generator
that comes with the AST2400/AST2500/AST2600 SOCs from AspeedTech.

The HRNG on these SOCs uses Ring Oscillators working together to generate
a stream of random bits that can be read by the platform via a 32bit data
register.

Signed-off-by: Oscar A Perez <linux@neuralgames.com>
---
 drivers/char/hw_random/Kconfig      |  13 ++
 drivers/char/hw_random/Makefile     |   1 +
 drivers/char/hw_random/aspeed-rng.c | 294 ++++++++++++++++++++++++++++
 3 files changed, 308 insertions(+)
 create mode 100644 drivers/char/hw_random/aspeed-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 8486c29d8324..d4275e1cbce0 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -466,6 +466,19 @@ config HW_RANDOM_NPCM
 
  	  If unsure, say Y.
 
+config HW_RANDOM_ASPEED
+	tristate "Aspeed Hardware Random Number Generator support"
+	depends on ARCH_ASPEED || COMPILE_TEST
+	default HW_RANDOM
+	help
+	  If you say yes to this option, support will be included for the
+	  Hardware Random Number Generator that comes with Aspeed SoCs.
+
+	  This driver can also be built as a module.  If so, the module
+	  will be called aspeed-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 a7801b49ce6c..ff70994efde9 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -41,3 +41,4 @@ 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
+obj-$(CONFIG_HW_RANDOM_ASPEED) += aspeed-rng.o
diff --git a/drivers/char/hw_random/aspeed-rng.c b/drivers/char/hw_random/aspeed-rng.c
new file mode 100644
index 000000000000..794d8e044bbe
--- /dev/null
+++ b/drivers/char/hw_random/aspeed-rng.c
@@ -0,0 +1,294 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * drivers/char/hw_random/aspeed-rng.c
+ *
+ * Copyright (C) 2020 Oscar A. Perez <linux@neuralgames.com>
+ *
+ * Derived from drivers/char/hw_random/timeriomem-rng.c
+ *   Copyright (C) 2009 Alexander Clouter <alex@digriz.org.uk>
+ *
+ *   Derived from drivers/char/hw_random/omap-rng.c
+ *     Copyright 2005 (c) MontaVista Software, Inc.
+ *     Author: Deepak Saxena <dsaxena@plexity.net>
+ *
+ * Overview:
+ *   This driver is meant for SOCs like the AST2400/AST2500/AST2600 from
+ *   AspeedTech that integrate non-deterministic Random Number Generators
+ *   based on Ring Oscillators (a.k.a. RO-based HRNG).
+ *   According to AspeedTech, the random number generators on these SOCs
+ *   contain four free-run ROs that can be configured in eight different
+ *   modes. The modes are just logic combinations of these four ROs that
+ *   together generate a stream of random bits. These random bits are read
+ *   from a 32bit data register and, new random data becomes available on
+ *   this 32bit data register every one microsecond.
+ *
+ *   All the platform has to do is to provide to the driver the 'quality'
+ *   entropy value, the 'mode' in which the combining ROs will generate
+ *   the stream of random bits and, the 'period' value that is used as a
+ *   wait-time between reads from the 32bit data register.
+ *
+ */
+
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/hrtimer.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/ktime.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/time.h>
+
+#define HRNG_CONTROL_REG_OFFSET		0x00
+#define HRNG_OUTPUT_DATA_OFFSET		0x04
+#define HRNG_CONTROL_ENABLE		BIT(0)
+#define HRNG_CONTROL_MODE_MASK		GENMASK(3, 1)
+#define HRNG_CONTROL_MODE_SHIFT		1
+
+struct aspeed_hrng_data {
+	void __iomem            *address;
+
+	/* measures in usecs */
+	unsigned int            period;
+
+	/* bits of entropy per 1024 bits read */
+	unsigned int            quality;
+};
+
+struct aspeed_hrng_private {
+	struct device		*dev;
+	void __iomem		*io_base;
+	ktime_t			period;
+	unsigned int		present:1;
+	unsigned int		ro_mode:7;
+
+	struct hrtimer		timer;
+	struct completion	completion;
+
+	struct hwrng		rng_ops;
+};
+
+static int aspeed_hrng_read(struct hwrng *hwrng, void *data,
+			    size_t max, bool wait)
+{
+	struct aspeed_hrng_private
+		*priv =	container_of(hwrng,
+				     struct aspeed_hrng_private,
+				     rng_ops);
+	int retval = 0;
+	int period_us = ktime_to_us(priv->period);
+
+	/*
+	 * There may not have been enough time for new data to be generated
+	 * since the last request.  If the caller doesn't want to wait, let them
+	 * bail out.  Otherwise, wait for the completion.  If the new data has
+	 * already been generated, the completion should already be available.
+	 */
+	if (!wait && !priv->present)
+		return 0;
+
+	wait_for_completion(&priv->completion);
+
+	do {
+		/*
+		 * After the first read, all additional reads will need to wait
+		 * for the RNG to generate new data.  Since the period can have
+		 * a wide range of values (1us to 1s have been observed), allow
+		 * for 1% tolerance in the sleep time rather than a fixed value.
+		 */
+		if (retval > 0)
+			usleep_range(period_us,
+				     period_us + min(1, period_us / 100));
+
+		*(u32 *)data = readl(priv->io_base + HRNG_OUTPUT_DATA_OFFSET);
+
+		retval += sizeof(u32);
+		data += sizeof(u32);
+		max -= sizeof(u32);
+	} while (wait && max >= sizeof(u32));
+
+	/*
+	 * Block any new callers until the RNG has had time to generate new
+	 * data.
+	 */
+	priv->present = 0;
+	reinit_completion(&priv->completion);
+	hrtimer_forward_now(&priv->timer, priv->period);
+	hrtimer_restart(&priv->timer);
+
+	return retval;
+}
+
+static enum hrtimer_restart aspeed_hrng_trigger(struct hrtimer *timer)
+{
+	struct aspeed_hrng_private *priv =
+			container_of(timer, struct aspeed_hrng_private, timer);
+
+	priv->present = 1;
+	complete(&priv->completion);
+
+	return HRTIMER_NORESTART;
+}
+
+static void aspeed_hrng_enable(struct aspeed_hrng_private *priv)
+{
+	u32 regval;
+
+	regval = readl(priv->io_base + HRNG_CONTROL_REG_OFFSET);
+	regval &= ~HRNG_CONTROL_ENABLE;
+	writel(regval, priv->io_base + HRNG_CONTROL_REG_OFFSET);
+}
+
+static void aspeed_hrng_disable(struct aspeed_hrng_private *priv)
+{
+	u32 regval;
+
+	regval = readl(priv->io_base + HRNG_CONTROL_REG_OFFSET);
+	regval |= HRNG_CONTROL_ENABLE;
+	writel(regval, priv->io_base + HRNG_CONTROL_REG_OFFSET);
+}
+
+static void aspeed_hrng_set_mode(struct aspeed_hrng_private *priv)
+{
+	u32 regval;
+
+	aspeed_hrng_disable(priv);
+	regval = readl(priv->io_base + HRNG_CONTROL_REG_OFFSET);
+	regval &= ~HRNG_CONTROL_MODE_MASK;
+	regval |= (priv->ro_mode << HRNG_CONTROL_MODE_SHIFT) &
+		  HRNG_CONTROL_MODE_MASK;
+	writel(regval, priv->io_base + HRNG_CONTROL_REG_OFFSET);
+	aspeed_hrng_enable(priv);
+}
+
+static int aspeed_hrng_probe(struct platform_device *pdev)
+{
+	struct aspeed_hrng_data *pdata = pdev->dev.platform_data;
+	struct aspeed_hrng_private *priv;
+	struct resource *res;
+	int err = 0;
+	int period;
+
+	if (!pdev->dev.of_node && !pdata) {
+		dev_err(&pdev->dev, "aspeed_hrng_data is missing\n");
+		return -EINVAL;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res)
+		return -ENXIO;
+
+	if (res->start % 4 != 0 || resource_size(res) != 8) {
+		dev_err(&pdev->dev,
+			"address space must be eight bytes wide and 32-bit aligned\n");
+		return -EINVAL;
+	}
+
+	/* Allocate memory for the device structure (and zero it) */
+	priv = devm_kzalloc(&pdev->dev,
+			    sizeof(struct aspeed_hrng_private), GFP_KERNEL);
+	if (!priv)
+		return -ENOMEM;
+
+	platform_set_drvdata(pdev, priv);
+
+	priv->dev = &pdev->dev;
+
+	if (pdev->dev.of_node) {
+		int i;
+
+		if (!of_property_read_u32(pdev->dev.of_node, "period", &i)) {
+			period = i;
+		} else {
+			dev_err(&pdev->dev, "missing period property\n");
+			return -EINVAL;
+		}
+
+		if (!of_property_read_u32(pdev->dev.of_node, "quality", &i)) {
+			priv->rng_ops.quality = i;
+		} else {
+			dev_info(&pdev->dev,
+				 "missing quality property. Using default value of 0\n");
+			priv->rng_ops.quality = 0;
+		}
+
+		if (!of_property_read_u32(pdev->dev.of_node, "mode", &i)) {
+			priv->ro_mode = (i & 0x7);
+		} else {
+			dev_info(&pdev->dev,
+				 "missing mode property. Using default mode 0x7\n");
+			priv->ro_mode = 0x7;
+		}
+	} else {
+		period = pdata->period;
+		priv->rng_ops.quality = pdata->quality;
+		priv->ro_mode = 0x7; /* default mode for the Ring Oscillators */
+	}
+
+	priv->period = ns_to_ktime(period * NSEC_PER_USEC);
+	init_completion(&priv->completion);
+	hrtimer_init(&priv->timer, CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
+	priv->timer.function = aspeed_hrng_trigger;
+
+	priv->rng_ops.name = dev_name(&pdev->dev);
+	priv->rng_ops.read = aspeed_hrng_read;
+
+	priv->io_base = devm_ioremap_resource(&pdev->dev, res);
+	if (IS_ERR(priv->io_base))
+		return PTR_ERR(priv->io_base);
+
+	/* By default, RO RNG is set to mode 7 and RNG is enabled */
+	dev_dbg(&pdev->dev, "setting RO RNG to mode %u\n", priv->ro_mode);
+	aspeed_hrng_set_mode(priv);
+
+	/* Assume random data is already available. */
+	priv->present = 1;
+	complete(&priv->completion);
+
+	err = hwrng_register(&priv->rng_ops);
+	if (err) {
+		dev_err(&pdev->dev, "problem registering\n");
+		return err;
+	}
+
+	dev_info(&pdev->dev, "RO-based RNG registered: mode %u @ %dus\n",
+		 priv->ro_mode, period);
+
+	return 0;
+}
+
+static int aspeed_hrng_remove(struct platform_device *pdev)
+{
+	struct aspeed_hrng_private *priv = platform_get_drvdata(pdev);
+
+	aspeed_hrng_disable(priv);
+	hwrng_unregister(&priv->rng_ops);
+	hrtimer_cancel(&priv->timer);
+
+	return 0;
+}
+
+static const struct of_device_id aspeed_hrng_match[] = {
+	{ .compatible = "aspeed,ast2400-rng" },
+	{ .compatible = "aspeed,ast2500-rng" },
+	{ .compatible = "aspeed,ast2600-rng" },
+	{},
+};
+MODULE_DEVICE_TABLE(of, aspeed_hrng_match);
+
+static struct platform_driver aspeed_hrng_driver = {
+	.driver = {
+		.name		= "aspeed-rng",
+		.of_match_table	= aspeed_hrng_match,
+	},
+	.probe		= aspeed_hrng_probe,
+	.remove		= aspeed_hrng_remove,
+};
+
+module_platform_driver(aspeed_hrng_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Oscar A Perez <oscar.perez@ztsystems.com>");
+MODULE_DESCRIPTION("Aspeed Ring Oscillator Random Number Generator driver");
-- 
2.17.1

Re: [PATCH 2/2] hwrng: Add support for ASPEED RNG

[kbuild test robot]

Hi Oscar,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on char-misc/char-misc-testing]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:    https://github.com/0day-ci/linux/commits/Oscar-A-Perez/hwrng-Add-support-for-ASPEED-RNG/20200121-020818
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git c20c76acf6ec1df0af3bdd3370f7e3fef4494ba8
config: i386-tinyconfig
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
        make ARCH=i386  tinyconfig
        make ARCH=i386 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/char/hw_random/Kconfig:481: syntax error
   drivers/char/hw_random/Kconfig:480:warning: ignoring unsupported character ','
   drivers/char/hw_random/Kconfig:480:warning: ignoring unsupported character '.'
>> drivers/char/hw_random/Kconfig:480: unknown statement "If"
   make[2]: *** [oldconfig] Error 1
   make[1]: *** [oldconfig] Error 2
   make: *** [sub-make] Error 2
   4 real  2 user  0 sys  65.95% cpu 	make oldconfig
--
>> drivers/char/hw_random/Kconfig:481: syntax error
   drivers/char/hw_random/Kconfig:480:warning: ignoring unsupported character ','
   drivers/char/hw_random/Kconfig:480:warning: ignoring unsupported character '.'
>> drivers/char/hw_random/Kconfig:480: unknown statement "If"
   make[2]: *** [olddefconfig] Error 1
   make[1]: *** [olddefconfig] Error 2
   make: *** [sub-make] Error 2
   4 real  2 user  0 sys  62.01% cpu 	make olddefconfig
--
>> drivers/char/hw_random/Kconfig:481: syntax error
   drivers/char/hw_random/Kconfig:480:warning: ignoring unsupported character ','
   drivers/char/hw_random/Kconfig:480:warning: ignoring unsupported character '.'
>> drivers/char/hw_random/Kconfig:480: unknown statement "If"
   make[5]: *** [allnoconfig] Error 1
   make[4]: *** [allnoconfig] Error 2
   make[3]: *** [__build_one_by_one] Error 2
   make[3]: Target 'allnoconfig' not remade because of errors.
   make[3]: Target 'tiny.config' not remade because of errors.
   make[2]: *** [tinyconfig] Error 2
   make[1]: *** [tinyconfig] Error 2
   make: *** [sub-make] Error 2
   7 real  2 user  0 sys  49.49% cpu 	make tinyconfig

vim +481 drivers/char/hw_random/Kconfig

    23	
    24	config HW_RANDOM_TIMERIOMEM
    25		tristate "Timer IOMEM HW Random Number Generator support"
    26		depends on HAS_IOMEM
    27		---help---
    28		  This driver provides kernel-side support for a generic Random
    29		  Number Generator used by reading a 'dumb' iomem address that
    30		  is to be read no faster than, for example, once a second;
    31		  the default FPGA bitstream on the TS-7800 has such functionality.
    32	
    33		  To compile this driver as a module, choose M here: the
    34		  module will be called timeriomem-rng.
    35	
    36		  If unsure, say Y.
    37	
    38	config HW_RANDOM_INTEL
    39		tristate "Intel HW Random Number Generator support"
    40		depends on (X86 || IA64) && PCI
    41		default HW_RANDOM
    42		---help---
    43		  This driver provides kernel-side support for the Random Number
    44		  Generator hardware found on Intel i8xx-based motherboards.
    45	
    46		  To compile this driver as a module, choose M here: the
    47		  module will be called intel-rng.
    48	
    49		  If unsure, say Y.
    50	
    51	config HW_RANDOM_AMD
    52		tristate "AMD HW Random Number Generator support"
    53		depends on (X86 || PPC_MAPLE) && PCI
    54		default HW_RANDOM
    55		---help---
    56		  This driver provides kernel-side support for the Random Number
    57		  Generator hardware found on AMD 76x-based motherboards.
    58	
    59		  To compile this driver as a module, choose M here: the
    60		  module will be called amd-rng.
    61	
    62		  If unsure, say Y.
    63	
    64	config HW_RANDOM_ATMEL
    65		tristate "Atmel Random Number Generator support"
    66		depends on ARCH_AT91 && HAVE_CLK && OF
    67		default HW_RANDOM
    68		---help---
    69		  This driver provides kernel-side support for the Random Number
    70		  Generator hardware found on Atmel AT91 devices.
    71	
    72		  To compile this driver as a module, choose M here: the
    73		  module will be called atmel-rng.
    74	
    75		  If unsure, say Y.
    76	
    77	config HW_RANDOM_BCM2835
    78		tristate "Broadcom BCM2835/BCM63xx Random Number Generator support"
    79		depends on ARCH_BCM2835 || ARCH_BCM_NSP || ARCH_BCM_5301X || \
    80			   ARCH_BCM_63XX || BCM63XX || BMIPS_GENERIC
    81		default HW_RANDOM
    82		---help---
    83		  This driver provides kernel-side support for the Random Number
    84		  Generator hardware found on the Broadcom BCM2835 and BCM63xx SoCs.
    85	
    86		  To compile this driver as a module, choose M here: the
    87		  module will be called bcm2835-rng
    88	
    89		  If unsure, say Y.
    90	
    91	config HW_RANDOM_IPROC_RNG200
    92		tristate "Broadcom iProc/STB RNG200 support"
    93		depends on ARCH_BCM_IPROC || ARCH_BRCMSTB
    94		default HW_RANDOM
    95		---help---
    96		  This driver provides kernel-side support for the RNG200
    97		  hardware found on the Broadcom iProc and STB SoCs.
    98	
    99		  To compile this driver as a module, choose M here: the
   100		  module will be called iproc-rng200
   101	
   102		  If unsure, say Y.
   103	
   104	config HW_RANDOM_GEODE
   105		tristate "AMD Geode HW Random Number Generator support"
   106		depends on X86_32 && PCI
   107		default HW_RANDOM
   108		---help---
   109		  This driver provides kernel-side support for the Random Number
   110		  Generator hardware found on the AMD Geode LX.
   111	
   112		  To compile this driver as a module, choose M here: the
   113		  module will be called geode-rng.
   114	
   115		  If unsure, say Y.
   116	
   117	config HW_RANDOM_N2RNG
   118		tristate "Niagara2 Random Number Generator support"
   119		depends on SPARC64
   120		default HW_RANDOM
   121		---help---
   122		  This driver provides kernel-side support for the Random Number
   123		  Generator hardware found on Niagara2 cpus.
   124	
   125		  To compile this driver as a module, choose M here: the
   126		  module will be called n2-rng.
   127	
   128		  If unsure, say Y.
   129	
   130	config HW_RANDOM_VIA
   131		tristate "VIA HW Random Number Generator support"
   132		depends on X86
   133		default HW_RANDOM
   134		---help---
   135		  This driver provides kernel-side support for the Random Number
   136		  Generator hardware found on VIA based motherboards.
   137	
   138		  To compile this driver as a module, choose M here: the
   139		  module will be called via-rng.
   140	
   141		  If unsure, say Y.
   142	
   143	config HW_RANDOM_IXP4XX
   144		tristate "Intel IXP4xx NPU HW Pseudo-Random Number Generator support"
   145		depends on ARCH_IXP4XX
   146		default HW_RANDOM
   147		---help---
   148		  This driver provides kernel-side support for the Pseudo-Random
   149		  Number Generator hardware found on the Intel IXP45x/46x NPU.
   150	
   151		  To compile this driver as a module, choose M here: the
   152		  module will be called ixp4xx-rng.
   153	
   154		  If unsure, say Y.
   155	
   156	config HW_RANDOM_OMAP
   157		tristate "OMAP Random Number Generator support"
   158		depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || ARCH_MVEBU
   159		default HW_RANDOM
   160	 	---help---
   161	 	  This driver provides kernel-side support for the Random Number
   162		  Generator hardware found on OMAP16xx, OMAP2/3/4/5, AM33xx/AM43xx
   163		  multimedia processors, and Marvell Armada 7k/8k SoCs.
   164	
   165		  To compile this driver as a module, choose M here: the
   166		  module will be called omap-rng.
   167	
   168	 	  If unsure, say Y.
   169	
   170	config HW_RANDOM_OMAP3_ROM
   171		tristate "OMAP3 ROM Random Number Generator support"
   172		depends on ARCH_OMAP3
   173		default HW_RANDOM
   174		---help---
   175		  This driver provides kernel-side support for the Random Number
   176		  Generator hardware found on OMAP34xx processors.
   177	
   178		  To compile this driver as a module, choose M here: the
   179		  module will be called omap3-rom-rng.
   180	
   181		  If unsure, say Y.
   182	
   183	config HW_RANDOM_OCTEON
   184		tristate "Octeon Random Number Generator support"
   185		depends on CAVIUM_OCTEON_SOC
   186		default HW_RANDOM
   187		---help---
   188		  This driver provides kernel-side support for the Random Number
   189		  Generator hardware found on Octeon processors.
   190	
   191		  To compile this driver as a module, choose M here: the
   192		  module will be called octeon-rng.
   193	
   194		  If unsure, say Y.
   195	
   196	config HW_RANDOM_PASEMI
   197		tristate "PA Semi HW Random Number Generator support"
   198		depends on PPC_PASEMI
   199		default HW_RANDOM
   200		---help---
   201		  This driver provides kernel-side support for the Random Number
   202		  Generator hardware found on PA Semi PWRficient SoCs.
   203	
   204		  To compile this driver as a module, choose M here: the
   205		  module will be called pasemi-rng.
   206	
   207		  If unsure, say Y.
   208	
   209	config HW_RANDOM_VIRTIO
   210		tristate "VirtIO Random Number Generator support"
   211		depends on VIRTIO
   212		---help---
   213		  This driver provides kernel-side support for the virtual Random Number
   214		  Generator hardware.
   215	
   216		  To compile this driver as a module, choose M here: the
   217		  module will be called virtio-rng.  If unsure, say N.
   218	
   219	config HW_RANDOM_TX4939
   220		tristate "TX4939 Random Number Generator support"
   221		depends on SOC_TX4939
   222		default HW_RANDOM
   223		---help---
   224		  This driver provides kernel-side support for the Random Number
   225		  Generator hardware found on TX4939 SoC.
   226	
   227		  To compile this driver as a module, choose M here: the
   228		  module will be called tx4939-rng.
   229	
   230		  If unsure, say Y.
   231	
   232	config HW_RANDOM_MXC_RNGA
   233		tristate "Freescale i.MX RNGA Random Number Generator"
   234		depends on SOC_IMX31
   235		default HW_RANDOM
   236		---help---
   237		  This driver provides kernel-side support for the Random Number
   238		  Generator hardware found on Freescale i.MX processors.
   239	
   240		  To compile this driver as a module, choose M here: the
   241		  module will be called mxc-rnga.
   242	
   243		  If unsure, say Y.
   244	
   245	config HW_RANDOM_IMX_RNGC
   246		tristate "Freescale i.MX RNGC Random Number Generator"
   247		depends on ARCH_MXC
   248		default HW_RANDOM
   249		---help---
   250		  This driver provides kernel-side support for the Random Number
   251		  Generator Version C hardware found on some Freescale i.MX
   252		  processors. Version B is also supported by this driver.
   253	
   254		  To compile this driver as a module, choose M here: the
   255		  module will be called imx-rngc.
   256	
   257		  If unsure, say Y.
   258	
   259	config HW_RANDOM_NOMADIK
   260		tristate "ST-Ericsson Nomadik Random Number Generator support"
   261		depends on ARCH_NOMADIK
   262		default HW_RANDOM
   263		---help---
   264		  This driver provides kernel-side support for the Random Number
   265		  Generator hardware found on ST-Ericsson SoCs (8815 and 8500).
   266	
   267		  To compile this driver as a module, choose M here: the
   268		  module will be called nomadik-rng.
   269	
   270		  If unsure, say Y.
   271	
   272	config HW_RANDOM_PSERIES
   273		tristate "pSeries HW Random Number Generator support"
   274		depends on PPC64 && IBMVIO
   275		default HW_RANDOM
   276		---help---
   277		  This driver provides kernel-side support for the Random Number
   278		  Generator hardware found on POWER7+ machines and above
   279	
   280		  To compile this driver as a module, choose M here: the
   281		  module will be called pseries-rng.
   282	
   283		  If unsure, say Y.
   284	
   285	config HW_RANDOM_POWERNV
   286		tristate "PowerNV Random Number Generator support"
   287		depends on PPC_POWERNV
   288		default HW_RANDOM
   289		---help---
   290		  This is the driver for Random Number Generator hardware found
   291		  in POWER7+ and above machines for PowerNV platform.
   292	
   293		  To compile this driver as a module, choose M here: the
   294		  module will be called powernv-rng.
   295	
   296		  If unsure, say Y.
   297	
   298	config HW_RANDOM_HISI
   299		tristate "Hisilicon Random Number Generator support"
   300		depends on HW_RANDOM && ARCH_HISI
   301		default HW_RANDOM
   302		---help---
   303		  This driver provides kernel-side support for the Random Number
   304		  Generator hardware found on Hisilicon Hip04 and Hip05 SoC.
   305	
   306		  To compile this driver as a module, choose M here: the
   307		  module will be called hisi-rng.
   308	
   309		  If unsure, say Y.
   310	
   311	config HW_RANDOM_HISI_V2
   312		tristate "HiSilicon True Random Number Generator V2 support"
   313		depends on HW_RANDOM && ARM64 && ACPI
   314		default HW_RANDOM
   315		help
   316		  This driver provides kernel-side support for the True Random Number
   317		  Generator V2 hardware found on HiSilicon Hi1620 SoC.
   318	
   319		  To compile this driver as a module, choose M here: the
   320		  module will be called hisi-trng-v2.
   321	
   322		  If unsure, say Y.
   323	
   324	config HW_RANDOM_ST
   325		tristate "ST Microelectronics HW Random Number Generator support"
   326		depends on HW_RANDOM && ARCH_STI
   327		---help---
   328		  This driver provides kernel-side support for the Random Number
   329		  Generator hardware found on STi series of SoCs.
   330	
   331		  To compile this driver as a module, choose M here: the
   332		  module will be called st-rng.
   333	
   334	config HW_RANDOM_XGENE
   335		tristate "APM X-Gene True Random Number Generator (TRNG) support"
   336		depends on HW_RANDOM && ARCH_XGENE
   337		default HW_RANDOM
   338		---help---
   339		  This driver provides kernel-side support for the Random Number
   340		  Generator hardware found on APM X-Gene SoC.
   341	
   342		  To compile this driver as a module, choose M here: the
   343		  module will be called xgene_rng.
   344	
   345		  If unsure, say Y.
   346	
   347	config HW_RANDOM_STM32
   348		tristate "STMicroelectronics STM32 random number generator"
   349		depends on HW_RANDOM && (ARCH_STM32 || COMPILE_TEST)
   350		depends on HAS_IOMEM
   351		default HW_RANDOM
   352		help
   353		  This driver provides kernel-side support for the Random Number
   354		  Generator hardware found on STM32 microcontrollers.
   355	
   356		  To compile this driver as a module, choose M here: the
   357		  module will be called stm32-rng.
   358	
   359		  If unsure, say N.
   360	
   361	config HW_RANDOM_PIC32
   362		tristate "Microchip PIC32 Random Number Generator support"
   363		depends on HW_RANDOM && MACH_PIC32
   364		default y
   365		---help---
   366		  This driver provides kernel-side support for the Random Number
   367		  Generator hardware found on a PIC32.
   368	
   369		  To compile this driver as a module, choose M here. the
   370		  module will be called pic32-rng.
   371	
   372		  If unsure, say Y.
   373	
   374	config HW_RANDOM_MESON
   375		tristate "Amlogic Meson Random Number Generator support"
   376		depends on HW_RANDOM
   377		depends on ARCH_MESON || COMPILE_TEST
   378		default y
   379		---help---
   380		  This driver provides kernel-side support for the Random Number
   381		  Generator hardware found on Amlogic Meson SoCs.
   382	
   383		  To compile this driver as a module, choose M here. the
   384		  module will be called meson-rng.
   385	
   386		  If unsure, say Y.
   387	
   388	config HW_RANDOM_CAVIUM
   389		tristate "Cavium ThunderX Random Number Generator support"
   390		depends on HW_RANDOM && PCI && (ARM64 || (COMPILE_TEST && 64BIT))
   391		default HW_RANDOM
   392		---help---
   393		  This driver provides kernel-side support for the Random Number
   394		  Generator hardware found on Cavium SoCs.
   395	
   396		  To compile this driver as a module, choose M here: the
   397		  module will be called cavium_rng.
   398	
   399		  If unsure, say Y.
   400	
   401	config HW_RANDOM_MTK
   402		tristate "Mediatek Random Number Generator support"
   403		depends on HW_RANDOM
   404		depends on ARCH_MEDIATEK || COMPILE_TEST
   405		default y
   406		---help---
   407		  This driver provides kernel-side support for the Random Number
   408		  Generator hardware found on Mediatek SoCs.
   409	
   410		  To compile this driver as a module, choose M here. the
   411		  module will be called mtk-rng.
   412	
   413		  If unsure, say Y.
   414	
   415	config HW_RANDOM_S390
   416		tristate "S390 True Random Number Generator support"
   417		depends on S390
   418		default HW_RANDOM
   419		---help---
   420		  This driver provides kernel-side support for the True
   421		  Random Number Generator available as CPACF extension
   422		  on modern s390 hardware platforms.
   423	
   424		  To compile this driver as a module, choose M here: the
   425		  module will be called s390-trng.
   426	
   427		  If unsure, say Y.
   428	
   429	config HW_RANDOM_EXYNOS
   430		tristate "Samsung Exynos True Random Number Generator support"
   431		depends on ARCH_EXYNOS || COMPILE_TEST
   432		default HW_RANDOM
   433		---help---
   434		  This driver provides support for the True Random Number
   435		  Generator available in Exynos SoCs.
   436	
   437		  To compile this driver as a module, choose M here: the module
   438		  will be called exynos-trng.
   439	
   440		  If unsure, say Y.
   441	
   442	config HW_RANDOM_OPTEE
   443		tristate "OP-TEE based Random Number Generator support"
   444		depends on OPTEE
   445		default HW_RANDOM
   446		help
   447		  This  driver provides support for OP-TEE based Random Number
   448		  Generator on ARM SoCs where hardware entropy sources are not
   449		  accessible to normal world (Linux).
   450	
   451		  To compile this driver as a module, choose M here: the module
   452		  will be called optee-rng.
   453	
   454		  If unsure, say Y.
   455	
   456	config HW_RANDOM_NPCM
   457		tristate "NPCM Random Number Generator support"
   458		depends on ARCH_NPCM || COMPILE_TEST
   459		default HW_RANDOM
   460		help
   461	 	  This driver provides support for the Random Number
   462		  Generator hardware available in Nuvoton NPCM SoCs.
   463	
   464		  To compile this driver as a module, choose M here: the
   465		  module will be called npcm-rng.
   466	
   467	 	  If unsure, say Y.
   468	
   469	config HW_RANDOM_ASPEED
   470		tristate "Aspeed Hardware Random Number Generator support"
   471		depends on ARCH_ASPEED || COMPILE_TEST
   472		default HW_RANDOM
   473		help
   474		  If you say yes to this option, support will be included for the
   475		  Hardware Random Number Generator that comes with Aspeed SoCs.
   476	
   477		  This driver can also be built as a module.  If so, the module
   478		  will be called aspeed-rng.
   479	
 > 480		 If unsure, say Y.
 > 481	

---
0-DAY kernel test infrastructure                 Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org Intel Corporation

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[Joel Stanley]

Hi,

On Mon, 20 Jan 2020 at 15:12, Oscar A Perez <linux@neuralgames.com> wrote:
>
> This minimal driver adds support for the Hardware Random Number Generator
> that comes with the AST2400/AST2500/AST2600 SOCs from AspeedTech.
>
> The HRNG on these SOCs uses Ring Oscillators working together to generate
> a stream of random bits that can be read by the platform via a 32bit data
> register.

Thanks for the patch.

We've been using the timeriomem-rng driver for the past few years on
aspeed hardware. You can see how that's set up by looking at
arch/arm/boot/dts/aspeed-g{4,5,6}.dtsi

I suggest we continue to use the generic driver.

Cheers,

Joel



>
> Signed-off-by: Oscar A Perez <linux@neuralgames.com>
> ---
>  .../devicetree/bindings/rng/aspeed-rng.yaml   | 90 +++++++++++++++++++
>  1 file changed, 90 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/aspeed-rng.yaml
>
> diff --git a/Documentation/devicetree/bindings/rng/aspeed-rng.yaml b/Documentation/devicetree/bindings/rng/aspeed-rng.yaml
> new file mode 100644
> index 000000000000..06070ebe1c33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/aspeed-rng.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/rng/aspeed-rng.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +
> +title: Bindings for Aspeed Hardware Random Number Generator
> +
> +
> +maintainers:
> +  - Oscar A Perez <linux@neuralgames.com>
> +
> +
> +description: |
> +  The HRNG on the AST2400/AST2500/AST2600 SOCs from AspeedTech  uses four Ring
> +  Oscillators working together to generate a stream of random bits that can be
> +  read by the platform via a 32bit data register every one microsecond.
> +  All the platform has to do is to provide to the driver the 'quality' entropy
> +  value, the  'mode' in which the combining  ROs will generate the  stream  of
> +  random bits and, the 'period' value that is used as a wait-time between reads
> +  from the 32bit data register.
> +
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - aspeed,ast2400-rng
> +              - aspeed,ast2500-rng
> +              - aspeed,ast2600-rng
> +
> +
> +  reg:
> +    description:
> +      Base address and length of the register set of this block.
> +      Currently 'reg' must be eight bytes wide and 32-bit aligned.
> +
> +    maxItems: 1
> +
> +
> +  period:
> +    description:
> +      Wait time in microseconds to be used between reads.
> +      The RNG on these Aspeed SOCs generates 32bit of random data
> +      every one microsecond. Choose between 1 and n microseconds.
> +
> +    maxItems: 1
> +
> +
> +  mode:
> +    description:
> +      One of the eight modes in which the four internal ROs (Ring
> +      Oscillators)  are combined to generate a stream  of random
> +      bits. The default mode is seven which is the default method
> +      of combining RO random bits on these Aspeed SOCs.
> +
> +    maxItems: 1
> +
> +
> +  quality:
> +    description:
> +      Estimated number of bits of entropy per 1024 bits read from
> +      the RNG.  Note that the default quality is zero which stops
> +      this HRNG from automatically filling the kernel's entropy
> +      pool with data.
> +
> +    maxItems: 1
> +
> +
> +required:
> +  - compatible
> +  - reg
> +  - period
> +  - quality
> +
> +
> +examples:
> +  - |
> +    rng: hwrng@1e6e2074 {
> +         compatible = "aspeed,ast2500-rng";
> +         reg = <0x1e6e2074 0x8>;
> +         period = <4>;
> +         quality = <128>;
> +         mode = <0x7>;
> +    };
> +
> +
> +...
> --
> 2.17.1
>

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[linux]

Hi Joel,

On 2020-01-20 19:53, Joel Stanley wrote:
> Hi,
> 
> On Mon, 20 Jan 2020 at 15:12, Oscar A Perez <linux@neuralgames.com> 
> wrote:
>> 
>> This minimal driver adds support for the Hardware Random Number 
>> Generator
>> that comes with the AST2400/AST2500/AST2600 SOCs from AspeedTech.
>> 
>> The HRNG on these SOCs uses Ring Oscillators working together to 
>> generate
>> a stream of random bits that can be read by the platform via a 32bit 
>> data
>> register.
> 
> Thanks for the patch.
> 
> We've been using the timeriomem-rng driver for the past few years on
> aspeed hardware. You can see how that's set up by looking at
> arch/arm/boot/dts/aspeed-g{4,5,6}.dtsi
> 
> I suggest we continue to use the generic driver.
> 
> Cheers,
> 
> Joel
> 
> 
> 

Thanks for reviewing the patch.

The RNG on Aspeed hardware allows eight different modes for combining 
its four internal Ring Oscillators that together generate a stream of 
random bits. However, the timeriomem-rng driver does not allow for mode 
selection so, the Aspeed RNG with this generic driver runs always on 
mode 'seven' (The default value for mode according to the AspeedTech 
datasheets).

I've performed some testings on this Aspeed RNG using the NIST 
Statistical Test Suite (NIST 800-22r1a) and, the results I got show that 
the default mode 'seven' isn't producing the best entropy and linear 
rank when compared against the other modes available on these SOCs.  On 
the other hand, the driver that I'm proposing here allows for mode 
selection which would help improve the random output for those looking 
to get the best out of this Aspeed RNG.

Thanks and regards,

Oscar A Perez

>> 
>> Signed-off-by: Oscar A Perez <linux@neuralgames.com>
>> ---
>>  .../devicetree/bindings/rng/aspeed-rng.yaml   | 90 
>> +++++++++++++++++++
>>  1 file changed, 90 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/rng/aspeed-rng.yaml
>> 
>> diff --git a/Documentation/devicetree/bindings/rng/aspeed-rng.yaml 
>> b/Documentation/devicetree/bindings/rng/aspeed-rng.yaml
>> new file mode 100644
>> index 000000000000..06070ebe1c33
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/rng/aspeed-rng.yaml
>> @@ -0,0 +1,90 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/rng/aspeed-rng.yaml#"
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
>> +
>> +
>> +title: Bindings for Aspeed Hardware Random Number Generator
>> +
>> +
>> +maintainers:
>> +  - Oscar A Perez <linux@neuralgames.com>
>> +
>> +
>> +description: |
>> +  The HRNG on the AST2400/AST2500/AST2600 SOCs from AspeedTech  uses 
>> four Ring
>> +  Oscillators working together to generate a stream of random bits 
>> that can be
>> +  read by the platform via a 32bit data register every one 
>> microsecond.
>> +  All the platform has to do is to provide to the driver the 
>> 'quality' entropy
>> +  value, the  'mode' in which the combining  ROs will generate the  
>> stream  of
>> +  random bits and, the 'period' value that is used as a wait-time 
>> between reads
>> +  from the 32bit data register.
>> +
>> +
>> +properties:
>> +  compatible:
>> +    oneOf:
>> +      - items:
>> +          - enum:
>> +              - aspeed,ast2400-rng
>> +              - aspeed,ast2500-rng
>> +              - aspeed,ast2600-rng
>> +
>> +
>> +  reg:
>> +    description:
>> +      Base address and length of the register set of this block.
>> +      Currently 'reg' must be eight bytes wide and 32-bit aligned.
>> +
>> +    maxItems: 1
>> +
>> +
>> +  period:
>> +    description:
>> +      Wait time in microseconds to be used between reads.
>> +      The RNG on these Aspeed SOCs generates 32bit of random data
>> +      every one microsecond. Choose between 1 and n microseconds.
>> +
>> +    maxItems: 1
>> +
>> +
>> +  mode:
>> +    description:
>> +      One of the eight modes in which the four internal ROs (Ring
>> +      Oscillators)  are combined to generate a stream  of random
>> +      bits. The default mode is seven which is the default method
>> +      of combining RO random bits on these Aspeed SOCs.
>> +
>> +    maxItems: 1
>> +
>> +
>> +  quality:
>> +    description:
>> +      Estimated number of bits of entropy per 1024 bits read from
>> +      the RNG.  Note that the default quality is zero which stops
>> +      this HRNG from automatically filling the kernel's entropy
>> +      pool with data.
>> +
>> +    maxItems: 1
>> +
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - period
>> +  - quality
>> +
>> +
>> +examples:
>> +  - |
>> +    rng: hwrng@1e6e2074 {
>> +         compatible = "aspeed,ast2500-rng";
>> +         reg = <0x1e6e2074 0x8>;
>> +         period = <4>;
>> +         quality = <128>;
>> +         mode = <0x7>;
>> +    };
>> +
>> +
>> +...
>> --
>> 2.17.1
>> 

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[Andrew Jeffery]

> Thanks for reviewing the patch.
> 
> The RNG on Aspeed hardware allows eight different modes for combining 
> its four internal Ring Oscillators that together generate a stream of 
> random bits. However, the timeriomem-rng driver does not allow for mode 
> selection so, the Aspeed RNG with this generic driver runs always on 
> mode 'seven' (The default value for mode according to the AspeedTech 
> datasheets).
> 
> I've performed some testings on this Aspeed RNG using the NIST 
> Statistical Test Suite (NIST 800-22r1a) and, the results I got show that 
> the default mode 'seven' isn't producing the best entropy and linear 
> rank when compared against the other modes available on these SOCs.  On 
> the other hand, the driver that I'm proposing here allows for mode 
> selection which would help improve the random output for those looking 
> to get the best out of this Aspeed RNG.

Have you published the data and results of this study somewhere? This
really should be mentioned in the commit message as justification for
not using timeriomem-rng.

Andrew

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[linux]

On 2020-01-22 19:53, Andrew Jeffery wrote:
>> Thanks for reviewing the patch.
>> 
>> The RNG on Aspeed hardware allows eight different modes for combining
>> its four internal Ring Oscillators that together generate a stream of
>> random bits. However, the timeriomem-rng driver does not allow for 
>> mode
>> selection so, the Aspeed RNG with this generic driver runs always on
>> mode 'seven' (The default value for mode according to the AspeedTech
>> datasheets).
>> 
>> I've performed some testings on this Aspeed RNG using the NIST
>> Statistical Test Suite (NIST 800-22r1a) and, the results I got show 
>> that
>> the default mode 'seven' isn't producing the best entropy and linear
>> rank when compared against the other modes available on these SOCs.  
>> On
>> the other hand, the driver that I'm proposing here allows for mode
>> selection which would help improve the random output for those looking
>> to get the best out of this Aspeed RNG.
> 
> Have you published the data and results of this study somewhere? This
> really should be mentioned in the commit message as justification for
> not using timeriomem-rng.
> 
> Andrew

Hi Andrew,

I have uploaded the results of my tests to my GitHub, along with all the 
binaries
containing the random bits that I collected from this Aspeed RNG using 
all 8 modes.
You can also find in this repository a patch for the hw_random core 
driver that
I've been using to collect this data. Here is the link:
   https://github.com/operezmuena/aspeed-rng-testing

You can see in the reports that when using large enough samples (40Mb in 
size)
this Aspeed RNG consistently fails the linear rank and entropy tests, no 
matter
what RNG mode is selected. However, modes 2, 4 and 6 produce better 
entropy than
the rest.
I'm now collecting rng data from 2 other AST2520 SOCs that I have in 
order to
compare results.

Regards,
Oscar

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[Andrew Jeffery]

On Sat, 25 Jan 2020, at 11:40, linux@neuralgames.com wrote:
> On 2020-01-22 19:53, Andrew Jeffery wrote:
> >> Thanks for reviewing the patch.
> >> 
> >> The RNG on Aspeed hardware allows eight different modes for combining
> >> its four internal Ring Oscillators that together generate a stream of
> >> random bits. However, the timeriomem-rng driver does not allow for 
> >> mode
> >> selection so, the Aspeed RNG with this generic driver runs always on
> >> mode 'seven' (The default value for mode according to the AspeedTech
> >> datasheets).
> >> 
> >> I've performed some testings on this Aspeed RNG using the NIST
> >> Statistical Test Suite (NIST 800-22r1a) and, the results I got show 
> >> that
> >> the default mode 'seven' isn't producing the best entropy and linear
> >> rank when compared against the other modes available on these SOCs.  
> >> On
> >> the other hand, the driver that I'm proposing here allows for mode
> >> selection which would help improve the random output for those looking
> >> to get the best out of this Aspeed RNG.
> > 
> > Have you published the data and results of this study somewhere? This
> > really should be mentioned in the commit message as justification for
> > not using timeriomem-rng.
> > 
> > Andrew
> 
> Hi Andrew,
> 
> I have uploaded the results of my tests to my GitHub, along with all the 
> binaries
> containing the random bits that I collected from this Aspeed RNG using 
> all 8 modes.
> You can also find in this repository a patch for the hw_random core 
> driver that
> I've been using to collect this data. Here is the link:
>    https://github.com/operezmuena/aspeed-rng-testing
> 
> You can see in the reports that when using large enough samples (40Mb in 
> size)
> this Aspeed RNG consistently fails the linear rank and entropy tests, no 
> matter
> what RNG mode is selected. However, modes 2, 4 and 6 produce better 
> entropy than
> the rest.
> I'm now collecting rng data from 2 other AST2520 SOCs that I have in 
> order to
> compare results.

Nice work. Eyeballing the summaries, it seems mode 6 or mode 4 may be
improvements over 7? What's your analysis? It would be nice to have the
data from your other two SoCs to corroborate. Again, going forward, please
point to your measurements in your commit message.

Not that I've looked, but is it feasible to augment timeriomem-rng with
the ability to configure the RNG rather than implement a new driver? Why
didn't you go that route?

Andrew

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[linux]

On 2020-01-27 18:53, Andrew Jeffery wrote:
> On Sat, 25 Jan 2020, at 11:40, linux@neuralgames.com wrote:
>> On 2020-01-22 19:53, Andrew Jeffery wrote:
>> >> Thanks for reviewing the patch.
>> >>
>> >> The RNG on Aspeed hardware allows eight different modes for combining
>> >> its four internal Ring Oscillators that together generate a stream of
>> >> random bits. However, the timeriomem-rng driver does not allow for
>> >> mode
>> >> selection so, the Aspeed RNG with this generic driver runs always on
>> >> mode 'seven' (The default value for mode according to the AspeedTech
>> >> datasheets).
>> >>
>> >> I've performed some testings on this Aspeed RNG using the NIST
>> >> Statistical Test Suite (NIST 800-22r1a) and, the results I got show
>> >> that
>> >> the default mode 'seven' isn't producing the best entropy and linear
>> >> rank when compared against the other modes available on these SOCs.
>> >> On
>> >> the other hand, the driver that I'm proposing here allows for mode
>> >> selection which would help improve the random output for those looking
>> >> to get the best out of this Aspeed RNG.
>> >
>> > Have you published the data and results of this study somewhere? This
>> > really should be mentioned in the commit message as justification for
>> > not using timeriomem-rng.
>> >
>> > Andrew
>> 
>> Hi Andrew,
>> 
>> I have uploaded the results of my tests to my GitHub, along with all 
>> the
>> binaries
>> containing the random bits that I collected from this Aspeed RNG using
>> all 8 modes.
>> You can also find in this repository a patch for the hw_random core
>> driver that
>> I've been using to collect this data. Here is the link:
>>    https://github.com/operezmuena/aspeed-rng-testing
>> 
>> You can see in the reports that when using large enough samples (40Mb 
>> in
>> size)
>> this Aspeed RNG consistently fails the linear rank and entropy tests, 
>> no
>> matter
>> what RNG mode is selected. However, modes 2, 4 and 6 produce better
>> entropy than
>> the rest.
>> I'm now collecting rng data from 2 other AST2520 SOCs that I have in
>> order to
>> compare results.
> 
> Nice work. Eyeballing the summaries, it seems mode 6 or mode 4 may be
> improvements over 7? What's your analysis? It would be nice to have the
> data from your other two SoCs to corroborate. Again, going forward, 
> please
> point to your measurements in your commit message.
> 

Hi Andrew,

I pushed to my GitHub repository the RNG dumps and NIST reports from the 
other 2 SOCs. The results are similar to the first SOC. None of the 
modes passed the NIST test for linear rank and approximate entropy. 
Also, these SOCs show that mode 6 produces better results than mode 7. 
However, having only a sample of 3 SOCs isn't going to give us 
statistical significance about which mode would be the best one on these 
SOCs but, it is hinting us that perhaps allowing the selection of other 
RNG modes would be a good feature to have in a driver.
Now, I must say that this is the first RO-based RNG that I have tested 
and I'm a bit concerned about the results I've been getting. I'm now 
wondering how RNGs from other SOC vendors would perform with this same 
test suite.

> Not that I've looked, but is it feasible to augment timeriomem-rng with
> the ability to configure the RNG rather than implement a new driver? 
> Why
> didn't you go that route?
> 
> Andrew

I decided to wrote the Aspeed-RNG driver because was under the 
impression that the community would prefer dedicated drivers over 
generic ones for these SOCs.  However, enhancing timeriomem-rng module 
is not hard at all.  As I matter of fact, I'm currently testing changes 
to timeriomem-rng and so far so good. If you would like to have a quick 
look to my changes, I just pushed patches to the same repo a couple of 
hours ago:  
https://github.com/operezmuena/aspeed-rng-testing/tree/master/patches

Thanks
Oscar

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[Andrew Jeffery]

On Wed, 29 Jan 2020, at 10:56, linux@neuralgames.com wrote:
> On 2020-01-27 18:53, Andrew Jeffery wrote:
> > Not that I've looked, but is it feasible to augment timeriomem-rng with
> > the ability to configure the RNG rather than implement a new driver? 
> > Why
> > didn't you go that route?
> > 
> 
> I decided to wrote the Aspeed-RNG driver because was under the 
> impression that the community would prefer dedicated drivers over 
> generic ones for these SOCs. 

I think we should leverage existing work where we can. Lets not make
more extra for ourselves :)

> However, enhancing timeriomem-rng module 
> is not hard at all.  As I matter of fact, I'm currently testing changes 
> to timeriomem-rng and so far so good. If you would like to have a quick 
> look to my changes, I just pushed patches to the same repo a couple of 
> hours ago:  
> https://github.com/operezmuena/aspeed-rng-testing/tree/master/patches

I think this is a good approach  so long as we can create a clean interface
to the control MMIO(s) inside the driver, i.e. we shouldn't be baking any
Aspeed-specific information into generic sections of code. Usually this
means sticking a pointer to an ops struct in the data member of the
matching OF ID struct.

Input from the RNG maintainers will be helpful here.

Andrew

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[Andrew Jeffery]

On Mon, 3 Feb 2020, at 14:37, Andrew Jeffery wrote:
> 
> I think we should leverage existing work where we can. Lets not make
> more extra for ourselves :)

Dammit, replaced the wrong word there - the irony:

"Lets not make _extra work_ for ourselves"

Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG

[Rob Herring]

On Mon, Jan 20, 2020 at 03:01:08PM +0000, Oscar A Perez wrote:
> This minimal driver adds support for the Hardware Random Number Generator
> that comes with the AST2400/AST2500/AST2600 SOCs from AspeedTech.

This patch is not a driver. 'dt-bindings: rng: ...' for the subject. 
(Plus, 2 patches with the same subject is never a good idea.)

> 
> The HRNG on these SOCs uses Ring Oscillators working together to generate
> a stream of random bits that can be read by the platform via a 32bit data
> register.
> 
> Signed-off-by: Oscar A Perez <linux@neuralgames.com>
> ---
>  .../devicetree/bindings/rng/aspeed-rng.yaml   | 90 +++++++++++++++++++
>  1 file changed, 90 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/aspeed-rng.yaml
> 
> diff --git a/Documentation/devicetree/bindings/rng/aspeed-rng.yaml b/Documentation/devicetree/bindings/rng/aspeed-rng.yaml
> new file mode 100644
> index 000000000000..06070ebe1c33
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/rng/aspeed-rng.yaml
> @@ -0,0 +1,90 @@
> +# SPDX-License-Identifier: GPL-2.0

Dual license new bindings:

(GPL-2.0-only OR BSD-2-Clause)

> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/rng/aspeed-rng.yaml#"
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
> +
> +
> +title: Bindings for Aspeed Hardware Random Number Generator
> +
> +
> +maintainers:
> +  - Oscar A Perez <linux@neuralgames.com>
> +
> +
> +description: |
> +  The HRNG on the AST2400/AST2500/AST2600 SOCs from AspeedTech  uses four Ring
> +  Oscillators working together to generate a stream of random bits that can be
> +  read by the platform via a 32bit data register every one microsecond.
> +  All the platform has to do is to provide to the driver the 'quality' entropy
> +  value, the  'mode' in which the combining  ROs will generate the  stream  of
> +  random bits and, the 'period' value that is used as a wait-time between reads
> +  from the 32bit data register.
> +
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - aspeed,ast2400-rng
> +              - aspeed,ast2500-rng
> +              - aspeed,ast2600-rng

Just:

compatible:
  enum: ...

> +
> +
> +  reg:
> +    description:
> +      Base address and length of the register set of this block.

Drop. That's *every* 'reg' property.

> +      Currently 'reg' must be eight bytes wide and 32-bit aligned.

Currently? Is that going to change? Are things going to break if the DT 
has a bigger size?

> +
> +    maxItems: 1
> +
> +
> +  period:

Needs a vendor prefix and unit suffix.

> +    description:
> +      Wait time in microseconds to be used between reads.
> +      The RNG on these Aspeed SOCs generates 32bit of random data
> +      every one microsecond. Choose between 1 and n microseconds.

Why would you pick something more than 1?

> +
> +    maxItems: 1
> +
> +
> +  mode:

Needs a vendor prefix and a type reference.

> +    description:
> +      One of the eight modes in which the four internal ROs (Ring
> +      Oscillators)  are combined to generate a stream  of random
> +      bits. The default mode is seven which is the default method
> +      of combining RO random bits on these Aspeed SOCs.
> +
> +    maxItems: 1
> +
> +
> +  quality:

Needs a vendor prefix and a type reference.

> +    description:
> +      Estimated number of bits of entropy per 1024 bits read from
> +      the RNG.  Note that the default quality is zero which stops
> +      this HRNG from automatically filling the kernel's entropy
> +      pool with data.
> +
> +    maxItems: 1
> +
> +
> +required:
> +  - compatible
> +  - reg
> +  - period
> +  - quality
> +
> +
> +examples:
> +  - |
> +    rng: hwrng@1e6e2074 {

rng@...

> +         compatible = "aspeed,ast2500-rng";
> +         reg = <0x1e6e2074 0x8>;
> +         period = <4>;
> +         quality = <128>;
> +         mode = <0x7>;
> +    };
> +
> +
> +...
> -- 
> 2.17.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel