linux-kernel - Re: [PATCH] hw_random: rockchip: import driver from vendor tree

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YzNthZ0MtfwjIqdH@aurel32.net>
Date:   Tue, 27 Sep 2022 23:39:17 +0200
From:   Aurelien Jarno <aurelien@...el32.net>
To:     LABBE Corentin <clabbe@...libre.com>
Cc:     Robin Murphy <robin.murphy@....com>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Lin Jinhan <troy.lin@...k-chips.com>, wevsty <ty@...s.org>,
        Mikhail Rudenko <mike.rudenko@...il.com>,
        Heiko Stuebner <heiko@...ech.de>,
        Lin Huang <hl@...k-chips.com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        linux-rockchip@...ts.infradead.org
Subject: Re: [PATCH] hw_random: rockchip: import driver from vendor tree

On 2022-09-27 21:46, LABBE Corentin wrote:
> Le Tue, Sep 27, 2022 at 06:37:53PM +0200, Aurelien Jarno a écrit :
> > On 2022-09-20 10:35, Robin Murphy wrote:
> > > On 2022-09-19 22:00, Jason A. Donenfeld wrote:
> > > > The Rockchip driver has long existed out of tree, but not upstream.
> > > > There is support for it upstream in u-boot, but not in Linux proper.
> > > > This commit imports the GPLv2 driver written by Lin Jinhan, together
> > > > with the DTS and config blobs from Wevsty.
> > > 
> > > Note that Corentin has a series enabling the full crypto driver for 
> > > RK3328 and RK3399[1], so it would seem more sensible to add TRNG support 
> > > to that. Having confliciting compatibles for the same hardware that 
> > > force the user to change their DT to choose one functionality or the 
> > > other isn't good (plus there's also no binding for this one).
> > 
> > It might make sense for the cryptov1-rng driver (I haven't checked). For
> > the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
> > RK3588 one), and from what I understand crypto and TRNG are two
> > different devices, using different address spaces, clock, reset and
> > interrupts. The vendor kernel uses two different drivers.
> > 
> 
> I confirm that TRNG is not on the same IP on rk3568, something I didnt remark when doing my V2 driver. (I need to remove rng clock from rk3568 dt).
> But the rk3588 crypto IP and the TRNG are in the same device.

Ok, thanks for confirming about the rk3568. It seems the only one in the
family with separate devices for TRNG and crypto. Does it means we need
a separate TRNG driver only for it? Or could we handle it the same way
than for instance rk3588 anyway?

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@...el32.net                 http://www.aurel32.net