* [PATCH 1/2] hwrng: Add support for ASPEED RNG @ 2020-01-20 15:01 Oscar A Perez 2020-01-20 15:01 ` [PATCH 2/2] " Oscar A Perez ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Oscar A Perez @ 2020-01-20 15:01 UTC (permalink / raw) To: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Joel Stanley, Andrew Jeffery, Oscar A Perez, linux-crypto, devicetree, linux-arm-kernel, linux-aspeed, linux-kernel 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/2] hwrng: Add support for ASPEED RNG 2020-01-20 15:01 [PATCH 1/2] hwrng: Add support for ASPEED RNG Oscar A Perez @ 2020-01-20 15:01 ` Oscar A Perez 2020-01-20 19:21 ` kbuild test robot 2020-01-21 1:53 ` [PATCH 1/2] " Joel Stanley 2020-02-03 10:31 ` Rob Herring 2 siblings, 1 reply; 12+ messages in thread From: Oscar A Perez @ 2020-01-20 15:01 UTC (permalink / raw) To: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Joel Stanley, Andrew Jeffery, Arnd Bergmann, Greg Kroah-Hartman, Oscar A Perez, Krzysztof Kozlowski, Daniel Thompson, Weili Qian, Sumit Garg, Zaibo Xu, Tomer Maimon, Jens Wiklander, linux-crypto, devicetree, linux-arm-kernel, linux-aspeed, linux-kernel 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 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] hwrng: Add support for ASPEED RNG 2020-01-20 15:01 ` [PATCH 2/2] " Oscar A Perez @ 2020-01-20 19:21 ` kbuild test robot 0 siblings, 0 replies; 12+ messages in thread From: kbuild test robot @ 2020-01-20 19:21 UTC (permalink / raw) To: Oscar A Perez Cc: kbuild-all, Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Joel Stanley, Andrew Jeffery, Arnd Bergmann, Greg Kroah-Hartman, Oscar A Perez, Krzysztof Kozlowski, Daniel Thompson, Weili Qian, Sumit Garg, Zaibo Xu, Tomer Maimon, Jens Wiklander, linux-crypto, devicetree, linux-arm-kernel, linux-aspeed, linux-kernel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-01-20 15:01 [PATCH 1/2] hwrng: Add support for ASPEED RNG Oscar A Perez 2020-01-20 15:01 ` [PATCH 2/2] " Oscar A Perez @ 2020-01-21 1:53 ` Joel Stanley 2020-01-23 1:25 ` linux 2020-02-03 10:31 ` Rob Herring 2 siblings, 1 reply; 12+ messages in thread From: Joel Stanley @ 2020-01-21 1:53 UTC (permalink / raw) To: Oscar A Perez Cc: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Andrew Jeffery, Linux Crypto Mailing List, devicetree, Linux ARM, linux-aspeed, Linux Kernel Mailing List 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-01-21 1:53 ` [PATCH 1/2] " Joel Stanley @ 2020-01-23 1:25 ` linux 2020-01-23 1:53 ` Andrew Jeffery 0 siblings, 1 reply; 12+ messages in thread From: linux @ 2020-01-23 1:25 UTC (permalink / raw) To: Joel Stanley Cc: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Andrew Jeffery, Linux Crypto Mailing List, devicetree, Linux ARM, linux-aspeed, Linux Kernel Mailing List 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 >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-01-23 1:25 ` linux @ 2020-01-23 1:53 ` Andrew Jeffery 2020-01-25 1:10 ` linux 0 siblings, 1 reply; 12+ messages in thread From: Andrew Jeffery @ 2020-01-23 1:53 UTC (permalink / raw) To: Oscar A Perez, Joel Stanley Cc: Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Linux Crypto Mailing List, devicetree, Linux ARM, linux-aspeed, Linux Kernel Mailing List > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-01-23 1:53 ` Andrew Jeffery @ 2020-01-25 1:10 ` linux 2020-01-28 0:53 ` Andrew Jeffery 0 siblings, 1 reply; 12+ messages in thread From: linux @ 2020-01-25 1:10 UTC (permalink / raw) To: Andrew Jeffery Cc: Joel Stanley, Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Linux Crypto Mailing List, devicetree, Linux ARM, linux-aspeed, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-01-25 1:10 ` linux @ 2020-01-28 0:53 ` Andrew Jeffery 2020-01-29 0:26 ` linux 0 siblings, 1 reply; 12+ messages in thread From: Andrew Jeffery @ 2020-01-28 0:53 UTC (permalink / raw) To: Oscar A Perez Cc: Joel Stanley, Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Linux Crypto Mailing List, devicetree, Linux ARM, linux-aspeed, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-01-28 0:53 ` Andrew Jeffery @ 2020-01-29 0:26 ` linux 2020-02-03 4:07 ` Andrew Jeffery 0 siblings, 1 reply; 12+ messages in thread From: linux @ 2020-01-29 0:26 UTC (permalink / raw) To: Andrew Jeffery Cc: Joel Stanley, Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Linux Crypto Mailing List, devicetree, Linux ARM, linux-aspeed, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-01-29 0:26 ` linux @ 2020-02-03 4:07 ` Andrew Jeffery 2020-02-03 4:09 ` Andrew Jeffery 0 siblings, 1 reply; 12+ messages in thread From: Andrew Jeffery @ 2020-02-03 4:07 UTC (permalink / raw) To: Oscar A Perez Cc: Joel Stanley, Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Linux Crypto Mailing List, devicetree, Linux ARM, linux-aspeed, Linux Kernel Mailing List 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-02-03 4:07 ` Andrew Jeffery @ 2020-02-03 4:09 ` Andrew Jeffery 0 siblings, 0 replies; 12+ messages in thread From: Andrew Jeffery @ 2020-02-03 4:09 UTC (permalink / raw) To: Oscar A Perez Cc: Joel Stanley, Matt Mackall, Herbert Xu, Rob Herring, Mark Rutland, Linux Crypto Mailing List, devicetree, Linux ARM, linux-aspeed, Linux Kernel Mailing List 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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] hwrng: Add support for ASPEED RNG 2020-01-20 15:01 [PATCH 1/2] hwrng: Add support for ASPEED RNG Oscar A Perez 2020-01-20 15:01 ` [PATCH 2/2] " Oscar A Perez 2020-01-21 1:53 ` [PATCH 1/2] " Joel Stanley @ 2020-02-03 10:31 ` Rob Herring 2 siblings, 0 replies; 12+ messages in thread From: Rob Herring @ 2020-02-03 10:31 UTC (permalink / raw) To: Oscar A Perez Cc: Matt Mackall, Herbert Xu, Mark Rutland, Joel Stanley, Andrew Jeffery, linux-crypto, devicetree, linux-arm-kernel, linux-aspeed, linux-kernel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-02-03 10:32 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-20 15:01 [PATCH 1/2] hwrng: Add support for ASPEED RNG Oscar A Perez 2020-01-20 15:01 ` [PATCH 2/2] " Oscar A Perez 2020-01-20 19:21 ` kbuild test robot 2020-01-21 1:53 ` [PATCH 1/2] " Joel Stanley 2020-01-23 1:25 ` linux 2020-01-23 1:53 ` Andrew Jeffery 2020-01-25 1:10 ` linux 2020-01-28 0:53 ` Andrew Jeffery 2020-01-29 0:26 ` linux 2020-02-03 4:07 ` Andrew Jeffery 2020-02-03 4:09 ` Andrew Jeffery 2020-02-03 10:31 ` Rob Herring
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).