From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: "Alexey Klimov" <alexey.klimov@linaro.org>, olivia@selenic.com, herbert@gondor.apana.org.au, sehi.kim@samsung.com, linux-samsung-soc@vger.kernel.org, peter.griffin@linaro.org, "Łukasz Stelmach" <l.stelmach@samsung.com> Cc: alim.akhtar@samsung.com, linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com, andre.draszik@linaro.org, willmcvicker@google.com, saravanak@google.com, elder@linaro.org, tudor.ambarus@linaro.org, klimov.linux@gmail.com Subject: Re: [PATCH REVIEW] hwrng: add exynos Secure World RNG device driver Date: Thu, 28 Mar 2024 14:36:40 +0100 [thread overview] Message-ID: <6b691a48-ca97-4f23-a09f-69b9254f0c11@linaro.org> (raw) In-Reply-To: <20240328125056.1054878-1-alexey.klimov@linaro.org> On 28/03/2024 13:50, Alexey Klimov wrote: > The Exynos TRNG device is controlled by firmware and shared between No, it is not. I have TRNG perfectly usable on my board. Maybe you are refer to some specific SoC... Please always Cc existing TRNG driver maintainer. > non-secure world and secure world. Access to it is exposed via SMC > interface which is implemented here. The firmware code does > additional security checks, start-up test and some checks on resume. > > This device is found, for instance, in Google Tensor GS101-family > of devices. Nothing here explains why this cannot be integrated into existing driver. Maybe it, maybe it cannot... You try to upstream again vendor driver ignoring that community already did it and instead it might be enough to customize it. Guys, the same as all the MCT, PHYs and PCI in previous works of various people: stop duplicating drivers by upstreaming new vendor stuff with all the issues we already fixed and please work on re-using existing drivers. Sometimes work cannot be combined, so come with arguments. Otherwise we keep repeating and repeating the same feedback. > > Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> > --- > drivers/char/hw_random/Kconfig | 12 + > drivers/char/hw_random/Makefile | 1 + > drivers/char/hw_random/exynos-swd-trng.c | 423 +++++++++++++++++++++++ > 3 files changed, 436 insertions(+) > create mode 100644 drivers/char/hw_random/exynos-swd-trng.c > > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig > index 442c40efb200..bff7c3ec129a 100644 > --- a/drivers/char/hw_random/Kconfig > +++ b/drivers/char/hw_random/Kconfig > @@ -479,6 +479,18 @@ config HW_RANDOM_EXYNOS > > If unsure, say Y. > > +config HW_RANDOM_EXYNOS_SWD > + tristate "Exynos SWD HW random number generator support" What is SWD? > + default n > + help > + This driver provides kernel-side support for accessing Samsung > + TRNG hardware located in secure world using smc calls. > + > + To compile this driver as a module, choose M here: the > + module will be called exynos-swd-trng. > + > + If unsure, say N. > + ... > + > +static UNIVERSAL_DEV_PM_OPS(exyswd_rng_pm_ops, exyswd_rng_suspend, > + exyswd_rng_resume, NULL); > + > +static struct platform_driver exyswd_rng_driver = { > + .probe = exyswd_rng_probe, > + .remove = exyswd_rng_remove, > + .driver = { > + .name = DRVNAME, > + .owner = THIS_MODULE, So this was fixed ~8-10 years ago. Yet it re-appears. Please do not use downstream code as template. Take upstream driver and either change it or customize it. > + .pm = &exyswd_rng_pm_ops, > + }, > +}; > + > +static struct platform_device *exyswd_rng_pdev; And if I have multiple devices? > + > +static int __init exyswd_rng_init(void) > +{ > + int ret; > + > + exyswd_rng_pdev = platform_device_register_simple(DRVNAME, -1, NULL, 0); > + if (IS_ERR(exyswd_rng_pdev)) > + pr_err(DRVNAME ": could not register device: %ld\n", > + PTR_ERR(exyswd_rng_pdev)); This is some oddity... Why do you create devices based on module load? So I load this on Qualcomm anbd you create exynos device? This does not make sense. > + > + ret = platform_driver_register(&exyswd_rng_driver); > + if (ret) { > + platform_device_unregister(exyswd_rng_pdev); > + return ret; > + } > + > + pr_info("ExyRNG driver, (c) 2014 Samsung Electronics\n"); Drop, dirvers should not print code just because I load a driver. Again: imagine I load it on Qualcomm. Best regards, Krzysztof
WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> To: "Alexey Klimov" <alexey.klimov@linaro.org>, olivia@selenic.com, herbert@gondor.apana.org.au, sehi.kim@samsung.com, linux-samsung-soc@vger.kernel.org, peter.griffin@linaro.org, "Łukasz Stelmach" <l.stelmach@samsung.com> Cc: alim.akhtar@samsung.com, linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com, andre.draszik@linaro.org, willmcvicker@google.com, saravanak@google.com, elder@linaro.org, tudor.ambarus@linaro.org, klimov.linux@gmail.com Subject: Re: [PATCH REVIEW] hwrng: add exynos Secure World RNG device driver Date: Thu, 28 Mar 2024 14:36:40 +0100 [thread overview] Message-ID: <6b691a48-ca97-4f23-a09f-69b9254f0c11@linaro.org> (raw) In-Reply-To: <20240328125056.1054878-1-alexey.klimov@linaro.org> On 28/03/2024 13:50, Alexey Klimov wrote: > The Exynos TRNG device is controlled by firmware and shared between No, it is not. I have TRNG perfectly usable on my board. Maybe you are refer to some specific SoC... Please always Cc existing TRNG driver maintainer. > non-secure world and secure world. Access to it is exposed via SMC > interface which is implemented here. The firmware code does > additional security checks, start-up test and some checks on resume. > > This device is found, for instance, in Google Tensor GS101-family > of devices. Nothing here explains why this cannot be integrated into existing driver. Maybe it, maybe it cannot... You try to upstream again vendor driver ignoring that community already did it and instead it might be enough to customize it. Guys, the same as all the MCT, PHYs and PCI in previous works of various people: stop duplicating drivers by upstreaming new vendor stuff with all the issues we already fixed and please work on re-using existing drivers. Sometimes work cannot be combined, so come with arguments. Otherwise we keep repeating and repeating the same feedback. > > Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> > --- > drivers/char/hw_random/Kconfig | 12 + > drivers/char/hw_random/Makefile | 1 + > drivers/char/hw_random/exynos-swd-trng.c | 423 +++++++++++++++++++++++ > 3 files changed, 436 insertions(+) > create mode 100644 drivers/char/hw_random/exynos-swd-trng.c > > diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig > index 442c40efb200..bff7c3ec129a 100644 > --- a/drivers/char/hw_random/Kconfig > +++ b/drivers/char/hw_random/Kconfig > @@ -479,6 +479,18 @@ config HW_RANDOM_EXYNOS > > If unsure, say Y. > > +config HW_RANDOM_EXYNOS_SWD > + tristate "Exynos SWD HW random number generator support" What is SWD? > + default n > + help > + This driver provides kernel-side support for accessing Samsung > + TRNG hardware located in secure world using smc calls. > + > + To compile this driver as a module, choose M here: the > + module will be called exynos-swd-trng. > + > + If unsure, say N. > + ... > + > +static UNIVERSAL_DEV_PM_OPS(exyswd_rng_pm_ops, exyswd_rng_suspend, > + exyswd_rng_resume, NULL); > + > +static struct platform_driver exyswd_rng_driver = { > + .probe = exyswd_rng_probe, > + .remove = exyswd_rng_remove, > + .driver = { > + .name = DRVNAME, > + .owner = THIS_MODULE, So this was fixed ~8-10 years ago. Yet it re-appears. Please do not use downstream code as template. Take upstream driver and either change it or customize it. > + .pm = &exyswd_rng_pm_ops, > + }, > +}; > + > +static struct platform_device *exyswd_rng_pdev; And if I have multiple devices? > + > +static int __init exyswd_rng_init(void) > +{ > + int ret; > + > + exyswd_rng_pdev = platform_device_register_simple(DRVNAME, -1, NULL, 0); > + if (IS_ERR(exyswd_rng_pdev)) > + pr_err(DRVNAME ": could not register device: %ld\n", > + PTR_ERR(exyswd_rng_pdev)); This is some oddity... Why do you create devices based on module load? So I load this on Qualcomm anbd you create exynos device? This does not make sense. > + > + ret = platform_driver_register(&exyswd_rng_driver); > + if (ret) { > + platform_device_unregister(exyswd_rng_pdev); > + return ret; > + } > + > + pr_info("ExyRNG driver, (c) 2014 Samsung Electronics\n"); Drop, dirvers should not print code just because I load a driver. Again: imagine I load it on Qualcomm. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-28 13:36 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-28 12:50 [PATCH REVIEW] hwrng: add exynos Secure World RNG device driver Alexey Klimov 2024-03-28 12:50 ` Alexey Klimov 2024-03-28 13:36 ` Krzysztof Kozlowski [this message] 2024-03-28 13:36 ` Krzysztof Kozlowski 2024-03-28 17:01 ` Krzysztof Kozlowski 2024-03-28 17:01 ` Krzysztof Kozlowski 2024-03-28 17:05 ` Krzysztof Kozlowski 2024-03-28 17:05 ` Krzysztof Kozlowski 2024-03-29 7:55 ` Gowthami Thiagarajan 2024-03-29 7:55 ` Gowthami Thiagarajan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=6b691a48-ca97-4f23-a09f-69b9254f0c11@linaro.org \ --to=krzysztof.kozlowski@linaro.org \ --cc=alexey.klimov@linaro.org \ --cc=alim.akhtar@samsung.com \ --cc=andre.draszik@linaro.org \ --cc=elder@linaro.org \ --cc=herbert@gondor.apana.org.au \ --cc=kernel-team@android.com \ --cc=klimov.linux@gmail.com \ --cc=l.stelmach@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=olivia@selenic.com \ --cc=peter.griffin@linaro.org \ --cc=saravanak@google.com \ --cc=sehi.kim@samsung.com \ --cc=tudor.ambarus@linaro.org \ --cc=willmcvicker@google.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.