On 24/03/2020 17:59, Ionela Voinescu wrote:
> Hi guys,
>
> On Thursday 19 Mar 2020 at 08:47:46 (-0000), tip-bot2 for Saravana Kannan wrote:
>> The following commit has been merged into the timers/core branch of tip:
>>
>> Conommit-ID: 4f41fe386a94639cd9a1831298d4f85db5662f1e
>> Gitweb: https://git.kernel.org/tip/4f41fe386a94639cd9a1831298d4f85db5662f1e
>> Author: Saravana Kannan <saravanak@xxxxxxxxxx>
>> AuthorDate: Fri, 10 Jan 2020 21:21:25 -08:00
>> Committer: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>
>> CommitterDate: Tue, 17 Mar 2020 13:10:07 +01:00
>>
>> clocksource/drivers/timer-probe: Avoid creating dead devices
>>
>> Timer initialization is done during early boot way before the driver
>> core starts processing devices and drivers. Timers initialized during
>> this early boot period don't really need or use a struct device.
>>
>> However, for timers represented as device tree nodes, the struct devices
>> are still created and sit around unused and wasting memory. This change
>> avoid this by marking the device tree nodes as "populated" if the
>> corresponding timer is successfully initialized.
>>
>> Signed-off-by: Saravana Kannan <saravanak@xxxxxxxxxx>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx>
>> Link: https://lore.kernel.org/r/20200111052125.238212-1-saravanak@xxxxxxxxxx
>> ---
>> drivers/clocksource/timer-probe.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/clocksource/timer-probe.c b/drivers/clocksource/timer-probe.c
>> index ee9574d..a10f28d 100644
>> --- a/drivers/clocksource/timer-probe.c
>> +++ b/drivers/clocksource/timer-probe.c
>> @@ -27,8 +27,10 @@ void __init timer_probe(void)
>>
>> init_func_ret = match->data;
>>
>> + of_node_set_flag(np, OF_POPULATED);
>> ret = init_func_ret(np);
>> if (ret) {
>> + of_node_clear_flag(np, OF_POPULATED);
>> if (ret != -EPROBE_DEFER)
>> pr_err("Failed to initialize '%pOF': %d\n", np,
>> ret);
>>
>
> This patch is creating problems on some vexpress platforms - ones that
> are using CLKSRC_VERSATILE (drivers/clocksource/timer-versatile.c).
> I noticed issues on TC2 and FVPs (fixed virtual platforms) starting with
> next-20200318 and still reproducible with next-20200323.
I am also seeing a regression on tegra30-cardhu-a04 when testing system
suspend on -next. Bisect is pointing to this commit and reverting on top
of -next fixes the problem. Unfortunately, there is no crash dump
observed, but the device hangs somewhere when testing suspend.
I have not looked into this any further but wanted to report the problem.
Cheers
Jon
--
nvpublic
|