From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 238C2C3DA49 for ; Tue, 30 Jul 2024 10:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=z3e/RFQ+CrlBcAyJ/d2R2nwv2HjdcFruh075qSGwsr4=; b=CWRz5oeANkn+RaNDOcJsxsDn9f FkRzPpJquiH7fctUJt9K0pYGPQvR0tsnfwHIl0Im4ukb73pODyHhxoeDDc0C3RgyoVXs0H2o7KJHR KeNq+BMUM4SLaGnrc/VlEAw441KKsOIQc5nwtUQUtdkuSXdJyYAM/Y3cpEvCTru1DaJbP8LVacyBL rg2yrdjaInz7YH2hdk7puyKVWDVzyPzH51kRFKuM69TceOIWxAxrn2A5sHDMSHMA27B2M+pMz2cfO 2TLKT0WnId6fnV87GTgRUBZPcN254HGGsaYDDehyNgksvxHOIpygn5nkKarOuouRkNQ+t0AQ58GML 9HgXvFlw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYkF2-0000000El6E-1eHw; Tue, 30 Jul 2024 10:38:04 +0000 Received: from gloria.sntech.de ([185.11.138.130]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sYkE5-0000000EknE-097L; Tue, 30 Jul 2024 10:37:06 +0000 Received: from i5e86192c.versanet.de ([94.134.25.44] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sYkDk-0007C3-Qa; Tue, 30 Jul 2024 12:36:44 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Dragan Simic , Daniel Golle , Diederik de Haas Cc: Chen-Yu Tsai , linux-rockchip@lists.infradead.org, linux-arm-kernel@lists.infradead.org, Rob Herring , Conor Dooley , linux-kernel@vger.kernel.org, Herbert Xu , Martin Kaiser , Sascha Hauer , Sebastian Reichel , Ard Biesheuvel , Uwe =?ISO-8859-1?Q?Kleine=2DK=F6nig?= , devicetree@vger.kernel.org, linux-crypto@vger.kernel.org, Philipp Zabel , Olivia Mackall , Krzysztof Kozlowski , Aurelien Jarno Subject: Re: [PATCH v7 0/3] hwrng: add hwrng support for Rockchip RK3568 Date: Tue, 30 Jul 2024 12:36:43 +0200 Message-ID: <17577153.5WZRyvrzyv@diego> In-Reply-To: <6690040.iosknibmi9@bagend> References: <6690040.iosknibmi9@bagend> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240730_033705_111703_0DDE8881 X-CRM114-Status: GOOD ( 29.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am Dienstag, 30. Juli 2024, 11:03:06 CEST schrieb Diederik de Haas: > On Tuesday, 30 July 2024 01:18:37 CEST Daniel Golle wrote: > > On Wed, Jul 24, 2024 at 08:07:51AM +0200, Dragan Simic wrote: > > > Thanks a lot for the testing. Though, such wildly different test results > > > can, regrettably, lead to only one conclusion: the HWRNG found in RK3566 > > > is unusable. :/ > > FTR: I agree with Dragan, unfortunately. > > > The results on RK3568 look much better and the series right now also > > only enabled the RNG on RK3568 systems. However, we have only seen few > > boards with RK3568 up to now, and I only got a couple of NanoPi R5C > > here to test, all with good hwrng results. > > > > Do you think it would be agreeable to only enable the HWRNG for RK3568 > > as suggested in this series? Or are we expecting quality to also vary > > as much as it (sadly) does for RK3566? > > Unless we get *evidence* to the contrary, we should assume that the HWRNG on > RK3568 is fine as the currently available test results are fine. > So I think enabling it only for RK3568 is the right thing to do. > > So a 'revert' to v7 variant seems appropriate, but with the following changes: > - Add `status = "disabled";` property to the definition in rk356x.dtsi > - Add a new commit where you enable it only for rk3568 and document in the > commit message why it's not enabled on rk3566 with a possible link to the v7 > thread for clarification on why that is I was going to protest about the "disable" until reading the 2nd part :-D . And yeah that makes a lot of sense, "add" it to rk356x.dtsi, as the IP is part of both variants, but only enable it in rk3568.dtsi because of the seemingly faulty implementation on the rk3566. > You could probably also integrate that into 1 commit, but make sure that the > commit summary and description match the implementation. > IMO that wasn't 'technically' the case in v8 as the rng node was added to > rk356x, but it was only enabled on rk3568. > > My 0.02