[PATCH] [RFC] clk: stm32mp1: Keep RNG1 clock always running
Gatien CHEVALLIER
gatien.chevallier at foss.st.com
Thu May 16 00:42:51 PDT 2024
Hi Marek
On 5/16/24 03:06, Marek Vasut wrote:
> On 5/15/24 11:16 AM, Gatien CHEVALLIER wrote:
>
> Hi,
>
>>>> 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.
>
> You're right, there is a read attempt right before the hang, and
> __clk_is_enabled() returns 0 in stm32_read_rng() . In fact, it is the
> pm_runtime_get_sync() which is returning -EACCES instead of zero, and
> this is currently not checked so the failure is not detected before
> register access takes place, to register file with clock disabled, which
> triggers a hard hang.
>
> I'll be sending a patch shortly, thanks for this hint !
>
Great news, indeed the return code isn't checked. Let's use
pm_runtime_resume_and_get().
>>>> 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."
>
> Could this be firmware related ?
>
>> 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.
>
> Can you try 'processors' ?
>
Given this:
#ifdef CONFIG_PM_DEBUG
if (pm_test_level != TEST_NONE && pm_test_level <= TEST_CPUS) {
pr_warn("Unsupported test mode for suspend to idle, please choose
none/freezer/devices/platform.\n");
return -EAGAIN;
}
#endif
and this
static const char * const pm_tests[__TEST_AFTER_LAST] = {
[TEST_NONE] = "none",
[TEST_CORE] = "core",
[TEST_CPUS] = "processors",
[TEST_PLATFORM] = "platform",
[TEST_DEVICES] = "devices",
[TEST_FREEZER] = "freezer",
};
I'm getting the error as well.
> I did also notice it sometimes takes much longer than a minute to hang,
> but eventually it does hang. Maybe let it cycle for an hour or a few ?
>
I'll let it loop for some time then for device pm state.
> [...]
>
Thanks for investigating this.
Cheers,
Gatien
More information about the linux-arm-kernel
mailing list