[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25f5f60e-46ff-18af-2a65-1e3f6719ef49@gmail.com>
Date: Mon, 13 May 2019 19:00:36 +0300
From: Oleksandr <olekstysh@...il.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Julien Grall <julien.grall@....com>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Simon Horman <horms@...ge.net.au>,
Magnus Damm <magnus.damm@...il.com>,
Russell King <linux@...linux.org.uk>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
Subject: Re: [RFC PATCH] ARM: mach-shmobile: Parse DT to get ARCH timer memory
region
On 13.05.19 18:13, Geert Uytterhoeven wrote:
> Hi Oleksandr,
Hi Geert
>> So, if the DT bindings for the counter module is not an option (if I
>> correctly understood a discussion pointed by Geert in another letter),
>> we should probably prevent all timer code here from being executed if
>> PSCI is in use.
>> What I mean is to return to [2], but with the modification to use
>> psci_smp_available() helper as an indicator of PSCI usage.
>>
>> Julien, Geert, what do you think?
> Yes, that sounds good to me.
>
> Note that psci_smp_available() seems to return false if CONFIG_SMP=n,
> so checking for that is not sufficient to avoid crashes when running a
> uniprocessor kernel on a PSCI-enabled system.
Indeed, you are right.
Nothing than just check for psci_ops.cpu_on == NULL directly comes to
mind...
Have already checked with CONFIG_SMP=n, it works.
Sounds ok?
--
Regards,
Oleksandr Tyshchenko
Powered by blists - more mailing lists