[PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Sudeep Holla]

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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
 drivers/firmware/psci.c   | 24 +++++++++++++++++++++++-
 include/uapi/linux/psci.h |  2 ++
 2 files changed, 25 insertions(+), 1 deletion(-)

v2->v3:
	- Added else condition so that if SYSTEM_RESET2 fails, it ends
	  up doing a system halt
	- Wrap single statement if..else with braces because of presence
	  of multiple line comment

diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index c80ec1d03274..c9ea8f38bd42 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,7 +254,17 @@ static int get_set_conduit_method(struct device_node *np)

 static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
 {
-	invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+	if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
+	    psci_system_reset2_supported) {
+		/*
+		 * reset_type[31] = 0 (architectural)
+		 * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
+		 * cookie = 0 (ignored by the implementation)
+		 */
+		invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
+	} else {
+		invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
+	}
 }

 static void psci_sys_poweroff(void)
@@ -451,6 +462,16 @@ static const struct platform_suspend_ops psci_suspend_ops = {
 	.enter          = psci_system_suspend_enter,
 };

+static void __init psci_init_system_reset2(void)
+{
+	int ret;
+
+	ret = psci_features(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2));
+
+	if (ret != PSCI_RET_NOT_SUPPORTED)
+		psci_system_reset2_supported = true;
+}
+
 static void __init psci_init_system_suspend(void)
 {
 	int ret;
@@ -588,6 +609,7 @@ static int __init psci_probe(void)
 		psci_init_smccc();
 		psci_init_cpu_suspend();
 		psci_init_system_suspend();
+		psci_init_system_reset2();
 	}

 	return 0;
diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
index b3bcabe380da..5b0ba0062541 100644
--- a/include/uapi/linux/psci.h
+++ b/include/uapi/linux/psci.h
@@ -49,8 +49,10 @@

 #define PSCI_1_0_FN_PSCI_FEATURES		PSCI_0_2_FN(10)
 #define PSCI_1_0_FN_SYSTEM_SUSPEND		PSCI_0_2_FN(14)
+#define PSCI_1_1_FN_SYSTEM_RESET2		PSCI_0_2_FN(18)

 #define PSCI_1_0_FN64_SYSTEM_SUSPEND		PSCI_0_2_FN64(14)
+#define PSCI_1_1_FN64_SYSTEM_RESET2		PSCI_0_2_FN64(18)

 /* PSCI v0.2 power state encoding for CPU_SUSPEND function */
 #define PSCI_0_2_POWER_STATE_ID_MASK		0xffff
--
2.17.1

Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Rafael J. Wysocki]

On Friday, April 12, 2019 12:02:27 PM CEST 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
>  drivers/firmware/psci.c   | 24 +++++++++++++++++++++++-
>  include/uapi/linux/psci.h |  2 ++
>  2 files changed, 25 insertions(+), 1 deletion(-)
> 
> v2->v3:
> 	- Added else condition so that if SYSTEM_RESET2 fails, it ends
> 	  up doing a system halt
> 	- Wrap single statement if..else with braces because of presence
> 	  of multiple line comment
> 
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index c80ec1d03274..c9ea8f38bd42 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,7 +254,17 @@ static int get_set_conduit_method(struct device_node
> *np)
> 
>  static void psci_sys_reset(enum reboot_mode reboot_mode, const char *cmd)
>  {
> -	invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
> +	if ((reboot_mode == REBOOT_WARM || reboot_mode == REBOOT_SOFT) &&
> +	    psci_system_reset2_supported) {
> +		/*
> +		 * reset_type[31] = 0 (architectural)
> +		 * reset_type[30:0] = 0 (SYSTEM_WARM_RESET)
> +		 * cookie = 0 (ignored by the implementation)
> +		 */
> +		invoke_psci_fn(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2), 0, 0, 0);
> +	} else {
> +		invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0);
> +	}
>  }
> 
>  static void psci_sys_poweroff(void)
> @@ -451,6 +462,16 @@ static const struct platform_suspend_ops
> psci_suspend_ops = { .enter          = psci_system_suspend_enter,
>  };
> 
> +static void __init psci_init_system_reset2(void)
> +{
> +	int ret;
> +
> +	ret = psci_features(PSCI_FN_NATIVE(1_1, SYSTEM_RESET2));
> +
> +	if (ret != PSCI_RET_NOT_SUPPORTED)
> +		psci_system_reset2_supported = true;
> +}
> +
>  static void __init psci_init_system_suspend(void)
>  {
>  	int ret;
> @@ -588,6 +609,7 @@ static int __init psci_probe(void)
>  		psci_init_smccc();
>  		psci_init_cpu_suspend();
>  		psci_init_system_suspend();
> +		psci_init_system_reset2();
>  	}
> 
>  	return 0;
> diff --git a/include/uapi/linux/psci.h b/include/uapi/linux/psci.h
> index b3bcabe380da..5b0ba0062541 100644
> --- a/include/uapi/linux/psci.h
> +++ b/include/uapi/linux/psci.h
> @@ -49,8 +49,10 @@
> 
>  #define PSCI_1_0_FN_PSCI_FEATURES		PSCI_0_2_FN(10)
>  #define PSCI_1_0_FN_SYSTEM_SUSPEND		PSCI_0_2_FN(14)
> +#define PSCI_1_1_FN_SYSTEM_RESET2		PSCI_0_2_FN(18)
> 
>  #define PSCI_1_0_FN64_SYSTEM_SUSPEND		PSCI_0_2_FN64(14)
> +#define PSCI_1_1_FN64_SYSTEM_RESET2		PSCI_0_2_FN64(18)
> 
>  /* PSCI v0.2 power state encoding for CPU_SUSPEND function */
>  #define PSCI_0_2_POWER_STATE_ID_MASK		0xffff
> --

So I queued up the PSCI series from Ulf which clashes with this patch.

I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a 
result. :-)

Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Sudeep Holla]

On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> On Friday, April 12, 2019 12:02:27 PM CEST 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > ---
> >  drivers/firmware/psci.c   | 24 +++++++++++++++++++++++-
> >  include/uapi/linux/psci.h |  2 ++
> >  2 files changed, 25 insertions(+), 1 deletion(-)

[...]

> > --
> 
> So I queued up the PSCI series from Ulf which clashes with this patch.
>

Ah OK, I wasn't aware(just back from holiday) that it's going through
your tree. No worries, I will rebase and repost soon. I want testing
by xilinx or Aaro Koskinen before that.

> I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> result. :-)
>

I can understand, I assure it's one off :)

--
Regards,
Sudeep

Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Ulf Hansson]

Sudeep, Lorenzo, Mark

On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
> On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > On Friday, April 12, 2019 12:02:27 PM CEST 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > > ---
> > >  drivers/firmware/psci.c   | 24 +++++++++++++++++++++++-
> > >  include/uapi/linux/psci.h |  2 ++
> > >  2 files changed, 25 insertions(+), 1 deletion(-)
>
> [...]
>
> > > --
> >
> > So I queued up the PSCI series from Ulf which clashes with this patch.
> >
>
> Ah OK, I wasn't aware(just back from holiday) that it's going through
> your tree. No worries, I will rebase and repost soon. I want testing
> by xilinx or Aaro Koskinen before that.
>
> > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > result. :-)
> >
>
> I can understand, I assure it's one off :)

Speaking about that. I would gladly help out to host a git tree to
collect patches that you have acked. In this way, we can, for example,
get the patches pre-tested in linux next before we send the
pull-request.

If you think sounds like a good idea, just tell me so I can prepare a
tree for the next release cycle...

Kind regards
Uffe

Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Sudeep Holla]

On Fri, Apr 12, 2019 at 02:37:05PM +0200, Ulf Hansson wrote:
> Sudeep, Lorenzo, Mark
> 
> On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >
> > On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > > On Friday, April 12, 2019 12:02:27 PM CEST 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > > > ---
> > > >  drivers/firmware/psci.c   | 24 +++++++++++++++++++++++-
> > > >  include/uapi/linux/psci.h |  2 ++
> > > >  2 files changed, 25 insertions(+), 1 deletion(-)
> >
> > [...]
> >
> > > > --
> > >
> > > So I queued up the PSCI series from Ulf which clashes with this patch.
> > >
> >
> > Ah OK, I wasn't aware(just back from holiday) that it's going through
> > your tree. No worries, I will rebase and repost soon. I want testing
> > by xilinx or Aaro Koskinen before that.
> >
> > > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > > result. :-)
> > >
> >
> > I can understand, I assure it's one off :)
>
> Speaking about that. I would gladly help out to host a git tree to
> collect patches that you have acked. In this way, we can, for example,
> get the patches pre-tested in linux next before we send the
> pull-request.
>
> If you think sounds like a good idea, just tell me so I can prepare a
> tree for the next release cycle...
>

For now, I just have this one patch. So if Rafael has queued all your
patches, I can just rebase and post it once I get tested-by from Aaro
Koskinen, so that Rafael can queue this too. Or are you planning to
send PR to Rafael, sorry if I missed details already discussed on the
list.

--
Regards,
Sudeep

Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Lorenzo Pieralisi]

On Fri, Apr 12, 2019 at 02:42:22PM +0100, Sudeep Holla wrote:
> On Fri, Apr 12, 2019 at 02:37:05PM +0200, Ulf Hansson wrote:
> > Sudeep, Lorenzo, Mark
> > 
> > On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > >
> > > On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > > > On Friday, April 12, 2019 12:02:27 PM CEST 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > > > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > > > > ---
> > > > >  drivers/firmware/psci.c   | 24 +++++++++++++++++++++++-
> > > > >  include/uapi/linux/psci.h |  2 ++
> > > > >  2 files changed, 25 insertions(+), 1 deletion(-)
> > >
> > > [...]
> > >
> > > > > --
> > > >
> > > > So I queued up the PSCI series from Ulf which clashes with this patch.
> > > >
> > >
> > > Ah OK, I wasn't aware(just back from holiday) that it's going through
> > > your tree. No worries, I will rebase and repost soon. I want testing
> > > by xilinx or Aaro Koskinen before that.
> > >
> > > > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > > > result. :-)
> > > >
> > >
> > > I can understand, I assure it's one off :)
> >
> > Speaking about that. I would gladly help out to host a git tree to
> > collect patches that you have acked. In this way, we can, for example,
> > get the patches pre-tested in linux next before we send the
> > pull-request.
> >
> > If you think sounds like a good idea, just tell me so I can prepare a
> > tree for the next release cycle...
> >
> 
> For now, I just have this one patch. So if Rafael has queued all your
> patches, I can just rebase and post it once I get tested-by from Aaro
> Koskinen, so that Rafael can queue this too. Or are you planning to
> send PR to Rafael, sorry if I missed details already discussed on the
> list.

Mark and I can queue PSCI patches as we usually do, we agreed they would
go via Rafael's tree (thanks) because of dependencies with the PM tree
(that did not turn out to be there so we could have sent them to arm-soc
just as well as we usually do), next cycle if and when there are patches
to be queued we will queue them up and send them upstream ourselves.

Thanks,
Lorenzo

Re: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Ulf Hansson]

On Fri, 12 Apr 2019 at 16:19, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
>
> On Fri, Apr 12, 2019 at 02:42:22PM +0100, Sudeep Holla wrote:
> > On Fri, Apr 12, 2019 at 02:37:05PM +0200, Ulf Hansson wrote:
> > > Sudeep, Lorenzo, Mark
> > >
> > > On Fri, 12 Apr 2019 at 12:15, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > > >
> > > > On Fri, Apr 12, 2019 at 12:10:45PM +0200, Rafael J. Wysocki wrote:
> > > > > On Friday, April 12, 2019 12:02:27 PM CEST 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > > > > > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > > > > > Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> > > > > > ---
> > > > > >  drivers/firmware/psci.c   | 24 +++++++++++++++++++++++-
> > > > > >  include/uapi/linux/psci.h |  2 ++
> > > > > >  2 files changed, 25 insertions(+), 1 deletion(-)
> > > >
> > > > [...]
> > > >
> > > > > > --
> > > > >
> > > > > So I queued up the PSCI series from Ulf which clashes with this patch.
> > > > >
> > > >
> > > > Ah OK, I wasn't aware(just back from holiday) that it's going through
> > > > your tree. No worries, I will rebase and repost soon. I want testing
> > > > by xilinx or Aaro Koskinen before that.
> > > >
> > > > > I can take this one too, but I'd rather avoid becoming a PSCI maintainer as a
> > > > > result. :-)
> > > > >
> > > >
> > > > I can understand, I assure it's one off :)
> > >
> > > Speaking about that. I would gladly help out to host a git tree to
> > > collect patches that you have acked. In this way, we can, for example,
> > > get the patches pre-tested in linux next before we send the
> > > pull-request.
> > >
> > > If you think sounds like a good idea, just tell me so I can prepare a
> > > tree for the next release cycle...
> > >
> >
> > For now, I just have this one patch. So if Rafael has queued all your
> > patches, I can just rebase and post it once I get tested-by from Aaro
> > Koskinen, so that Rafael can queue this too. Or are you planning to
> > send PR to Rafael, sorry if I missed details already discussed on the
> > list.
>
> Mark and I can queue PSCI patches as we usually do, we agreed they would
> go via Rafael's tree (thanks) because of dependencies with the PM tree
> (that did not turn out to be there so we could have sent them to arm-soc
> just as well as we usually do), next cycle if and when there are patches
> to be queued we will queue them up and send them upstream ourselves.

Why I wanted them queued via Rafael's tree, is because of the
following series for PSCI that I will post in a a day or two, that has
dependencies to new changes to genpd.

My proposal with a git tree was mainly because of allowing patches to
be pre-tested in Stephen Rothwell's linux-next tree, before you send
the pull request to arm-soc. Or are you saying you already have a tree
for this, but not listed in MAINTAINERS?

In any case, it was just a suggestion to improve the working flow for
better tests etc. Feel free to ignore it.

Kind regards
Uffe

RE: [PATCH v3] firmware/psci: add support for SYSTEM_RESET2

[Koskinen, Aaro (Nokia - FI/Espoo)]

Hi,

From: Sudeep Holla [sudeep.holla@arm.com]:
> 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: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Tested-by: Aaro Koskinen <aaro.koskinen@nokia.com>

Thanks,

A.