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 <[email protected]>
---
.../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 <[email protected]>
+
+
+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
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 <[email protected]>
---
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 <[email protected]>
+ *
+ * Derived from drivers/char/hw_random/timeriomem-rng.c
+ * Copyright (C) 2009 Alexander Clouter <[email protected]>
+ *
+ * Derived from drivers/char/hw_random/omap-rng.c
+ * Copyright 2005 (c) MontaVista Software, Inc.
+ * Author: Deepak Saxena <[email protected]>
+ *
+ * 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 <[email protected]>");
+MODULE_DESCRIPTION("Aspeed Ring Oscillator Random Number Generator driver");
--
2.17.1
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 <[email protected]>
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/[email protected] Intel Corporation
Hi,
On Mon, 20 Jan 2020 at 15:12, Oscar A Perez <[email protected]> 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 <[email protected]>
> ---
> .../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 <[email protected]>
> +
> +
> +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
>
Hi Joel,
On 2020-01-20 19:53, Joel Stanley wrote:
> Hi,
>
> On Mon, 20 Jan 2020 at 15:12, Oscar A Perez <[email protected]>
> 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 <[email protected]>
>> ---
>> .../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 <[email protected]>
>> +
>> +
>> +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
>>
> 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
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
On Sat, 25 Jan 2020, at 11:40, [email protected] 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
On 2020-01-27 18:53, Andrew Jeffery wrote:
> On Sat, 25 Jan 2020, at 11:40, [email protected] 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
On Wed, 29 Jan 2020, at 10:56, [email protected] 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
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"
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 <[email protected]>
> ---
> .../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 <[email protected]>
> +
> +
> +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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel