[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200529171231.GA2581035@bogus>
Date: Fri, 29 May 2020 11:12:31 -0600
From: Rob Herring <robh@...nel.org>
To: Arnd Bergmann <arnd@...db.de>
Cc: Olivier Sobrie <olivier.sobrie@...exinsight.com>,
Matt Mackall <mpm@...enic.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
<linux-crypto@...r.kernel.org>, DTML <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Waleed Ziad <waleed94ziad@...il.com>,
sebastien.rabou@...exinsight.com
Subject: Re: [PATCH 3/3] hwrng: ba431-rng: add support for BA431 hwrng
On Mon, May 25, 2020 at 10:28:46PM +0200, Arnd Bergmann wrote:
> On Mon, May 25, 2020 at 10:07 PM Olivier Sobrie
> <olivier.sobrie@...exinsight.com> wrote:
> >
> > Silex insight BA431 is an IP designed to generate random numbers that
> > can be integrated in various FPGA.
> > This driver adds support for it through the hwrng interface.
> >
> > This driver is used in Silex Insight Viper OEM boards.
> >
> > Signed-off-by: Olivier Sobrie <olivier.sobrie@...exinsight.com>
> > Signed-off-by: Waleed Ziad <waleed94ziad@...il.com>
>
> The driver looks good to me.
>
> Acked-by: Arnd Bergmann <arnd@...db.de>
>
> > drivers/char/hw_random/Kconfig | 10 ++
> > drivers/char/hw_random/Makefile | 1 +
> > drivers/char/hw_random/ba431-rng.c | 240 +++++++++++++++++++++++++++++
>
> I wonder if we should move drivers/char/hw_random to its own top-level drivers
> subsystem outside of drivers/char. It seems to be growing steadily and is larger
> than a lot of other subsystems with currently 34 drivers in there.
>
> Not your problem though.
>
> > + /* Wait until the state changed */
> > + for (i = 0; i < BA431_RESET_READ_STATUS_RETRIES; ++i) {
> > + state = ba431_trng_get_state(ba431);
> > + if (state >= BA431_STATE_STARTUP)
> > + break;
> > +
> > + udelay(BA431_RESET_READ_STATUS_INTERVAL);
> > + }
>
> Looking for something to improve, I noticed that this loop can take over
> a millisecond to time out, and it always runs in non-atomic context.
> It may be better to use usleep_range() than udelay().
Or better yet, use the register polling helpers.
Rob
Powered by blists - more mailing lists