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: Wed, 15 May 2024 11:16:45 +0200 [thread overview]
Message-ID: <51951dd4-8e8c-4e67-89f6-6a710022e34f@foss.st.com> (raw)
In-Reply-To: <cc6f98eb-f6b2-4a34-a8ed-c0f759fa4c79@denx.de>
Hi Marek,
On 5/14/24 16:37, Marek Vasut wrote:
> On 5/14/24 10:10 AM, Gatien CHEVALLIER wrote:
>> Hi Marek,
>
> Hi,
>
>> Strange indeed.
>
> Yes.
>
>> A potential reason that comes to my mind would be that something tries
>> to get a random number after the driver suspended and fails to do so.
>
> Possibly.
>
>> Else it might just be a bad clock balance.
>
> I don't think so, this would be reported by the kernel and it would show
> up in /sys/kernel/debug/clk/clk_summary as incrementing use count. It
> would also not happen in a non-deterministic manner like this happens
> here, the hang doesn't always happen after well defined suspend/resume
> cycle count.
>
>> Can you describe the software ecosystem that you're running please?
>> (SCMI/no SCMI)?
>
> STM32MP157C DHCOM PDK2 with mainline U-Boot 2024.07-rc2 , no SCMI.
>
>> Do you have the 3 fixes of stm32_rng.c that you've sent recently in your
>> software when testing?
>
> Yes, but this happens even without them.
>
>> What if you add a trace in a random generation function in random.c?
>
> Do you have a function name or line number for me ?
I put a trace in _get_random_bytes() in drivers/char/random.c. I'm not
100% sure but this should be the entry point when getting a random number.
>
>> After this, I'll try to reproduce the issue.
>
> If you have a minute to test it on some ST MP15 board, that would be
> real nice. Thanks !
I tried to reproduce the issue you're facing on a STM32MP157C-DK2 no
SCMI on the 6.9-rc7 kernel tag. I uses OP-TEE and TF-A in the bootchain
but this should not have an impact here.
How did you manage to test using "echo core > /sys/power/pm_test"?
In kernel/power/suspend.c, enter_state(). If the pm_test_level is core,
then an error is fired with the following trace:
"Unsupported test mode for suspend to idle, please choose
none/freezer/devices/platform."
I've tried using "echo devices > /sys/power/pm_test" so that I can at
least test that the driver is put to sleep then wakes up. I do not
reproduce your issue.
[ 169.026421] Filesystems sync: 0.013 seconds
[ 169.031087] Freezing user space processes
[ 169.036562] Freezing user space processes completed (elapsed 0.002
seconds)
[ 169.042238] OOM killer disabled.
[ 169.045383] Freezing remaining freezable tasks
[ 169.051408] Freezing remaining freezable tasks completed (elapsed
0.001 seconds)
[ 169.238226] dwc2 49000000.usb-otg: suspending usb gadget
configfs-gadget.g1
[ 169.270236] In stm32_rng_suspend
[ 169.275501] PM: suspend debug: Waiting for 5 second(s).
[ 174.283418] In stm32_rng_resume
[ 174.284291] stm32-dwmac 5800a000.ethernet end0: configuring for
phy/rgmii-id link mode
[ 174.337714] dwmac4: Master AXI performs any burst length
[ 174.341699] stm32-dwmac 5800a000.ethernet end0: No Safety Features
support found
[ 174.349138] stm32-dwmac 5800a000.ethernet end0: IEEE 1588-2008
Advanced Timestamp supported
[ 174.363442] dwc2 49000000.usb-otg: resuming usb gadget configfs-gadget.g1
[ 174.667669] onboard-usb-hub 2-1: reset high-speed USB device number 2
using ehci-platform
[ 174.989075] OOM killer enabled.
[ 174.990848] Restarting tasks ... done.
[ 175.003976] random: crng reseeded on system resumption
[ 175.009464] PM: suspend exit
[ 175.011473] random: ASKING FOR 96 BYTES
[ 175.011468] random: ASKING FOR 96 BYTES
[ 175.015747] random: ASKING FOR 16 BYTES
[ 175.044933] random: ASKING FOR 96 BYTES
[ 175.059399] random: ASKING FOR 96 BYTES
[ 175.070925] random: ASKING FOR 16 BYTES
[ 175.079285] random: ASKING FOR 96 BYTES
[ 175.082113] random: ASKING FOR 16 BYTES
[ 175.096759] random: ASKING FOR 16 BYTES
[ 175.098674] random: ASKING FOR 96 BYTES
[ 175.295584] random: ASKING FOR 16 BYTES
[ 175.302357] random: ASKING FOR 96 BYTES
[ 175.311525] random: ASKING FOR 16 BYTES
[ 175.312989] random: ASKING FOR 16 BYTES
Can you give it another shot with the trace so that we can ensure that
no random is asked after the driver is suspended in your case please?
Thanks,
Gatien
next prev parent reply other threads:[~2024-05-15 9:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 22:02 [PATCH] [RFC] clk: stm32mp1: Keep RNG1 clock always running Marek Vasut
2024-05-14 8:10 ` Gatien CHEVALLIER
2024-05-14 14:37 ` Marek Vasut
2024-05-15 9:16 ` Gatien CHEVALLIER [this message]
2024-05-16 1:06 ` Marek Vasut
2024-05-16 7:42 ` Gatien CHEVALLIER
2024-05-16 10:43 ` Marek Vasut
2024-05-16 14:35 ` Gatien CHEVALLIER
2024-05-16 20:01 ` Marek Vasut
2024-05-17 15:39 ` Gatien CHEVALLIER
2024-05-21 10:27 ` Marek Vasut
2024-05-28 13:55 ` Gatien CHEVALLIER
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51951dd4-8e8c-4e67-89f6-6a710022e34f@foss.st.com \
--to=gatien.chevallier@foss.st.com \
--cc=alexandre.torgue@foss.st.com \
--cc=gabriel.fernandez@foss.st.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=marex@denx.de \
--cc=mcoquelin.stm32@gmail.com \
--cc=mturquette@baylibre.com \
--cc=olivia@selenic.com \
--cc=robh@kernel.org \
--cc=sboyd@kernel.org \
--cc=u.kleine-koenig@pengutronix.de \
--cc=yangyingliang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).