| Message ID | 20220919210025.2376254-1-Jason@zx2c4.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | hw_random: rockchip: import driver from vendor tree | expand |
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");
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
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
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.
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?
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.
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
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
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
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
Hi Corentin / Jason, On Tue, 31 Jan 2023 at 16:10, Corentin LABBE <clabbe@baylibre.com> wrote: > > 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. > Is there any update on this driver I just tested this patch on my RK3399 board. 8<-------------------------------------------------------------->8 # 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, 0.829212 s, 121 kB/s # cat /dev/hwrng | rngtest -c 1000 ... rngtest: starting FIPS tests... rngtest: bits received from input: 20000032 rngtest: FIPS 140-2 successes: 0 rngtest: FIPS 140-2 failures: 1000 <-- failures rngtest: FIPS 140-2(2001-10-10) Monobit: 21 rngtest: FIPS 140-2(2001-10-10) Poker: 1000 rngtest: FIPS 140-2(2001-10-10) Runs: 1000 rngtest: FIPS 140-2(2001-10-10) Long run: 0 rngtest: FIPS 140-2(2001-10-10) Continuous run: 4 rngtest: input channel speed: (min=18.079; avg=955.991; max=9765625.000)Kibits/s rngtest: FIPS tests speed: (min=18.062; avg=31.619; max=50.459)Mibits/s rngtest: Program run time: 22125055 microseconds Whereas for /dev/random # cat /dev/random | rngtest -c 1000 ... rngtest: starting FIPS tests... rngtest: bits received from input: 20000032 rngtest: FIPS 140-2 successes: 998 rngtest: FIPS 140-2 failures: 2 rngtest: FIPS 140-2(2001-10-10) Monobit: 0 rngtest: FIPS 140-2(2001-10-10) Poker: 1 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=381.470; avg=5551.073; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=24.933; avg=70.400; max=79.805)Mibits/s rngtest: Program run time: 276870 microseconds Thanks -Anand > Thanks > Regards > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
Hi everybody, Is there any chance this random driver will be upstreamed? I'm using it instead of the built-in crypto driver (rk3328-crypto), as this crypto driver showed the following: > [ 9.270549] rk3288-crypto ff060000.crypto: will run requests pump with realtime priority > [ 9.270687] rk3288-crypto ff060000.crypto: Register ecb(aes) as ecb-aes-rk > [ 9.270808] rk3288-crypto ff060000.crypto: Register cbc(aes) as cbc-aes-rk > [ 9.270831] rk3288-crypto ff060000.crypto: Register ecb(des) as ecb-des-rk > [ 9.270848] rk3288-crypto ff060000.crypto: Register cbc(des) as cbc-des-rk > [ 9.270864] rk3288-crypto ff060000.crypto: Register ecb(des3_ede) as ecb-des3-ede-rk > [ 9.270880] rk3288-crypto ff060000.crypto: Register cbc(des3_ede) as cbc-des3-ede-rk > [ 9.270896] rk3288-crypto ff060000.crypto: Register sha1 as rk-sha1 > [ 9.270915] rk3288-crypto ff060000.crypto: Register sha256 as rk-sha256 > [ 9.270932] rk3288-crypto ff060000.crypto: Register md5 as rk-md5 so the options here are pretty useless: standard tls / ssh (ktls anyone?) almost never uses ecb or cbc ciphers, and about des ... yeah, won't dig into that one. I think a rk3328 device will actually benefit more from a entropy source (even if it's not high-quality) than from sha1/256 which are almost always covered by armv8 crypto extensions. I tried this patch (and disabled the crypto device in dts), it works. Off course there are FIPS failures, but the user employing a rk3328 board probably knows this is not a high-security device. Any chances here? applying the patch on 6.6.48 (even with clang thinLTO) works flawlessly. kind regards, Janpieter Sollie
Le Mon, Sep 23, 2024 at 09:48:54AM +0200, Janpieter Sollie a écrit : > > Hi everybody, > > Is there any chance this random driver will be upstreamed? > I'm using it instead of the built-in crypto driver (rk3328-crypto), as this crypto driver showed > the following: > > > [ 9.270549] rk3288-crypto ff060000.crypto: will run requests pump with realtime priority > > [ 9.270687] rk3288-crypto ff060000.crypto: Register ecb(aes) as ecb-aes-rk > > [ 9.270808] rk3288-crypto ff060000.crypto: Register cbc(aes) as cbc-aes-rk > > [ 9.270831] rk3288-crypto ff060000.crypto: Register ecb(des) as ecb-des-rk > > [ 9.270848] rk3288-crypto ff060000.crypto: Register cbc(des) as cbc-des-rk > > [ 9.270864] rk3288-crypto ff060000.crypto: Register ecb(des3_ede) as ecb-des3-ede-rk > > [ 9.270880] rk3288-crypto ff060000.crypto: Register cbc(des3_ede) as cbc-des3-ede-rk > > [ 9.270896] rk3288-crypto ff060000.crypto: Register sha1 as rk-sha1 > > [ 9.270915] rk3288-crypto ff060000.crypto: Register sha256 as rk-sha256 > > [ 9.270932] rk3288-crypto ff060000.crypto: Register md5 as rk-md5 > > so the options here are pretty useless: > standard tls / ssh (ktls anyone?) almost never uses ecb or cbc ciphers, and about des ... yeah, > won't dig into that one. > I think a rk3328 device will actually benefit more from a entropy source (even if it's not > high-quality) than from sha1/256 which are almost always covered by armv8 crypto extensions. > I tried this patch (and disabled the crypto device in dts), it works. > Off course there are FIPS failures, but the user employing a rk3328 board probably knows this is > not a high-security device. > > Any chances here? applying the patch on 6.6.48 (even with clang thinLTO) works flawlessly. > > kind regards, > > Janpieter Sollie Did you test if it really works by testing entropy output QUALITY ? I asked how the serie was tested and the sender never answered raising a big red flag. If you check the thread, someone tested and the quality bringed by the vendor driver is really BAD. This is due to the fact that their sample value was really too short. So as-is, this serie is a security issue to the randomness quality. I need to regrab some time finishing, my patch adding support for it on intree crypto driver. I found an old tree that I push here https://github.com/montjoie/linux/tree/rk3288-trng This is not a final patch, but it could help finding a correct value of sample via the debugfs. I dont remember which value of sample was necessary to obtain a minimal quality. (perhaps 500 since it seems the default in my patch). Unfortunatly, I cannot test it immediatly, as my CI controller got some HW issue, and I need to fix them. Regards
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");