linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Sodagudi Prasad <psodagud@codeaurora.org>
To: Sudeep Holla <sudeep.holla@arm.com>
Cc: mark.rutland@arm.com, lorenzo.pieralisi@arm.com,
	julien.thierry@arm.com, catalin.marinas@arm.com,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: PSCI version 1.1 and SYSTEM_RESET2
Date: Wed, 08 May 2019 18:38:39 -0700	[thread overview]
Message-ID: <ce0b66f5d00e760f87ddeeacbc40b956@codeaurora.org> (raw)
In-Reply-To: <20190502090507.GC12498@e107155-lin>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-05-09  1:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-30 21:44 PSCI version 1.1 and SYSTEM_RESET2 Sodagudi Prasad
2019-05-01  0:07 ` Sodagudi Prasad
2019-05-01  9:49   ` Sudeep Holla
2019-05-01 18:43     ` Sodagudi Prasad
2019-05-02  9:05       ` Sudeep Holla
2019-05-09  1:38         ` Sodagudi Prasad [this message]
2019-05-09  1:47           ` [PATCH] kernel/panic: Use SYSTEM_RESET2 command for warm reset Prasad Sodagudi
2019-05-09  9:40             ` Sudeep Holla
2019-05-16 18:29             ` Aaro Koskinen
2019-05-17 18:03               ` Sodagudi Prasad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce0b66f5d00e760f87ddeeacbc40b956@codeaurora.org \
    --to=psodagud@codeaurora.org \
    --cc=catalin.marinas@arm.com \
    --cc=julien.thierry@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).