Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220416135412.4109213-1-festevam@gmail.com>
In-Reply-To: <20220416135412.4109213-1-festevam@gmail.com>
From:   Fabio Estevam <festevam@gmail.com>
Date:   Sat, 16 Apr 2022 11:33:53 -0300
Message-ID: <CAOMZO5B3ENSkK0aL+n=cm73--60mVukNtej=LOdx-Xa8XDkV4g@mail.gmail.com>
Subject: Re: [PATCH v2] crypto: caam - fix i.MX6SX entropy delay value
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Horia Geanta Neag <horia.geanta@nxp.com>,
        Gaurav Jain <gaurav.jain@nxp.com>,
        Varun Sethi <V.Sethi@nxp.com>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>, Fabio Estevam <festevam@denx.de>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Horia and Varun,

On Sat, Apr 16, 2022 at 10:54 AM Fabio Estevam <festevam@gmail.com> wrote:
>
> From: Fabio Estevam <festevam@denx.de>
>
> Since commit 358ba762d9f1 ("crypto: caam - enable prediction resistance
> in HRWNG") the following CAAM errors can be seen on i.MX6SX:
>
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> hwrng: no data available
> caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error
> ...
>
> This error is due to an incorrect entropy delay for i.MX6SX.
>
> Fix it by increasing the minimum entropy delay for i.MX6SX
> as done in U-Boot:
> https://patchwork.ozlabs.org/project/uboot/patch/20220415111049.2565744-1-gaurav.jain@nxp.com/
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> ---
> Change since v1:
> - Align the fix with U-Boot.

Actually, after thinking more about it, I realize that this issue is
not i.MX6SX specific as
I have seen reports of the same failures on i.MX6D as well.

Would it make sense to fix it like this instead?

--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -516,7 +516,7 @@ struct rng4tst {
        };
 #define RTSDCTL_ENT_DLY_SHIFT 16
 #define RTSDCTL_ENT_DLY_MASK (0xffff << RTSDCTL_ENT_DLY_SHIFT)
-#define RTSDCTL_ENT_DLY_MIN 3200
+#define RTSDCTL_ENT_DLY_MIN 12000
 #define RTSDCTL_ENT_DLY_MAX 12800
        u32 rtsdctl;            /* seed control register */
        union {

Any drawbacks in using this generic approach?

Please advise.