mbox series

[v3,0/5] hwrng: add support for i.MX6 rngb

Message ID 20200714123920.23711-1-horia.geanta@nxp.com
Headers show
Series hwrng: add support for i.MX6 rngb | expand

Message

Horia Geantă July 14, 2020, 12:39 p.m. UTC
Add support for RNGB found in some i.MX6 SoCs (6SL, 6SLL, 6ULL, 6ULZ),
based on RNGC driver (drivers/char/hw_random/imx-rngc.c).

This driver claims support also for RNGB (besides RNGC),
and is currently used only by i.MX25.

Note:

Several NXP SoC from QorIQ family (P1010, P1023, P4080, P3041, P5020)
also have a RNGB, however it's part of the CAAM
(Cryptograhic Accelerator and Assurance Module) crypto accelerator.
In this case, RNGB is managed in the caam driver
(drivers/crypto/caam/), since it's tightly related to
the caam "job ring" interface, not to mention CAAM internally relying on
RNGB as source of randomness.

On the other hand, the i.MX6 SoCs with RNGB have a DCP
(Data Co-Processor) crypto accelerator and this block and RNGB
are independent.

Changelog:
v3
-mention in the DT binding the compatibility with "fsl,imx25-rngb"
-collected Reviewed-by
v2
-update rngb DT binding with compatible strings for i.MX6 SoCs

Horia Geantă (5):
  dt-bindings: rng: add RNGB compatibles for i.MX6 SoCs
  ARM: dts: imx6sl: fix rng node
  ARM: dts: imx6sll: add rng
  ARM: dts: imx6ull: add rng
  hwrng: imx-rngc: enable driver for i.MX6

 Documentation/devicetree/bindings/rng/imx-rng.txt | 3 +++
 arch/arm/boot/dts/imx6sl.dtsi                     | 2 ++
 arch/arm/boot/dts/imx6sll.dtsi                    | 7 +++++++
 arch/arm/boot/dts/imx6ull.dtsi                    | 7 +++++++
 drivers/char/hw_random/Kconfig                    | 2 +-
 drivers/char/hw_random/imx-rngc.c                 | 3 +++
 6 files changed, 23 insertions(+), 1 deletion(-)

Comments

Arnd Bergmann July 14, 2020, 12:47 p.m. UTC | #1
On Tue, Jul 14, 2020 at 2:39 PM Horia Geantă <horia.geanta@nxp.com> wrote:
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 8478eb757f3c..98f95a09ce55 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -255,7 +255,7 @@ config HW_RANDOM_MXC_RNGA
>  config HW_RANDOM_IMX_RNGC
>         tristate "Freescale i.MX RNGC Random Number Generator"
>         depends on HAS_IOMEM && HAVE_CLK
> -       depends on SOC_IMX25 || COMPILE_TEST
> +       depends on SOC_IMX25 || SOC_IMX6SL || SOC_IMX6SLL || SOC_IMX6UL || COMPILE_TEST
>         default HW_RANDOM

Are these the only chips that have it? If other i.MX variations have
the same block,
or might have it in the future, maybe just generialize the dependency
to SOC_IMX6
or ARCH_IMX?

> diff --git a/drivers/char/hw_random/imx-rngc.c b/drivers/char/hw_random/imx-rngc.c
> index 9c47e431ce90..84576d2fbf8c 100644
> --- a/drivers/char/hw_random/imx-rngc.c
> +++ b/drivers/char/hw_random/imx-rngc.c
> @@ -350,6 +350,9 @@ static SIMPLE_DEV_PM_OPS(imx_rngc_pm_ops, imx_rngc_suspend, imx_rngc_resume);
>
>  static const struct of_device_id imx_rngc_dt_ids[] = {
>         { .compatible = "fsl,imx25-rngb", .data = NULL, },
> +       { .compatible = "fsl,imx6sl-rngb", .data = NULL, },
> +       { .compatible = "fsl,imx6sll-rngb", .data = NULL, },
> +       { .compatible = "fsl,imx6ull-rngb", .data = NULL, },
>         { /* sentinel */ }

In the .dts file you describe the devices as compatible with fsl,imx25-rngb,
so this change is not really needed, unless you want to add non-NULL
.data fields in a follow-up. It is usually a good idea to have the more
specialized compatible strings in the DT, but the driver change won't
do anything here.

       Arnd
Fabio Estevam July 14, 2020, 12:48 p.m. UTC | #2
On Tue, Jul 14, 2020 at 9:39 AM Horia Geantă <horia.geanta@nxp.com> wrote:

>  static const struct of_device_id imx_rngc_dt_ids[] = {
>         { .compatible = "fsl,imx25-rngb", .data = NULL, },
> +       { .compatible = "fsl,imx6sl-rngb", .data = NULL, },
> +       { .compatible = "fsl,imx6sll-rngb", .data = NULL, },
> +       { .compatible = "fsl,imx6ull-rngb", .data = NULL, },

It seems that these new entries are not needed, since they fallback to
"fsl,imx25-rngb".
Horia Geantă July 14, 2020, 2:27 p.m. UTC | #3
On 7/14/2020 3:48 PM, Arnd Bergmann wrote:
> On Tue, Jul 14, 2020 at 2:39 PM Horia Geantă <horia.geanta@nxp.com> wrote:
>> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
>> index 8478eb757f3c..98f95a09ce55 100644
>> --- a/drivers/char/hw_random/Kconfig
>> +++ b/drivers/char/hw_random/Kconfig
>> @@ -255,7 +255,7 @@ config HW_RANDOM_MXC_RNGA
>>  config HW_RANDOM_IMX_RNGC
>>         tristate "Freescale i.MX RNGC Random Number Generator"
>>         depends on HAS_IOMEM && HAVE_CLK
>> -       depends on SOC_IMX25 || COMPILE_TEST
>> +       depends on SOC_IMX25 || SOC_IMX6SL || SOC_IMX6SLL || SOC_IMX6UL || COMPILE_TEST
>>         default HW_RANDOM
> 
> Are these the only chips that have it? If other i.MX variations have
> the same block,
> or might have it in the future, maybe just generialize the dependency
> to SOC_IMX6
> or ARCH_IMX?
> 
Fabio also suggested this during v1, see discussion here:
https://lore.kernel.org/linux-crypto/292aafd1-7249-5b76-ccc3-77b153594ef9@nxp.com

The SoC list is relatively stable, to the best of my knowledge.

>> diff --git a/drivers/char/hw_random/imx-rngc.c b/drivers/char/hw_random/imx-rngc.c
>> index 9c47e431ce90..84576d2fbf8c 100644
>> --- a/drivers/char/hw_random/imx-rngc.c
>> +++ b/drivers/char/hw_random/imx-rngc.c
>> @@ -350,6 +350,9 @@ static SIMPLE_DEV_PM_OPS(imx_rngc_pm_ops, imx_rngc_suspend, imx_rngc_resume);
>>
>>  static const struct of_device_id imx_rngc_dt_ids[] = {
>>         { .compatible = "fsl,imx25-rngb", .data = NULL, },
>> +       { .compatible = "fsl,imx6sl-rngb", .data = NULL, },
>> +       { .compatible = "fsl,imx6sll-rngb", .data = NULL, },
>> +       { .compatible = "fsl,imx6ull-rngb", .data = NULL, },
>>         { /* sentinel */ }
> 
> In the .dts file you describe the devices as compatible with fsl,imx25-rngb,
> so this change is not really needed, unless you want to add non-NULL
> .data fields in a follow-up. It is usually a good idea to have the more
> specialized compatible strings in the DT, but the driver change won't
> do anything here.
> 
Indeed, this isn't needed.
Will remove it in v4.

Thanks,
Horia