PSCI version 1.1 and SYSTEM_RESET2

PSCI version 1.1 and SYSTEM_RESET2

[Sodagudi Prasad]

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.

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

Re: PSCI version 1.1 and SYSTEM_RESET2

[Sodagudi Prasad]

On 2019-04-30 14:44, Sodagudi Prasad wrote:
+Sudeep

> 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 
support.
https://patchwork.kernel.org/patch/10884345/


Hi Sudeep,

I was going through your discussion in the below list -
https://lore.kernel.org/lkml/d73d3580-4ec1-a281-4585-5c776fc08c79@xilinx.com/

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

panic() --> emergency_restart() --> machine_emergency_restart() --> 
machine_restart(NULL);

It would nice if there is a config option to reboot the device either in 
warm or cold in the case of kernel panic.
Calling machine_restart with a NULL parameter for kernel crash is 
leading to devices cold reboot.

-Thanks, Prasad

> 
> -Thanks, Prasad

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

Re: PSCI version 1.1 and SYSTEM_RESET2

[Sudeep Holla]

On Tue, Apr 30, 2019 at 05:07:31PM -0700, Sodagudi Prasad wrote:
> On 2019-04-30 14:44, Sodagudi Prasad wrote:
> +Sudeep
>
> > 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
> support.
> https://patchwork.kernel.org/patch/10884345/
>

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

>
> Hi Sudeep,
>
> I was going through your discussion in the below list -
> https://lore.kernel.org/lkml/d73d3580-4ec1-a281-4585-5c776fc08c79@xilinx.com/
>
> 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
> crashed.
>
> panic() --> emergency_restart() --> machine_emergency_restart() -->
> machine_restart(NULL);
>
> 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 ?

I am just trying to understand the use case. Xilinx asked for the same
but never got to understand their use case.

--
Regards,
Sudeep

Re: PSCI version 1.1 and SYSTEM_RESET2

[Sodagudi Prasad]

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:
>> +Sudeep
>> 
>> > 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
>> support.
>> https://patchwork.kernel.org/patch/10884345/
>> 
> 
> This has landed in -next, and hopefully must appear in v5.2
> 
>> 
>> Hi Sudeep,
>> 
>> I was going through your discussion in the below list -
>> https://lore.kernel.org/lkml/d73d3580-4ec1-a281-4585-5c776fc08c79@xilinx.com/
>> 
>> 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
>> crashed.
>> 
>> panic() --> emergency_restart() --> machine_emergency_restart() -->
>> machine_restart(NULL);
>> 
>> 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.
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?

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

> 
> --
> Regards,
> Sudeep

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

Re: PSCI version 1.1 and SYSTEM_RESET2

[Sudeep Holla]

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.

> 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

Re: PSCI version 1.1 and SYSTEM_RESET2

[Sodagudi Prasad]

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

[PATCH] kernel/panic: Use SYSTEM_RESET2 command for warm reset

[Prasad Sodagudi]

Some platforms may need warm reboot support when kernel crashed
for post mortem analysis instead of cold reboot. So use config
CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command
support for warm reset.

Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
---
 kernel/panic.c    |  4 ++++
 lib/Kconfig.debug | 10 ++++++++++
 2 files changed, 14 insertions(+)

diff --git a/kernel/panic.c b/kernel/panic.c
index c1fcaad..6ab6675 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -198,6 +198,10 @@ void panic(const char *fmt, ...)
 
 	console_verbose();
 	bust_spinlocks(1);
+#ifdef CONFIG_WARM_REBOOT_ON_PANIC
+	/* Configure for warm reboot instead of cold reboot. */
+	reboot_mode = REBOOT_WARM;
+#endif
 	va_start(args, fmt);
 	len = vscnprintf(buf, sizeof(buf), fmt, args);
 	va_end(args);
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index d695ec1..2a727d8 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1000,6 +1000,16 @@ config PANIC_TIMEOUT
 	  value n > 0 will wait n seconds before rebooting, while a timeout
 	  value n < 0 will reboot immediately.
 
+config WARM_REBOOT_ON_PANIC
+	bool "Warm reboot instead of cold reboot for panic"
+	default n
+	help
+	  Some vendor platform may need warm reboot instead of cold reboot
+	  for debugging. Before vendor specific power off driver is
+	  probed, platform always gets cold reset. By setting Y here and
+	  support for PSCI V1.1 is present from firmware, platform would
+	  get warm reset instead of cold reset.
+
 config SCHED_DEBUG
 	bool "Collect scheduler debugging info"
 	depends on DEBUG_KERNEL && PROC_FS
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na Linux Foundation Collaborative Project

Re: [PATCH] kernel/panic: Use SYSTEM_RESET2 command for warm reset

[Sudeep Holla]

On Wed, May 08, 2019 at 06:47:12PM -0700, Prasad Sodagudi wrote:
> Some platforms may need warm reboot support when kernel crashed
> for post mortem analysis instead of cold reboot. So use config
> CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command
> support for warm reset.
>

Please drop all the references to PSCI and SYSTEM_RESET2 including
in subject. This is more generic and PSCIv1.1 with SYSTEM_RESET2 can
make use of it.

> Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
> ---
>  kernel/panic.c    |  4 ++++
>  lib/Kconfig.debug | 10 ++++++++++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/kernel/panic.c b/kernel/panic.c
> index c1fcaad..6ab6675 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -198,6 +198,10 @@ void panic(const char *fmt, ...)
>  
>  	console_verbose();
>  	bust_spinlocks(1);
> +#ifdef CONFIG_WARM_REBOOT_ON_PANIC
> +	/* Configure for warm reboot instead of cold reboot. */
> +	reboot_mode = REBOOT_WARM;
> +#endif
>  	va_start(args, fmt);
>  	len = vscnprintf(buf, sizeof(buf), fmt, args);
>  	va_end(args);
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index d695ec1..2a727d8 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1000,6 +1000,16 @@ config PANIC_TIMEOUT
>  	  value n > 0 will wait n seconds before rebooting, while a timeout
>  	  value n < 0 will reboot immediately.
>  
> +config WARM_REBOOT_ON_PANIC
> +	bool "Warm reboot instead of cold reboot for panic"
> +	default n
> +	help
> +	  Some vendor platform may need warm reboot instead of cold reboot
> +	  for debugging. Before vendor specific power off driver is
> +	  probed, platform always gets cold reset. By setting Y here and
> +	  support for PSCI V1.1 is present from firmware, platform would
> +	  get warm reset instead of cold reset.
> +

Ditto here, drop PSCI reference. Since it's being pushed as generic
solution, expecting anyone reading this to understand what is this PSCI
makes no sense and may be even confusing.

--
Regards,
Sudeep

Re: [PATCH] kernel/panic: Use SYSTEM_RESET2 command for warm reset

[Aaro Koskinen]

Hi,

On Wed, May 08, 2019 at 06:47:12PM -0700, Prasad Sodagudi wrote:
> Some platforms may need warm reboot support when kernel crashed
> for post mortem analysis instead of cold reboot. So use config
> CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command
> support for warm reset.

Please see commit b287a25a7148 - you can now use kernel command
line option reboot=panic_warm to get this.

A.

Re: [PATCH] kernel/panic: Use SYSTEM_RESET2 command for warm reset

[Sodagudi Prasad]

On 2019-05-16 11:29, Aaro Koskinen wrote:
> Hi,
> 
> On Wed, May 08, 2019 at 06:47:12PM -0700, Prasad Sodagudi wrote:
>> Some platforms may need warm reboot support when kernel crashed
>> for post mortem analysis instead of cold reboot. So use config
>> CONFIG_WARM_REBOOT_ON_PANIC and SYSTEM_RESET2 psci command
>> support for warm reset.
> 
> Please see commit b287a25a7148 - you can now use kernel command
> line option reboot=panic_warm to get this.

Thanks Aaro. Yes. I can use this option.  Thanks Sudeep and all for 
discussing.

> 
> A.

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