Re: [PATCH] [RFC] clk: stm32mp1: Keep RNG1 clock always running

From: Gatien CHEVALLIER <gatien.chevallier@foss.st.com>
To: Marek Vasut <marex@denx.de>, <linux-crypto@vger.kernel.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Gabriel Fernandez" <gabriel.fernandez@foss.st.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Olivia Mackall" <olivia@selenic.com>,
	"Rob Herring" <robh@kernel.org>,
	"Stephen Boyd" <sboyd@kernel.org>,
	"Yang Yingliang" <yangyingliang@huawei.com>,
	linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
	linux-stm32@st-md-mailman.stormreply.com
Subject: Re: [PATCH] [RFC] clk: stm32mp1: Keep RNG1 clock always running
Date: Tue, 28 May 2024 15:55:20 +0200	[thread overview]
Message-ID: <47ed8f22-fc8c-4fb4-89c5-7d8ef7e8e728@foss.st.com> (raw)
In-Reply-To: <0a37659a-1c5e-4bff-ab8e-9c777c0520d5@denx.de>

On 5/21/24 12:27, Marek Vasut wrote:
> On 5/17/24 5:39 PM, Gatien CHEVALLIER wrote:
> 
> Hi,
> 
>>> Possibly. I use script as init which contains basically #!/bin/sh , 
>>> mount of a few filesystems like dev, proc, sys, and then the pm_test 
>>> sequence to avoid wasting time booting full userspace.
>>>
>> Ok,
>>
>> The strangest thing is not being to enable the clock, maybe there's
>> something on the clock driver side. Tracking clock enable/disable
>> may lead to something.
> 
> I suspect the problem is that rng_read and runtime suspend/resume can 
> run in parallel, that's why this problem occurs.
> 

Hum, this looks strange... This would need to be confirmed in your
use case. That would mean that flags aren't synced at the entry of these
functions?

>>>> FYI, I have been running your script with (echo devices > 
>>>> /sys/power/pm_test) for 5 hours now and haven't been able to 
>>>> reproduce the issue.
>>>
>>> Maybe the 'devices' test is not enough and the deeper pm_test states 
>>> have some sort of impact ?
>>>
>>
>> Maybe, I don't have the knowledge to confirm or invalidate this.
>> Tasks should be frozen before drivers are put to sleep so my instinct
>> would say no but you can't take it for granted :)
> 
> Could it be the kernel that requires randomness ?

That can be confirmed by adding traces to the entry point in random.c.
Maybe activating CONFIG_WARN_ALL_UNSEEDED_RANDOM will help investigate
this. It will add verbosity if crng isn't ready.

Or maybe try calling directely rng_is_initialized() to see if the crng
is ready when your issue occurs.

Best regards,
Gatien

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel