[PATCH] hw_random: rockchip: import driver from vendor tree

[PATCH] hw_random: rockchip: import driver from vendor tree

[Jason A. Donenfeld]

The Rockchip driver has long existed out of tree, but not upstream.
There is support for it upstream in u-boot, but not in Linux proper.
This commit imports the GPLv2 driver written by Lin Jinhan, together
with the DTS and config blobs from Wevsty.

Co-authored-by: Lin Jinhan <troy.lin@rock-chips.com>
Co-authored-by: wevsty <ty@wevs.org>
Tested-by: Mikhail Rudenko <mike.rudenko@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Lin Huang <hl@rock-chips.com>
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
---
 arch/arm64/boot/dts/rockchip/rk3328.dtsi |  11 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi |  10 +
 drivers/char/hw_random/Kconfig           |  13 +
 drivers/char/hw_random/Makefile          |   1 +
 drivers/char/hw_random/rockchip-rng.c    | 330 +++++++++++++++++++++++
 5 files changed, 365 insertions(+)
 create mode 100644 drivers/char/hw_random/rockchip-rng.c

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index 49ae15708a0b..f52589f5aa59 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -279,6 +279,17 @@ &pdmm0_sdi2_sleep
 		status = "disabled";
 	};
 
+	rng: rng@ff060000 {
+		compatible = "rockchip,cryptov1-rng";
+		reg = <0x0 0xff060000 0x0 0x4000>;
+
+		clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>;
+		clock-names = "clk_crypto", "hclk_crypto";
+		assigned-clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>;
+		assigned-clock-rates = <150000000>, <100000000>;
+		status = "disabled";
+	};
+
 	grf: syscon@ff100000 {
 		compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
 		reg = <0x0 0xff100000 0x0 0x1000>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 9d5b0e8c9cca..bd5ce85a063a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -2042,6 +2042,16 @@ edp_in_vopl: endpoint@1 {
 		};
 	};
 
+	rng: rng@ff8b8000 {
+		compatible = "rockchip,cryptov1-rng";
+		reg = <0x0 0xff8b8000 0x0 0x1000>;
+		clocks = <&cru SCLK_CRYPTO1>, <&cru HCLK_S_CRYPTO1>;
+		clock-names = "clk_crypto", "hclk_crypto";
+		assigned-clocks = <&cru SCLK_CRYPTO1>, <&cru HCLK_S_CRYPTO1>;
+		assigned-clock-rates = <150000000>, <100000000>;
+		status = "okay";
+	};
+
 	gpu: gpu@ff9a0000 {
 		compatible = "rockchip,rk3399-mali", "arm,mali-t860";
 		reg = <0x0 0xff9a0000 0x0 0x10000>;
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 3da8e85f8aae..1dbe9a9b2944 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -372,6 +372,19 @@ config HW_RANDOM_STM32
 
 	  If unsure, say N.
 
+config HW_RANDOM_ROCKCHIP
+	tristate "Rockchip Random Number Generator support"
+	depends on ARCH_ROCKCHIP
+	default HW_RANDOM
+	help
+	  This driver provides kernel-side support for the Random Number
+	  Generator hardware found on Rockchip cpus.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called rockchip-rng.
+
+	  If unsure, say Y.
+
 config HW_RANDOM_PIC32
 	tristate "Microchip PIC32 Random Number Generator support"
 	depends on HW_RANDOM && MACH_PIC32
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index 3e948cf04476..852fb42e225b 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
 obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
 obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
 obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
+obj-$(CONFIG_HW_RANDOM_ROCKCHIP) += rockchip-rng.o
 obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
 obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
 obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.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..c0121f1f542e
--- /dev/null
+++ b/drivers/char/hw_random/rockchip-rng.c
@@ -0,0 +1,330 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rockchip-rng.c Random Number Generator driver for the Rockchip
+ *
+ * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Lin Jinhan <troy.lin@rock-chips.com>
+ *
+ */
+#include <linux/clk.h>
+#include <linux/hw_random.h>
+#include <linux/iopoll.h>
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#define _SBF(s, v)	((v) << (s))
+#define HIWORD_UPDATE(val, mask, shift) \
+			((val) << (shift) | (mask) << ((shift) + 16))
+
+#define ROCKCHIP_AUTOSUSPEND_DELAY		100
+#define ROCKCHIP_POLL_PERIOD_US			100
+#define ROCKCHIP_POLL_TIMEOUT_US		10000
+#define RK_MAX_RNG_BYTE				(32)
+
+#define CRYPTO_V1_CTRL				0x0008
+#define CRYPTO_V1_RNG_START			BIT(8)
+#define CRYPTO_V1_RNG_FLUSH			BIT(9)
+#define CRYPTO_V1_TRNG_CTRL			0x0200
+#define CRYPTO_V1_OSC_ENABLE			BIT(16)
+#define CRYPTO_V1_TRNG_SAMPLE_PERIOD(x)		(x)
+#define CRYPTO_V1_TRNG_DOUT_0			0x0204
+
+#define CRYPTO_V2_RNG_CTL			0x0400
+#define CRYPTO_V2_RNG_64_BIT_LEN		_SBF(4, 0x00)
+#define CRYPTO_V2_RNG_128_BIT_LEN		_SBF(4, 0x01)
+#define CRYPTO_V2_RNG_192_BIT_LEN		_SBF(4, 0x02)
+#define CRYPTO_V2_RNG_256_BIT_LEN		_SBF(4, 0x03)
+#define CRYPTO_V2_RNG_FATESY_SOC_RING		_SBF(2, 0x00)
+#define CRYPTO_V2_RNG_SLOWER_SOC_RING_0		_SBF(2, 0x01)
+#define CRYPTO_V2_RNG_SLOWER_SOC_RING_1		_SBF(2, 0x02)
+#define CRYPTO_V2_RNG_SLOWEST_SOC_RING		_SBF(2, 0x03)
+#define CRYPTO_V2_RNG_ENABLE			BIT(1)
+#define CRYPTO_V2_RNG_START			BIT(0)
+#define CRYPTO_V2_RNG_SAMPLE_CNT		0x0404
+#define CRYPTO_V2_RNG_DOUT_0			0x0410
+
+struct rk_rng_soc_data {
+	const char * const *clks;
+	int clks_num;
+	int (*rk_rng_read)(struct hwrng *rng, void *buf, size_t max, bool wait);
+};
+
+struct rk_rng {
+	struct device		*dev;
+	struct hwrng		rng;
+	void __iomem		*mem;
+	struct rk_rng_soc_data	*soc_data;
+	u32			clk_num;
+	struct clk_bulk_data	*clk_bulks;
+};
+
+static const char * const rk_rng_v1_clks[] = {
+	"hclk_crypto",
+	"clk_crypto",
+};
+
+static const char * const rk_rng_v2_clks[] = {
+	"hclk_crypto",
+	"aclk_crypto",
+	"clk_crypto",
+	"clk_crypto_apk",
+};
+
+static void rk_rng_writel(struct rk_rng *rng, u32 val, u32 offset)
+{
+	__raw_writel(val, rng->mem + offset);
+}
+
+static u32 rk_rng_readl(struct rk_rng *rng, u32 offset)
+{
+	return __raw_readl(rng->mem + offset);
+}
+
+static int rk_rng_init(struct hwrng *rng)
+{
+	int ret;
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+
+	ret = clk_bulk_prepare_enable(rk_rng->clk_num, rk_rng->clk_bulks);
+	if (ret < 0) {
+		dev_err(rk_rng->dev, "failed to enable clks %d\n", ret);
+		return ret;
+	}
+
+	return 0;
+}
+
+static void rk_rng_cleanup(struct hwrng *rng)
+{
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+
+	clk_bulk_disable_unprepare(rk_rng->clk_num, rk_rng->clk_bulks);
+}
+
+static void rk_rng_read_regs(struct rk_rng *rng, u32 offset, void *buf,
+			     size_t size)
+{
+	u32 i, sample;
+
+	for (i = 0; i < size; i += 4) {
+		sample = rk_rng_readl(rng, offset + i);
+		memcpy(buf + i, &sample, sizeof(sample));
+	}
+}
+
+static int rk_rng_v1_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+	int ret = 0;
+	u32 reg_ctrl = 0;
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+
+	ret = pm_runtime_get_sync(rk_rng->dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(rk_rng->dev);
+		return ret;
+	}
+
+	/* enable osc_ring to get entropy, sample period is set as 100 */
+	reg_ctrl = CRYPTO_V1_OSC_ENABLE | CRYPTO_V1_TRNG_SAMPLE_PERIOD(100);
+	rk_rng_writel(rk_rng, reg_ctrl, CRYPTO_V1_TRNG_CTRL);
+
+	reg_ctrl = HIWORD_UPDATE(CRYPTO_V1_RNG_START, CRYPTO_V1_RNG_START, 0);
+
+	rk_rng_writel(rk_rng, reg_ctrl, CRYPTO_V1_CTRL);
+
+	ret = readl_poll_timeout(rk_rng->mem + CRYPTO_V1_CTRL, reg_ctrl,
+				 !(reg_ctrl & CRYPTO_V1_RNG_START),
+				 ROCKCHIP_POLL_PERIOD_US,
+				 ROCKCHIP_POLL_TIMEOUT_US);
+	if (ret < 0)
+		goto out;
+
+	ret = min_t(size_t, max, RK_MAX_RNG_BYTE);
+
+	rk_rng_read_regs(rk_rng, CRYPTO_V1_TRNG_DOUT_0, buf, ret);
+
+out:
+	/* close TRNG */
+	rk_rng_writel(rk_rng, HIWORD_UPDATE(0, CRYPTO_V1_RNG_START, 0),
+		      CRYPTO_V1_CTRL);
+
+	pm_runtime_mark_last_busy(rk_rng->dev);
+	pm_runtime_put_sync_autosuspend(rk_rng->dev);
+
+	return ret;
+}
+
+static int rk_rng_v2_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+	int ret = 0;
+	u32 reg_ctrl = 0;
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+
+	ret = pm_runtime_get_sync(rk_rng->dev);
+	if (ret < 0) {
+		pm_runtime_put_noidle(rk_rng->dev);
+		return ret;
+	}
+
+	/* enable osc_ring to get entropy, sample period is set as 100 */
+	rk_rng_writel(rk_rng, 100, CRYPTO_V2_RNG_SAMPLE_CNT);
+
+	reg_ctrl |= CRYPTO_V2_RNG_256_BIT_LEN;
+	reg_ctrl |= CRYPTO_V2_RNG_SLOWER_SOC_RING_0;
+	reg_ctrl |= CRYPTO_V2_RNG_ENABLE;
+	reg_ctrl |= CRYPTO_V2_RNG_START;
+
+	rk_rng_writel(rk_rng, HIWORD_UPDATE(reg_ctrl, 0xffff, 0),
+			CRYPTO_V2_RNG_CTL);
+
+	ret = readl_poll_timeout(rk_rng->mem + CRYPTO_V2_RNG_CTL, reg_ctrl,
+				 !(reg_ctrl & CRYPTO_V2_RNG_START),
+				 ROCKCHIP_POLL_PERIOD_US,
+				 ROCKCHIP_POLL_TIMEOUT_US);
+	if (ret < 0)
+		goto out;
+
+	ret = min_t(size_t, max, RK_MAX_RNG_BYTE);
+
+	rk_rng_read_regs(rk_rng, CRYPTO_V2_RNG_DOUT_0, buf, ret);
+
+out:
+	/* close TRNG */
+	rk_rng_writel(rk_rng, HIWORD_UPDATE(0, 0xffff, 0), CRYPTO_V2_RNG_CTL);
+
+	pm_runtime_mark_last_busy(rk_rng->dev);
+	pm_runtime_put_sync_autosuspend(rk_rng->dev);
+
+	return ret;
+}
+
+static const struct rk_rng_soc_data rk_rng_v1_soc_data = {
+	.clks_num = ARRAY_SIZE(rk_rng_v1_clks),
+	.clks = rk_rng_v1_clks,
+	.rk_rng_read = rk_rng_v1_read,
+};
+
+static const struct rk_rng_soc_data rk_rng_v2_soc_data = {
+	.clks_num = ARRAY_SIZE(rk_rng_v2_clks),
+	.clks = rk_rng_v2_clks,
+	.rk_rng_read = rk_rng_v2_read,
+};
+
+static const struct of_device_id rk_rng_dt_match[] = {
+	{
+		.compatible = "rockchip,cryptov1-rng",
+		.data = (void *)&rk_rng_v1_soc_data,
+	},
+	{
+		.compatible = "rockchip,cryptov2-rng",
+		.data = (void *)&rk_rng_v2_soc_data,
+	},
+	{ },
+};
+
+MODULE_DEVICE_TABLE(of, rk_rng_dt_match);
+
+static int rk_rng_probe(struct platform_device *pdev)
+{
+	int i;
+	int ret;
+	struct rk_rng *rk_rng;
+	struct device_node *np = pdev->dev.of_node;
+	const struct of_device_id *match;
+
+	rk_rng = devm_kzalloc(&pdev->dev, sizeof(struct rk_rng), GFP_KERNEL);
+	if (!rk_rng)
+		return -ENOMEM;
+
+	match = of_match_node(rk_rng_dt_match, np);
+	rk_rng->soc_data = (struct rk_rng_soc_data *)match->data;
+
+	rk_rng->dev = &pdev->dev;
+	rk_rng->rng.name    = "rockchip";
+#ifndef CONFIG_PM
+	rk_rng->rng.init    = rk_rng_init;
+	rk_rng->rng.cleanup = rk_rng_cleanup,
+#endif
+	rk_rng->rng.read    = rk_rng->soc_data->rk_rng_read;
+	rk_rng->rng.quality = 1024;
+
+	rk_rng->clk_bulks =
+		devm_kzalloc(&pdev->dev, sizeof(*rk_rng->clk_bulks) *
+			     rk_rng->soc_data->clks_num, GFP_KERNEL);
+
+	rk_rng->clk_num = rk_rng->soc_data->clks_num;
+
+	for (i = 0; i < rk_rng->soc_data->clks_num; i++)
+		rk_rng->clk_bulks[i].id = rk_rng->soc_data->clks[i];
+
+	rk_rng->mem = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
+	if (IS_ERR(rk_rng->mem))
+		return PTR_ERR(rk_rng->mem);
+
+	ret = devm_clk_bulk_get(&pdev->dev, rk_rng->clk_num,
+				rk_rng->clk_bulks);
+	if (ret) {
+		dev_err(&pdev->dev, "failed to get clks property\n");
+		return ret;
+	}
+
+	platform_set_drvdata(pdev, rk_rng);
+
+	pm_runtime_set_autosuspend_delay(&pdev->dev,
+					ROCKCHIP_AUTOSUSPEND_DELAY);
+	pm_runtime_use_autosuspend(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
+	ret = devm_hwrng_register(&pdev->dev, &rk_rng->rng);
+	if (ret) {
+		pm_runtime_dont_use_autosuspend(&pdev->dev);
+		pm_runtime_disable(&pdev->dev);
+	}
+
+	return ret;
+}
+
+#ifdef CONFIG_PM
+static int 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 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)
+};
+#endif
+
+static struct platform_driver rk_rng_driver = {
+	.driver	= {
+		.name	= "rockchip-rng",
+#ifdef CONFIG_PM
+		.pm	= &rk_rng_pm_ops,
+#endif
+		.of_match_table = rk_rng_dt_match,
+	},
+	.probe	= rk_rng_probe,
+};
+
+module_platform_driver(rk_rng_driver);
+
+MODULE_DESCRIPTION("ROCKCHIP H/W Random Number Generator driver");
+MODULE_AUTHOR("Lin Jinhan <troy.lin@rock-chips.com>");
+MODULE_LICENSE("GPL v2");
-- 
2.37.3

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[Robin Murphy]

On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> The Rockchip driver has long existed out of tree, but not upstream.
> There is support for it upstream in u-boot, but not in Linux proper.
> This commit imports the GPLv2 driver written by Lin Jinhan, together
> with the DTS and config blobs from Wevsty.

Note that Corentin has a series enabling the full crypto driver for 
RK3328 and RK3399[1], so it would seem more sensible to add TRNG support 
to that. Having confliciting compatibles for the same hardware that 
force the user to change their DT to choose one functionality or the 
other isn't good (plus there's also no binding for this one).

Robin.

[1] 
https://lore.kernel.org/linux-rockchip/20220901125710.3733083-29-clabbe@baylibre.com/

> Co-authored-by: Lin Jinhan <troy.lin@rock-chips.com>
> Co-authored-by: wevsty <ty@wevs.org>
> Tested-by: Mikhail Rudenko <mike.rudenko@gmail.com>
> Cc: Heiko Stuebner <heiko@sntech.de>
> Cc: Lin Huang <hl@rock-chips.com>
> Cc: Shawn Lin <shawn.lin@rock-chips.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: linux-rockchip@lists.infradead.org
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
>   arch/arm64/boot/dts/rockchip/rk3328.dtsi |  11 +
>   arch/arm64/boot/dts/rockchip/rk3399.dtsi |  10 +
>   drivers/char/hw_random/Kconfig           |  13 +
>   drivers/char/hw_random/Makefile          |   1 +
>   drivers/char/hw_random/rockchip-rng.c    | 330 +++++++++++++++++++++++
>   5 files changed, 365 insertions(+)
>   create mode 100644 drivers/char/hw_random/rockchip-rng.c
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index 49ae15708a0b..f52589f5aa59 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -279,6 +279,17 @@ &pdmm0_sdi2_sleep
>   		status = "disabled";
>   	};
>   
> +	rng: rng@ff060000 {
> +		compatible = "rockchip,cryptov1-rng";
> +		reg = <0x0 0xff060000 0x0 0x4000>;
> +
> +		clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>;
> +		clock-names = "clk_crypto", "hclk_crypto";
> +		assigned-clocks = <&cru SCLK_CRYPTO>, <&cru HCLK_CRYPTO_SLV>;
> +		assigned-clock-rates = <150000000>, <100000000>;
> +		status = "disabled";
> +	};
> +
>   	grf: syscon@ff100000 {
>   		compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
>   		reg = <0x0 0xff100000 0x0 0x1000>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 9d5b0e8c9cca..bd5ce85a063a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -2042,6 +2042,16 @@ edp_in_vopl: endpoint@1 {
>   		};
>   	};
>   
> +	rng: rng@ff8b8000 {
> +		compatible = "rockchip,cryptov1-rng";
> +		reg = <0x0 0xff8b8000 0x0 0x1000>;
> +		clocks = <&cru SCLK_CRYPTO1>, <&cru HCLK_S_CRYPTO1>;
> +		clock-names = "clk_crypto", "hclk_crypto";
> +		assigned-clocks = <&cru SCLK_CRYPTO1>, <&cru HCLK_S_CRYPTO1>;
> +		assigned-clock-rates = <150000000>, <100000000>;
> +		status = "okay";
> +	};
> +
>   	gpu: gpu@ff9a0000 {
>   		compatible = "rockchip,rk3399-mali", "arm,mali-t860";
>   		reg = <0x0 0xff9a0000 0x0 0x10000>;
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 3da8e85f8aae..1dbe9a9b2944 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -372,6 +372,19 @@ config HW_RANDOM_STM32
>   
>   	  If unsure, say N.
>   
> +config HW_RANDOM_ROCKCHIP
> +	tristate "Rockchip Random Number Generator support"
> +	depends on ARCH_ROCKCHIP
> +	default HW_RANDOM
> +	help
> +	  This driver provides kernel-side support for the Random Number
> +	  Generator hardware found on Rockchip cpus.
> +
> +	  To compile this driver as a module, choose M here: the
> +	  module will be called rockchip-rng.
> +
> +	  If unsure, say Y.
> +
>   config HW_RANDOM_PIC32
>   	tristate "Microchip PIC32 Random Number Generator support"
>   	depends on HW_RANDOM && MACH_PIC32
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index 3e948cf04476..852fb42e225b 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -34,6 +34,7 @@ obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
>   obj-$(CONFIG_HW_RANDOM_ST) += st-rng.o
>   obj-$(CONFIG_HW_RANDOM_XGENE) += xgene-rng.o
>   obj-$(CONFIG_HW_RANDOM_STM32) += stm32-rng.o
> +obj-$(CONFIG_HW_RANDOM_ROCKCHIP) += rockchip-rng.o
>   obj-$(CONFIG_HW_RANDOM_PIC32) += pic32-rng.o
>   obj-$(CONFIG_HW_RANDOM_MESON) += meson-rng.o
>   obj-$(CONFIG_HW_RANDOM_CAVIUM) += cavium-rng.o cavium-rng-vf.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..c0121f1f542e
> --- /dev/null
> +++ b/drivers/char/hw_random/rockchip-rng.c
> @@ -0,0 +1,330 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * rockchip-rng.c Random Number Generator driver for the Rockchip
> + *
> + * Copyright (c) 2018, Fuzhou Rockchip Electronics Co., Ltd.
> + * Author: Lin Jinhan <troy.lin@rock-chips.com>
> + *
> + */
> +#include <linux/clk.h>
> +#include <linux/hw_random.h>
> +#include <linux/iopoll.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +
> +#define _SBF(s, v)	((v) << (s))
> +#define HIWORD_UPDATE(val, mask, shift) \
> +			((val) << (shift) | (mask) << ((shift) + 16))
> +
> +#define ROCKCHIP_AUTOSUSPEND_DELAY		100
> +#define ROCKCHIP_POLL_PERIOD_US			100
> +#define ROCKCHIP_POLL_TIMEOUT_US		10000
> +#define RK_MAX_RNG_BYTE				(32)
> +
> +#define CRYPTO_V1_CTRL				0x0008
> +#define CRYPTO_V1_RNG_START			BIT(8)
> +#define CRYPTO_V1_RNG_FLUSH			BIT(9)
> +#define CRYPTO_V1_TRNG_CTRL			0x0200
> +#define CRYPTO_V1_OSC_ENABLE			BIT(16)
> +#define CRYPTO_V1_TRNG_SAMPLE_PERIOD(x)		(x)
> +#define CRYPTO_V1_TRNG_DOUT_0			0x0204
> +
> +#define CRYPTO_V2_RNG_CTL			0x0400
> +#define CRYPTO_V2_RNG_64_BIT_LEN		_SBF(4, 0x00)
> +#define CRYPTO_V2_RNG_128_BIT_LEN		_SBF(4, 0x01)
> +#define CRYPTO_V2_RNG_192_BIT_LEN		_SBF(4, 0x02)
> +#define CRYPTO_V2_RNG_256_BIT_LEN		_SBF(4, 0x03)
> +#define CRYPTO_V2_RNG_FATESY_SOC_RING		_SBF(2, 0x00)
> +#define CRYPTO_V2_RNG_SLOWER_SOC_RING_0		_SBF(2, 0x01)
> +#define CRYPTO_V2_RNG_SLOWER_SOC_RING_1		_SBF(2, 0x02)
> +#define CRYPTO_V2_RNG_SLOWEST_SOC_RING		_SBF(2, 0x03)
> +#define CRYPTO_V2_RNG_ENABLE			BIT(1)
> +#define CRYPTO_V2_RNG_START			BIT(0)
> +#define CRYPTO_V2_RNG_SAMPLE_CNT		0x0404
> +#define CRYPTO_V2_RNG_DOUT_0			0x0410
> +
> +struct rk_rng_soc_data {
> +	const char * const *clks;
> +	int clks_num;
> +	int (*rk_rng_read)(struct hwrng *rng, void *buf, size_t max, bool wait);
> +};
> +
> +struct rk_rng {
> +	struct device		*dev;
> +	struct hwrng		rng;
> +	void __iomem		*mem;
> +	struct rk_rng_soc_data	*soc_data;
> +	u32			clk_num;
> +	struct clk_bulk_data	*clk_bulks;
> +};
> +
> +static const char * const rk_rng_v1_clks[] = {
> +	"hclk_crypto",
> +	"clk_crypto",
> +};
> +
> +static const char * const rk_rng_v2_clks[] = {
> +	"hclk_crypto",
> +	"aclk_crypto",
> +	"clk_crypto",
> +	"clk_crypto_apk",
> +};
> +
> +static void rk_rng_writel(struct rk_rng *rng, u32 val, u32 offset)
> +{
> +	__raw_writel(val, rng->mem + offset);
> +}
> +
> +static u32 rk_rng_readl(struct rk_rng *rng, u32 offset)
> +{
> +	return __raw_readl(rng->mem + offset);
> +}
> +
> +static int rk_rng_init(struct hwrng *rng)
> +{
> +	int ret;
> +	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
> +
> +	ret = clk_bulk_prepare_enable(rk_rng->clk_num, rk_rng->clk_bulks);
> +	if (ret < 0) {
> +		dev_err(rk_rng->dev, "failed to enable clks %d\n", ret);
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static void rk_rng_cleanup(struct hwrng *rng)
> +{
> +	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
> +
> +	clk_bulk_disable_unprepare(rk_rng->clk_num, rk_rng->clk_bulks);
> +}
> +
> +static void rk_rng_read_regs(struct rk_rng *rng, u32 offset, void *buf,
> +			     size_t size)
> +{
> +	u32 i, sample;
> +
> +	for (i = 0; i < size; i += 4) {
> +		sample = rk_rng_readl(rng, offset + i);
> +		memcpy(buf + i, &sample, sizeof(sample));
> +	}
> +}
> +
> +static int rk_rng_v1_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> +	int ret = 0;
> +	u32 reg_ctrl = 0;
> +	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
> +
> +	ret = pm_runtime_get_sync(rk_rng->dev);
> +	if (ret < 0) {
> +		pm_runtime_put_noidle(rk_rng->dev);
> +		return ret;
> +	}
> +
> +	/* enable osc_ring to get entropy, sample period is set as 100 */
> +	reg_ctrl = CRYPTO_V1_OSC_ENABLE | CRYPTO_V1_TRNG_SAMPLE_PERIOD(100);
> +	rk_rng_writel(rk_rng, reg_ctrl, CRYPTO_V1_TRNG_CTRL);
> +
> +	reg_ctrl = HIWORD_UPDATE(CRYPTO_V1_RNG_START, CRYPTO_V1_RNG_START, 0);
> +
> +	rk_rng_writel(rk_rng, reg_ctrl, CRYPTO_V1_CTRL);
> +
> +	ret = readl_poll_timeout(rk_rng->mem + CRYPTO_V1_CTRL, reg_ctrl,
> +				 !(reg_ctrl & CRYPTO_V1_RNG_START),
> +				 ROCKCHIP_POLL_PERIOD_US,
> +				 ROCKCHIP_POLL_TIMEOUT_US);
> +	if (ret < 0)
> +		goto out;
> +
> +	ret = min_t(size_t, max, RK_MAX_RNG_BYTE);
> +
> +	rk_rng_read_regs(rk_rng, CRYPTO_V1_TRNG_DOUT_0, buf, ret);
> +
> +out:
> +	/* close TRNG */
> +	rk_rng_writel(rk_rng, HIWORD_UPDATE(0, CRYPTO_V1_RNG_START, 0),
> +		      CRYPTO_V1_CTRL);
> +
> +	pm_runtime_mark_last_busy(rk_rng->dev);
> +	pm_runtime_put_sync_autosuspend(rk_rng->dev);
> +
> +	return ret;
> +}
> +
> +static int rk_rng_v2_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> +{
> +	int ret = 0;
> +	u32 reg_ctrl = 0;
> +	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
> +
> +	ret = pm_runtime_get_sync(rk_rng->dev);
> +	if (ret < 0) {
> +		pm_runtime_put_noidle(rk_rng->dev);
> +		return ret;
> +	}
> +
> +	/* enable osc_ring to get entropy, sample period is set as 100 */
> +	rk_rng_writel(rk_rng, 100, CRYPTO_V2_RNG_SAMPLE_CNT);
> +
> +	reg_ctrl |= CRYPTO_V2_RNG_256_BIT_LEN;
> +	reg_ctrl |= CRYPTO_V2_RNG_SLOWER_SOC_RING_0;
> +	reg_ctrl |= CRYPTO_V2_RNG_ENABLE;
> +	reg_ctrl |= CRYPTO_V2_RNG_START;
> +
> +	rk_rng_writel(rk_rng, HIWORD_UPDATE(reg_ctrl, 0xffff, 0),
> +			CRYPTO_V2_RNG_CTL);
> +
> +	ret = readl_poll_timeout(rk_rng->mem + CRYPTO_V2_RNG_CTL, reg_ctrl,
> +				 !(reg_ctrl & CRYPTO_V2_RNG_START),
> +				 ROCKCHIP_POLL_PERIOD_US,
> +				 ROCKCHIP_POLL_TIMEOUT_US);
> +	if (ret < 0)
> +		goto out;
> +
> +	ret = min_t(size_t, max, RK_MAX_RNG_BYTE);
> +
> +	rk_rng_read_regs(rk_rng, CRYPTO_V2_RNG_DOUT_0, buf, ret);
> +
> +out:
> +	/* close TRNG */
> +	rk_rng_writel(rk_rng, HIWORD_UPDATE(0, 0xffff, 0), CRYPTO_V2_RNG_CTL);
> +
> +	pm_runtime_mark_last_busy(rk_rng->dev);
> +	pm_runtime_put_sync_autosuspend(rk_rng->dev);
> +
> +	return ret;
> +}
> +
> +static const struct rk_rng_soc_data rk_rng_v1_soc_data = {
> +	.clks_num = ARRAY_SIZE(rk_rng_v1_clks),
> +	.clks = rk_rng_v1_clks,
> +	.rk_rng_read = rk_rng_v1_read,
> +};
> +
> +static const struct rk_rng_soc_data rk_rng_v2_soc_data = {
> +	.clks_num = ARRAY_SIZE(rk_rng_v2_clks),
> +	.clks = rk_rng_v2_clks,
> +	.rk_rng_read = rk_rng_v2_read,
> +};
> +
> +static const struct of_device_id rk_rng_dt_match[] = {
> +	{
> +		.compatible = "rockchip,cryptov1-rng",
> +		.data = (void *)&rk_rng_v1_soc_data,
> +	},
> +	{
> +		.compatible = "rockchip,cryptov2-rng",
> +		.data = (void *)&rk_rng_v2_soc_data,
> +	},
> +	{ },
> +};
> +
> +MODULE_DEVICE_TABLE(of, rk_rng_dt_match);
> +
> +static int rk_rng_probe(struct platform_device *pdev)
> +{
> +	int i;
> +	int ret;
> +	struct rk_rng *rk_rng;
> +	struct device_node *np = pdev->dev.of_node;
> +	const struct of_device_id *match;
> +
> +	rk_rng = devm_kzalloc(&pdev->dev, sizeof(struct rk_rng), GFP_KERNEL);
> +	if (!rk_rng)
> +		return -ENOMEM;
> +
> +	match = of_match_node(rk_rng_dt_match, np);
> +	rk_rng->soc_data = (struct rk_rng_soc_data *)match->data;
> +
> +	rk_rng->dev = &pdev->dev;
> +	rk_rng->rng.name    = "rockchip";
> +#ifndef CONFIG_PM
> +	rk_rng->rng.init    = rk_rng_init;
> +	rk_rng->rng.cleanup = rk_rng_cleanup,
> +#endif
> +	rk_rng->rng.read    = rk_rng->soc_data->rk_rng_read;
> +	rk_rng->rng.quality = 1024;
> +
> +	rk_rng->clk_bulks =
> +		devm_kzalloc(&pdev->dev, sizeof(*rk_rng->clk_bulks) *
> +			     rk_rng->soc_data->clks_num, GFP_KERNEL);
> +
> +	rk_rng->clk_num = rk_rng->soc_data->clks_num;
> +
> +	for (i = 0; i < rk_rng->soc_data->clks_num; i++)
> +		rk_rng->clk_bulks[i].id = rk_rng->soc_data->clks[i];
> +
> +	rk_rng->mem = devm_of_iomap(&pdev->dev, pdev->dev.of_node, 0, NULL);
> +	if (IS_ERR(rk_rng->mem))
> +		return PTR_ERR(rk_rng->mem);
> +
> +	ret = devm_clk_bulk_get(&pdev->dev, rk_rng->clk_num,
> +				rk_rng->clk_bulks);
> +	if (ret) {
> +		dev_err(&pdev->dev, "failed to get clks property\n");
> +		return ret;
> +	}
> +
> +	platform_set_drvdata(pdev, rk_rng);
> +
> +	pm_runtime_set_autosuspend_delay(&pdev->dev,
> +					ROCKCHIP_AUTOSUSPEND_DELAY);
> +	pm_runtime_use_autosuspend(&pdev->dev);
> +	pm_runtime_enable(&pdev->dev);
> +
> +	ret = devm_hwrng_register(&pdev->dev, &rk_rng->rng);
> +	if (ret) {
> +		pm_runtime_dont_use_autosuspend(&pdev->dev);
> +		pm_runtime_disable(&pdev->dev);
> +	}
> +
> +	return ret;
> +}
> +
> +#ifdef CONFIG_PM
> +static int 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 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)
> +};
> +#endif
> +
> +static struct platform_driver rk_rng_driver = {
> +	.driver	= {
> +		.name	= "rockchip-rng",
> +#ifdef CONFIG_PM
> +		.pm	= &rk_rng_pm_ops,
> +#endif
> +		.of_match_table = rk_rng_dt_match,
> +	},
> +	.probe	= rk_rng_probe,
> +};
> +
> +module_platform_driver(rk_rng_driver);
> +
> +MODULE_DESCRIPTION("ROCKCHIP H/W Random Number Generator driver");
> +MODULE_AUTHOR("Lin Jinhan <troy.lin@rock-chips.com>");
> +MODULE_LICENSE("GPL v2");

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[Jason A. Donenfeld]

Hi Robin,

On Tue, Sep 20, 2022 at 10:35:44AM +0100, Robin Murphy wrote:
> On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> > The Rockchip driver has long existed out of tree, but not upstream.
> > There is support for it upstream in u-boot, but not in Linux proper.
> > This commit imports the GPLv2 driver written by Lin Jinhan, together
> > with the DTS and config blobs from Wevsty.
> 
> Note that Corentin has a series enabling the full crypto driver for 
> RK3328 and RK3399[1], so it would seem more sensible to add TRNG support 
> to that. Having confliciting compatibles for the same hardware that 
> force the user to change their DT to choose one functionality or the 
> other isn't good (plus there's also no binding for this one).

Kyle, CC'd, pointed out the same thing to me. He apparently has already
done the work to have a hwrng ontop of that series. So hopefully it's
just a matter of having everyone coordinate.

So I'll duck out and let you guys handle it. Just please make sure the
thing you're rejecting this for does actually come to fruition.

Kyle, should you send your thing to Corentin?

Jason

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[Aurelien Jarno]

On 2022-09-20 10:35, Robin Murphy wrote:
> On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> > The Rockchip driver has long existed out of tree, but not upstream.
> > There is support for it upstream in u-boot, but not in Linux proper.
> > This commit imports the GPLv2 driver written by Lin Jinhan, together
> > with the DTS and config blobs from Wevsty.
> 
> Note that Corentin has a series enabling the full crypto driver for 
> RK3328 and RK3399[1], so it would seem more sensible to add TRNG support 
> to that. Having confliciting compatibles for the same hardware that 
> force the user to change their DT to choose one functionality or the 
> other isn't good (plus there's also no binding for this one).

It might make sense for the cryptov1-rng driver (I haven't checked). For
the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
RK3588 one), and from what I understand crypto and TRNG are two
different devices, using different address spaces, clock, reset and
interrupts. The vendor kernel uses two different drivers.

Regards
Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[LABBE Corentin]

Le Tue, Sep 27, 2022 at 06:37:53PM +0200, Aurelien Jarno a écrit :
> On 2022-09-20 10:35, Robin Murphy wrote:
> > On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> > > The Rockchip driver has long existed out of tree, but not upstream.
> > > There is support for it upstream in u-boot, but not in Linux proper.
> > > This commit imports the GPLv2 driver written by Lin Jinhan, together
> > > with the DTS and config blobs from Wevsty.
> > 
> > Note that Corentin has a series enabling the full crypto driver for 
> > RK3328 and RK3399[1], so it would seem more sensible to add TRNG support 
> > to that. Having confliciting compatibles for the same hardware that 
> > force the user to change their DT to choose one functionality or the 
> > other isn't good (plus there's also no binding for this one).
> 
> It might make sense for the cryptov1-rng driver (I haven't checked). For
> the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
> RK3588 one), and from what I understand crypto and TRNG are two
> different devices, using different address spaces, clock, reset and
> interrupts. The vendor kernel uses two different drivers.
> 

I confirm that TRNG is not on the same IP on rk3568, something I didnt remark when doing my V2 driver. (I need to remove rng clock from rk3568 dt).
But the rk3588 crypto IP and the TRNG are in the same device.

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[Aurelien Jarno]

On 2022-09-27 21:46, LABBE Corentin wrote:
> Le Tue, Sep 27, 2022 at 06:37:53PM +0200, Aurelien Jarno a écrit :
> > On 2022-09-20 10:35, Robin Murphy wrote:
> > > On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> > > > The Rockchip driver has long existed out of tree, but not upstream.
> > > > There is support for it upstream in u-boot, but not in Linux proper.
> > > > This commit imports the GPLv2 driver written by Lin Jinhan, together
> > > > with the DTS and config blobs from Wevsty.
> > > 
> > > Note that Corentin has a series enabling the full crypto driver for 
> > > RK3328 and RK3399[1], so it would seem more sensible to add TRNG support 
> > > to that. Having confliciting compatibles for the same hardware that 
> > > force the user to change their DT to choose one functionality or the 
> > > other isn't good (plus there's also no binding for this one).
> > 
> > It might make sense for the cryptov1-rng driver (I haven't checked). For
> > the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
> > RK3588 one), and from what I understand crypto and TRNG are two
> > different devices, using different address spaces, clock, reset and
> > interrupts. The vendor kernel uses two different drivers.
> > 
> 
> I confirm that TRNG is not on the same IP on rk3568, something I didnt remark when doing my V2 driver. (I need to remove rng clock from rk3568 dt).
> But the rk3588 crypto IP and the TRNG are in the same device.

Ok, thanks for confirming about the rk3568. It seems the only one in the
family with separate devices for TRNG and crypto. Does it means we need
a separate TRNG driver only for it? Or could we handle it the same way
than for instance rk3588 anyway?

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[LABBE Corentin]

Le Tue, Sep 27, 2022 at 11:39:17PM +0200, Aurelien Jarno a écrit :
> On 2022-09-27 21:46, LABBE Corentin wrote:
> > Le Tue, Sep 27, 2022 at 06:37:53PM +0200, Aurelien Jarno a écrit :
> > > On 2022-09-20 10:35, Robin Murphy wrote:
> > > > On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> > > > > The Rockchip driver has long existed out of tree, but not upstream.
> > > > > There is support for it upstream in u-boot, but not in Linux proper.
> > > > > This commit imports the GPLv2 driver written by Lin Jinhan, together
> > > > > with the DTS and config blobs from Wevsty.
> > > > 
> > > > Note that Corentin has a series enabling the full crypto driver for 
> > > > RK3328 and RK3399[1], so it would seem more sensible to add TRNG support 
> > > > to that. Having confliciting compatibles for the same hardware that 
> > > > force the user to change their DT to choose one functionality or the 
> > > > other isn't good (plus there's also no binding for this one).
> > > 
> > > It might make sense for the cryptov1-rng driver (I haven't checked). For
> > > the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
> > > RK3588 one), and from what I understand crypto and TRNG are two
> > > different devices, using different address spaces, clock, reset and
> > > interrupts. The vendor kernel uses two different drivers.
> > > 
> > 
> > I confirm that TRNG is not on the same IP on rk3568, something I didnt remark when doing my V2 driver. (I need to remove rng clock from rk3568 dt).
> > But the rk3588 crypto IP and the TRNG are in the same device.
> 
> Ok, thanks for confirming about the rk3568. It seems the only one in the
> family with separate devices for TRNG and crypto. Does it means we need
> a separate TRNG driver only for it? Or could we handle it the same way
> than for instance rk3588 anyway?

I just got now the part 1 of rk3588 TRM which I has missing and it show some conflicting information.
rk3588 seems to have both a dedicated TRNG (TRNG_NS/TRNG_S) with dedicated address space and a TRNG inside the crypto IP.
But for the moment, the TRNG inside crypto IP seems defective.

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[Mikhail Rudenko]

On 2022-09-29 at 09:45 +02, LABBE Corentin <clabbe@baylibre.com> wrote:
> Le Tue, Sep 27, 2022 at 11:39:17PM +0200, Aurelien Jarno a écrit :
>> On 2022-09-27 21:46, LABBE Corentin wrote:
>> > Le Tue, Sep 27, 2022 at 06:37:53PM +0200, Aurelien Jarno a écrit :
>> > > On 2022-09-20 10:35, Robin Murphy wrote:
>> > > > On 2022-09-19 22:00, Jason A. Donenfeld wrote:
>> > > > > The Rockchip driver has long existed out of tree, but not upstream.
>> > > > > There is support for it upstream in u-boot, but not in Linux proper.
>> > > > > This commit imports the GPLv2 driver written by Lin Jinhan, together
>> > > > > with the DTS and config blobs from Wevsty.
>> > > >
>> > > > Note that Corentin has a series enabling the full crypto driver for
>> > > > RK3328 and RK3399[1], so it would seem more sensible to add TRNG support
>> > > > to that. Having confliciting compatibles for the same hardware that
>> > > > force the user to change their DT to choose one functionality or the
>> > > > other isn't good (plus there's also no binding for this one).
>> > >
>> > > It might make sense for the cryptov1-rng driver (I haven't checked). For
>> > > the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
>> > > RK3588 one), and from what I understand crypto and TRNG are two
>> > > different devices, using different address spaces, clock, reset and
>> > > interrupts. The vendor kernel uses two different drivers.
>> > >
>> >
>> > I confirm that TRNG is not on the same IP on rk3568, something I didnt remark when doing my V2 driver. (I need to remove rng clock from rk3568 dt).
>> > But the rk3588 crypto IP and the TRNG are in the same device.
>>
>> Ok, thanks for confirming about the rk3568. It seems the only one in the
>> family with separate devices for TRNG and crypto. Does it means we need
>> a separate TRNG driver only for it? Or could we handle it the same way
>> than for instance rk3588 anyway?
>
> I just got now the part 1 of rk3588 TRM which I has missing and it show some conflicting information.
> rk3588 seems to have both a dedicated TRNG (TRNG_NS/TRNG_S) with dedicated address space and a TRNG inside the crypto IP.
> But for the moment, the TRNG inside crypto IP seems defective.

So what's the ultimate decision? Does anyone work on merging this into
the existing crypto driver? I have a use case with an rk3399-based board,
where having hardware rng enhances boot times dramatically (at least for
some userspaces; see also [1]).

[1] https://bugzilla.kernel.org/show_bug.cgi?id=216502

--
Best regards,
Mikhail Rudenko

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[Corentin LABBE]

Le Wed, Nov 16, 2022 at 09:04:07PM +0300, Mikhail Rudenko a écrit :
> 
> On 2022-09-29 at 09:45 +02, LABBE Corentin <clabbe@baylibre.com> wrote:
> > Le Tue, Sep 27, 2022 at 11:39:17PM +0200, Aurelien Jarno a écrit :
> >> On 2022-09-27 21:46, LABBE Corentin wrote:
> >> > Le Tue, Sep 27, 2022 at 06:37:53PM +0200, Aurelien Jarno a écrit :
> >> > > On 2022-09-20 10:35, Robin Murphy wrote:
> >> > > > On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> >> > > > > The Rockchip driver has long existed out of tree, but not upstream.
> >> > > > > There is support for it upstream in u-boot, but not in Linux proper.
> >> > > > > This commit imports the GPLv2 driver written by Lin Jinhan, together
> >> > > > > with the DTS and config blobs from Wevsty.
> >> > > >
> >> > > > Note that Corentin has a series enabling the full crypto driver for
> >> > > > RK3328 and RK3399[1], so it would seem more sensible to add TRNG support
> >> > > > to that. Having confliciting compatibles for the same hardware that
> >> > > > force the user to change their DT to choose one functionality or the
> >> > > > other isn't good (plus there's also no binding for this one).
> >> > >
> >> > > It might make sense for the cryptov1-rng driver (I haven't checked). For
> >> > > the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
> >> > > RK3588 one), and from what I understand crypto and TRNG are two
> >> > > different devices, using different address spaces, clock, reset and
> >> > > interrupts. The vendor kernel uses two different drivers.
> >> > >
> >> >
> >> > I confirm that TRNG is not on the same IP on rk3568, something I didnt remark when doing my V2 driver. (I need to remove rng clock from rk3568 dt).
> >> > But the rk3588 crypto IP and the TRNG are in the same device.
> >>
> >> Ok, thanks for confirming about the rk3568. It seems the only one in the
> >> family with separate devices for TRNG and crypto. Does it means we need
> >> a separate TRNG driver only for it? Or could we handle it the same way
> >> than for instance rk3588 anyway?
> >
> > I just got now the part 1 of rk3588 TRM which I has missing and it show some conflicting information.
> > rk3588 seems to have both a dedicated TRNG (TRNG_NS/TRNG_S) with dedicated address space and a TRNG inside the crypto IP.
> > But for the moment, the TRNG inside crypto IP seems defective.
> 
> So what's the ultimate decision? Does anyone work on merging this into
> the existing crypto driver? I have a use case with an rk3399-based board,
> where having hardware rng enhances boot times dramatically (at least for
> some userspaces; see also [1]).
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=216502
> 

Hello

I started to work on adding RNG to rk3288_crypto.
I need to publish the work on my github and take time to send it for review.

Regards

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[Mikhail Rudenko]

On 2022-11-22 at 14:29 +01, Corentin LABBE <clabbe@baylibre.com> wrote:

> Le Wed, Nov 16, 2022 at 09:04:07PM +0300, Mikhail Rudenko a écrit :
>>
>> On 2022-09-29 at 09:45 +02, LABBE Corentin <clabbe@baylibre.com> wrote:
>> > Le Tue, Sep 27, 2022 at 11:39:17PM +0200, Aurelien Jarno a écrit :
>> >> On 2022-09-27 21:46, LABBE Corentin wrote:
>> >> > Le Tue, Sep 27, 2022 at 06:37:53PM +0200, Aurelien Jarno a écrit :
>> >> > > On 2022-09-20 10:35, Robin Murphy wrote:
>> >> > > > On 2022-09-19 22:00, Jason A. Donenfeld wrote:
>> >> > > > > The Rockchip driver has long existed out of tree, but not upstream.
>> >> > > > > There is support for it upstream in u-boot, but not in Linux proper.
>> >> > > > > This commit imports the GPLv2 driver written by Lin Jinhan, together
>> >> > > > > with the DTS and config blobs from Wevsty.
>> >> > > >
>> >> > > > Note that Corentin has a series enabling the full crypto driver for
>> >> > > > RK3328 and RK3399[1], so it would seem more sensible to add TRNG support
>> >> > > > to that. Having confliciting compatibles for the same hardware that
>> >> > > > force the user to change their DT to choose one functionality or the
>> >> > > > other isn't good (plus there's also no binding for this one).
>> >> > >
>> >> > > It might make sense for the cryptov1-rng driver (I haven't checked). For
>> >> > > the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
>> >> > > RK3588 one), and from what I understand crypto and TRNG are two
>> >> > > different devices, using different address spaces, clock, reset and
>> >> > > interrupts. The vendor kernel uses two different drivers.
>> >> > >
>> >> >
>> >> > I confirm that TRNG is not on the same IP on rk3568, something I didnt remark when doing my V2 driver. (I need to remove rng clock from rk3568 dt).
>> >> > But the rk3588 crypto IP and the TRNG are in the same device.
>> >>
>> >> Ok, thanks for confirming about the rk3568. It seems the only one in the
>> >> family with separate devices for TRNG and crypto. Does it means we need
>> >> a separate TRNG driver only for it? Or could we handle it the same way
>> >> than for instance rk3588 anyway?
>> >
>> > I just got now the part 1 of rk3588 TRM which I has missing and it show some conflicting information.
>> > rk3588 seems to have both a dedicated TRNG (TRNG_NS/TRNG_S) with dedicated address space and a TRNG inside the crypto IP.
>> > But for the moment, the TRNG inside crypto IP seems defective.
>>
>> So what's the ultimate decision? Does anyone work on merging this into
>> the existing crypto driver? I have a use case with an rk3399-based board,
>> where having hardware rng enhances boot times dramatically (at least for
>> some userspaces; see also [1]).
>>
>> [1] https://bugzilla.kernel.org/show_bug.cgi?id=216502
>>
>
> Hello
>
> I started to work on adding RNG to rk3288_crypto.
> I need to publish the work on my github and take time to send it for review.

Glad to hear you are working on this. Please cc me when posting patches :)

>
> Regards

--
Best regards,
Mikhail Rudenko

Re: [PATCH] hw_random: rockchip: import driver from vendor tree

[Corentin LABBE]

Le Tue, Sep 20, 2022 at 10:35:44AM +0100, Robin Murphy a écrit :
> On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> > The Rockchip driver has long existed out of tree, but not upstream.
> > There is support for it upstream in u-boot, but not in Linux proper.
> > This commit imports the GPLv2 driver written by Lin Jinhan, together
> > with the DTS and config blobs from Wevsty.
> 
> Note that Corentin has a series enabling the full crypto driver for 
> RK3328 and RK3399[1], so it would seem more sensible to add TRNG support 
> to that. Having confliciting compatibles for the same hardware that 
> force the user to change their DT to choose one functionality or the 
> other isn't good (plus there's also no binding for this one).
> 
> Robin.
> 

Hello

I am very interested on how this serie was tested and which tools was used to ensure output was random.
And how did you get that CRYPTO_V1_TRNG_SAMPLE_PERIOD(100); was the best choice.

Thanks
Regards