Re: PSCI version 1.1 and SYSTEM_RESET2

From: Sodagudi Prasad
Date: Wed May 01 2019 - 14:43:19 EST

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:

> Hi Mark/Will,
> I would like to understand whether ARM linux community have plans to
> support PSCI version 1.1 or not.
> PSCI_1_1 specification introduced support for SYSTEM_RESET2 command
> and this new command helps mobile devices to SYSTEM_WARM_RESET
> support. Rebooting devices with warm reboot helps to capture the
> snapshot of the ram contents for post-mortem analysis.

I think, there is a recent discussion from Sudeep for the SYSTEM_RESET2

This has landed in -next, and hopefully must appear in v5.2

Hi Sudeep,

I was going through your discussion in the below list -

There is no provision to set up reboot mode dynamically instead kernel
command line parameter.
Looking for options to reboot device with warm reboot option when kernel

panic() --> emergency_restart() --> machine_emergency_restart() -->

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.
<Sudeep> 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.

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.

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.

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?

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.

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


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