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
