hwrng: Add support for ASPEED RNG
Subsystems (4)
PATCH 1/2 hwrng: Add support for ASPEED RNG
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.
--- .../devicetree/bindings/rng/aspeed-rng.yaml | 90 +++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 Documentation/devicetree/bindings/rng/aspeed-rng.yaml
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +90 -0
@@ -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 at 1e6e2074 { + compatible = "aspeed,ast2500-rng"; + reg = <0x1e6e2074 0x8>; + period = <4>; + quality = <128>; + mode = <0x7>; + }; + + +...
Signature · 1 line
2.17.1
PATCH 2/2 hwrng: Add support for ASPEED RNG
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.
--- 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
drivers/char/hw_random/Kconfig +13 -0
@@ -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
drivers/char/hw_random/Makefile +1 -0
@@ -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
drivers/char/hw_random/aspeed-rng.c new file +294 -0
294 lines not on this page · raw message
Signature · 1 line
2.17.1
kbuild test robot
build botThank you for the patch! Yet something to improve:
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
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 at lists.01.org Intel Corporation
Joel Stanley
maintainerHi,
Quoted 7 lines · Oscar A Perez
This minimal driver adds support for the Hardware Random Number Generator that comes with the AST2400/AST2500/AST2600 SOCs from AspeedTech.
The HRNG on these SOCs uses Ring Oscillators working together to generate a stream of random bits that can be read by the platform via a 32bit data register.
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
Quoted 106 lines
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.yamlDocumentation/devicetree/bindings/rng/aspeed-rng.yaml new file +90
-1@@ -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 at 1e6e2074 { + compatible = "aspeed,ast2500-rng"; + reg = <0x1e6e2074 0x8>; + period = <4>; + quality = <128>; + mode = <0x7>; + }; + + +... --2.17.1
Hi Joel,
Quoted 21 lines · Joel Stanley
Hi,
Quoted 10 lines · Oscar A Perez
This minimal driver adds support for the Hardware Random Number Generator
that comes with the AST2400/AST2500/AST2600 SOCs from AspeedTech.The HRNG on these SOCs uses Ring Oscillators working together to generate
a stream of random bits that can be read by the platform via a 32bit data
register.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
Quoted 8 lines
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
Quoted 115 lines
Quoted 115 lines
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.yamlDocumentation/devicetree/bindings/rng/aspeed-rng.yaml new file +16
-0@@ -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 usesfour 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 readsDocumentation/devicetree/bindings/rng/aspeed-rng.yaml new file +69
-1+ 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 at 1e6e2074 { + compatible = "aspeed,ast2500-rng"; + reg = <0x1e6e2074 0x8>; + period = <4>; + quality = <128>; + mode = <0x7>; + }; + + +... --2.17.1
Quoted 10 lines
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).
Quoted 7 lines
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
Quoted 20 lines · Andrew Jeffery
Quoted 10 lines
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).Quoted 9 lines
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.
Quoted 5 lines
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
Quoted 38 lines · linux at neuralgames.com
Quoted 20 lines · Andrew Jeffery
Quoted 10 lines
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).Quoted 9 lines
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.Quoted 5 lines
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 thehw_randomcore driver that
I've been using to collect this data. Here is the link:
https://github.com/operezmuena/aspeed-rng-testing
Quoted 10 lines
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
Quoted 53 lines · Andrew Jeffery
Quoted 39 lines · linux at neuralgames.com
Quoted 20 lines · Andrew Jeffery
Quoted 10 lines
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).Quoted 9 lines
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.Quoted 5 lines
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 thehw_randomcore driver that
I've been using to collect this data. Here is the link:
https://github.com/operezmuena/aspeed-rng-testingQuoted 12 lines
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.
Quoted 6 lines
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.
Quoted 6 lines
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
Quoted 10 lines · linux at neuralgames.com
Quoted 5 lines · Andrew Jeffery
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 :)
Quoted 6 lines
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
Quoted 3 lines · Andrew Jeffery
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"
Rob Herring
maintainerQuoted 2 lines · Oscar A Perez
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.)
Quoted 17 lines
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.yamlDocumentation/devicetree/bindings/rng/aspeed-rng.yaml new file +0
-0
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 1
Quoted 1 line
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +1
-0@@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0
Dual license new bindings:
(GPL-2.0-only OR BSD-2-Clause)
Quoted 21 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +21
-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.
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 32
Quoted 10 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +10
-0+ + +properties: + compatible: + oneOf: + - items: + - enum: + - aspeed,ast2400-rng + - aspeed,ast2500-rng + - aspeed,ast2600-rng
Just:
compatible:
enum: ...
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 37
Quoted 5 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +5
-0+ + + reg: + description: + Base address and length of the register set of this block.
Drop. That's *every* 'reg' property.
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 38
Quoted 1 line
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +1
-0+ 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?
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 43
Quoted 5 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +5
-0+ + maxItems: 1 + + + period:
Needs a vendor prefix and unit suffix.
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 47
Quoted 4 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +4
-0+ 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?
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 52
Quoted 5 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +5
-0+ + maxItems: 1 + + + mode:
Needs a vendor prefix and a type reference.
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 62
Quoted 10 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +10
-0+ 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.
Quoted 9 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +9
-0+ 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 + +
Documentation/devicetree/bindings/rng/aspeed-rng.yaml line 81
Quoted 10 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +10
-0+required: + - compatible + - reg + - period + - quality + + +examples: + - | + rng: hwrng at 1e6e2074 {
rng at ...
Quoted 17 lines
Documentation/devicetree/bindings/rng/aspeed-rng.yaml new file +9
-0+ compatible = "aspeed,ast2500-rng"; + reg = <0x1e6e2074 0x8>; + period = <4>; + quality = <128>; + mode = <0x7>; + }; + + +...Signature · 7 lines
2.17.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel