lkml.org 
[lkml]   [2019]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PSCI version 1.1 and SYSTEM_RESET2
On 2019-05-02 02:05, Sudeep Holla wrote:
> On Wed, May 01, 2019 at 11:43:00AM -0700, Sodagudi Prasad wrote:
>> On 2019-05-01 02:49, Sudeep Holla wrote:
>> > On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote:
>> > > On 2019-04-30 14:44, Sodagudi Prasad wrote:
>
> [...]
>
>> > >
>> > > It would nice if there is a config option to reboot the device
>> > > either in
>> > > warm or cold in the case of kernel panic.
>> >
>> > I presume you prefer to do warm boot in case of panic to get a dump of
>> > the memory to inspect ? If so, is kexec/kdump not the mechanism to
>> > achieve that ?
>>
>> Hi Sudeep,
>>
>> Thanks for your response and sharing details about your patch.
>>
>> > If so, is kexec/kdump not the mechanism to achieve that?
>> >
>> Qualcomm is having vendor specific solution to capture ram contents
>> and for
>> offline analysis.
>>
>
> Ah OK.
>
>> >
>> > I am just trying to understand the use case. Xilinx asked for the same
>> > but never got to understand their use case.
>>
>> Here is the background -
>> Usually, power off drivers are overriding arm_pm_restart and
>> pm_power_off
>> callbacks and registering with reboot notifier with some priority for
>> the
>> reboot operations. Here is the Qualcomm poweroff driver for
>> reference.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/power/reset/msm-poweroff.c
>>
>> Before vendor chip set specific power off driver is probed,
>> arm_pm_restart
>> functions pointer holds the psci_sys_reset function. Once vendor power
>> off
>> driver is probed, vendor drivers can override the arm_pm_restart
>> function
>> pointer.
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/psci.c#n562
>>
>> Once vendor driver is probed, drivers can take care of devices warm or
>> hard
>> reset configuration part properly. But there is a window from
>> start_kernel() to vendor specific driver probed, devices are getting
>> cold
>> resets even if kernel crashed. This is due to arm_pm_restart points
>> to
>> psci_sys_reset function by default. Is this problem clear now?
>>
>
> Too specific use case IMO and I am not sure if we need a generic
> solution
> to deal with this. Anyways, I don't see any check in arch/psci specific
> code for what you want, just ensure reboot_mode is set appropriately.
> Post a patch and see what people have to say.

Hi Sudeep,

Yes. With your system_reset2 command support addition, just configuring
the reboot_mode is good enough.

-Thanks, Prasad

>
>> Qualcomm downstream kernel has a lot of use cases with respect device
>> reset
>> sequence and the downstream driver is much different from upstream
>> drivers.
>> I think, the above-mentioned problem is common for all the chipset
>> vendors
>> and it is not specific Qualcomm use cases. I have one downstream
>> solution
>> to this problem but thought to bring up this problem to the upstream
>> community for a common solution, so that all the vendors can use it.
>>
>
> May be or may be not, post the patch and let's see.
>
>> I have modified below flow to avoid cold restart in the case of early
>> kernel
>> panic.
>> panic() --> emergency_restart() --> machine_emergency_restart() -->
>> machine_restart(NULL);
>>
>> -Thanks, Prasad
>>
>> >
>> > --
>> > Regards,
>> > Sudeep
>>
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> Forum,
>> Linux Foundation Collaborative Project

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
Linux Foundation Collaborative Project

\
 
 \ /
  Last update: 2019-05-09 03:38    [W:0.135 / U:1.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site