[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[chee.hong.ang at intel.com]

From: "Ang, Chee Hong" <chee.hong.ang@intel.com>

Currently u-boot only support standard PSCI functions for power management
and lack of convenient method to allow the users to extend the PSCI functions
to support platform specific services. Most of the u-boot users still rely
on ATF (ARM Trusted Firmware) to handle the standard power management and
platform specific PSCI services.
The purpose of this patchsets is to allow u-boot users to support their
own platform specific secure SMC/PSCI services without making any
SMC calls to ATF. This will benefit the users who need to use u-boot as the
only bootloader and secure service provider without relying on ATF.

Below is a simple code example for adding your own PSCI functions:

#include <common.h>
#include <errno.h>
#include <asm/io.h>
#include <asm/psci.h>
#include <asm/secure.h>

#define PSCI_SMC64_FUNC_ID1	0xC2000001
#define PSCI_SMC64_FUNC_ID2	0xC2000002

static void __secure psci_plat_specific_func1(unsigned long function_id)
{
	/* Your code for handling the SMC/PSCI platform specific service 1 */
}

static void __secure psci_plat_specific_func2(unsigned long function_id)
{
	/* Your code for handling the SMC/PSCI platform specific service 2 */
}

DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
		   psci_plat_specific_func1);
DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
		   psci_plat_specific_func2);

Ang, Chee Hong (1):
  ARMv8: Disable fwcall when PSCI is enabled

Chee Hong Ang (1):
  ARMv8: Allow SiP service extensions on top of PSCI code

 arch/arm/cpu/armv8/Makefile   |  2 ++
 arch/arm/cpu/armv8/psci.S     | 33 +++++++++++++++++++++++++++------
 arch/arm/cpu/armv8/u-boot.lds |  4 ++++
 arch/arm/include/asm/secure.h | 31 +++++++++++++++++++++++++++++++
 4 files changed, 64 insertions(+), 6 deletions(-)

-- 
2.7.4

[U-Boot] [PATCH v1 1/2] ARMv8: Allow SiP service extensions on top of PSCI code

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Allow PSCI layer to handle any SiP service functions added by
platform vendors. PSCI layer will look for SiP service function
in the SiP function table located in '._secure_svc_tbl_entries'
section if the SMC function identifier is not found in the PSCI
standard functions table. Use DECLARE_SECURE_SVC macro to declare
and add platform specific SiP service function.
This new section '._secure_svc_tbl_entries' is located next to
'._secure.text' section. Refer to arch/arm/cpu/armv8/u-boot.lds.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/cpu/armv8/psci.S     | 33 +++++++++++++++++++++++++++------
 arch/arm/cpu/armv8/u-boot.lds |  4 ++++
 arch/arm/include/asm/secure.h | 31 +++++++++++++++++++++++++++++++
 3 files changed, 62 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv8/psci.S b/arch/arm/cpu/armv8/psci.S
index 358df8f..fc42d80 100644
--- a/arch/arm/cpu/armv8/psci.S
+++ b/arch/arm/cpu/armv8/psci.S
@@ -8,6 +8,7 @@
 #include <config.h>
 #include <linux/linkage.h>
 #include <asm/psci.h>
+#include <asm/secure.h>
 
 /* Default PSCI function, return -1, Not Implemented */
 #define PSCI_DEFAULT(__fn) \
@@ -147,18 +148,38 @@ handle_psci:
 3:	mov	x0, #ARM_PSCI_RET_NI
 	psci_return
 
-unknown_smc_id:
-	ldr	x0, =0xFFFFFFFF
+/*
+ * Handle SiP service functions defined in SiP service function table.
+ * Use DECLARE_SECURE_SVC(_name, _id, _fn) to add platform specific SiP
+ * service function into the SiP service function table.
+ * SiP service function table is located in '._secure_svc_tbl_entries' section,
+ * which is next to '._secure.text' section.
+ */
+handle_svc:
+	adr	x9, __secure_svc_tbl_start
+	adr	x10, __secure_svc_tbl_end
+	subs	x12, x10, x9	/* Get number of entries in table */
+	b.eq	2f		/* Make sure SiP function table is not empty */
+	psci_enter
+1:	ldr x10, [x9]		/* Load SiP function table */
+	ldr x11, [x9, #8]
+	cmp	w10, w0
+	b.eq	2b		/* SiP service function found */
+	add x9, x9, #SECURE_SVC_TBL_OFFSET	/* Move to next entry */
+	subs	x12, x12, #SECURE_SVC_TBL_OFFSET
+	b.eq	3b		/* If reach the end, bail out */
+	b	1b
+2:	ldr	x0, =0xFFFFFFFF
 	eret
 
 handle_smc32:
 	/* SMC function ID  0x84000000-0x8400001F: 32 bits PSCI */
 	ldr	w9, =0x8400001F
 	cmp	w0, w9
-	b.gt	unknown_smc_id
+	b.gt	handle_svc
 	ldr	w9, =0x84000000
 	cmp	w0, w9
-	b.lt	unknown_smc_id
+	b.lt	handle_svc
 
 	adr	x9, _psci_32_table
 	b	handle_psci
@@ -171,10 +192,10 @@ handle_smc64:
 	/* SMC function ID 0xC4000000-0xC400001F: 64 bits PSCI */
 	ldr	x9, =0xC400001F
 	cmp	x0, x9
-	b.gt	unknown_smc_id
+	b.gt	handle_svc
 	ldr	x9, =0xC4000000
 	cmp	x0, x9
-	b.lt	unknown_smc_id
+	b.lt	handle_svc
 
 	adr	x9, _psci_64_table
 	b	handle_psci
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index 53de80f..2554980 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -58,6 +58,10 @@ SECTIONS
 		AT(ADDR(.__secure_start) + SIZEOF(.__secure_start))
 	{
 		*(._secure.text)
+		. = ALIGN(8);
+		__secure_svc_tbl_start = .;
+		KEEP(*(._secure_svc_tbl_entries))
+		__secure_svc_tbl_end = .;
 	}
 
 	.secure_data : AT(LOADADDR(.secure_text) + SIZEOF(.secure_text))
diff --git a/arch/arm/include/asm/secure.h b/arch/arm/include/asm/secure.h
index d23044a..50582c9 100644
--- a/arch/arm/include/asm/secure.h
+++ b/arch/arm/include/asm/secure.h
@@ -6,6 +6,37 @@
 #define __secure __attribute__ ((section ("._secure.text")))
 #define __secure_data __attribute__ ((section ("._secure.data")))
 
+#ifndef __ASSEMBLY__
+
+typedef struct secure_svc_tbl {
+	u32	id;
+#ifdef CONFIG_ARMV8_PSCI
+	u8	pad[4];
+#endif
+	void	*func;
+} secure_svc_tbl_t;
+
+/*
+ * Macro to declare a SiP function service in '_secure_svc_tbl_entries' section
+ */
+#define DECLARE_SECURE_SVC(_name, _id, _fn) \
+	static const secure_svc_tbl_t __secure_svc_ ## _name \
+		__attribute__((used, section("._secure_svc_tbl_entries"))) \
+			 = { \
+				.id = _id, \
+				.func = _fn }
+
+#else
+
+#ifdef CONFIG_ARMV8_PSCI
+#define SECURE_SVC_TBL_OFFSET		16
+#else
+#define SECURE_SVC_TBL_OFFSET		8
+
+#endif
+
+#endif /* __ASSEMBLY__ */
+
 #if defined(CONFIG_ARMV7_SECURE_BASE) || defined(CONFIG_ARMV8_SECURE_BASE)
 /*
  * Warning, horror ahead.
-- 
2.7.4

[U-Boot] [U-Boot, v1, 1/2] ARMv8: Allow SiP service extensions on top of PSCI code

[Tom Rini]

On Tue, Feb 12, 2019 at 12:27:02AM -0800, chee.hong.ang at intel.com wrote:

> From: Chee Hong Ang <chee.hong.ang@intel.com>
> 
> Allow PSCI layer to handle any SiP service functions added by
> platform vendors. PSCI layer will look for SiP service function
> in the SiP function table located in '._secure_svc_tbl_entries'
> section if the SMC function identifier is not found in the PSCI
> standard functions table. Use DECLARE_SECURE_SVC macro to declare
> and add platform specific SiP service function.
> This new section '._secure_svc_tbl_entries' is located next to
> '._secure.text' section. Refer to arch/arm/cpu/armv8/u-boot.lds.
> 
> Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190424/8b3afd3b/attachment.sig>

[U-Boot] [PATCH v1 2/2] ARMv8: Disable fwcall when PSCI is enabled

[chee.hong.ang at intel.com]

From: "Ang, Chee Hong" <chee.hong.ang@intel.com>

When PSCI is enabled, we are expecting U-Boot which now act
as EL3 software will handle all the PSCI calls. We won't need
fwcall as no further HVC or SMC are needed.

Signed-off-by: Ang, Chee Hong <chee.hong.ang@intel.com>
---
 arch/arm/cpu/armv8/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index 4c4b13c..ae6178f 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -18,7 +18,9 @@ endif
 obj-y	+= cache.o
 obj-y	+= tlb.o
 obj-y	+= transition.o
+ifndef CONFIG_ARMV8_PSCI
 obj-y	+= fwcall.o
+endif
 obj-y	+= cpu-dt.o
 obj-$(CONFIG_ARM_SMCCC)		+= smccc-call.o
 
-- 
2.7.4

[U-Boot] [U-Boot, v1, 2/2] ARMv8: Disable fwcall when PSCI is enabled

[Tom Rini]

On Tue, Feb 12, 2019 at 12:27:03AM -0800, chee.hong.ang at intel.com wrote:

> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> 
> When PSCI is enabled, we are expecting U-Boot which now act
> as EL3 software will handle all the PSCI calls. We won't need
> fwcall as no further HVC or SMC are needed.
> 
> Signed-off-by: Ang, Chee Hong <chee.hong.ang@intel.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190424/ff06fc01/attachment.sig>

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Ang, Chee Hong]

Hi Tom,

        Any comments on this patch ?

Best Regards,
Ang
On Tue, 2019-02-12 at 00:27 -0800, chee.hong.ang at intel.com wrote:
> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> 
> Currently u-boot only support standard PSCI functions for power
> management
> and lack of convenient method to allow the users to extend the PSCI
> functions
> to support platform specific services. Most of the u-boot users still
> rely
> on ATF (ARM Trusted Firmware) to handle the standard power management
> and
> platform specific PSCI services.
> The purpose of this patchsets is to allow u-boot users to support
> their
> own platform specific secure SMC/PSCI services without making any
> SMC calls to ATF. This will benefit the users who need to use u-boot
> as the
> only bootloader and secure service provider without relying on ATF.
> 
> Below is a simple code example for adding your own PSCI functions:
> 
> #include <common.h>
> #include <errno.h>
> #include <asm/io.h>
> #include <asm/psci.h>
> #include <asm/secure.h>
> 
> #define PSCI_SMC64_FUNC_ID1	0xC2000001
> #define PSCI_SMC64_FUNC_ID2	0xC2000002
> 
> static void __secure psci_plat_specific_func1(unsigned long
> function_id)
> {
> 	/* Your code for handling the SMC/PSCI platform specific
> service 1 */
> }
> 
> static void __secure psci_plat_specific_func2(unsigned long
> function_id)
> {
> 	/* Your code for handling the SMC/PSCI platform specific
> service 2 */
> }
> 
> DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> 		   psci_plat_specific_func1);
> DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> 		   psci_plat_specific_func2);
> 
> Ang, Chee Hong (1):
>   ARMv8: Disable fwcall when PSCI is enabled
> 
> Chee Hong Ang (1):
>   ARMv8: Allow SiP service extensions on top of PSCI code
> 
>  arch/arm/cpu/armv8/Makefile   |  2 ++
>  arch/arm/cpu/armv8/psci.S     | 33 +++++++++++++++++++++++++++------
>  arch/arm/cpu/armv8/u-boot.lds |  4 ++++
>  arch/arm/include/asm/secure.h | 31 +++++++++++++++++++++++++++++++
>  4 files changed, 64 insertions(+), 6 deletions(-)
> 

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Ang, Chee Hong]

On Tue, 2019-02-12 at 00:27 -0800, chee.hong.ang at intel.com wrote:
> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
Hi Tom/Albert,

       Any comment on this patch ?

Best Regards,
Ang
> 
> Currently u-boot only support standard PSCI functions for power
> management
> and lack of convenient method to allow the users to extend the PSCI
> functions
> to support platform specific services. Most of the u-boot users still
> rely
> on ATF (ARM Trusted Firmware) to handle the standard power management
> and
> platform specific PSCI services.
> The purpose of this patchsets is to allow u-boot users to support
> their
> own platform specific secure SMC/PSCI services without making any
> SMC calls to ATF. This will benefit the users who need to use u-boot
> as the
> only bootloader and secure service provider without relying on ATF.
> 
> Below is a simple code example for adding your own PSCI functions:
> 
> #include <common.h>
> #include <errno.h>
> #include <asm/io.h>
> #include <asm/psci.h>
> #include <asm/secure.h>
> 
> #define PSCI_SMC64_FUNC_ID1	0xC2000001
> #define PSCI_SMC64_FUNC_ID2	0xC2000002
> 
> static void __secure psci_plat_specific_func1(unsigned long
> function_id)
> {
> 	/* Your code for handling the SMC/PSCI platform specific
> service 1 */
> }
> 
> static void __secure psci_plat_specific_func2(unsigned long
> function_id)
> {
> 	/* Your code for handling the SMC/PSCI platform specific
> service 2 */
> }
> 
> DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> 		   psci_plat_specific_func1);
> DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> 		   psci_plat_specific_func2);
> 
> Ang, Chee Hong (1):
>   ARMv8: Disable fwcall when PSCI is enabled
> 
> Chee Hong Ang (1):
>   ARMv8: Allow SiP service extensions on top of PSCI code
> 
>  arch/arm/cpu/armv8/Makefile   |  2 ++
>  arch/arm/cpu/armv8/psci.S     | 33 +++++++++++++++++++++++++++------
>  arch/arm/cpu/armv8/u-boot.lds |  4 ++++
>  arch/arm/include/asm/secure.h | 31 +++++++++++++++++++++++++++++++
>  4 files changed, 64 insertions(+), 6 deletions(-)
> 

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Tom Rini]

On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang at intel.com wrote:

> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> 
> Currently u-boot only support standard PSCI functions for power management
> and lack of convenient method to allow the users to extend the PSCI functions
> to support platform specific services. Most of the u-boot users still rely
> on ATF (ARM Trusted Firmware) to handle the standard power management and
> platform specific PSCI services.
> The purpose of this patchsets is to allow u-boot users to support their
> own platform specific secure SMC/PSCI services without making any
> SMC calls to ATF. This will benefit the users who need to use u-boot as the
> only bootloader and secure service provider without relying on ATF.
> 
> Below is a simple code example for adding your own PSCI functions:
> 
> #include <common.h>
> #include <errno.h>
> #include <asm/io.h>
> #include <asm/psci.h>
> #include <asm/secure.h>
> 
> #define PSCI_SMC64_FUNC_ID1	0xC2000001
> #define PSCI_SMC64_FUNC_ID2	0xC2000002
> 
> static void __secure psci_plat_specific_func1(unsigned long function_id)
> {
> 	/* Your code for handling the SMC/PSCI platform specific service 1 */
> }
> 
> static void __secure psci_plat_specific_func2(unsigned long function_id)
> {
> 	/* Your code for handling the SMC/PSCI platform specific service 2 */
> }
> 
> DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> 		   psci_plat_specific_func1);
> DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> 		   psci_plat_specific_func2);
> 
> Ang, Chee Hong (1):
>   ARMv8: Disable fwcall when PSCI is enabled
> 
> Chee Hong Ang (1):
>   ARMv8: Allow SiP service extensions on top of PSCI code

Conceptually, I suppose this is a logical step.  In specifics, would we
want to make this functionality opt-in, or no, that doesn't make sense?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190308/9b2218d5/attachment.sig>

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Ang, Chee Hong]

On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang at intel.com
> wrote:
> 
> > 
> > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > 
> > Currently u-boot only support standard PSCI functions for power
> > management
> > and lack of convenient method to allow the users to extend the PSCI
> > functions
> > to support platform specific services. Most of the u-boot users
> > still rely
> > on ATF (ARM Trusted Firmware) to handle the standard power
> > management and
> > platform specific PSCI services.
> > The purpose of this patchsets is to allow u-boot users to support
> > their
> > own platform specific secure SMC/PSCI services without making any
> > SMC calls to ATF. This will benefit the users who need to use u-
> > boot as the
> > only bootloader and secure service provider without relying on ATF.
> > 
> > Below is a simple code example for adding your own PSCI functions:
> > 
> > #include <common.h>
> > #include <errno.h>
> > #include <asm/io.h>
> > #include <asm/psci.h>
> > #include <asm/secure.h>
> > 
> > #define PSCI_SMC64_FUNC_ID1	0xC2000001
> > #define PSCI_SMC64_FUNC_ID2	0xC2000002
> > 
> > static void __secure psci_plat_specific_func1(unsigned long
> > function_id)
> > {
> > 	/* Your code for handling the SMC/PSCI platform specific
> > service 1 */
> > }
> > 
> > static void __secure psci_plat_specific_func2(unsigned long
> > function_id)
> > {
> > 	/* Your code for handling the SMC/PSCI platform specific
> > service 2 */
> > }
> > 
> > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> > 		   psci_plat_specific_func1);
> > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> > 		   psci_plat_specific_func2);
> > 
> > Ang, Chee Hong (1):
> >   ARMv8: Disable fwcall when PSCI is enabled
> > 
> > Chee Hong Ang (1):
> >   ARMv8: Allow SiP service extensions on top of PSCI code
> Conceptually, I suppose this is a logical step.  In specifics, would
> we
> want to make this functionality opt-in, or no, that doesn't make
> sense?
> 
Allowing user to add platform specific service is part of SMC/PSCI
specification as specifed in ARM document (Table 2-1):
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_
SMC_Calling_Convention.pdf

So I think this functionality should be part of the standard PSCI/SMC
implementation. Currently u-boot only support standard PSCI call which
is:
----------------------------------------------
| 0x84000000-0x8400001F  | PSCI 32-bit calls |
| 0xC4000000-0xC400001F  | PSCI 64-bit calls |
----------------------------------------------

My implementation do not affect or alter the behavior of any existing
standard PSCI calls.

Users can simply add their own platform specific services by using the
service call range as below:
----------------------------------------------------
| 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls |
| 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
----------------------------------------------------

For complete service call ranges please refer to Table 6-2 in the ARM
document.

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Tom Rini]

On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
> On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang at intel.com
> > wrote:
> > 
> > > 
> > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > 
> > > Currently u-boot only support standard PSCI functions for power
> > > management
> > > and lack of convenient method to allow the users to extend the PSCI
> > > functions
> > > to support platform specific services. Most of the u-boot users
> > > still rely
> > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > management and
> > > platform specific PSCI services.
> > > The purpose of this patchsets is to allow u-boot users to support
> > > their
> > > own platform specific secure SMC/PSCI services without making any
> > > SMC calls to ATF. This will benefit the users who need to use u-
> > > boot as the
> > > only bootloader and secure service provider without relying on ATF.
> > > 
> > > Below is a simple code example for adding your own PSCI functions:
> > > 
> > > #include <common.h>
> > > #include <errno.h>
> > > #include <asm/io.h>
> > > #include <asm/psci.h>
> > > #include <asm/secure.h>
> > > 
> > > #define PSCI_SMC64_FUNC_ID1	0xC2000001
> > > #define PSCI_SMC64_FUNC_ID2	0xC2000002
> > > 
> > > static void __secure psci_plat_specific_func1(unsigned long
> > > function_id)
> > > {
> > > 	/* Your code for handling the SMC/PSCI platform specific
> > > service 1 */
> > > }
> > > 
> > > static void __secure psci_plat_specific_func2(unsigned long
> > > function_id)
> > > {
> > > 	/* Your code for handling the SMC/PSCI platform specific
> > > service 2 */
> > > }
> > > 
> > > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> > > 		   psci_plat_specific_func1);
> > > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> > > 		   psci_plat_specific_func2);
> > > 
> > > Ang, Chee Hong (1):
> > >   ARMv8: Disable fwcall when PSCI is enabled
> > > 
> > > Chee Hong Ang (1):
> > >   ARMv8: Allow SiP service extensions on top of PSCI code
> > Conceptually, I suppose this is a logical step.  In specifics, would
> > we
> > want to make this functionality opt-in, or no, that doesn't make
> > sense?
> > 
> Allowing user to add platform specific service is part of SMC/PSCI
> specification as specifed in ARM document (Table 2-1):
> http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_
> SMC_Calling_Convention.pdf
> 
> So I think this functionality should be part of the standard PSCI/SMC
> implementation. Currently u-boot only support standard PSCI call which
> is:
> ----------------------------------------------
> | 0x84000000-0x8400001F  | PSCI 32-bit calls |
> | 0xC4000000-0xC400001F  | PSCI 64-bit calls |
> ----------------------------------------------
> 
> My implementation do not affect or alter the behavior of any existing
> standard PSCI calls.
> 
> Users can simply add their own platform specific services by using the
> service call range as below:
> ----------------------------------------------------
> | 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls |
> | 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
> ----------------------------------------------------
> 
> For complete service call ranges please refer to Table 6-2 in the ARM
> document.

OK, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190311/4281cd9b/attachment.sig>

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Ang, Chee Hong]

On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
> > 
> > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > > 
> > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang at intel.com
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > 
> > > > Currently u-boot only support standard PSCI functions for power
> > > > management
> > > > and lack of convenient method to allow the users to extend the
> > > > PSCI
> > > > functions
> > > > to support platform specific services. Most of the u-boot users
> > > > still rely
> > > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > > management and
> > > > platform specific PSCI services.
> > > > The purpose of this patchsets is to allow u-boot users to
> > > > support
> > > > their
> > > > own platform specific secure SMC/PSCI services without making
> > > > any
> > > > SMC calls to ATF. This will benefit the users who need to use
> > > > u-
> > > > boot as the
> > > > only bootloader and secure service provider without relying on
> > > > ATF.
> > > > 
> > > > Below is a simple code example for adding your own PSCI
> > > > functions:
> > > > 
> > > > #include <common.h>
> > > > #include <errno.h>
> > > > #include <asm/io.h>
> > > > #include <asm/psci.h>
> > > > #include <asm/secure.h>
> > > > 
> > > > #define PSCI_SMC64_FUNC_ID1	0xC2000001
> > > > #define PSCI_SMC64_FUNC_ID2	0xC2000002
> > > > 
> > > > static void __secure psci_plat_specific_func1(unsigned long
> > > > function_id)
> > > > {
> > > > 	/* Your code for handling the SMC/PSCI platform
> > > > specific
> > > > service 1 */
> > > > }
> > > > 
> > > > static void __secure psci_plat_specific_func2(unsigned long
> > > > function_id)
> > > > {
> > > > 	/* Your code for handling the SMC/PSCI platform
> > > > specific
> > > > service 2 */
> > > > }
> > > > 
> > > > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> > > > 		   psci_plat_specific_func1);
> > > > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> > > > 		   psci_plat_specific_func2);
> > > > 
> > > > Ang, Chee Hong (1):
> > > >   ARMv8: Disable fwcall when PSCI is enabled
> > > > 
> > > > Chee Hong Ang (1):
> > > >   ARMv8: Allow SiP service extensions on top of PSCI code
> > > Conceptually, I suppose this is a logical step.  In specifics,
> > > would
> > > we
> > > want to make this functionality opt-in, or no, that doesn't make
> > > sense?
> > > 
> > Allowing user to add platform specific service is part of SMC/PSCI
> > specification as specifed in ARM document (Table 2-1):
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN00
> > 28B_
> > SMC_Calling_Convention.pdf
> > 
> > So I think this functionality should be part of the standard
> > PSCI/SMC
> > implementation. Currently u-boot only support standard PSCI call
> > which
> > is:
> > ----------------------------------------------
> > > 
> > > 0x84000000-0x8400001F  | PSCI 32-bit calls |
> > > 0xC4000000-0xC400001F  | PSCI 64-bit calls |
> > ----------------------------------------------
> > 
> > My implementation do not affect or alter the behavior of any
> > existing
> > standard PSCI calls.
> > 
> > Users can simply add their own platform specific services by using
> > the
> > service call range as below:
> > ----------------------------------------------------
> > > 
> > > 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls |
> > > 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
> > ----------------------------------------------------
> > 
> > For complete service call ranges please refer to Table 6-2 in the
> > ARM
> > document.
> OK, thanks!
> 
Any chance this enhancement get accepted ? Thanks.

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Tom Rini]

On Wed, Mar 13, 2019 at 08:10:31AM +0000, Ang, Chee Hong wrote:
> On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> > On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
> > > 
> > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > > > 
> > > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang at intel.com
> > > > wrote:
> > > > 
> > > > > 
> > > > > 
> > > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > > 
> > > > > Currently u-boot only support standard PSCI functions for power
> > > > > management
> > > > > and lack of convenient method to allow the users to extend the
> > > > > PSCI
> > > > > functions
> > > > > to support platform specific services. Most of the u-boot users
> > > > > still rely
> > > > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > > > management and
> > > > > platform specific PSCI services.
> > > > > The purpose of this patchsets is to allow u-boot users to
> > > > > support
> > > > > their
> > > > > own platform specific secure SMC/PSCI services without making
> > > > > any
> > > > > SMC calls to ATF. This will benefit the users who need to use
> > > > > u-
> > > > > boot as the
> > > > > only bootloader and secure service provider without relying on
> > > > > ATF.
> > > > > 
> > > > > Below is a simple code example for adding your own PSCI
> > > > > functions:
> > > > > 
> > > > > #include <common.h>
> > > > > #include <errno.h>
> > > > > #include <asm/io.h>
> > > > > #include <asm/psci.h>
> > > > > #include <asm/secure.h>
> > > > > 
> > > > > #define PSCI_SMC64_FUNC_ID1	0xC2000001
> > > > > #define PSCI_SMC64_FUNC_ID2	0xC2000002
> > > > > 
> > > > > static void __secure psci_plat_specific_func1(unsigned long
> > > > > function_id)
> > > > > {
> > > > > 	/* Your code for handling the SMC/PSCI platform
> > > > > specific
> > > > > service 1 */
> > > > > }
> > > > > 
> > > > > static void __secure psci_plat_specific_func2(unsigned long
> > > > > function_id)
> > > > > {
> > > > > 	/* Your code for handling the SMC/PSCI platform
> > > > > specific
> > > > > service 2 */
> > > > > }
> > > > > 
> > > > > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> > > > > 		   psci_plat_specific_func1);
> > > > > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> > > > > 		   psci_plat_specific_func2);
> > > > > 
> > > > > Ang, Chee Hong (1):
> > > > >   ARMv8: Disable fwcall when PSCI is enabled
> > > > > 
> > > > > Chee Hong Ang (1):
> > > > >   ARMv8: Allow SiP service extensions on top of PSCI code
> > > > Conceptually, I suppose this is a logical step.  In specifics,
> > > > would
> > > > we
> > > > want to make this functionality opt-in, or no, that doesn't make
> > > > sense?
> > > > 
> > > Allowing user to add platform specific service is part of SMC/PSCI
> > > specification as specifed in ARM document (Table 2-1):
> > > http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN00
> > > 28B_
> > > SMC_Calling_Convention.pdf
> > > 
> > > So I think this functionality should be part of the standard
> > > PSCI/SMC
> > > implementation. Currently u-boot only support standard PSCI call
> > > which
> > > is:
> > > ----------------------------------------------
> > > > 
> > > > 0x84000000-0x8400001F  | PSCI 32-bit calls |
> > > > 0xC4000000-0xC400001F  | PSCI 64-bit calls |
> > > ----------------------------------------------
> > > 
> > > My implementation do not affect or alter the behavior of any
> > > existing
> > > standard PSCI calls.
> > > 
> > > Users can simply add their own platform specific services by using
> > > the
> > > service call range as below:
> > > ----------------------------------------------------
> > > > 
> > > > 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls |
> > > > 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
> > > ----------------------------------------------------
> > > 
> > > For complete service call ranges please refer to Table 6-2 in the
> > > ARM
> > > document.
> > OK, thanks!
> > 
> Any chance this enhancement get accepted ? Thanks.

After the current release, if there's no further comments.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190313/d6f2097e/attachment.sig>

[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI

[Ang, Chee Hong]

On Wed, 2019-03-13 at 12:01 -0400, Tom Rini wrote:
> On Wed, Mar 13, 2019 at 08:10:31AM +0000, Ang, Chee Hong wrote:
> > 
> > On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> > > 
> > > On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
> > > > 
> > > > 
> > > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > > > > 
> > > > > 
> > > > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang at intel
> > > > > .com
> > > > > wrote:
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > > > 
> > > > > > Currently u-boot only support standard PSCI functions for
> > > > > > power
> > > > > > management
> > > > > > and lack of convenient method to allow the users to extend
> > > > > > the
> > > > > > PSCI
> > > > > > functions
> > > > > > to support platform specific services. Most of the u-boot
> > > > > > users
> > > > > > still rely
> > > > > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > > > > management and
> > > > > > platform specific PSCI services.
> > > > > > The purpose of this patchsets is to allow u-boot users to
> > > > > > support
> > > > > > their
> > > > > > own platform specific secure SMC/PSCI services without
> > > > > > making
> > > > > > any
> > > > > > SMC calls to ATF. This will benefit the users who need to
> > > > > > use
> > > > > > u-
> > > > > > boot as the
> > > > > > only bootloader and secure service provider without relying
> > > > > > on
> > > > > > ATF.
> > > > > > 
> > > > > > Below is a simple code example for adding your own PSCI
> > > > > > functions:
> > > > > > 
> > > > > > #include <common.h>
> > > > > > #include <errno.h>
> > > > > > #include <asm/io.h>
> > > > > > #include <asm/psci.h>
> > > > > > #include <asm/secure.h>
> > > > > > 
> > > > > > #define PSCI_SMC64_FUNC_ID1	0xC2000001
> > > > > > #define PSCI_SMC64_FUNC_ID2	0xC2000002
> > > > > > 
> > > > > > static void __secure psci_plat_specific_func1(unsigned long
> > > > > > function_id)
> > > > > > {
> > > > > > 	/* Your code for handling the SMC/PSCI platform
> > > > > > specific
> > > > > > service 1 */
> > > > > > }
> > > > > > 
> > > > > > static void __secure psci_plat_specific_func2(unsigned long
> > > > > > function_id)
> > > > > > {
> > > > > > 	/* Your code for handling the SMC/PSCI platform
> > > > > > specific
> > > > > > service 2 */
> > > > > > }
> > > > > > 
> > > > > > DECLARE_SECURE_SVC(plat_specific_func1,
> > > > > > PSCI_SMC64_FUNC_ID1,
> > > > > > 		   psci_plat_specific_func1);
> > > > > > DECLARE_SECURE_SVC(plat_specific_func2,
> > > > > > PSCI_SMC64_FUNC_ID2,
> > > > > > 		   psci_plat_specific_func2);
> > > > > > 
> > > > > > Ang, Chee Hong (1):
> > > > > >   ARMv8: Disable fwcall when PSCI is enabled
> > > > > > 
> > > > > > Chee Hong Ang (1):
> > > > > >   ARMv8: Allow SiP service extensions on top of PSCI code
> > > > > Conceptually, I suppose this is a logical step.  In
> > > > > specifics,
> > > > > would
> > > > > we
> > > > > want to make this functionality opt-in, or no, that doesn't
> > > > > make
> > > > > sense?
> > > > > 
> > > > Allowing user to add platform specific service is part of
> > > > SMC/PSCI
> > > > specification as specifed in ARM document (Table 2-1):
> > > > http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_D
> > > > EN00
> > > > 28B_
> > > > SMC_Calling_Convention.pdf
> > > > 
> > > > So I think this functionality should be part of the standard
> > > > PSCI/SMC
> > > > implementation. Currently u-boot only support standard PSCI
> > > > call
> > > > which
> > > > is:
> > > > ----------------------------------------------
> > > > > 
> > > > > 
> > > > > 0x84000000-0x8400001F  | PSCI 32-bit calls |
> > > > > 0xC4000000-0xC400001F  | PSCI 64-bit calls |
> > > > ----------------------------------------------
> > > > 
> > > > My implementation do not affect or alter the behavior of any
> > > > existing
> > > > standard PSCI calls.
> > > > 
> > > > Users can simply add their own platform specific services by
> > > > using
> > > > the
> > > > service call range as below:
> > > > ----------------------------------------------------
> > > > > 
> > > > > 
> > > > > 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls |
> > > > > 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
> > > > ----------------------------------------------------
> > > > 
> > > > For complete service call ranges please refer to Table 6-2 in
> > > > the
> > > > ARM
> > > > document.
> > > OK, thanks!
> > > 
> > Any chance this enhancement get accepted ? Thanks.
> After the current release, if there's no further comments.
> 
Hi Tom,
Is this patch being merged into mainline ? Or you have any further
concern or comments ? Thanks.