[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190502090507.GC12498@e107155-lin>
Date: Thu, 2 May 2019 10:05:08 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Sodagudi Prasad <psodagud@...eaurora.org>
Cc: julien.thierry@....com, will.deacon@....com,
catalin.marinas@....com, mark.rutland@....com,
lorenzo.pieralisi@....com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: PSCI version 1.1 and SYSTEM_RESET2
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
Powered by blists - more mailing lists