mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: Sudeep Holla <sudeep.holla@arm.com>,
	Michal Simek <michal.simek@xilinx.com>,
	<linux-arm-kernel@lists.infradead.org>
Cc: Mark Rutland <mark.rutland@arm.com>, Will Wong <WILLW@xilinx.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	<linux-kernel@vger.kernel.org>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: [PATCH v2] firmware/psci: add support for SYSTEM_RESET2
Date: Mon, 9 Jul 2018 15:13:42 +0200	[thread overview]
Message-ID: <0fce3ee6-873e-154f-b61e-546d9da338df@xilinx.com> (raw)
In-Reply-To: <3e7235c7-d2c2-29f6-6bec-ae21cb841731@arm.com>

On 9.7.2018 14:36, Sudeep Holla wrote:
> 
> 
> On 09/07/18 13:17, Michal Simek wrote:
>> Hi Sudeep,
>>
>> On 2.5.2018 12:30, Sudeep Holla wrote:
>>> PSCI v1.1 introduced SYSTEM_RESET2 to allow both architectural resets
>>> where the semantics are described by the PSCI specification itself as
>>> well as vendor-specific resets. Currently only system warm reset
>>> semantics is defined as part of architectural resets by the specification.
>>>
>>> This patch implements support for SYSTEM_RESET2 by making using of
>>> reboot_mode passed by the reboot infrastructure in the kernel.
>>>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>> ---
>>>  drivers/firmware/psci.c   | 21 +++++++++++++++++++++
>>>  include/uapi/linux/psci.h |  2 ++
>>>  2 files changed, 23 insertions(+)
>>>
>>> v1->v2:
>>> 	- Added mising static anotation to psci_system_reset2_supported
>>> 	- Added missing ')' in the comment
>>>
>>> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
>>> index c80ec1d03274..91748725534e 100644
>>> --- a/drivers/firmware/psci.c
>>> +++ b/drivers/firmware/psci.c
>>> @@ -88,6 +88,7 @@ static u32 psci_function_id[PSCI_FN_MAX];
>>>  				PSCI_1_0_EXT_POWER_STATE_TYPE_MASK)
>>>
>>>  static u32 psci_cpu_suspend_feature;
>>> +static bool psci_system_reset2_supported;
>>>
>>>  static inline bool psci_has_ext_power_state(void)
>>>  {
>>> @@ -253,6 +254,15 @@ static int get_set_conduit_method(struct device_node *np)
>>>
>>>  static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
>>>  {
>>> +	if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
>>
>> I am curious about this reboot_mode setup. I have grepped the kernel and
>> reboot_mode is setup via kernel parameters at boot time.
>> Shouldn't user decide what reboot type wants to do?
>>
> 
> I have almost forgotten how I tested this. IIRC and looking quickly @
> kernel/reboot.c and __setup(reboot=,...), I recall passing reboot=w
> while testing this.

I would expect that too. It means static setting at boot time.

> We can do something like what efi_reboot, but not
> sure if we need that yet if users need too decide after boot.


I am checking with colleague about all xilinx use cases but I would be
surprised if static configuration at run time is enough.

Also not quite sure about mixing reboot_warm and reboot_soft cases
together. They shouldn't be the same.

Based on psci 1.0 spec there are more options especially for bit[31]
which should be likely setup via DT(no experience with EFI) with names
and codes which should be passed to firmware but still the same issue
remains how to setup reboot type.

Thanks,
Michal



  reply	other threads:[~2018-07-09 13:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-01 14:51 [PATCH] " Sudeep Holla
2018-05-01 17:59 ` Florian Fainelli
2018-05-02 10:20   ` Sudeep Holla
2018-05-02 10:30 ` [PATCH v2] " Sudeep Holla
2018-07-09 12:17   ` Michal Simek
2018-07-09 12:36     ` Sudeep Holla
2018-07-09 13:13       ` Michal Simek [this message]
2018-07-09 13:21         ` Sudeep Holla
2018-07-19 10:47           ` Michal Simek
2018-07-26 13:29             ` Sudeep Holla
2018-07-30  8:59               ` Michal Simek

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=0fce3ee6-873e-154f-b61e-546d9da338df@xilinx.com \
    --to=michal.simek@xilinx.com \
    --cc=WILLW@xilinx.com \
    --cc=f.fainelli@gmail.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 \
    /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

all inboxes | Powered by JetHome®