diff mbox series

[v4,2/3] hwrng: add Rockchip SoC hwrng driver

Message ID 240db6e0ab07e8e2a86da99b0fc085eabaf9f0cc.1719106472.git.daniel@makrotopia.org (mailing list archive)
State Superseded
Headers show
Series hwrng: add hwrng support for Rockchip RK3568 | expand

Commit Message

Daniel Golle June 23, 2024, 3:33 a.m. UTC
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 RK356x 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>
---
 MAINTAINERS                           |   1 +
 drivers/char/hw_random/Kconfig        |  14 ++
 drivers/char/hw_random/Makefile       |   1 +
 drivers/char/hw_random/rockchip-rng.c | 222 ++++++++++++++++++++++++++
 4 files changed, 238 insertions(+)
 create mode 100644 drivers/char/hw_random/rockchip-rng.c

Comments

Krzysztof Kozlowski June 23, 2024, 7 a.m. UTC | #1
On 23/06/2024 05:33, Daniel Golle wrote:
> +
> +	rk_rng->rng.name = dev_driver_string(dev);
> +#ifndef CONFIG_PM
> +	rk_rng->rng.init = rk_rng_init;
> +	rk_rng->rng.cleanup = rk_rng_cleanup;
> +#endif
> +	rk_rng->rng.read = rk_rng_read;
> +	rk_rng->rng.priv = (unsigned long) dev;
> +	rk_rng->rng.quality = 900;

I doubt in this value. Usually SoC vendors do not provide datasheet with
any reliable and verifiable (so one which could be proven by 3rd party)
information. Can you provide a source? (and vendor downstream tree does
not really count)

> +
> +	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");
> +
> +	dev_dbg(&pdev->dev, "Registered Rockchip hwrng\n");

Drop, it is not useful at all. Srsly, we had already long enough talk,
which wasted time of three people. Why do you insist on wasting more?

There is no single benefit of such debug statement. sysfs already
provides you this information. Simple entry/exit  is provided by
tracing. You duplicate existing interfaces without any benefit, because
this prints nothing more.

Best regards,
Krzysztof
Uwe Kleine-König June 23, 2024, 9:46 a.m. UTC | #2
Hello Krzysztof,

On 6/23/24 09:00, Krzysztof Kozlowski wrote:
> On 23/06/2024 05:33, Daniel Golle wrote:
>> +
>> +	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");
>> +
>> +	dev_dbg(&pdev->dev, "Registered Rockchip hwrng\n");
> 
> Drop, it is not useful at all. Srsly, we had already long enough talk,
 > [...]

And in this long talk using dev_dbg() was one of the suggestions for a 
compromise. For me this is ok.

> There is no single benefit of such debug statement. sysfs already
> provides you this information. Simple entry/exit  is provided by
> tracing. You duplicate existing interfaces without any benefit, because
> this prints nothing more.

There might be a (small) value if you want to know when during boot the 
device becomes available. So having a dev_dbg() that can be enabled 
dynamically (assuming DYNAMIC_DEBUG=y) and isn't in the way otherwise 
might be justified. IMHO a dev_dbg is lightweight enough that *I* won't 
continue the discussion.

Best regards
Uwe
Aurelien Jarno June 23, 2024, 10:42 a.m. UTC | #3
Hi,

On 2024-06-23 09:00, Krzysztof Kozlowski wrote:
> On 23/06/2024 05:33, Daniel Golle wrote:
> > +
> > +	rk_rng->rng.name = dev_driver_string(dev);
> > +#ifndef CONFIG_PM
> > +	rk_rng->rng.init = rk_rng_init;
> > +	rk_rng->rng.cleanup = rk_rng_cleanup;
> > +#endif
> > +	rk_rng->rng.read = rk_rng_read;
> > +	rk_rng->rng.priv = (unsigned long) dev;
> > +	rk_rng->rng.quality = 900;
> 
> I doubt in this value. Usually SoC vendors do not provide datasheet with
> any reliable and verifiable (so one which could be proven by 3rd party)
> information. Can you provide a source? (and vendor downstream tree does
> not really count)

As the original author of the patch, I am the one who have chosen the
value. I did it as explained in the commit message:

| 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.

It is also explained, admittedly more briefly, above the
RK_RNG_SAMPLE_CNT #define, as the commit messages are not really
relevant anymore once the patches are accepted:

| * 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).
| */

The decision to adjust RK_RNG_SAMPLE_CNT to reach ~90% of FIPS 140-2
successes was based on the quality chosen by most hw_random drivers
currently in the kernel sources. The FIPS 140-2 tests were performed
using rngtest from the rng-tools project.

All that said, I am not an expert in that domain, so feel free to point
to the documentation or provide the correct method to determine the
quality.

Regards
Aurelien

[1] https://git.kernel.org/pub/scm/utils/kernel/rng-tools/rng-tools.git/
Dragan Simic June 23, 2024, 11:47 a.m. UTC | #4
Hello Uwe,

On 2024-06-23 11:46, Uwe Kleine-König wrote:
> On 6/23/24 09:00, Krzysztof Kozlowski wrote:
>> On 23/06/2024 05:33, Daniel Golle wrote:
>>> +
>>> +	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");
>>> +
>>> +	dev_dbg(&pdev->dev, "Registered Rockchip hwrng\n");
>> 
>> Drop, it is not useful at all. Srsly, we had already long enough talk,
>> [...]
> 
> And in this long talk using dev_dbg() was one of the suggestions for a
> compromise. For me this is ok.
> 
>> There is no single benefit of such debug statement. sysfs already
>> provides you this information. Simple entry/exit  is provided by
>> tracing. You duplicate existing interfaces without any benefit, 
>> because
>> this prints nothing more.
> 
> There might be a (small) value if you want to know when during boot
> the device becomes available. So having a dev_dbg() that can be
> enabled dynamically (assuming DYNAMIC_DEBUG=y) and isn't in the way
> otherwise might be justified. IMHO a dev_dbg is lightweight enough
> that *I* won't continue the discussion.

For anyone interested, below is an example that shows the usability
of knowing when a device becomes available:

https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/issues/21
Anand Moon June 23, 2024, 2:10 p.m. UTC | #5
Hi,

On Sun, 23 Jun 2024 at 16:13, Aurelien Jarno <aurelien@aurel32.net> wrote:
>
> Hi,
>
> On 2024-06-23 09:00, Krzysztof Kozlowski wrote:
> > On 23/06/2024 05:33, Daniel Golle wrote:
> > > +
> > > +   rk_rng->rng.name = dev_driver_string(dev);
> > > +#ifndef CONFIG_PM
> > > +   rk_rng->rng.init = rk_rng_init;
> > > +   rk_rng->rng.cleanup = rk_rng_cleanup;
> > > +#endif
> > > +   rk_rng->rng.read = rk_rng_read;
> > > +   rk_rng->rng.priv = (unsigned long) dev;
> > > +   rk_rng->rng.quality = 900;
> >
> > I doubt in this value. Usually SoC vendors do not provide datasheet with
> > any reliable and verifiable (so one which could be proven by 3rd party)
> > information. Can you provide a source? (and vendor downstream tree does
> > not really count)
>
> As the original author of the patch, I am the one who have chosen the
> value. I did it as explained in the commit message:
>
> | 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.
>
> It is also explained, admittedly more briefly, above the
> RK_RNG_SAMPLE_CNT #define, as the commit messages are not really
> relevant anymore once the patches are accepted:
>
> | * 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).
> | */
>
> The decision to adjust RK_RNG_SAMPLE_CNT to reach ~90% of FIPS 140-2
> successes was based on the quality chosen by most hw_random drivers
> currently in the kernel sources. The FIPS 140-2 tests were performed
> using rngtest from the rng-tools project.
>
> All that said, I am not an expert in that domain, so feel free to point
> to the documentation or provide the correct method to determine the
> quality.
>
> Regards
> Aurelien
>
> [1] https://git.kernel.org/pub/scm/utils/kernel/rng-tools/rng-tools.git/

This is an old repository, the latest can be found below
[1] https://github.com/nhorman/rng-tools

However, I could not find the support from ARM and ARM64 in the repository below
because all the assembly is written for the X86 arch.

Thanks

-Anand
diff mbox series

Patch

diff --git a/MAINTAINERS b/MAINTAINERS
index 5cd3bc2b034f..580536b72d25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19503,6 +19503,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..714d177ac45e
--- /dev/null
+++ b/drivers/char/hw_random/rockchip-rng.c
@@ -0,0 +1,222 @@ 
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * rockchip-rng.c True Random Number Generator driver for Rockchip SoCs
+ *
+ * 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_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;
+};
+
+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 */
+	writel(TRNG_RNG_CTL_LEN_256_BIT |
+	       TRNG_RNG_CTL_OSC_RING_SPEED_0 |
+	       TRNG_RNG_CTL_ENABLE,
+	       rk_rng->base + TRNG_RNG_CTL);
+
+	return 0;
+}
+
+static void rk_rng_cleanup(struct hwrng *rng)
+{
+	struct rk_rng *rk_rng = container_of(rng, struct rk_rng, rng);
+
+	/* stop TRNG */
+	writel(0, rk_rng->base + TRNG_RNG_CTL);
+
+	/* 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 */
+	writel(TRNG_RNG_CTL_START, rk_rng->base + TRNG_RNG_CTL);
+
+	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);
+#ifndef CONFIG_PM
+	rk_rng->rng.init = rk_rng_init;
+	rk_rng->rng.cleanup = rk_rng_cleanup;
+#endif
+	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");
+
+	dev_dbg(&pdev->dev, "Registered Rockchip hwrng\n");
+
+	return 0;
+}
+
+#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);
+}
+#endif
+
+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 True Random Number Generator driver");
+MODULE_AUTHOR("Lin Jinhan <troy.lin@rock-chips.com>, Aurelien Jarno <aurelien@aurel32.net>");
+MODULE_LICENSE("GPL");