linux-kernel - Re: [PATCH v8 3/3] arm64: dts: rockchip: add DT entry for RNG to RK356x

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHmME9pAgDV_kQZXTDG0LiX7W6+SBL3+fNsF6B-RyTMXRMxBnw@mail.gmail.com>
Date: Sun, 21 Jul 2024 15:51:00 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: Daniel Golle <daniel@...rotopia.org>
Cc: Aurelien Jarno <aurelien@...el32.net>, Olivia Mackall <olivia@...enic.com>, 
	Herbert Xu <herbert@...dor.apana.org.au>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Heiko Stuebner <heiko@...ech.de>, Philipp Zabel <p.zabel@...gutronix.de>, 
	Dragan Simic <dsimic@...jaro.org>, Uwe Kleine-König <ukleinek@...ian.org>, 
	Sascha Hauer <s.hauer@...gutronix.de>, 
	Cristian Ciocaltea <cristian.ciocaltea@...labora.com>, Martin Kaiser <martin@...ser.cx>, 
	Francesco Dolcini <francesco.dolcini@...adex.com>, Ard Biesheuvel <ardb@...nel.org>, 
	linux-crypto@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 3/3] arm64: dts: rockchip: add DT entry for RNG to RK356x

On Sun, Jul 21, 2024 at 3:49 PM Daniel Golle <daniel@...rotopia.org> wrote:
>
> On Sun, Jul 21, 2024 at 02:07:23PM +0200, Jason A. Donenfeld wrote:
> > On Sun, Jul 21, 2024 at 01:48:38AM +0100, Daniel Golle wrote:
> > > From: Aurelien Jarno <aurelien@...el32.net>
> > >
> > > Enable the just added Rockchip RNG driver for RK356x SoCs.
> > >
> > > Signed-off-by: Aurelien Jarno <aurelien@...el32.net>
> > > Signed-off-by: Daniel Golle <daniel@...rotopia.org>
> > > ---
> > >  arch/arm64/boot/dts/rockchip/rk3568.dtsi |  7 +++++++
> > >  arch/arm64/boot/dts/rockchip/rk356x.dtsi | 10 ++++++++++
> > >  2 files changed, 17 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3568.dtsi b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > > index f1be76a54ceb..b9c6b2dc87fa 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3568.dtsi
> > > @@ -257,6 +257,13 @@ power-domain@...568_PD_PIPE {
> > >     };
> > >  };
> > >
> > > +&rng {
> > > +   rockchip,sample-count = <1000>;
> > > +   quality = <900>;
> >
> > As I already wrote you for v7, quality is out of 1024, not 1000, so this
> > won't hit 90% as you intend.
>
> It's not actually 90%. Around 125 out of 1000 test runs are failing on
> the R5C boards I got here, so that makes it 87.5% which is pretty close
> to the 87.9% of the 900/1024 figure there, hence I kept it 900 despite
> your comment.

Just do 922?

>
> >
> > But also, I think putting this in the DT is a mistake. Other drivers
> > don't generally do this, and if the hardware is actually the same piece
> > to piece (it is...), then there's not per-manufactured unit tweaking
> > needed. So keep this in the actual driver C like other drivers.
>
> So quality should be assigned using the DT compatible, right?
> And if needed we should have several of them, one for each SoC (if
> testing now turns out to show that the results are specific for the SoC
> rather than for the board).

No, do it in the C. If you don't have evidence of such crazy
complexity and diversity, don't overengineer for it. Nothing else does
this in the DT.