[PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Daniel Golle]

Rockchip SoCs used to have a random number generator as part of their
crypto device.

However newer Rockchip SoCs like the RK3568 have an independent True
Random Number Generator device. This patchset adds a driver for it and
enables it in the device tree.

Tested on FriendlyARM NanoPi R5C.

v6 -> v7:
 * Patch 1: unchanged

 * Patch 2: bring back rk_rng_write_ctl()
   - bring back rk_rng_write_ctl() with improved comment to describe
     the hardware.

 * Patch 3: unchaned

v5 -> v6:
 * Patch 1: unchanged

 * Patch 2: get rid of #ifdef
   - use if (IS_ENABLED(...)) { ... }instead of #ifdef inside functions
   - use __maybe_unused for functions previously enclosed by #ifdef'ery

 * Patch 3: unchanged

v4 -> v5:
 * Patch 1: always use RK3568 name
   - use full RK3568 name in patch description
   - add RK3568 to title in binding

 * Patch 2: full name and cosmetics
   - also always mention RK3568 as there may be other RNG in other
     (future) Rockchip SoCs
   - remove debug output on successful probe
   - use MODULE_AUTHOR several times instead of single comma-separated

 * Patch 3: unchanged

v3 -> v4:
 * Patch 1: minor corrections
   - fix Rokchip -> Rockchip typo
   - change commit title as requested

 * Patch 2: improved error handling and resource management
   - Always use writel() instead of writel_relaxed()
   - Use pm_runtime_resume_and_get
   - Correctly return error code in rk_rng_read()
   - Make use of devm_reset_control_array_get_exclusive
   - Use devm_pm_runtime_enable and there by get rid of rk_rng_remove()

 * Patch 3:
   - Move node to conform with ordering by address

v2 -> v3: patch adopted by Daniel Golle
 * Patch 1: address comments of Krzysztof Kozlowski, add MAINTAINERS
   - improved description
   - meaningful clock-names
   - add entry in MAINTAINERS files

 * Patch 2: numerous code-style improvements
   - drop misleading rk_rng_write_ctl(), simplify I/O writes
   - drop unused TRNG_RNG_DOUT_[1-7] macros
   - handle error handling for pm_runtime_get_sync()
   - use memcpy_fromio() instead of open coding for-loop
   - some minor white-spaces fixes

 * Patch 3:
   - use clock-names as defined in dt-bindings

v1 -> v2:
 * Patch 1: fix issues reported by Rob Herring and Krzysztof Kozlowski:
   - Rename rockchip-rng.yaml into rockchip,rk3568-rng.yaml
   - Fix binding title and description
   - Fix compatible property
   - Rename clocks and add the corresponding descriptions
   - Drop reset-names
   - Add a bus definition with #address-cells and #size-cells to the
     example.

 * Patch 2: fix issue reported by kernel test robot <lkp@intel.com>
   - Do not read the random registers as big endian, looking at the
     RK3568 TRM this is actually not needed. This fixes a sparse
     warning.

 * Patch 3: unchanged


Aurelien Jarno (3):
  dt-bindings: rng: Add Rockchip RK3568 TRNG
  hwrng: add hwrng driver for Rockchip RK3568 SoC
  arm64: dts: rockchip: add DT entry for RNG to RK356x

 .../bindings/rng/rockchip,rk3568-rng.yaml     |  61 +++++
 MAINTAINERS                                   |   7 +
 arch/arm64/boot/dts/rockchip/rk356x.dtsi      |   9 +
 drivers/char/hw_random/Kconfig                |  14 ++
 drivers/char/hw_random/Makefile               |   1 +
 drivers/char/hw_random/rockchip-rng.c         | 227 ++++++++++++++++++
 6 files changed, 319 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
 create mode 100644 drivers/char/hw_random/rockchip-rng.c

-- 
2.45.2

[PATCH v7 1/3] dt-bindings: rng: Add Rockchip RK3568 TRNG

[Daniel Golle]

From: Aurelien Jarno <aurelien@aurel32.net>

Add the True Random Number Generator on the Rockchip RK3568 SoC.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 .../bindings/rng/rockchip,rk3568-rng.yaml     | 61 +++++++++++++++++++
 MAINTAINERS                                   |  6 ++
 2 files changed, 67 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml

diff --git a/Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml b/Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
new file mode 100644
index 000000000000..e0595814a6d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rng/rockchip,rk3568-rng.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip RK3568 TRNG
+
+description: True Random Number Generator on Rockchip RK3568 SoC
+
+maintainers:
+  - Aurelien Jarno <aurelien@aurel32.net>
+  - Daniel Golle <daniel@makrotopia.org>
+
+properties:
+  compatible:
+    enum:
+      - rockchip,rk3568-rng
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: TRNG clock
+      - description: TRNG AHB clock
+
+  clock-names:
+    items:
+      - const: core
+      - const: ahb
+
+  resets:
+    maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rk3568-cru.h>
+    bus {
+      #address-cells = <2>;
+      #size-cells = <2>;
+
+      rng@fe388000 {
+        compatible = "rockchip,rk3568-rng";
+        reg = <0x0 0xfe388000 0x0 0x4000>;
+        clocks = <&cru CLK_TRNG_NS>, <&cru HCLK_TRNG_NS>;
+        clock-names = "core", "ahb";
+        resets = <&cru SRST_TRNG_NS>;
+      };
+    };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index fb1df8c29f5a..7b2b8b1f526c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19693,6 +19693,12 @@ F:	Documentation/userspace-api/media/v4l/metafmt-rkisp1.rst
 F:	drivers/media/platform/rockchip/rkisp1
 F:	include/uapi/linux/rkisp1-config.h
 
+ROCKCHIP RK3568 RANDOM NUMBER GENERATOR SUPPORT
+M:	Daniel Golle <daniel@makrotopia.org>
+M:	Aurelien Jarno <aurelien@aurel32.net>
+S:	Maintained
+F:	Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
+
 ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
 M:	Jacob Chen <jacob-chen@iotwrt.com>
 M:	Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
-- 
2.45.2

[PATCH v7 2/3] hwrng: add hwrng driver for Rockchip RK3568 SoC

[Daniel Golle]

From: Aurelien Jarno <aurelien@aurel32.net>

Rockchip SoCs used to have a random number generator as part of their
crypto device, and support for it has to be added to the corresponding
driver. However newer Rockchip SoCs like the RK3568 have an independent
True Random Number Generator device. This patch adds a driver for it,
greatly inspired from the downstream driver.

The TRNG device does not seem to have a signal conditionner and the FIPS
140-2 test returns a lot of failures. They can be reduced by increasing
RK_RNG_SAMPLE_CNT, in a tradeoff between quality and speed. This value
has been adjusted to get ~90% of successes and the quality value has
been set accordingly.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
[daniel@makrotpia.org: code style fixes]
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
 MAINTAINERS                           |   1 +
 drivers/char/hw_random/Kconfig        |  14 ++
 drivers/char/hw_random/Makefile       |   1 +
 drivers/char/hw_random/rockchip-rng.c | 227 ++++++++++++++++++++++++++
 4 files changed, 243 insertions(+)
 create mode 100644 drivers/char/hw_random/rockchip-rng.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 7b2b8b1f526c..2745cfe56774 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19698,6 +19698,7 @@ M:	Daniel Golle <daniel@makrotopia.org>
 M:	Aurelien Jarno <aurelien@aurel32.net>
 S:	Maintained
 F:	Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
+F:	drivers/char/hw_random/rockchip-rng.c
 
 ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
 M:	Jacob Chen <jacob-chen@iotwrt.com>
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 442c40efb200..2b62cd08f91a 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -573,6 +573,20 @@ config HW_RANDOM_JH7110
 	  To compile this driver as a module, choose M here.
 	  The module will be called jh7110-trng.
 
+config HW_RANDOM_ROCKCHIP
+	tristate "Rockchip True Random Number Generator"
+	depends on HW_RANDOM && (ARCH_ROCKCHIP || COMPILE_TEST)
+	depends on HAS_IOMEM
+	default HW_RANDOM
+	help
+	  This driver provides kernel-side support for the True Random Number
+	  Generator hardware found on some Rockchip SoC like RK3566 or RK3568.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called rockchip-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 32549a1186dc..01f012eab440 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -48,4 +48,5 @@ obj-$(CONFIG_HW_RANDOM_XIPHERA) += xiphera-trng.o
 obj-$(CONFIG_HW_RANDOM_ARM_SMCCC_TRNG) += arm_smccc_trng.o
 obj-$(CONFIG_HW_RANDOM_CN10K) += cn10k-rng.o
 obj-$(CONFIG_HW_RANDOM_POLARFIRE_SOC) += mpfs-rng.o
+obj-$(CONFIG_HW_RANDOM_ROCKCHIP) += rockchip-rng.o
 obj-$(CONFIG_HW_RANDOM_JH7110) += jh7110-trng.o
diff --git a/drivers/char/hw_random/rockchip-rng.c b/drivers/char/hw_random/rockchip-rng.c
new file mode 100644
index 000000000000..a8ccaf14c2c2
--- /dev/null
+++ b/drivers/char/hw_random/rockchip-rng.c
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rockchip-rng.c True Random Number Generator driver for Rockchip RK3568 SoC
+ *
+ * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd.
+ * Copyright (c) 2022, Aurelien Jarno
+ * Authors:
+ *  Lin Jinhan <troy.lin@rock-chips.com>
+ *  Aurelien Jarno <aurelien@aurel32.net>
+ */
+#include <linux/clk.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/reset.h>
+#include <linux/slab.h>
+
+#define RK_RNG_AUTOSUSPEND_DELAY	100
+#define RK_RNG_MAX_BYTE			32
+#define RK_RNG_POLL_PERIOD_US		100
+#define RK_RNG_POLL_TIMEOUT_US		10000
+
+/*
+ * TRNG collects osc ring output bit every RK_RNG_SAMPLE_CNT time. The value is
+ * a tradeoff between speed and quality and has been adjusted to get a quality
+ * of ~900 (~90% of FIPS 140-2 successes).
+ */
+#define RK_RNG_SAMPLE_CNT		1000
+
+/* TRNG registers from RK3568 TRM-Part2, section 5.4.1 */
+#define TRNG_RST_CTL			0x0004
+#define TRNG_RNG_CTL			0x0400
+#define TRNG_RNG_CTL_LEN_64_BIT		(0x00 << 4)
+#define TRNG_RNG_CTL_LEN_128_BIT	(0x01 << 4)
+#define TRNG_RNG_CTL_LEN_192_BIT	(0x02 << 4)
+#define TRNG_RNG_CTL_LEN_256_BIT	(0x03 << 4)
+#define TRNG_RNG_CTL_OSC_RING_SPEED_0	(0x00 << 2)
+#define TRNG_RNG_CTL_OSC_RING_SPEED_1	(0x01 << 2)
+#define TRNG_RNG_CTL_OSC_RING_SPEED_2	(0x02 << 2)
+#define TRNG_RNG_CTL_OSC_RING_SPEED_3	(0x03 << 2)
+#define TRNG_RNG_CTL_MASK		GENMASK(15, 0)
+#define TRNG_RNG_CTL_ENABLE		BIT(1)
+#define TRNG_RNG_CTL_START		BIT(0)
+#define TRNG_RNG_SAMPLE_CNT		0x0404
+#define TRNG_RNG_DOUT			0x0410
+
+struct rk_rng {
+	struct hwrng rng;
+	void __iomem *base;
+	struct reset_control *rst;
+	int clk_num;
+	struct clk_bulk_data *clk_bulks;
+};
+
+/* The mask in the upper 16 bits determines the bits that are updated */
+static void rk_rng_write_ctl(struct rk_rng *rng, u32 val, u32 mask)
+{
+	writel((mask << 16) | val, rng->base + TRNG_RNG_CTL);
+}
+
+static int rk_rng_init(struct hwrng *rng)
+{
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+	int ret;
+
+	/* start clocks */
+	ret = clk_bulk_prepare_enable(rk_rng->clk_num, rk_rng->clk_bulks);
+	if (ret < 0) {
+		dev_err((struct device *) rk_rng->rng.priv,
+			"Failed to enable clks %d\n", ret);
+		return ret;
+	}
+
+	/* set the sample period */
+	writel(RK_RNG_SAMPLE_CNT, rk_rng->base + TRNG_RNG_SAMPLE_CNT);
+
+	/* set osc ring speed and enable it */
+	rk_rng_write_ctl(rk_rng, TRNG_RNG_CTL_LEN_256_BIT |
+				 TRNG_RNG_CTL_OSC_RING_SPEED_0 |
+				 TRNG_RNG_CTL_ENABLE,
+			 TRNG_RNG_CTL_MASK);
+
+	return 0;
+}
+
+static void rk_rng_cleanup(struct hwrng *rng)
+{
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+
+	/* stop TRNG */
+	rk_rng_write_ctl(rk_rng, 0, TRNG_RNG_CTL_MASK);
+
+	/* stop clocks */
+	clk_bulk_disable_unprepare(rk_rng->clk_num, rk_rng->clk_bulks);
+}
+
+static int rk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+	size_t to_read = min_t(size_t, max, RK_RNG_MAX_BYTE);
+	u32 reg;
+	int ret = 0;
+
+	ret = pm_runtime_resume_and_get((struct device *) rk_rng->rng.priv);
+	if (ret < 0)
+		return ret;
+
+	/* Start collecting random data */
+	rk_rng_write_ctl(rk_rng, TRNG_RNG_CTL_START, TRNG_RNG_CTL_START);
+
+	ret = readl_poll_timeout(rk_rng->base + TRNG_RNG_CTL, reg,
+				 !(reg & TRNG_RNG_CTL_START),
+				 RK_RNG_POLL_PERIOD_US,
+				 RK_RNG_POLL_TIMEOUT_US);
+	if (ret < 0)
+		goto out;
+
+	/* Read random data stored in the registers */
+	memcpy_fromio(buf, rk_rng->base + TRNG_RNG_DOUT, to_read);
+out:
+	pm_runtime_mark_last_busy((struct device *) rk_rng->rng.priv);
+	pm_runtime_put_sync_autosuspend((struct device *) rk_rng->rng.priv);
+
+	return (ret < 0) ? ret : to_read;
+}
+
+static int rk_rng_probe(struct platform_device *pdev)
+{
+	struct device *dev = &pdev->dev;
+	struct rk_rng *rk_rng;
+	int ret;
+
+	rk_rng = devm_kzalloc(dev, sizeof(*rk_rng), GFP_KERNEL);
+	if (!rk_rng)
+		return -ENOMEM;
+
+	rk_rng->base = devm_platform_ioremap_resource(pdev, 0);
+	if (IS_ERR(rk_rng->base))
+		return PTR_ERR(rk_rng->base);
+
+	rk_rng->clk_num = devm_clk_bulk_get_all(dev, &rk_rng->clk_bulks);
+	if (rk_rng->clk_num < 0)
+		return dev_err_probe(dev, rk_rng->clk_num,
+				     "Failed to get clks property\n");
+
+	rk_rng->rst = devm_reset_control_array_get_exclusive(&pdev->dev);
+	if (IS_ERR(rk_rng->rst))
+		return dev_err_probe(dev, PTR_ERR(rk_rng->rst),
+				     "Failed to get reset property\n");
+
+	reset_control_assert(rk_rng->rst);
+	udelay(2);
+	reset_control_deassert(rk_rng->rst);
+
+	platform_set_drvdata(pdev, rk_rng);
+
+	rk_rng->rng.name = dev_driver_string(dev);
+	if (!IS_ENABLED(CONFIG_PM)) {
+		rk_rng->rng.init = rk_rng_init;
+		rk_rng->rng.cleanup = rk_rng_cleanup;
+	}
+	rk_rng->rng.read = rk_rng_read;
+	rk_rng->rng.priv = (unsigned long) dev;
+	rk_rng->rng.quality = 900;
+
+	pm_runtime_set_autosuspend_delay(dev, RK_RNG_AUTOSUSPEND_DELAY);
+	pm_runtime_use_autosuspend(dev);
+	devm_pm_runtime_enable(dev);
+
+	ret = devm_hwrng_register(dev, &rk_rng->rng);
+	if (ret)
+		return dev_err_probe(&pdev->dev, ret, "Failed to register Rockchip hwrng\n");
+
+	return 0;
+}
+
+static int __maybe_unused rk_rng_runtime_suspend(struct device *dev)
+{
+	struct rk_rng *rk_rng = dev_get_drvdata(dev);
+
+	rk_rng_cleanup(&rk_rng->rng);
+
+	return 0;
+}
+
+static int __maybe_unused rk_rng_runtime_resume(struct device *dev)
+{
+	struct rk_rng *rk_rng = dev_get_drvdata(dev);
+
+	return rk_rng_init(&rk_rng->rng);
+}
+
+static const struct dev_pm_ops rk_rng_pm_ops = {
+	SET_RUNTIME_PM_OPS(rk_rng_runtime_suspend,
+				rk_rng_runtime_resume, NULL)
+	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+				pm_runtime_force_resume)
+};
+
+static const struct of_device_id rk_rng_dt_match[] = {
+	{ .compatible = "rockchip,rk3568-rng", },
+	{ /* sentinel */ },
+};
+
+MODULE_DEVICE_TABLE(of, rk_rng_dt_match);
+
+static struct platform_driver rk_rng_driver = {
+	.driver	= {
+		.name	= "rockchip-rng",
+		.pm	= &rk_rng_pm_ops,
+		.of_match_table = rk_rng_dt_match,
+	},
+	.probe	= rk_rng_probe,
+};
+
+module_platform_driver(rk_rng_driver);
+
+MODULE_DESCRIPTION("Rockchip RK3568 True Random Number Generator driver");
+MODULE_AUTHOR("Lin Jinhan <troy.lin@rock-chips.com>");
+MODULE_AUTHOR("Aurelien Jarno <aurelien@aurel32.net>");
+MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
+MODULE_LICENSE("GPL");
-- 
2.45.2

[PATCH v7 3/3] arm64: dts: rockchip: add DT entry for RNG to RK356x

[Daniel Golle]

From: Aurelien Jarno <aurelien@aurel32.net>

Enable the just added Rockchip RNG driver for RK356x SoCs.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
 arch/arm64/boot/dts/rockchip/rk356x.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
index 4690be841a1c..78377e7d1d6d 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
@@ -1113,6 +1113,15 @@ sdhci: mmc@fe310000 {
 		status = "disabled";
 	};
 
+	rng: rng@fe388000 {
+		compatible = "rockchip,rk3568-rng";
+		reg = <0x0 0xfe388000 0x0 0x4000>;
+		clocks = <&cru CLK_TRNG_NS>, <&cru HCLK_TRNG_NS>;
+		clock-names = "core", "ahb";
+		resets = <&cru SRST_TRNG_NS>;
+		reset-names = "reset";
+	};
+
 	i2s0_8ch: i2s@fe400000 {
 		compatible = "rockchip,rk3568-i2s-tdm";
 		reg = <0x0 0xfe400000 0x0 0x1000>;
-- 
2.45.2

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Chen-Yu Tsai]

On Sun, Jul 14, 2024 at 11:16 PM Daniel Golle <daniel@makrotopia.org> wrote:
>
> Rockchip SoCs used to have a random number generator as part of their
> crypto device.
>
> However newer Rockchip SoCs like the RK3568 have an independent True
> Random Number Generator device. This patchset adds a driver for it and
> enables it in the device tree.
>
> Tested on FriendlyARM NanoPi R5C.
>
> v6 -> v7:
>  * Patch 1: unchanged
>
>  * Patch 2: bring back rk_rng_write_ctl()
>    - bring back rk_rng_write_ctl() with improved comment to describe
>      the hardware.
>
>  * Patch 3: unchaned
>
> v5 -> v6:
>  * Patch 1: unchanged
>
>  * Patch 2: get rid of #ifdef
>    - use if (IS_ENABLED(...)) { ... }instead of #ifdef inside functions
>    - use __maybe_unused for functions previously enclosed by #ifdef'ery
>
>  * Patch 3: unchanged
>
> v4 -> v5:
>  * Patch 1: always use RK3568 name
>    - use full RK3568 name in patch description
>    - add RK3568 to title in binding
>
>  * Patch 2: full name and cosmetics
>    - also always mention RK3568 as there may be other RNG in other
>      (future) Rockchip SoCs
>    - remove debug output on successful probe
>    - use MODULE_AUTHOR several times instead of single comma-separated
>
>  * Patch 3: unchanged
>
> v3 -> v4:
>  * Patch 1: minor corrections
>    - fix Rokchip -> Rockchip typo
>    - change commit title as requested
>
>  * Patch 2: improved error handling and resource management
>    - Always use writel() instead of writel_relaxed()
>    - Use pm_runtime_resume_and_get
>    - Correctly return error code in rk_rng_read()
>    - Make use of devm_reset_control_array_get_exclusive
>    - Use devm_pm_runtime_enable and there by get rid of rk_rng_remove()
>
>  * Patch 3:
>    - Move node to conform with ordering by address
>
> v2 -> v3: patch adopted by Daniel Golle
>  * Patch 1: address comments of Krzysztof Kozlowski, add MAINTAINERS
>    - improved description
>    - meaningful clock-names
>    - add entry in MAINTAINERS files
>
>  * Patch 2: numerous code-style improvements
>    - drop misleading rk_rng_write_ctl(), simplify I/O writes
>    - drop unused TRNG_RNG_DOUT_[1-7] macros
>    - handle error handling for pm_runtime_get_sync()
>    - use memcpy_fromio() instead of open coding for-loop
>    - some minor white-spaces fixes
>
>  * Patch 3:
>    - use clock-names as defined in dt-bindings
>
> v1 -> v2:
>  * Patch 1: fix issues reported by Rob Herring and Krzysztof Kozlowski:
>    - Rename rockchip-rng.yaml into rockchip,rk3568-rng.yaml
>    - Fix binding title and description
>    - Fix compatible property
>    - Rename clocks and add the corresponding descriptions
>    - Drop reset-names
>    - Add a bus definition with #address-cells and #size-cells to the
>      example.
>
>  * Patch 2: fix issue reported by kernel test robot <lkp@intel.com>
>    - Do not read the random registers as big endian, looking at the
>      RK3568 TRM this is actually not needed. This fixes a sparse
>      warning.
>
>  * Patch 3: unchanged
>
>
> Aurelien Jarno (3):
>   dt-bindings: rng: Add Rockchip RK3568 TRNG
>   hwrng: add hwrng driver for Rockchip RK3568 SoC
>   arm64: dts: rockchip: add DT entry for RNG to RK356x

Tested-by: Chen-Yu Tsai <wens@csie.org>

>  .../bindings/rng/rockchip,rk3568-rng.yaml     |  61 +++++
>  MAINTAINERS                                   |   7 +
>  arch/arm64/boot/dts/rockchip/rk356x.dtsi      |   9 +
>  drivers/char/hw_random/Kconfig                |  14 ++
>  drivers/char/hw_random/Makefile               |   1 +
>  drivers/char/hw_random/rockchip-rng.c         | 227 ++++++++++++++++++
>  6 files changed, 319 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
>  create mode 100644 drivers/char/hw_random/rockchip-rng.c
>
> --
> 2.45.2

Re: [PATCH v7 2/3] hwrng: add hwrng driver for Rockchip RK3568 SoC

[Martin Kaiser]

Hi,

Thus wrote Daniel Golle (daniel@makrotopia.org):

> From: Aurelien Jarno <aurelien@aurel32.net>

> Rockchip SoCs used to have a random number generator as part of their
> crypto device, and support for it has to be added to the corresponding
> driver. However newer Rockchip SoCs like the RK3568 have an independent
> True Random Number Generator device. This patch adds a driver for it,
> greatly inspired from the downstream driver.

> The TRNG device does not seem to have a signal conditionner and the FIPS
> 140-2 test returns a lot of failures. They can be reduced by increasing
> RK_RNG_SAMPLE_CNT, in a tradeoff between quality and speed. This value
> has been adjusted to get ~90% of successes and the quality value has
> been set accordingly.

> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> [daniel@makrotpia.org: code style fixes]
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
>  MAINTAINERS                           |   1 +
>  drivers/char/hw_random/Kconfig        |  14 ++
>  drivers/char/hw_random/Makefile       |   1 +
>  drivers/char/hw_random/rockchip-rng.c | 227 ++++++++++++++++++++++++++
>  4 files changed, 243 insertions(+)
>  create mode 100644 drivers/char/hw_random/rockchip-rng.c

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7b2b8b1f526c..2745cfe56774 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19698,6 +19698,7 @@ M:	Daniel Golle <daniel@makrotopia.org>
>  M:	Aurelien Jarno <aurelien@aurel32.net>
>  S:	Maintained
>  F:	Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml
> +F:	drivers/char/hw_random/rockchip-rng.c

>  ROCKCHIP RASTER 2D GRAPHIC ACCELERATION UNIT DRIVER
>  M:	Jacob Chen <jacob-chen@iotwrt.com>
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 442c40efb200..2b62cd08f91a 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -573,6 +573,20 @@ config HW_RANDOM_JH7110
>  	  To compile this driver as a module, choose M here.
>  	  The module will be called jh7110-trng.

> +config HW_RANDOM_ROCKCHIP
> +	tristate "Rockchip True Random Number Generator"
> +	depends on HW_RANDOM && (ARCH_ROCKCHIP || COMPILE_TEST)
> +	depends on HAS_IOMEM
> +	default HW_RANDOM
> +	help
> +	  This driver provides kernel-side support for the True Random Number
> +	  Generator hardware found on some Rockchip SoC like RK3566 or RK3568.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called rockchip-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 32549a1186dc..01f012eab440 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -48,4 +48,5 @@ obj-$(CONFIG_HW_RANDOM_XIPHERA) += xiphera-trng.o
>  obj-$(CONFIG_HW_RANDOM_ARM_SMCCC_TRNG) += arm_smccc_trng.o
>  obj-$(CONFIG_HW_RANDOM_CN10K) += cn10k-rng.o
>  obj-$(CONFIG_HW_RANDOM_POLARFIRE_SOC) += mpfs-rng.o
> +obj-$(CONFIG_HW_RANDOM_ROCKCHIP) += rockchip-rng.o
>  obj-$(CONFIG_HW_RANDOM_JH7110) += jh7110-trng.o
> diff --git a/drivers/char/hw_random/rockchip-rng.c b/drivers/char/hw_random/rockchip-rng.c
> new file mode 100644
> index 000000000000..a8ccaf14c2c2
> --- /dev/null
> +++ b/drivers/char/hw_random/rockchip-rng.c
> @@ -0,0 +1,227 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * rockchip-rng.c True Random Number Generator driver for Rockchip RK3568 SoC
> + *
> + * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd.
> + * Copyright (c) 2022, Aurelien Jarno
> + * Authors:
> + *  Lin Jinhan <troy.lin@rock-chips.com>
> + *  Aurelien Jarno <aurelien@aurel32.net>
> + */
> +#include <linux/clk.h>
> +#include <linux/hw_random.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +
> +#define RK_RNG_AUTOSUSPEND_DELAY	100
> +#define RK_RNG_MAX_BYTE			32
> +#define RK_RNG_POLL_PERIOD_US		100
> +#define RK_RNG_POLL_TIMEOUT_US		10000
> +
> +/*
> + * TRNG collects osc ring output bit every RK_RNG_SAMPLE_CNT time. The value is
> + * a tradeoff between speed and quality and has been adjusted to get a quality
> + * of ~900 (~90% of FIPS 140-2 successes).
> + */
> +#define RK_RNG_SAMPLE_CNT		1000
> +
> +/* TRNG registers from RK3568 TRM-Part2, section 5.4.1 */
> +#define TRNG_RST_CTL			0x0004
> +#define TRNG_RNG_CTL			0x0400
> +#define TRNG_RNG_CTL_LEN_64_BIT		(0x00 << 4)
> +#define TRNG_RNG_CTL_LEN_128_BIT	(0x01 << 4)
> +#define TRNG_RNG_CTL_LEN_192_BIT	(0x02 << 4)
> +#define TRNG_RNG_CTL_LEN_256_BIT	(0x03 << 4)
> +#define TRNG_RNG_CTL_OSC_RING_SPEED_0	(0x00 << 2)
> +#define TRNG_RNG_CTL_OSC_RING_SPEED_1	(0x01 << 2)
> +#define TRNG_RNG_CTL_OSC_RING_SPEED_2	(0x02 << 2)
> +#define TRNG_RNG_CTL_OSC_RING_SPEED_3	(0x03 << 2)
> +#define TRNG_RNG_CTL_MASK		GENMASK(15, 0)
> +#define TRNG_RNG_CTL_ENABLE		BIT(1)
> +#define TRNG_RNG_CTL_START		BIT(0)
> +#define TRNG_RNG_SAMPLE_CNT		0x0404
> +#define TRNG_RNG_DOUT			0x0410
> +
> +struct rk_rng {
> +	struct hwrng rng;
> +	void __iomem *base;
> +	struct reset_control *rst;

does it make sense to store rst here? it's used only in the probe function.

> +	int clk_num;
> +	struct clk_bulk_data *clk_bulks;
> +};
> +
> +/* The mask in the upper 16 bits determines the bits that are updated */
> +static void rk_rng_write_ctl(struct rk_rng *rng, u32 val, u32 mask)
> +{
> +	writel((mask << 16) | val, rng->base + TRNG_RNG_CTL);
> +}
> +
> +static int rk_rng_init(struct hwrng *rng)
> +{
> +	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
> +	int ret;
> +
> +	/* start clocks */
> +	ret = clk_bulk_prepare_enable(rk_rng->clk_num, rk_rng->clk_bulks);
> +	if (ret < 0) {
> +		dev_err((struct device *) rk_rng->rng.priv,
> +			"Failed to enable clks %d\n", ret);
> +		return ret;
> +	}
> +
> +	/* set the sample period */
> +	writel(RK_RNG_SAMPLE_CNT, rk_rng->base + TRNG_RNG_SAMPLE_CNT);
> +
> +	/* set osc ring speed and enable it */
> +	rk_rng_write_ctl(rk_rng, TRNG_RNG_CTL_LEN_256_BIT |
> +				 TRNG_RNG_CTL_OSC_RING_SPEED_0 |
> +				 TRNG_RNG_CTL_ENABLE,
> +			 TRNG_RNG_CTL_MASK);
> +
> +	return 0;
> +}
> +
> +static void rk_rng_cleanup(struct hwrng *rng)
> +{
> +	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
> +
> +	/* stop TRNG */
> +	rk_rng_write_ctl(rk_rng, 0, TRNG_RNG_CTL_MASK);
> +
> +	/* stop clocks */
> +	clk_bulk_disable_unprepare(rk_rng->clk_num, rk_rng->clk_bulks);
> +}
> +
> +static int rk_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> +	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
> +	size_t to_read = min_t(size_t, max, RK_RNG_MAX_BYTE);
> +	u32 reg;
> +	int ret = 0;

no need to initialise ret, it's overwritten immediately

> +
> +	ret = pm_runtime_resume_and_get((struct device *) rk_rng->rng.priv);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Start collecting random data */
> +	rk_rng_write_ctl(rk_rng, TRNG_RNG_CTL_START, TRNG_RNG_CTL_START);
> +
> +	ret = readl_poll_timeout(rk_rng->base + TRNG_RNG_CTL, reg,
> +				 !(reg & TRNG_RNG_CTL_START),
> +				 RK_RNG_POLL_PERIOD_US,
> +				 RK_RNG_POLL_TIMEOUT_US);
> +	if (ret < 0)
> +		goto out;
> +
> +	/* Read random data stored in the registers */
> +	memcpy_fromio(buf, rk_rng->base + TRNG_RNG_DOUT, to_read);
> +out:
> +	pm_runtime_mark_last_busy((struct device *) rk_rng->rng.priv);
> +	pm_runtime_put_sync_autosuspend((struct device *) rk_rng->rng.priv);
> +
> +	return (ret < 0) ? ret : to_read;
> +}
> +
> +static int rk_rng_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct rk_rng *rk_rng;
> +	int ret;
> +
> +	rk_rng = devm_kzalloc(dev, sizeof(*rk_rng), GFP_KERNEL);
> +	if (!rk_rng)
> +		return -ENOMEM;
> +
> +	rk_rng->base = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(rk_rng->base))
> +		return PTR_ERR(rk_rng->base);
> +
> +	rk_rng->clk_num = devm_clk_bulk_get_all(dev, &rk_rng->clk_bulks);
> +	if (rk_rng->clk_num < 0)
> +		return dev_err_probe(dev, rk_rng->clk_num,
> +				     "Failed to get clks property\n");
> +
> +	rk_rng->rst = devm_reset_control_array_get_exclusive(&pdev->dev);
> +	if (IS_ERR(rk_rng->rst))
> +		return dev_err_probe(dev, PTR_ERR(rk_rng->rst),
> +				     "Failed to get reset property\n");
> +
> +	reset_control_assert(rk_rng->rst);
> +	udelay(2);
> +	reset_control_deassert(rk_rng->rst);
> +
> +	platform_set_drvdata(pdev, rk_rng);
> +
> +	rk_rng->rng.name = dev_driver_string(dev);
> +	if (!IS_ENABLED(CONFIG_PM)) {
> +		rk_rng->rng.init = rk_rng_init;
> +		rk_rng->rng.cleanup = rk_rng_cleanup;
> +	}
> +	rk_rng->rng.read = rk_rng_read;
> +	rk_rng->rng.priv = (unsigned long) dev;
> +	rk_rng->rng.quality = 900;
> +
> +	pm_runtime_set_autosuspend_delay(dev, RK_RNG_AUTOSUSPEND_DELAY);
> +	pm_runtime_use_autosuspend(dev);
> +	devm_pm_runtime_enable(dev);

could this fail? is it worth checking the return value?

> +
> +	ret = devm_hwrng_register(dev, &rk_rng->rng);
> +	if (ret)
> +		return dev_err_probe(&pdev->dev, ret, "Failed to register Rockchip hwrng\n");
> +
> +	return 0;
> +}
> +
> +static int __maybe_unused rk_rng_runtime_suspend(struct device *dev)
> +{
> +	struct rk_rng *rk_rng = dev_get_drvdata(dev);
> +
> +	rk_rng_cleanup(&rk_rng->rng);
> +
> +	return 0;
> +}
> +
> +static int __maybe_unused rk_rng_runtime_resume(struct device *dev)
> +{
> +	struct rk_rng *rk_rng = dev_get_drvdata(dev);
> +
> +	return rk_rng_init(&rk_rng->rng);
> +}
> +
> +static const struct dev_pm_ops rk_rng_pm_ops = {
> +	SET_RUNTIME_PM_OPS(rk_rng_runtime_suspend,
> +				rk_rng_runtime_resume, NULL)
> +	SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> +				pm_runtime_force_resume)
> +};
> +
> +static const struct of_device_id rk_rng_dt_match[] = {
> +	{ .compatible = "rockchip,rk3568-rng", },
> +	{ /* sentinel */ },
> +};
> +
> +MODULE_DEVICE_TABLE(of, rk_rng_dt_match);
> +
> +static struct platform_driver rk_rng_driver = {
> +	.driver	= {
> +		.name	= "rockchip-rng",
> +		.pm	= &rk_rng_pm_ops,
> +		.of_match_table = rk_rng_dt_match,
> +	},
> +	.probe	= rk_rng_probe,
> +};
> +
> +module_platform_driver(rk_rng_driver);
> +
> +MODULE_DESCRIPTION("Rockchip RK3568 True Random Number Generator driver");
> +MODULE_AUTHOR("Lin Jinhan <troy.lin@rock-chips.com>");
> +MODULE_AUTHOR("Aurelien Jarno <aurelien@aurel32.net>");
> +MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
> +MODULE_LICENSE("GPL");
> -- 
> 2.45.2

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 2395 bytes --]

On Sunday, 14 July 2024 17:15:35 CEST Daniel Golle wrote:
> Rockchip SoCs used to have a random number generator as part of their
> crypto device.
> 
> However newer Rockchip SoCs like the RK3568 have an independent True
> Random Number Generator device. This patchset adds a driver for it and
> enables it in the device tree.
> 
> Tested on FriendlyARM NanoPi R5C.
> 
> ...
> 
> Aurelien Jarno (3):
>   dt-bindings: rng: Add Rockchip RK3568 TRNG
>   hwrng: add hwrng driver for Rockchip RK3568 SoC
>   arm64: dts: rockchip: add DT entry for RNG to RK356x
> 
>  .../bindings/rng/rockchip,rk3568-rng.yaml     |  61 +++++
>  MAINTAINERS                                   |   7 +
>  arch/arm64/boot/dts/rockchip/rk356x.dtsi      |   9 +
>  drivers/char/hw_random/Kconfig                |  14 ++
>  drivers/char/hw_random/Makefile               |   1 +
>  drivers/char/hw_random/rockchip-rng.c         | 227 ++++++++++++++++++
>  6 files changed, 319 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/rng/rockchip,rk3568-rng.yaml create mode
> 100644 drivers/char/hw_random/rockchip-rng.c

I just did the following test on my Quartz64 Model A running kernel 6.10
+ a number of patches, including this one:

===============================================================
root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.64507 s, 17.7 kB/s
root@quartz64a:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. 
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 362
rngtest: FIPS 140-2 failures: 638
rngtest: FIPS 140-2(2001-10-10) Monobit: 634
rngtest: FIPS 140-2(2001-10-10) Poker: 106
rngtest: FIPS 140-2(2001-10-10) Runs: 43
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.638; avg=139.351; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=21.169; avg=36.158; max=68.610)Mibits/s
rngtest: Program run time: 148109761 microseconds
===============================================================

That's almost twice as many failures as successes ...

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Daniel Golle]

[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]

Hi Diederik,

On Tue, Jul 16, 2024 at 02:34:40PM +0200, Diederik de Haas wrote:
> [...]
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 362
> rngtest: FIPS 140-2 failures: 638
> rngtest: FIPS 140-2(2001-10-10) Monobit: 634
> rngtest: FIPS 140-2(2001-10-10) Poker: 106
> rngtest: FIPS 140-2(2001-10-10) Runs: 43
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=2.638; avg=139.351; max=9765625.000)Kibits/s
> rngtest: FIPS tests speed: (min=21.169; avg=36.158; max=68.610)Mibits/s
> rngtest: Program run time: 148109761 microseconds
> ===============================================================
> 
> That's almost twice as many failures as successes ...

That's bad news, and apparently different from Aurelien's initial
testing of the driver.

Can you try if the result is also that bad when using his version of
the driver:

https://patchwork.kernel.org/project/linux-arm-kernel/patch/20221128184718.1963353-3-aurelien@aurel32.net/

If so, we can try to increase RK_RNG_SAMPLE_CNT, and we may need
different values depending on the SoC...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 4411 bytes --]

Hi Daniel,

On Tuesday, 16 July 2024 15:27:33 CEST Daniel Golle wrote:
> On Tue, Jul 16, 2024 at 02:34:40PM +0200, Diederik de Haas wrote:
> > [...]
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 20000032
> > rngtest: FIPS 140-2 successes: 362
> > rngtest: FIPS 140-2 failures: 638
> > rngtest: FIPS 140-2(2001-10-10) Monobit: 634
> > rngtest: FIPS 140-2(2001-10-10) Poker: 106
> > rngtest: FIPS 140-2(2001-10-10) Runs: 43
> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > rngtest: input channel speed: (min=2.638; avg=139.351;
> > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=21.169;
> > avg=36.158; max=68.610)Mibits/s rngtest: Program run time: 148109761
> > microseconds
> > ===============================================================
> > 
> > That's almost twice as many failures as successes ...
> 
> That's bad news, and apparently different from Aurelien's initial
> testing of the driver.
> 
> Can you try if the result is also that bad when using his version of
> the driver:
> 
> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20221128184718.1
> 963353-3-aurelien@aurel32.net/
> 
> If so, we can try to increase RK_RNG_SAMPLE_CNT, and we may need
> different values depending on the SoC...

I had been using a rebased version (with fixed includes) of Aurelien's
patch set and I switched to 'your' version somewhere in the 6.10-rcX
cycle, but I didn't record exactly when.
But I had a 6.9.2 kernel of which I'm confident has that rebased patch set:

=========================================================== 
root@quartz64a:~# uname -a
Linux quartz64a 6.9+unreleased-arm64 #1 SMP Debian 6.9.2-1~cknow (2024-04-24) aarch64 GNU/Linux

root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.6801 s, 17.6 kB/s
root@quartz64a:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions. 
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 361
rngtest: FIPS 140-2 failures: 639
rngtest: FIPS 140-2(2001-10-10) Monobit: 637
rngtest: FIPS 140-2(2001-10-10) Poker: 115
rngtest: FIPS 140-2(2001-10-10) Runs: 34
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.603; avg=137.548; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=21.479; avg=37.156; max=89.547)Mibits/s
rngtest: Program run time: 149992805 microseconds
=========================================================== 

So that's consistent(ly bad).

For shits and giggles, I tried it on my PineTab2 too (also rk3566):

=========================================================== 
root@pinetab2:~# uname -a
Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24) aarch64 GNU/Linux

root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s

root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 730
rngtest: FIPS 140-2 failures: 270
rngtest: FIPS 140-2(2001-10-10) Monobit: 266
rngtest: FIPS 140-2(2001-10-10) Poker: 23
rngtest: FIPS 140-2(2001-10-10) Runs: 9
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.615; avg=137.889; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=24.643; avg=34.518; max=68.364)Mibits/s
rngtest: Program run time: 149674336 microseconds
=========================================================== 

That's looking quite a lot better ... and I have no idea why.

The Q64-A is used as headless server and the PineTab2 is not,
but I connected to both over SSH and they were freshly booted
into, thus I haven't actually/normally used the PT2 since boot.

HTH,
  Diederik

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 3381 bytes --]

On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
> For shits and giggles, I tried it on my PineTab2 too (also rk3566):
> 
> ===========================================================
> root@pinetab2:~# uname -a
> Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24)
> aarch64 GNU/Linux
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> 1+0 records in
> 1+0 records out
> 100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
> 
> root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 5
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or
> FITNESS FOR A PARTICULAR PURPOSE.
> 
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 730
> rngtest: FIPS 140-2 failures: 270
> rngtest: FIPS 140-2(2001-10-10) Monobit: 266
> rngtest: FIPS 140-2(2001-10-10) Poker: 23
> rngtest: FIPS 140-2(2001-10-10) Runs: 9
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=2.615; avg=137.889;
> max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643;
> avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336
> microseconds
> ===========================================================
> 
> That's looking quite a lot better ... and I have no idea why.
> 
> The Q64-A is used as headless server and the PineTab2 is not,
> but I connected to both over SSH and they were freshly booted
> into, thus I haven't actually/normally used the PT2 since boot.

I did freshly install rng-tools5 package before running the test, so
I rebooted again to make sure that wasn't a factor:

===========================================================
root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 704
rngtest: FIPS 140-2 failures: 296
rngtest: FIPS 140-2(2001-10-10) Monobit: 293
rngtest: FIPS 140-2(2001-10-10) Poker: 32
rngtest: FIPS 140-2(2001-10-10) Runs: 10
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.612; avg=137.833; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=24.391; avg=34.416; max=68.364)Mibits/s
rngtest: Program run time: 149736205 microseconds
===========================================================

So that 704/296 vs 730/270 in the previous run on the PT2.

In case it helps:
===========================================================
root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng 
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0

root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
/sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng 
/sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
/sys/devices/virtual/misc/hw_random/rng_quality:900
/sys/devices/virtual/misc/hw_random/rng_selected:0
===========================================================

Cheers,
  Diederik

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Chen-Yu Tsai]

On Tue, Jul 16, 2024 at 10:13 PM Diederik de Haas <didi.debian@cknow.org> wrote:
>
> On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
> > For shits and giggles, I tried it on my PineTab2 too (also rk3566):
> >
> > ===========================================================
> > root@pinetab2:~# uname -a
> > Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24)
> > aarch64 GNU/Linux
> >
> > root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> > 1+0 records in
> > 1+0 records out
> > 100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
> >
> > root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> > rngtest 5
> > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > This is free software; see the source for copying conditions.
> > There is NO warranty; not even for MERCHANTABILITY or
> > FITNESS FOR A PARTICULAR PURPOSE.
> >
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 20000032
> > rngtest: FIPS 140-2 successes: 730
> > rngtest: FIPS 140-2 failures: 270
> > rngtest: FIPS 140-2(2001-10-10) Monobit: 266
> > rngtest: FIPS 140-2(2001-10-10) Poker: 23
> > rngtest: FIPS 140-2(2001-10-10) Runs: 9
> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > rngtest: input channel speed: (min=2.615; avg=137.889;
> > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643;
> > avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336
> > microseconds
> > ===========================================================
> >
> > That's looking quite a lot better ... and I have no idea why.
> >
> > The Q64-A is used as headless server and the PineTab2 is not,
> > but I connected to both over SSH and they were freshly booted
> > into, thus I haven't actually/normally used the PT2 since boot.
>
> I did freshly install rng-tools5 package before running the test, so
> I rebooted again to make sure that wasn't a factor:
>
> ===========================================================
> root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 5
> ...
>
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 704
> rngtest: FIPS 140-2 failures: 296
> rngtest: FIPS 140-2(2001-10-10) Monobit: 293
> rngtest: FIPS 140-2(2001-10-10) Poker: 32
> rngtest: FIPS 140-2(2001-10-10) Runs: 10
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=2.612; avg=137.833; max=9765625.000)Kibits/s
> rngtest: FIPS tests speed: (min=24.391; avg=34.416; max=68.364)Mibits/s
> rngtest: Program run time: 149736205 microseconds
> ===========================================================
>
> So that 704/296 vs 730/270 in the previous run on the PT2.
>
> In case it helps:
> ===========================================================
> root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
> /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
> /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
> /sys/devices/virtual/misc/hw_random/rng_quality:900
> /sys/devices/virtual/misc/hw_random/rng_selected:0
>
> root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
> /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
> /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
> /sys/devices/virtual/misc/hw_random/rng_quality:900
> /sys/devices/virtual/misc/hw_random/rng_selected:0
> ===========================================================

On my Rock 3A:

wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 992
rngtest: FIPS 140-2 failures: 8
rngtest: FIPS 140-2(2001-10-10) Monobit: 7
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.658; avg=140.067; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=26.751; avg=34.901; max=65.320)Mibits/s
rngtest: Program run time: 147367594 microseconds

wens@rock-3a:~$ uname -a
Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux


ChenYu

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 6759 bytes --]

On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:
> On Jul 16, 2024 at 10:13 PM Diederik de Haas <didi.debian@cknow.org> wrote:
> > On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
> > > For shits and giggles, I tried it on my PineTab2 too (also rk3566):
> > > 
> > > ===========================================================
> > > root@pinetab2:~# uname -a
> > > Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
> > > (2024-04-24) aarch64 GNU/Linux
> > > 
> > > root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> > > 1+0 records in
> > > 1+0 records out
> > > 100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
> > > 
> > > root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> > > rngtest 5
> > > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > > This is free software; see the source for copying conditions.
> > > There is NO warranty; not even for MERCHANTABILITY or
> > > FITNESS FOR A PARTICULAR PURPOSE.
> > > 
> > > rngtest: starting FIPS tests...
> > > rngtest: bits received from input: 20000032
> > > rngtest: FIPS 140-2 successes: 730
> > > rngtest: FIPS 140-2 failures: 270
> > > rngtest: FIPS 140-2(2001-10-10) Monobit: 266
> > > rngtest: FIPS 140-2(2001-10-10) Poker: 23
> > > rngtest: FIPS 140-2(2001-10-10) Runs: 9
> > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > > rngtest: input channel speed: (min=2.615; avg=137.889;
> > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643;
> > > avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336
> > > microseconds
> > > ===========================================================
> > > 
> > > That's looking quite a lot better ... and I have no idea why.
> > > 
> > > The Q64-A is used as headless server and the PineTab2 is not,
> > > but I connected to both over SSH and they were freshly booted
> > > into, thus I haven't actually/normally used the PT2 since boot.
> > 
> > I did freshly install rng-tools5 package before running the test, so
> > I rebooted again to make sure that wasn't a factor:
> > 
> > ===========================================================
> > root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> > rngtest 5
> > ...
> > 
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 20000032
> > rngtest: FIPS 140-2 successes: 704
> > rngtest: FIPS 140-2 failures: 296
> > rngtest: FIPS 140-2(2001-10-10) Monobit: 293
> > rngtest: FIPS 140-2(2001-10-10) Poker: 32
> > rngtest: FIPS 140-2(2001-10-10) Runs: 10
> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > rngtest: input channel speed: (min=2.612; avg=137.833;
> > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.391;
> > avg=34.416; max=68.364)Mibits/s rngtest: Program run time: 149736205
> > microseconds
> > ===========================================================
> > 
> > So that 704/296 vs 730/270 in the previous run on the PT2.
> > 
> > In case it helps:
> > ===========================================================
> > root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
> > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
> > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
> > /sys/devices/virtual/misc/hw_random/rng_quality:900
> > /sys/devices/virtual/misc/hw_random/rng_selected:0
> > 
> > root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
> > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
> > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
> > /sys/devices/virtual/misc/hw_random/rng_quality:900
> > /sys/devices/virtual/misc/hw_random/rng_selected:0
> > ===========================================================
> 
> On my Rock 3A:
> 
> wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
> rngtest 5
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions.  There
> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 992
> rngtest: FIPS 140-2 failures: 8
> rngtest: FIPS 140-2(2001-10-10) Monobit: 7
> rngtest: FIPS 140-2(2001-10-10) Poker: 0
> rngtest: FIPS 140-2(2001-10-10) Runs: 0
> rngtest: FIPS 140-2(2001-10-10) Long run: 1
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=2.658; avg=140.067;
> max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=26.751;
> avg=34.901; max=65.320)Mibits/s rngtest: Program run time: 147367594
> microseconds
> 
> wens@rock-3a:~$ uname -a
> Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
> Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux

I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before
the actual test run made a difference.
Tried it on my Quartz64 Model A: no

Then I tried it on my Quartz64 Model B:

root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 120
rngtest: FIPS 140-2 failures: 880
rngtest: FIPS 140-2(2001-10-10) Monobit: 879
rngtest: FIPS 140-2(2001-10-10) Poker: 332
rngtest: FIPS 140-2(2001-10-10) Runs: 91
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.615; avg=138.117; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=20.777; avg=34.535; max=68.857)Mibits/s
rngtest: Program run time: 149461754 microseconds

root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in
1+0 records out
100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s

root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 104
rngtest: FIPS 140-2 failures: 896
rngtest: FIPS 140-2(2001-10-10) Monobit: 892
rngtest: FIPS 140-2(2001-10-10) Poker: 335
rngtest: FIPS 140-2(2001-10-10) Runs: 79
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=2.613; avg=138.098; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=20.465; avg=34.587; max=69.107)Mibits/s
rngtest: Program run time: 149475187 microseconds

root@quartz64b:~# uname -a
Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24) aarch64 GNU/Linux

:-O

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 456 bytes --]

On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
> rngtest: FIPS 140-2(2001-10-10) Long run: 0

I don't know if it means something, but I noticed that I have
``Long run: 0`` with all my poor results,
while Chen-Yu had ``Long run: 1``.

Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
very poor result (100% failure):
https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@mail.gmail.com/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Daniel Golle]

On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
> On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> 
> I don't know if it means something, but I noticed that I have
> ``Long run: 0`` with all my poor results,
> while Chen-Yu had ``Long run: 1``.
> 
> Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
> very poor result (100% failure):
> https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@mail.gmail.com/

The conclusions I draw from that rather ugly situation are:
 - The hwrng should not be enabled by default, but it should by done
   for each board on which it is known to work well.
 - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
   defined in DT for each board:
   * introduce new 'rochchip,rng-sample-count' property
   * read 'quality' property already used for timeriomem_rng

I will prepare a follow-up patch taking those conclusions into account.

Just for completeness, here my test result on the NanoPi R5C:
root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
rngtest 6.15
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 875
rngtest: FIPS 140-2 failures: 125
rngtest: FIPS 140-2(2001-10-10) Monobit: 123
rngtest: FIPS 140-2(2001-10-10) Poker: 5
rngtest: FIPS 140-2(2001-10-10) Runs: 4
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=85.171; avg=141.102; max=4882812.500)Kibits/s
rngtest: FIPS tests speed: (min=17.809; avg=19.494; max=60.169)Mibits/s
rngtest: Program run time: 139628605 microseconds

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Chen-Yu Tsai]

On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> wrote:
>
> On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
> > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
> > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> >
> > I don't know if it means something, but I noticed that I have
> > ``Long run: 0`` with all my poor results,
> > while Chen-Yu had ``Long run: 1``.
> >
> > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
> > very poor result (100% failure):
> > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@mail.gmail.com/
>
> The conclusions I draw from that rather ugly situation are:
>  - The hwrng should not be enabled by default, but it should by done
>    for each board on which it is known to work well.
>  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
>    defined in DT for each board:
>    * introduce new 'rochchip,rng-sample-count' property
>    * read 'quality' property already used for timeriomem_rng
>
> I will prepare a follow-up patch taking those conclusions into account.
>
> Just for completeness, here my test result on the NanoPi R5C:
> root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 6.15
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 875
> rngtest: FIPS 140-2 failures: 125
> rngtest: FIPS 140-2(2001-10-10) Monobit: 123
> rngtest: FIPS 140-2(2001-10-10) Poker: 5
> rngtest: FIPS 140-2(2001-10-10) Runs: 4
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=85.171; avg=141.102; max=4882812.500)Kibits/s
> rngtest: FIPS tests speed: (min=17.809; avg=19.494; max=60.169)Mibits/s
> rngtest: Program run time: 139628605 microseconds

I doubt this is per-board. The RNG is inside the SoC, so it could be a chip
quality thing. On the RK3399 we also saw wildly varying results.

ChenYu

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Dragan Simic]

Hello Daniel,

On 2024-07-17 04:24, Daniel Golle wrote:
> On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
>> On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
>> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
>> 
>> I don't know if it means something, but I noticed that I have
>> ``Long run: 0`` with all my poor results,
>> while Chen-Yu had ``Long run: 1``.
>> 
>> Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
>> very poor result (100% failure):
>> https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@mail.gmail.com/
> 
> The conclusions I draw from that rather ugly situation are:
>  - The hwrng should not be enabled by default, but it should by done
>    for each board on which it is known to work well.
>  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
>    defined in DT for each board:
>    * introduce new 'rochchip,rng-sample-count' property
>    * read 'quality' property already used for timeriomem_rng
> 
> I will prepare a follow-up patch taking those conclusions into account.

Please note that Chen-Yu ran the tests on a board based on the RK3568,
while Diederik ran the tests on boards based on the RK3566.  The 
observed
difference in the test results suggests that something differs betwen
these two SoC variants, instead of having the actual boards contributing
something to the whole thing.

In other words, I think that enabling the HWRNG on per-board basis isn't
the right thing to do, but it should be enabled on per-SoC basis, after
enough testing is performed on the particular SoC.  The same applies to
defining any HWRNG properties in the DT.

If we really had to enable the HWRNG on per-board basis, that would mean
that some issues exist for certain SoC batches, affecting some boards.
AFAIK, the actual board design can't affect the operation of the HWRNG,
so any HWRNG issues associated with some boards can have their SoCs as
the only root cause.  Consequently, if any board experiences issues,
we should discard its SoC as having unreliable HWRNG, because another
sample of the same board, or a sample of some other board based on the
same SoC, may or may not experience the same issues.

I hope all this makes sense.

> Just for completeness, here my test result on the NanoPi R5C:
> root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 6.15
> Copyright (c) 2004 by Henrique de Moraes Holschuh
> This is free software; see the source for copying conditions.  There
> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 875
> rngtest: FIPS 140-2 failures: 125
> rngtest: FIPS 140-2(2001-10-10) Monobit: 123
> rngtest: FIPS 140-2(2001-10-10) Poker: 5
> rngtest: FIPS 140-2(2001-10-10) Runs: 4
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=85.171; avg=141.102; 
> max=4882812.500)Kibits/s
> rngtest: FIPS tests speed: (min=17.809; avg=19.494; max=60.169)Mibits/s
> rngtest: Program run time: 139628605 microseconds

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Dragan Simic]

Hello Chen-Yu,

On 2024-07-17 04:58, Chen-Yu Tsai wrote:
> On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> 
> wrote:
>> 
>> On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
>> > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
>> > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
>> >
>> > I don't know if it means something, but I noticed that I have
>> > ``Long run: 0`` with all my poor results,
>> > while Chen-Yu had ``Long run: 1``.
>> >
>> > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
>> > very poor result (100% failure):
>> > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@mail.gmail.com/
>> 
>> The conclusions I draw from that rather ugly situation are:
>>  - The hwrng should not be enabled by default, but it should by done
>>    for each board on which it is known to work well.
>>  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
>>    defined in DT for each board:
>>    * introduce new 'rochchip,rng-sample-count' property
>>    * read 'quality' property already used for timeriomem_rng
>> 
>> I will prepare a follow-up patch taking those conclusions into 
>> account.
>> 
>> Just for completeness, here my test result on the NanoPi R5C:
>> root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
>> rngtest 6.15
>> Copyright (c) 2004 by Henrique de Moraes Holschuh
>> This is free software; see the source for copying conditions.  There 
>> is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
>> PARTICULAR PURPOSE.
>> 
>> rngtest: starting FIPS tests...
>> rngtest: bits received from input: 20000032
>> rngtest: FIPS 140-2 successes: 875
>> rngtest: FIPS 140-2 failures: 125
>> rngtest: FIPS 140-2(2001-10-10) Monobit: 123
>> rngtest: FIPS 140-2(2001-10-10) Poker: 5
>> rngtest: FIPS 140-2(2001-10-10) Runs: 4
>> rngtest: FIPS 140-2(2001-10-10) Long run: 0
>> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
>> rngtest: input channel speed: (min=85.171; avg=141.102; 
>> max=4882812.500)Kibits/s
>> rngtest: FIPS tests speed: (min=17.809; avg=19.494; 
>> max=60.169)Mibits/s
>> rngtest: Program run time: 139628605 microseconds
> 
> I doubt this is per-board. The RNG is inside the SoC, so it
> could be a chip quality thing.

Totally agreed.  I see no way how a board design could affect the
HWRNGs built into Rockchip SoCs.  I even checked the RK3399 and
RK3566 Hardware Design Guides to be extra sure.

> On the RK3399 we also saw wildly varying results.

In my opinion, that qualifies the RK3399's HWRNG as unsuitable for
general use.  Having a HWRNG that fails to pass the tests on _some_
units is simply not acceptable from the security standpoint.

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Anand Moon]

Hi All,

On Wed, 17 Jul 2024 at 08:29, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> wrote:
> >
> > On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
> > > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
> > > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > >
> > > I don't know if it means something, but I noticed that I have
> > > ``Long run: 0`` with all my poor results,
> > > while Chen-Yu had ``Long run: 1``.
> > >
> > > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
> > > very poor result (100% failure):
> > > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@mail.gmail.com/
> >
> > The conclusions I draw from that rather ugly situation are:
> >  - The hwrng should not be enabled by default, but it should by done
> >    for each board on which it is known to work well.
> >  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
> >    defined in DT for each board:
> >    * introduce new 'rochchip,rng-sample-count' property
> >    * read 'quality' property already used for timeriomem_rng
> >
> > I will prepare a follow-up patch taking those conclusions into account.
> >
> > Just for completeness, here my test result on the NanoPi R5C:
> > root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
> > rngtest 6.15
> > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> >
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 20000032
> > rngtest: FIPS 140-2 successes: 875
> > rngtest: FIPS 140-2 failures: 125
> > rngtest: FIPS 140-2(2001-10-10) Monobit: 123
> > rngtest: FIPS 140-2(2001-10-10) Poker: 5
> > rngtest: FIPS 140-2(2001-10-10) Runs: 4
> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > rngtest: input channel speed: (min=85.171; avg=141.102; max=4882812.500)Kibits/s
> > rngtest: FIPS tests speed: (min=17.809; avg=19.494; max=60.169)Mibits/s
> > rngtest: Program run time: 139628605 microseconds
>
> I doubt this is per-board. The RNG is inside the SoC, so it could be a chip
> quality thing. On the RK3399 we also saw wildly varying results.
>
I feel the latest rng-tool only supports Intel platform x86_64 and i386.
It has no proper support for Arm64 and Armv7
It is heavily modified for the X86 platform
so it's not suitable for testing on other platforms.

If we enable HWRNG on all the Rockchip platforms it will be better.

[1] https://github.com/nhorman/rng-tools

> ChenYu

Thanks


-Anand

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Dragan Simic]

Hello Anand,

On 2024-07-17 07:06, Anand Moon wrote:
> On Wed, 17 Jul 2024 at 08:29, Chen-Yu Tsai <wens@kernel.org> wrote:
>> 
>> On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> 
>> wrote:
>> >
>> > On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
>> > > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
>> > > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
>> > >
>> > > I don't know if it means something, but I noticed that I have
>> > > ``Long run: 0`` with all my poor results,
>> > > while Chen-Yu had ``Long run: 1``.
>> > >
>> > > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
>> > > very poor result (100% failure):
>> > > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6rB2S7jg+dnoX8hAoWg@mail.gmail.com/
>> >
>> > The conclusions I draw from that rather ugly situation are:
>> >  - The hwrng should not be enabled by default, but it should by done
>> >    for each board on which it is known to work well.
>> >  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
>> >    defined in DT for each board:
>> >    * introduce new 'rochchip,rng-sample-count' property
>> >    * read 'quality' property already used for timeriomem_rng
>> >
>> > I will prepare a follow-up patch taking those conclusions into account.
>> >
>> > Just for completeness, here my test result on the NanoPi R5C:
>> > root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
>> > rngtest 6.15
>> > Copyright (c) 2004 by Henrique de Moraes Holschuh
>> > This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> >
>> > rngtest: starting FIPS tests...
>> > rngtest: bits received from input: 20000032
>> > rngtest: FIPS 140-2 successes: 875
>> > rngtest: FIPS 140-2 failures: 125
>> > rngtest: FIPS 140-2(2001-10-10) Monobit: 123
>> > rngtest: FIPS 140-2(2001-10-10) Poker: 5
>> > rngtest: FIPS 140-2(2001-10-10) Runs: 4
>> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
>> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
>> > rngtest: input channel speed: (min=85.171; avg=141.102; max=4882812.500)Kibits/s
>> > rngtest: FIPS tests speed: (min=17.809; avg=19.494; max=60.169)Mibits/s
>> > rngtest: Program run time: 139628605 microseconds
>> 
>> I doubt this is per-board. The RNG is inside the SoC, so it could be a 
>> chip
>> quality thing. On the RK3399 we also saw wildly varying results.
>> 
> I feel the latest rng-tool only supports Intel platform x86_64 and 
> i386.
> It has no proper support for Arm64 and Armv7
> It is heavily modified for the X86 platform
> so it's not suitable for testing on other platforms.
> 
> If we enable HWRNG on all the Rockchip platforms it will be better.
> 
> [1] https://github.com/nhorman/rng-tools

I don't see what could be tweaked in rngtest(1) to support any platform
better than the other, and still remain a valid test.  It just applies
certain FIPS test(s) to the random data obtained from /dev/hwrng or some
other source, and if that testing is tweaked in any way, then the test
results aren't valid on any platform.

In other words, perhaps the other components of rng-tools are tweaked to
support "mainstream" platforms better, but rngtest(1) simply must not be
tweaked in any way.

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 3532 bytes --]

On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote:
> On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> wrote:
> > On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
> > > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
> > > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > > 
> > > I don't know if it means something, but I noticed that I have
> > > ``Long run: 0`` with all my poor results,
> > > while Chen-Yu had ``Long run: 1``.
> > > 
> > > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
> > > very poor result (100% failure):
> > > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6
> > > rB2S7jg+dnoX8hAoWg@mail.gmail.com/> 
> > The conclusions I draw from that rather ugly situation are:
> >  - The hwrng should not be enabled by default, but it should by done
> >  
> >    for each board on which it is known to work well.
> >  
> >  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
> >  
> >    defined in DT for each board:
> >    * introduce new 'rochchip,rng-sample-count' property
> >    * read 'quality' property already used for timeriomem_rng
> > 
> > I will prepare a follow-up patch taking those conclusions into account.
> > 
> > Just for completeness, here my test result on the NanoPi R5C:
> > root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
> > rngtest 6.15
> > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > PURPOSE.
> > 
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 20000032
> > rngtest: FIPS 140-2 successes: 875
> > rngtest: FIPS 140-2 failures: 125
> > rngtest: FIPS 140-2(2001-10-10) Monobit: 123
> > rngtest: FIPS 140-2(2001-10-10) Poker: 5
> > rngtest: FIPS 140-2(2001-10-10) Runs: 4
> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > rngtest: input channel speed: (min=85.171; avg=141.102;
> > max=4882812.500)Kibits/s rngtest: FIPS tests speed: (min=17.809;
> > avg=19.494; max=60.169)Mibits/s rngtest: Program run time: 139628605
> > microseconds
> 
> I doubt this is per-board. The RNG is inside the SoC, so it could be a chip
> quality thing. 

I agree with ChenYu (and others) that this is isn't a per-board level thing.
I'd even go further: 's/I doubt/It can't be that/' (for the same reason 
though; this is inside the SoC).

Before I saw these latest emails, I was going to suggest:
1. Enable it only on RK3568 for now. I would be fine if this would be accepted 
by the maintainer

2. Ask that you make a special version (for me) where I could play with the 
params without having to compile a new kernel for each variant (it generally 
takes me more then 24h on my Q64-A). Either through kernel module properties 
or properties defined in the DeviceTree is fine with me.

3. Based on the results make  a choice to not enable it on rk3566 at all or 
(indeed) introduce DT properties to configure it differently per SoC.

4. Hope/Ask for more test results

> On the RK3399 we also saw wildly varying results.

On my Rock64('s) (RK3328) it doesn't work at all:

```
root@cs21:~# cat /dev/hwrng | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...
cat: /dev/hwrng: No such device
rngtest: entropy source drained
```

Cheers,
  Diederik

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Dragan Simic]

Hello Diederik,

On 2024-07-17 10:22, Diederik de Haas wrote:
> On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote:
>> On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> 
>> wrote:
>> > On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
>> > > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
>> > > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
>> > >
>> > > I don't know if it means something, but I noticed that I have
>> > > ``Long run: 0`` with all my poor results,
>> > > while Chen-Yu had ``Long run: 1``.
>> > >
>> > > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
>> > > very poor result (100% failure):
>> > > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6
>> > > rB2S7jg+dnoX8hAoWg@mail.gmail.com/>
>> > The conclusions I draw from that rather ugly situation are:
>> >  - The hwrng should not be enabled by default, but it should by done
>> >
>> >    for each board on which it is known to work well.
>> >
>> >  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
>> >
>> >    defined in DT for each board:
>> >    * introduce new 'rochchip,rng-sample-count' property
>> >    * read 'quality' property already used for timeriomem_rng
>> >
>> > I will prepare a follow-up patch taking those conclusions into account.
>> >
>> > Just for completeness, here my test result on the NanoPi R5C:
>> > root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
>> > rngtest 6.15
>> > Copyright (c) 2004 by Henrique de Moraes Holschuh
>> > This is free software; see the source for copying conditions.  There is NO
>> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> > PURPOSE.
>> >
>> > rngtest: starting FIPS tests...
>> > rngtest: bits received from input: 20000032
>> > rngtest: FIPS 140-2 successes: 875
>> > rngtest: FIPS 140-2 failures: 125
>> > rngtest: FIPS 140-2(2001-10-10) Monobit: 123
>> > rngtest: FIPS 140-2(2001-10-10) Poker: 5
>> > rngtest: FIPS 140-2(2001-10-10) Runs: 4
>> > rngtest: FIPS 140-2(2001-10-10) Long run: 0
>> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
>> > rngtest: input channel speed: (min=85.171; avg=141.102;
>> > max=4882812.500)Kibits/s rngtest: FIPS tests speed: (min=17.809;
>> > avg=19.494; max=60.169)Mibits/s rngtest: Program run time: 139628605
>> > microseconds
>> 
>> I doubt this is per-board. The RNG is inside the SoC, so it could be a 
>> chip
>> quality thing.
> 
> I agree with ChenYu (and others) that this is isn't a per-board level 
> thing.
> I'd even go further: 's/I doubt/It can't be that/' (for the same reason
> though; this is inside the SoC).
> 
> Before I saw these latest emails, I was going to suggest:
> 1. Enable it only on RK3568 for now. I would be fine if this would be 
> accepted
> by the maintainer

I think we need more testing on more units of the RK3568 SoC, simply
because the HWRNG may work badly on some units.  I know that it sucks,
but we basically need just one "bad apple" to mark an SoC as having
an unreliable HWRNG, which is IMHO the only right thing to do.

Of course, unless we can prove that tweaking the HWRNG knobs makes such
"bad apples" work well.

> 2. Ask that you make a special version (for me) where I could play with 
> the
> params without having to compile a new kernel for each variant (it 
> generally
> takes me more then 24h on my Q64-A). Either through kernel module 
> properties
> or properties defined in the DeviceTree is fine with me.
> 
> 3. Based on the results make  a choice to not enable it on rk3566 at 
> all or
> (indeed) introduce DT properties to configure it differently per SoC.

See above; unfortunately, we already have some "bad RK3566 apples".

> 4. Hope/Ask for more test results
> 
>> On the RK3399 we also saw wildly varying results.
> 
> On my Rock64('s) (RK3328) it doesn't work at all:
> 
> ```
> root@cs21:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> cat: /dev/hwrng: No such device
> rngtest: entropy source drained
> ```

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Chen-Yu Tsai]

On Wed, Jul 17, 2024 at 4:22 PM Diederik de Haas <didi.debian@cknow.org> wrote:
>
> On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote:
> > On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> wrote:
> > > On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
> > > > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
> > > > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > > >
> > > > I don't know if it means something, but I noticed that I have
> > > > ``Long run: 0`` with all my poor results,
> > > > while Chen-Yu had ``Long run: 1``.
> > > >
> > > > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
> > > > very poor result (100% failure):
> > > > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6
> > > > rB2S7jg+dnoX8hAoWg@mail.gmail.com/>
> > > The conclusions I draw from that rather ugly situation are:
> > >  - The hwrng should not be enabled by default, but it should by done
> > >
> > >    for each board on which it is known to work well.
> > >
> > >  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
> > >
> > >    defined in DT for each board:
> > >    * introduce new 'rochchip,rng-sample-count' property
> > >    * read 'quality' property already used for timeriomem_rng
> > >
> > > I will prepare a follow-up patch taking those conclusions into account.
> > >
> > > Just for completeness, here my test result on the NanoPi R5C:
> > > root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
> > > rngtest 6.15
> > > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > > This is free software; see the source for copying conditions.  There is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > > PURPOSE.
> > >
> > > rngtest: starting FIPS tests...
> > > rngtest: bits received from input: 20000032
> > > rngtest: FIPS 140-2 successes: 875
> > > rngtest: FIPS 140-2 failures: 125
> > > rngtest: FIPS 140-2(2001-10-10) Monobit: 123
> > > rngtest: FIPS 140-2(2001-10-10) Poker: 5
> > > rngtest: FIPS 140-2(2001-10-10) Runs: 4
> > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > > rngtest: input channel speed: (min=85.171; avg=141.102;
> > > max=4882812.500)Kibits/s rngtest: FIPS tests speed: (min=17.809;
> > > avg=19.494; max=60.169)Mibits/s rngtest: Program run time: 139628605
> > > microseconds
> >
> > I doubt this is per-board. The RNG is inside the SoC, so it could be a chip
> > quality thing.
>
> I agree with ChenYu (and others) that this is isn't a per-board level thing.
> I'd even go further: 's/I doubt/It can't be that/' (for the same reason
> though; this is inside the SoC).
>
> Before I saw these latest emails, I was going to suggest:
> 1. Enable it only on RK3568 for now. I would be fine if this would be accepted
> by the maintainer
>
> 2. Ask that you make a special version (for me) where I could play with the
> params without having to compile a new kernel for each variant (it generally
> takes me more then 24h on my Q64-A). Either through kernel module properties
> or properties defined in the DeviceTree is fine with me.
>
> 3. Based on the results make  a choice to not enable it on rk3566 at all or
> (indeed) introduce DT properties to configure it differently per SoC.
>
> 4. Hope/Ask for more test results
>
> > On the RK3399 we also saw wildly varying results.
>
> On my Rock64('s) (RK3328) it doesn't work at all:
>
> ```
> root@cs21:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> cat: /dev/hwrng: No such device
> rngtest: entropy source drained
> ```

RK3399 and RK3328 are covered by a different driver:

https://lore.kernel.org/all/20230707115242.3411259-1-clabbe@baylibre.com/

And that patch says the TRNG on the RK3328 is utterly broken.


ChenYu


> Cheers,
>   Diederik

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Wednesday, 17 July 2024 10:38:40 CEST Chen-Yu Tsai wrote:
> > On my Rock64('s) (RK3328) it doesn't work at all:
> > 
> > ```
> > root@cs21:~# cat /dev/hwrng | rngtest -c 1000
> > rngtest 5
> > ...
> > rngtest: starting FIPS tests...
> > cat: /dev/hwrng: No such device
> > rngtest: entropy source drained
> > ```
> 
> RK3399 and RK3328 are covered by a different driver:
> 
> https://lore.kernel.org/all/20230707115242.3411259-1-clabbe@baylibre.com/
> 
> And that patch says the TRNG on the RK3328 is utterly broken.

Yeah, someone made me aware of that post and then ofc I had to see it for 
myself ;-)

Cheers,
  Diederik

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Daniel Golle]

On Wed, Jul 17, 2024 at 10:22:18AM +0200, Diederik de Haas wrote:
> On Wednesday, 17 July 2024 04:58:51 CEST Chen-Yu Tsai wrote:
> > On Wed, Jul 17, 2024 at 10:25 AM Daniel Golle <daniel@makrotopia.org> wrote:
> > > On Tue, Jul 16, 2024 at 07:19:35PM +0200, Diederik de Haas wrote:
> > > > On Tuesday, 16 July 2024 18:53:43 CEST Diederik de Haas wrote:
> > > > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > > > 
> > > > I don't know if it means something, but I noticed that I have
> > > > ``Long run: 0`` with all my poor results,
> > > > while Chen-Yu had ``Long run: 1``.
> > > > 
> > > > Different SoC (RK3399), but Anand had ``Long run: 0`` too on their
> > > > very poor result (100% failure):
> > > > https://lore.kernel.org/linux-rockchip/CANAwSgTTzZOwBaR9zjJ5VMpxm5BydtW6
> > > > rB2S7jg+dnoX8hAoWg@mail.gmail.com/> 
> > > The conclusions I draw from that rather ugly situation are:
> > >  - The hwrng should not be enabled by default, but it should by done
> > >  
> > >    for each board on which it is known to work well.
> > >  
> > >  - RK_RNG_SAMPLE_CNT as well as the assumed rng quality should be
> > >  
> > >    defined in DT for each board:
> > >    * introduce new 'rochchip,rng-sample-count' property
> > >    * read 'quality' property already used for timeriomem_rng
> > > 
> > > I will prepare a follow-up patch taking those conclusions into account.
> > > 
> > > Just for completeness, here my test result on the NanoPi R5C:
> > > root@OpenWrt:~# cat /dev/hwrng | rngtest -c 1000
> > > rngtest 6.15
> > > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > > This is free software; see the source for copying conditions.  There is NO
> > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> > > PURPOSE.
> > > 
> > > rngtest: starting FIPS tests...
> > > rngtest: bits received from input: 20000032
> > > rngtest: FIPS 140-2 successes: 875
> > > rngtest: FIPS 140-2 failures: 125
> > > rngtest: FIPS 140-2(2001-10-10) Monobit: 123
> > > rngtest: FIPS 140-2(2001-10-10) Poker: 5
> > > rngtest: FIPS 140-2(2001-10-10) Runs: 4
> > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > > rngtest: input channel speed: (min=85.171; avg=141.102;
> > > max=4882812.500)Kibits/s rngtest: FIPS tests speed: (min=17.809;
> > > avg=19.494; max=60.169)Mibits/s rngtest: Program run time: 139628605
> > > microseconds
> > 
> > I doubt this is per-board. The RNG is inside the SoC, so it could be a chip
> > quality thing. 
> 
> I agree with ChenYu (and others) that this is isn't a per-board level thing.
> I'd even go further: 's/I doubt/It can't be that/' (for the same reason 
> though; this is inside the SoC).

There are quite a lot of options regarding the implementation of an in-SoC
RNG. Many of them rely on external components, such as a resistor or simply
a pin left floating. Others may be influenced by the power delivery setup.
Or rely on "thermal noise generated from inherently random quantum mechanical
properties of silicon" (Intel).

I don't know which design Rockchip chose, but just because the RNG is
inside the SoC I wouldn't exclude the option that the quality it
delivers may depend also on external components on the board, or even
the dielectric properties of the board material itself, or (in case of
bad designs) environmental circumstances such as the amount of
electromagnetic noise around, and that then again depends on relative
humidity, exposure to sunlight, ... The latter would be really bad, of
course, because then we would have some kind of hidden sensor rather
than a RNG, but nothing is too stupid to not show up when engineers of
proprietary technologies are left alone.

So imho only empirical data can tell.

> 
> Before I saw these latest emails, I was going to suggest:
> 1. Enable it only on RK3568 for now. I would be fine if this would be accepted 
> by the maintainer
> 
> 2. Ask that you make a special version (for me) where I could play with the 
> params without having to compile a new kernel for each variant (it generally 
> takes me more then 24h on my Q64-A). Either through kernel module properties 
> or properties defined in the DeviceTree is fine with me.

+1 Will do.

> 
> 3. Based on the results make  a choice to not enable it on rk3566 at all or 
> (indeed) introduce DT properties to configure it differently per SoC.
> 
> 4. Hope/Ask for more test results
> 
> > On the RK3399 we also saw wildly varying results.
> 
> On my Rock64('s) (RK3328) it doesn't work at all:
> 
> ```
> root@cs21:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> cat: /dev/hwrng: No such device
> rngtest: entropy source drained
> ```
> 
> Cheers,
>   Diederik

Re: [PATCH v7 2/3] hwrng: add hwrng driver for Rockchip RK3568 SoC

[Jason A. Donenfeld]

On Sun, Jul 14, 2024 at 04:16:17PM +0100, Daniel Golle wrote:
> +	rk_rng->rng.quality = 900;

This is out of 1024, not 1000.

https://elixir.bootlin.com/linux/v6.10/source/include/linux/hw_random.h#L35

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Chen-Yu Tsai]

On Wed, Jul 17, 2024 at 12:54 AM Diederik de Haas <didi.debian@cknow.org> wrote:
>
> On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:
> > On Jul 16, 2024 at 10:13 PM Diederik de Haas <didi.debian@cknow.org> wrote:
> > > On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
> > > > For shits and giggles, I tried it on my PineTab2 too (also rk3566):
> > > >
> > > > ===========================================================
> > > > root@pinetab2:~# uname -a
> > > > Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
> > > > (2024-04-24) aarch64 GNU/Linux
> > > >
> > > > root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> > > > 1+0 records in
> > > > 1+0 records out
> > > > 100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
> > > >
> > > > root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> > > > rngtest 5
> > > > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > > > This is free software; see the source for copying conditions.
> > > > There is NO warranty; not even for MERCHANTABILITY or
> > > > FITNESS FOR A PARTICULAR PURPOSE.
> > > >
> > > > rngtest: starting FIPS tests...
> > > > rngtest: bits received from input: 20000032
> > > > rngtest: FIPS 140-2 successes: 730
> > > > rngtest: FIPS 140-2 failures: 270
> > > > rngtest: FIPS 140-2(2001-10-10) Monobit: 266
> > > > rngtest: FIPS 140-2(2001-10-10) Poker: 23
> > > > rngtest: FIPS 140-2(2001-10-10) Runs: 9
> > > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > > > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > > > rngtest: input channel speed: (min=2.615; avg=137.889;
> > > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.643;
> > > > avg=34.518; max=68.364)Mibits/s rngtest: Program run time: 149674336
> > > > microseconds
> > > > ===========================================================
> > > >
> > > > That's looking quite a lot better ... and I have no idea why.
> > > >
> > > > The Q64-A is used as headless server and the PineTab2 is not,
> > > > but I connected to both over SSH and they were freshly booted
> > > > into, thus I haven't actually/normally used the PT2 since boot.
> > >
> > > I did freshly install rng-tools5 package before running the test, so
> > > I rebooted again to make sure that wasn't a factor:
> > >
> > > ===========================================================
> > > root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> > > rngtest 5
> > > ...
> > >
> > > rngtest: starting FIPS tests...
> > > rngtest: bits received from input: 20000032
> > > rngtest: FIPS 140-2 successes: 704
> > > rngtest: FIPS 140-2 failures: 296
> > > rngtest: FIPS 140-2(2001-10-10) Monobit: 293
> > > rngtest: FIPS 140-2(2001-10-10) Poker: 32
> > > rngtest: FIPS 140-2(2001-10-10) Runs: 10
> > > rngtest: FIPS 140-2(2001-10-10) Long run: 0
> > > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > > rngtest: input channel speed: (min=2.612; avg=137.833;
> > > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=24.391;
> > > avg=34.416; max=68.364)Mibits/s rngtest: Program run time: 149736205
> > > microseconds
> > > ===========================================================
> > >
> > > So that 704/296 vs 730/270 in the previous run on the PT2.
> > >
> > > In case it helps:
> > > ===========================================================
> > > root@quartz64a:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
> > > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
> > > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
> > > /sys/devices/virtual/misc/hw_random/rng_quality:900
> > > /sys/devices/virtual/misc/hw_random/rng_selected:0
> > >
> > > root@pinetab2:~# grep . /sys/devices/virtual/misc/hw_random/rng_*
> > > /sys/devices/virtual/misc/hw_random/rng_available:rockchip-rng
> > > /sys/devices/virtual/misc/hw_random/rng_current:rockchip-rng
> > > /sys/devices/virtual/misc/hw_random/rng_quality:900
> > > /sys/devices/virtual/misc/hw_random/rng_selected:0
> > > ===========================================================
> >
> > On my Rock 3A:
> >
> > wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
> > rngtest 5
> > Copyright (c) 2004 by Henrique de Moraes Holschuh
> > This is free software; see the source for copying conditions.  There
> > is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> > PARTICULAR PURPOSE.
> >
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 20000032
> > rngtest: FIPS 140-2 successes: 992
> > rngtest: FIPS 140-2 failures: 8
> > rngtest: FIPS 140-2(2001-10-10) Monobit: 7
> > rngtest: FIPS 140-2(2001-10-10) Poker: 0
> > rngtest: FIPS 140-2(2001-10-10) Runs: 0
> > rngtest: FIPS 140-2(2001-10-10) Long run: 1
> > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> > rngtest: input channel speed: (min=2.658; avg=140.067;
> > max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=26.751;
> > avg=34.901; max=65.320)Mibits/s rngtest: Program run time: 147367594
> > microseconds
> >
> > wens@rock-3a:~$ uname -a
> > Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
> > Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux
>
> I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before
> the actual test run made a difference.
> Tried it on my Quartz64 Model A: no
>
> Then I tried it on my Quartz64 Model B:
>
> root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 120
> rngtest: FIPS 140-2 failures: 880
> rngtest: FIPS 140-2(2001-10-10) Monobit: 879
> rngtest: FIPS 140-2(2001-10-10) Poker: 332
> rngtest: FIPS 140-2(2001-10-10) Runs: 91
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=2.615; avg=138.117; max=9765625.000)Kibits/s
> rngtest: FIPS tests speed: (min=20.777; avg=34.535; max=68.857)Mibits/s
> rngtest: Program run time: 149461754 microseconds
>
> root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> 1+0 records in
> 1+0 records out
> 100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s
>
> root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 104
> rngtest: FIPS 140-2 failures: 896
> rngtest: FIPS 140-2(2001-10-10) Monobit: 892
> rngtest: FIPS 140-2(2001-10-10) Poker: 335
> rngtest: FIPS 140-2(2001-10-10) Runs: 79
> rngtest: FIPS 140-2(2001-10-10) Long run: 0
> rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
> rngtest: input channel speed: (min=2.613; avg=138.098; max=9765625.000)Kibits/s
> rngtest: FIPS tests speed: (min=20.465; avg=34.587; max=69.107)Mibits/s
> rngtest: Program run time: 149475187 microseconds
>
> root@quartz64b:~# uname -a
> Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow (2024-04-24) aarch64 GNU/Linux
>
> :-O

I pulled out my Quartz64 model B, and the results seem better than yours.

root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 859
rngtest: FIPS 140-2 failures: 141
rngtest: FIPS 140-2(2001-10-10) Monobit: 137
rngtest: FIPS 140-2(2001-10-10) Poker: 10
rngtest: FIPS 140-2(2001-10-10) Runs: 5
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=134.990; avg=143.460; max=157.836)Kibits/s
rngtest: FIPS tests speed: (min=34.742; avg=40.675; max=41.285)Mibits/s
rngtest: Program run time: 136667679 microseconds
root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There
is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 843
rngtest: FIPS 140-2 failures: 157
rngtest: FIPS 140-2(2001-10-10) Monobit: 155
rngtest: FIPS 140-2(2001-10-10) Poker: 13
rngtest: FIPS 140-2(2001-10-10) Runs: 7
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=134.977; avg=143.669; max=157.906)Kibits/s
rngtest: FIPS tests speed: (min=37.036; avg=40.666; max=41.285)Mibits/s
rngtest: Program run time: 136459178 microseconds

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 7358 bytes --]

On Monday, 22 July 2024 19:57:05 CEST Chen-Yu Tsai wrote:
> On Wed, Jul 17, 2024 at 12:54 AM Diederik de Haas <didi.debian@cknow.org> 
wrote:
> > On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:
> > > On Jul 16, 2024 at 10:13 PM Diederik de Haas <didi.debian@cknow.org> 
wrote:
> > > > On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
> > > > > For shits and giggles, I tried it on my PineTab2 too (also rk3566):
> > > > > 
> > > > > ===========================================================
> > > > > root@pinetab2:~# uname -a
> > > > > Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
> > > > > (2024-04-24) aarch64 GNU/Linux
> > > > > 
> > > > > root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> > > > > 1+0 records in
> > > > > 1+0 records out
> > > > > 100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
> > > > > 
> > > > > root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> > > > > rngtest 5
> > > > > ...
> > > > > rngtest: starting FIPS tests...
> > > > > rngtest: bits received from input: 20000032
> > > > > rngtest: FIPS 140-2 successes: 730
> > > > > rngtest: FIPS 140-2 failures: 270
> > > > > ===========================================================
> > > > > 
> > > > > That's looking quite a lot better ... and I have no idea why.
> > > > > 
> > > > > The Q64-A is used as headless server and the PineTab2 is not,
> > > > > but I connected to both over SSH and they were freshly booted
> > > > > into, thus I haven't actually/normally used the PT2 since boot.
> > > > 
> > > > I did freshly install rng-tools5 package before running the test, so
> > > > I rebooted again to make sure that wasn't a factor:
> > > > 
> > > > ===========================================================
> > > > root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
> > > > rngtest 5
> > > > ...
> > > > rngtest: starting FIPS tests...
> > > > rngtest: bits received from input: 20000032
> > > > rngtest: FIPS 140-2 successes: 704
> > > > rngtest: FIPS 140-2 failures: 296
> > > > ===========================================================
> > > > 
> > > > So that 704/296 vs 730/270 in the previous run on the PT2.
> > > > 
> > > On my Rock 3A:
> > > 
> > > wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
> > > rngtest 5
> > > ...
> > > rngtest: starting FIPS tests...
> > > rngtest: bits received from input: 20000032
> > > rngtest: FIPS 140-2 successes: 992
> > > rngtest: FIPS 140-2 failures: 8
> > > 
> > > wens@rock-3a:~$ uname -a
> > > Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
> > > Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux
> > 
> > I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before
> > the actual test run made a difference.
> > Tried it on my Quartz64 Model A: no
> > 
> > Then I tried it on my Quartz64 Model B:
> > 
> > root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
> > rngtest 5
> > ...
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 20000032
> > rngtest: FIPS 140-2 successes: 120
> > rngtest: FIPS 140-2 failures: 880
> > 
> > root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> > 1+0 records in
> > 1+0 records out
> > 100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s
> > 
> > root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
> > rngtest 5
> > ...
> > rngtest: starting FIPS tests...
> > rngtest: bits received from input: 20000032
> > rngtest: FIPS 140-2 successes: 104
> > rngtest: FIPS 140-2 failures: 896
> > 
> > root@quartz64b:~# uname -a
> > Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
> > (2024-04-24) aarch64 GNU/Linux> 
> > :-O
> 
> I pulled out my Quartz64 model B, and the results seem better than yours.
> 
> root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 859
> rngtest: FIPS 140-2 failures: 141
> root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 843
> rngtest: FIPS 140-2 failures: 157

I noticed you used ``dd`` instead of ``cat``, so I tried again ...

Quartz64-A:
root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
rngtest 5
...
rngtest: starting FIPS tests...                                                               
rngtest: bits received from input: 20000032                                                   
rngtest: FIPS 140-2 successes: 411                                                            
rngtest: FIPS 140-2 failures: 589

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: starting FIPS tests...           
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 391         
rngtest: FIPS 140-2 failures: 609

root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
1+0 records in                             
1+0 records out                   
100000 bytes (100 kB, 98 KiB) copied, 5.66202 s, 17.7 kB/s

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 386                                                            
rngtest: FIPS 140-2 failures: 614

root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 356
rngtest: FIPS 140-2 failures: 644

Quartz64-B:
root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 118
rngtest: FIPS 140-2 failures: 882

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 133
rngtest: FIPS 140-2 failures: 867

root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 97
rngtest: FIPS 140-2 failures: 903

root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 130
rngtest: FIPS 140-2 failures: 870

And lastly on PineTab2:
root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 705
rngtest: FIPS 140-2 failures: 295

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 678
rngtest: FIPS 140-2 failures: 322

root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 681
rngtest: FIPS 140-2 failures: 319

root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
...
rngtest: FIPS 140-2 successes: 669
rngtest: FIPS 140-2 failures: 331


So my Q64-B tests are consistently MUCH worse then your Q64-B tests ...
This seems BAD to me, now that we even have completely different results per 
device of the EXACT same model?!? Hardware revision may be different (I have a 
v1.4), but it seems rather pointless to go into that direction.

It then also seems rather pointless to try it with different parameters if the 
results on the same SBC model can vary this much.

Thanks for your tests,
  Diederik

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Dragan Simic]

Hello Diederik and Chen-Yu,

On 2024-07-22 21:03, Diederik de Haas wrote:
> On Monday, 22 July 2024 19:57:05 CEST Chen-Yu Tsai wrote:
>> On Wed, Jul 17, 2024 at 12:54 AM Diederik de Haas 
>> <didi.debian@cknow.org>
> wrote:
>> > On Tuesday, 16 July 2024 17:18:48 CEST Chen-Yu Tsai wrote:
>> > > On Jul 16, 2024 at 10:13 PM Diederik de Haas <didi.debian@cknow.org>
> wrote:
>> > > > On Tuesday, 16 July 2024 15:59:40 CEST Diederik de Haas wrote:
>> > > > > For shits and giggles, I tried it on my PineTab2 too (also rk3566):
>> > > > >
>> > > > > ===========================================================
>> > > > > root@pinetab2:~# uname -a
>> > > > > Linux pinetab2 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
>> > > > > (2024-04-24) aarch64 GNU/Linux
>> > > > >
>> > > > > root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
>> > > > > 1+0 records in
>> > > > > 1+0 records out
>> > > > > 100000 bytes (100 kB, 98 KiB) copied, 5,69533 s, 17,6 kB/s
>> > > > >
>> > > > > root@plebian-pinetab2:~# cat /dev/hwrng | rngtest -c 1000
>> > > > > rngtest 5
>> > > > > ...
>> > > > > rngtest: starting FIPS tests...
>> > > > > rngtest: bits received from input: 20000032
>> > > > > rngtest: FIPS 140-2 successes: 730
>> > > > > rngtest: FIPS 140-2 failures: 270
>> > > > > ===========================================================
>> > > > >
>> > > > > That's looking quite a lot better ... and I have no idea why.
>> > > > >
>> > > > > The Q64-A is used as headless server and the PineTab2 is not,
>> > > > > but I connected to both over SSH and they were freshly booted
>> > > > > into, thus I haven't actually/normally used the PT2 since boot.
>> > > >
>> > > > I did freshly install rng-tools5 package before running the test, so
>> > > > I rebooted again to make sure that wasn't a factor:
>> > > >
>> > > > ===========================================================
>> > > > root@pinetab2:~# cat /dev/hwrng | rngtest -c 1000
>> > > > rngtest 5
>> > > > ...
>> > > > rngtest: starting FIPS tests...
>> > > > rngtest: bits received from input: 20000032
>> > > > rngtest: FIPS 140-2 successes: 704
>> > > > rngtest: FIPS 140-2 failures: 296
>> > > > ===========================================================
>> > > >
>> > > > So that 704/296 vs 730/270 in the previous run on the PT2.
>> > > >
>> > > On my Rock 3A:
>> > >
>> > > wens@rock-3a:~$ sudo cat /dev/hwrng | rngtest -c 1000
>> > > rngtest 5
>> > > ...
>> > > rngtest: starting FIPS tests...
>> > > rngtest: bits received from input: 20000032
>> > > rngtest: FIPS 140-2 successes: 992
>> > > rngtest: FIPS 140-2 failures: 8
>> > >
>> > > wens@rock-3a:~$ uname -a
>> > > Linux rock-3a 6.10.0-rc7-next-20240712-12899-g7df602fe7c8b #9 SMP Mon
>> > > Jul 15 00:39:32 CST 2024 aarch64 GNU/Linux
>> >
>> > I wondered if ``dd if=/dev/hwrng bs=100000 count=1 > /dev/null`` before
>> > the actual test run made a difference.
>> > Tried it on my Quartz64 Model A: no
>> >
>> > Then I tried it on my Quartz64 Model B:
>> >
>> > root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
>> > rngtest 5
>> > ...
>> > rngtest: starting FIPS tests...
>> > rngtest: bits received from input: 20000032
>> > rngtest: FIPS 140-2 successes: 120
>> > rngtest: FIPS 140-2 failures: 880
>> >
>> > root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
>> > 1+0 records in
>> > 1+0 records out
>> > 100000 bytes (100 kB, 98 KiB) copied, 5.71466 s, 17.5 kB/s
>> >
>> > root@quartz64b:~# cat /dev/hwrng | rngtest -c 1000
>> > rngtest 5
>> > ...
>> > rngtest: starting FIPS tests...
>> > rngtest: bits received from input: 20000032
>> > rngtest: FIPS 140-2 successes: 104
>> > rngtest: FIPS 140-2 failures: 896
>> >
>> > root@quartz64b:~# uname -a
>> > Linux quartz64b 6.10+unreleased-arm64 #1 SMP Debian 6.10-1~cknow
>> > (2024-04-24) aarch64 GNU/Linux>
>> > :-O
>> 
>> I pulled out my Quartz64 model B, and the results seem better than 
>> yours.
>> 
>> root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
>> rngtest 5
>> ...
>> rngtest: starting FIPS tests...
>> rngtest: bits received from input: 20000032
>> rngtest: FIPS 140-2 successes: 859
>> rngtest: FIPS 140-2 failures: 141
>> root@quartz64:~# sudo dd if=/dev/hwrng bs=256 | rngtest -c 1000
>> rngtest 5
>> ...
>> rngtest: starting FIPS tests...
>> rngtest: bits received from input: 20000032
>> rngtest: FIPS 140-2 successes: 843
>> rngtest: FIPS 140-2 failures: 157
> 
> I noticed you used ``dd`` instead of ``cat``, so I tried again ...
> 
> Quartz64-A:
> root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> rngtest 5
> ...
> rngtest: starting FIPS tests...
> 
> rngtest: bits received from input: 20000032
> 
> rngtest: FIPS 140-2 successes: 411
> 
> rngtest: FIPS 140-2 failures: 589
> 
> root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: starting FIPS tests...
> rngtest: bits received from input: 20000032
> rngtest: FIPS 140-2 successes: 391
> rngtest: FIPS 140-2 failures: 609
> 
> root@quartz64a:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> 1+0 records in
> 1+0 records out
> 100000 bytes (100 kB, 98 KiB) copied, 5.66202 s, 17.7 kB/s
> 
> root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 386
> 
> rngtest: FIPS 140-2 failures: 614
> 
> root@quartz64a:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 356
> rngtest: FIPS 140-2 failures: 644
> 
> Quartz64-B:
> root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 118
> rngtest: FIPS 140-2 failures: 882
> 
> root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 133
> rngtest: FIPS 140-2 failures: 867
> 
> root@quartz64b:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> 
> root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 97
> rngtest: FIPS 140-2 failures: 903
> 
> root@quartz64b:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 130
> rngtest: FIPS 140-2 failures: 870
> 
> And lastly on PineTab2:
> root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 705
> rngtest: FIPS 140-2 failures: 295
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 678
> rngtest: FIPS 140-2 failures: 322
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=100000 count=1 > /dev/null
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 681
> rngtest: FIPS 140-2 failures: 319
> 
> root@pinetab2:~# dd if=/dev/hwrng bs=256 | rngtest -c 1000
> ...
> rngtest: FIPS 140-2 successes: 669
> rngtest: FIPS 140-2 failures: 331
> 
> 
> So my Q64-B tests are consistently MUCH worse then your Q64-B tests ...
> This seems BAD to me, now that we even have completely different 
> results per
> device of the EXACT same model?!? Hardware revision may be different (I 
> have a
> v1.4), but it seems rather pointless to go into that direction.
> 
> It then also seems rather pointless to try it with different parameters 
> if the
> results on the same SBC model can vary this much.

Thanks a lot for the testing.  Though, such wildly different test 
results
can, regrettably, lead to only one conclusion:  the HWRNG found in 
RK3566
is unusable. :/

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Daniel Golle]

On Wed, Jul 24, 2024 at 08:07:51AM +0200, Dragan Simic wrote:
> Thanks a lot for the testing.  Though, such wildly different test results
> can, regrettably, lead to only one conclusion:  the HWRNG found in RK3566
> is unusable. :/

The results on RK3568 look much better and the series right now also
only enabled the RNG on RK3568 systems. However, we have only seen few
boards with RK3568 up to now, and I only got a couple of NanoPi R5C
here to test, all with good hwrng results.

Do you think it would be agreeable to only enable the HWRNG for RK3568
as suggested in this series? Or are we expecting quality to also vary
as much as it (sadly) does for RK3566?

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Tuesday, 30 July 2024 01:18:37 CEST Daniel Golle wrote:
> On Wed, Jul 24, 2024 at 08:07:51AM +0200, Dragan Simic wrote:
> > Thanks a lot for the testing.  Though, such wildly different test results
> > can, regrettably, lead to only one conclusion:  the HWRNG found in RK3566
> > is unusable. :/

FTR: I agree with Dragan, unfortunately.

> The results on RK3568 look much better and the series right now also
> only enabled the RNG on RK3568 systems. However, we have only seen few
> boards with RK3568 up to now, and I only got a couple of NanoPi R5C
> here to test, all with good hwrng results.
> 
> Do you think it would be agreeable to only enable the HWRNG for RK3568
> as suggested in this series? Or are we expecting quality to also vary
> as much as it (sadly) does for RK3566?

Unless we get *evidence* to the contrary, we should assume that the HWRNG on 
RK3568 is fine as the currently available test results are fine.
So I think enabling it only for RK3568 is the right thing to do.

So a 'revert' to v7 variant seems appropriate, but with the following changes:
- Add `status = "disabled";` property to the definition in rk356x.dtsi
- Add a new commit where you enable it only for rk3568 and document in the 
commit message why it's not enabled on rk3566 with a possible link to the v7 
thread for clarification on why that is

You could probably also integrate that into 1 commit, but make sure that the 
commit summary and description match the implementation.
IMO that wasn't 'technically' the case in v8 as the rng node was added to 
rk356x, but it was only enabled on rk3568.

My 0.02

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Heiko Stübner]

Am Dienstag, 30. Juli 2024, 11:03:06 CEST schrieb Diederik de Haas:
> On Tuesday, 30 July 2024 01:18:37 CEST Daniel Golle wrote:
> > On Wed, Jul 24, 2024 at 08:07:51AM +0200, Dragan Simic wrote:
> > > Thanks a lot for the testing.  Though, such wildly different test results
> > > can, regrettably, lead to only one conclusion:  the HWRNG found in RK3566
> > > is unusable. :/
> 
> FTR: I agree with Dragan, unfortunately.
> 
> > The results on RK3568 look much better and the series right now also
> > only enabled the RNG on RK3568 systems. However, we have only seen few
> > boards with RK3568 up to now, and I only got a couple of NanoPi R5C
> > here to test, all with good hwrng results.
> > 
> > Do you think it would be agreeable to only enable the HWRNG for RK3568
> > as suggested in this series? Or are we expecting quality to also vary
> > as much as it (sadly) does for RK3566?
> 
> Unless we get *evidence* to the contrary, we should assume that the HWRNG on 
> RK3568 is fine as the currently available test results are fine.
> So I think enabling it only for RK3568 is the right thing to do.
> 
> So a 'revert' to v7 variant seems appropriate, but with the following changes:
> - Add `status = "disabled";` property to the definition in rk356x.dtsi
> - Add a new commit where you enable it only for rk3568 and document in the 
> commit message why it's not enabled on rk3566 with a possible link to the v7 
> thread for clarification on why that is

I was going to protest about the "disable" until reading the 2nd part :-D .

And yeah that makes a lot of sense, "add" it to rk356x.dtsi, as the IP is
part of both variants, but only enable it in rk3568.dtsi because of the
seemingly faulty implementation on the rk3566.


> You could probably also integrate that into 1 commit, but make sure that the 
> commit summary and description match the implementation.
> IMO that wasn't 'technically' the case in v8 as the rng node was added to 
> rk356x, but it was only enabled on rk3568.
> 
> My 0.02

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Chen-Yu Tsai]

On Tue, Jul 30, 2024 at 6:37 PM Heiko Stübner <heiko@sntech.de> wrote:
>
> Am Dienstag, 30. Juli 2024, 11:03:06 CEST schrieb Diederik de Haas:
> > On Tuesday, 30 July 2024 01:18:37 CEST Daniel Golle wrote:
> > > On Wed, Jul 24, 2024 at 08:07:51AM +0200, Dragan Simic wrote:
> > > > Thanks a lot for the testing.  Though, such wildly different test results
> > > > can, regrettably, lead to only one conclusion:  the HWRNG found in RK3566
> > > > is unusable. :/
> >
> > FTR: I agree with Dragan, unfortunately.
> >
> > > The results on RK3568 look much better and the series right now also
> > > only enabled the RNG on RK3568 systems. However, we have only seen few
> > > boards with RK3568 up to now, and I only got a couple of NanoPi R5C
> > > here to test, all with good hwrng results.
> > >
> > > Do you think it would be agreeable to only enable the HWRNG for RK3568
> > > as suggested in this series? Or are we expecting quality to also vary
> > > as much as it (sadly) does for RK3566?
> >
> > Unless we get *evidence* to the contrary, we should assume that the HWRNG on
> > RK3568 is fine as the currently available test results are fine.
> > So I think enabling it only for RK3568 is the right thing to do.
> >
> > So a 'revert' to v7 variant seems appropriate, but with the following changes:
> > - Add `status = "disabled";` property to the definition in rk356x.dtsi
> > - Add a new commit where you enable it only for rk3568 and document in the
> > commit message why it's not enabled on rk3566 with a possible link to the v7
> > thread for clarification on why that is
>
> I was going to protest about the "disable" until reading the 2nd part :-D .
>
> And yeah that makes a lot of sense, "add" it to rk356x.dtsi, as the IP is
> part of both variants, but only enable it in rk3568.dtsi because of the
> seemingly faulty implementation on the rk3566.

Better yet, mark it as "broken" in rk3566.dtsi to reflect the tests that
we've all done.

ChenYu

> > You could probably also integrate that into 1 commit, but make sure that the
> > commit summary and description match the implementation.
> > IMO that wasn't 'technically' the case in v8 as the rng node was added to
> > rk356x, but it was only enabled on rk3568.
> >
> > My 0.02
>
>
>
>

Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568

[Dragan Simic]

Hello Daniel,

On 2024-07-30 01:18, Daniel Golle wrote:
> On Wed, Jul 24, 2024 at 08:07:51AM +0200, Dragan Simic wrote:
>> Thanks a lot for the testing.  Though, such wildly different test 
>> results
>> can, regrettably, lead to only one conclusion:  the HWRNG found in 
>> RK3566
>> is unusable. :/
> 
> The results on RK3568 look much better and the series right now also
> only enabled the RNG on RK3568 systems. However, we have only seen few
> boards with RK3568 up to now, and I only got a couple of NanoPi R5C
> here to test, all with good hwrng results.
> 
> Do you think it would be agreeable to only enable the HWRNG for RK3568
> as suggested in this series? Or are we expecting quality to also vary
> as much as it (sadly) does for RK3566?

I'm a bit late to the party, sorry for that.  The test results so far
show that the HWRNG in RK3566 simply cannot be relied upon, but the test
results also show that the RK3568's HWRNG seems fine.  I'm wondering 
why,
but until we bump into a sample of RK3568 whose HWRNG performs badly,
I'd say that enabling the HWRNG on RK3568 only is safe.

Of course, as other people already noted, the HWRNG should be defined in
rk356x.dtsi, because it does exist in both SoC variants, but should be
enabled in rk3568.dtsi only.  As already noted, describing it as broken
on RK3566 in rk356x.dtsi should also be good.