[PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Alexandre Courbot]

Just a set of small fixes to address the concerns expressed on v9 with the
non-prefixed version DT properties. I hope there won't be a need for an
eleventh (!) version. :P

Changelog from v9:
- Renamed tl vendor prefix to tlm (for Trusted Logic Mobility)
- Prefixed version properties with "tlm,"
- Split the DT bindings patches as per new recommendations

Alexandre Courbot (7):
  ARM: add basic support for Trusted Foundations
  of: add vendor prefix for Trusted Logic Mobility
  of: add Trusted Foundations bindings
  ARM: tegra: add support for Trusted Foundations
  ARM: tegra: split setting of CPU reset handler
  ARM: tegra: set CPU reset handler with firmware op
  ARM: tegra: support Trusted Foundations by default

 .../arm/firmware/tlm,trusted-foundations.txt       | 20 ++++++
 Documentation/devicetree/bindings/arm/tegra.txt    |  5 ++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 arch/arm/Kconfig                                   |  2 +
 arch/arm/Makefile                                  |  1 +
 arch/arm/configs/tegra_defconfig                   |  1 +
 arch/arm/firmware/Kconfig                          | 28 ++++++++
 arch/arm/firmware/Makefile                         |  1 +
 arch/arm/firmware/trusted_foundations.c            | 81 ++++++++++++++++++++++
 arch/arm/include/asm/trusted_foundations.h         | 67 ++++++++++++++++++
 arch/arm/mach-tegra/Kconfig                        |  1 +
 arch/arm/mach-tegra/common.c                       |  2 +
 arch/arm/mach-tegra/reset.c                        | 40 ++++++++---
 13 files changed, 239 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt
 create mode 100644 arch/arm/firmware/Kconfig
 create mode 100644 arch/arm/firmware/Makefile
 create mode 100644 arch/arm/firmware/trusted_foundations.c
 create mode 100644 arch/arm/include/asm/trusted_foundations.h

-- 
1.8.4.2

[PATCH v10 1/7] ARM: add basic support for Trusted Foundations

[Alexandre Courbot]

Trusted Foundations is a TrustZone-based secure monitor for ARM that
can be invoked using the same SMC-based API on all supported
platforms. This patch adds initial basic support for Trusted
Foundations using the ARM firmware API. Current features are limited
to the ability to boot secondary processors.

Note: The API followed by Trusted Foundations does *not* follow the SMC
calling conventions. It has nothing to do with PSCI neither and is only
relevant to devices that use Trusted Foundations (like most Tegra-based
retail devices).

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/Kconfig                           |  2 +
 arch/arm/Makefile                          |  1 +
 arch/arm/firmware/Kconfig                  | 28 +++++++++++
 arch/arm/firmware/Makefile                 |  1 +
 arch/arm/firmware/trusted_foundations.c    | 81 ++++++++++++++++++++++++++++++
 arch/arm/include/asm/trusted_foundations.h | 67 ++++++++++++++++++++++++
 6 files changed, 180 insertions(+)
 create mode 100644 arch/arm/firmware/Kconfig
 create mode 100644 arch/arm/firmware/Makefile
 create mode 100644 arch/arm/firmware/trusted_foundations.c
 create mode 100644 arch/arm/include/asm/trusted_foundations.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1ad6fb6c094d..bf14cec7777c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1076,6 +1076,8 @@ config ARM_TIMER_SP804
 	select CLKSRC_MMIO
 	select CLKSRC_OF if OF
 
+source "arch/arm/firmware/Kconfig"
+
 source arch/arm/mm/Kconfig
 
 config ARM_NR_BANKS
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index db50b626be98..f9a8e93a9ee2 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -268,6 +268,7 @@ core-$(CONFIG_KVM_ARM_HOST) 	+= arch/arm/kvm/
 core-y				+= arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
 core-y				+= arch/arm/net/
 core-y				+= arch/arm/crypto/
+core-y				+= arch/arm/firmware/
 core-y				+= $(machdirs) $(platdirs)
 
 drivers-$(CONFIG_OPROFILE)      += arch/arm/oprofile/
diff --git a/arch/arm/firmware/Kconfig b/arch/arm/firmware/Kconfig
new file mode 100644
index 000000000000..bb00ccf00d66
--- /dev/null
+++ b/arch/arm/firmware/Kconfig
@@ -0,0 +1,28 @@
+config ARCH_SUPPORTS_FIRMWARE
+	bool
+
+config ARCH_SUPPORTS_TRUSTED_FOUNDATIONS
+	bool
+	select ARCH_SUPPORTS_FIRMWARE
+
+menu "Firmware options"
+	depends on ARCH_SUPPORTS_FIRMWARE
+
+config TRUSTED_FOUNDATIONS
+	bool "Trusted Foundations secure monitor support"
+	depends on ARCH_SUPPORTS_TRUSTED_FOUNDATIONS
+	help
+	  Some devices (including most Tegra-based consumer devices on the
+	  market) are booted with the Trusted Foundations secure monitor
+	  active, requiring some core operations to be performed by the secure
+	  monitor instead of the kernel.
+
+	  This option allows the kernel to invoke the secure monitor whenever
+	  required on devices using Trusted Foundations. See
+	  arch/arm/include/asm/trusted_foundations.h or the
+	  tl,trusted-foundations device tree binding documentation for details
+	  on how to use it.
+
+	  Say n if you don't know what this is about.
+
+endmenu
diff --git a/arch/arm/firmware/Makefile b/arch/arm/firmware/Makefile
new file mode 100644
index 000000000000..a71f16536b6c
--- /dev/null
+++ b/arch/arm/firmware/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TRUSTED_FOUNDATIONS)	+= trusted_foundations.o
diff --git a/arch/arm/firmware/trusted_foundations.c b/arch/arm/firmware/trusted_foundations.c
new file mode 100644
index 000000000000..ef1e3d8f4af0
--- /dev/null
+++ b/arch/arm/firmware/trusted_foundations.c
@@ -0,0 +1,81 @@
+/*
+ * Trusted Foundations support for ARM CPUs
+ *
+ * Copyright (c) 2013, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/of.h>
+#include <asm/firmware.h>
+#include <asm/trusted_foundations.h>
+
+#define TF_SET_CPU_BOOT_ADDR_SMC 0xfffff200
+
+static void __naked tf_generic_smc(u32 type, u32 arg1, u32 arg2)
+{
+	asm volatile(
+		".arch_extension	sec\n\t"
+		"stmfd	sp!, {r4 - r11, lr}\n\t"
+		__asmeq("%0", "r0")
+		__asmeq("%1", "r1")
+		__asmeq("%2", "r2")
+		"mov	r3, #0\n\t"
+		"mov	r4, #0\n\t"
+		"smc	#0\n\t"
+		"ldmfd	sp!, {r4 - r11, pc}"
+		:
+		: "r" (type), "r" (arg1), "r" (arg2)
+		: "memory");
+}
+
+static int tf_set_cpu_boot_addr(int cpu, unsigned long boot_addr)
+{
+	tf_generic_smc(TF_SET_CPU_BOOT_ADDR_SMC, boot_addr, 0);
+
+	return 0;
+}
+
+static const struct firmware_ops trusted_foundations_ops = {
+	.set_cpu_boot_addr = tf_set_cpu_boot_addr,
+};
+
+void register_trusted_foundations(struct trusted_foundations_platform_data *pd)
+{
+	/*
+	 * we are not using version information for now since currently
+	 * supported SMCs are compatible with all TF releases
+	 */
+	register_firmware_ops(&trusted_foundations_ops);
+}
+
+void of_register_trusted_foundations(void)
+{
+	struct device_node *node;
+	struct trusted_foundations_platform_data pdata;
+	int err;
+
+	node = of_find_compatible_node(NULL, NULL, "tlm,trusted-foundations");
+	if (!node)
+		return;
+
+	err = of_property_read_u32(node, "tlm,version-major",
+				   &pdata.version_major);
+	if (err != 0)
+		panic("Trusted Foundation: missing version-major property\n");
+	err = of_property_read_u32(node, "tlm,version-minor",
+				   &pdata.version_minor);
+	if (err != 0)
+		panic("Trusted Foundation: missing version-minor property\n");
+	register_trusted_foundations(&pdata);
+}
diff --git a/arch/arm/include/asm/trusted_foundations.h b/arch/arm/include/asm/trusted_foundations.h
new file mode 100644
index 000000000000..3bd36e2c5f2e
--- /dev/null
+++ b/arch/arm/include/asm/trusted_foundations.h
@@ -0,0 +1,67 @@
+/*
+ * Copyright (c) 2013, NVIDIA Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+/*
+ * Support for the Trusted Foundations secure monitor.
+ *
+ * Trusted Foundation comes active on some ARM consumer devices (most
+ * Tegra-based devices sold on the market are concerned). Such devices can only
+ * perform some basic operations, like setting the CPU reset vector, through
+ * SMC calls to the secure monitor. The calls are completely specific to
+ * Trusted Foundations, and do *not* follow the SMC calling convention or the
+ * PSCI standard.
+ */
+
+#ifndef __ASM_ARM_TRUSTED_FOUNDATIONS_H
+#define __ASM_ARM_TRUSTED_FOUNDATIONS_H
+
+#include <linux/kconfig.h>
+#include <linux/printk.h>
+#include <linux/bug.h>
+#include <linux/of.h>
+
+struct trusted_foundations_platform_data {
+	unsigned int version_major;
+	unsigned int version_minor;
+};
+
+#if IS_ENABLED(CONFIG_TRUSTED_FOUNDATIONS)
+
+void register_trusted_foundations(struct trusted_foundations_platform_data *pd);
+void of_register_trusted_foundations(void);
+
+#else /* CONFIG_TRUSTED_FOUNDATIONS */
+
+static inline void register_trusted_foundations(
+				   struct trusted_foundations_platform_data *pd)
+{
+	/*
+	 * If we try to register TF, this means the system needs it to continue.
+	 * Its absence if thus a fatal error.
+	 */
+	panic("No support for Trusted Foundations, stopping...\n");
+}
+
+static inline void of_register_trusted_foundations(void)
+{
+	/*
+	 * If we find the target should enable TF but does not support it,
+	 * fail as the system won't be able to do much anyway
+	 */
+	if (of_find_compatible_node(NULL, NULL, "tl,trusted-foundations"))
+		register_trusted_foundations(NULL);
+}
+#endif /* CONFIG_TRUSTED_FOUNDATIONS */
+
+#endif
-- 
1.8.4.2

[PATCH v10 2/7] of: add vendor prefix for Trusted Logic Mobility

[Alexandre Courbot]

Add the "tlm" prefix for Trusted Logic Mobility.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 2956800f0240..d4d42aa9f2fa 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -66,6 +66,7 @@ ste	ST-Ericsson
 stericsson	ST-Ericsson
 toumaz	Toumaz
 ti	Texas Instruments
+tlm	Trusted Logic Mobility
 toshiba	Toshiba Corporation
 v3	V3 Semiconductor
 via	VIA Technologies, Inc.
-- 
1.8.4.2

[PATCH v10 3/7] of: add Trusted Foundations bindings

[Alexandre Courbot]

Add the Device Tree bindings for the Trusted Foundation secure monitor.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 .../arm/firmware/tlm,trusted-foundations.txt         | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt

diff --git a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt
new file mode 100644
index 000000000000..adb471c3d2dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt
@@ -0,0 +1,20 @@
+Trusted Foundations
+-------------------
+
+Boards that use the Trusted Foundations secure monitor can signal its
+presence by declaring a node compatible with "tlm,trusted-foundations"
+under the /firmware/ node
+
+Required properties:
+- compatible : "tlm,trusted-foundations"
+- tlm,version-major : major version number of Trusted Foundations firmware
+- tlm,version-minor: minor version number of Trusted Foundations firmware
+
+Example:
+	firmware {
+		trusted-foundations {
+			compatible = "tlm,trusted-foundations";
+			tlm,version-major = <2>;
+			tlm,version-minor = <8>;
+		};
+	};
-- 
1.8.4.2

[PATCH v10 4/7] ARM: tegra: add support for Trusted Foundations

[Alexandre Courbot]

Register the firmware operations for Trusted Foundations if the device
tree indicates it is active on the device.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
---
 Documentation/devicetree/bindings/arm/tegra.txt | 5 +++++
 arch/arm/mach-tegra/Kconfig                     | 1 +
 arch/arm/mach-tegra/common.c                    | 2 ++
 3 files changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt
index ed9c85334436..558ed4b4ef39 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -32,3 +32,8 @@ board-specific compatible values:
   nvidia,whistler
   toradex,colibri_t20-512
   toradex,iris
+
+Trusted Foundations
+-------------------------------------------
+Tegra supports the Trusted Foundation secure monitor. See the
+"tlm,trusted-foundations" binding's documentation for more details.
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 67a76f2dfb9f..4e512782ea23 100644
--- a/arch/arm/mach-tegra/Kconfig
+++ b/arch/arm/mach-tegra/Kconfig
@@ -2,6 +2,7 @@ config ARCH_TEGRA
 	bool "NVIDIA Tegra" if ARCH_MULTI_V7
 	select ARCH_HAS_CPUFREQ
 	select ARCH_REQUIRE_GPIOLIB
+	select ARCH_SUPPORTS_TRUSTED_FOUNDATIONS
 	select ARM_GIC
 	select CLKDEV_LOOKUP
 	select CLKSRC_MMIO
diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
index 94a119a35af8..b405e4594cb5 100644
--- a/arch/arm/mach-tegra/common.c
+++ b/arch/arm/mach-tegra/common.c
@@ -27,6 +27,7 @@
 #include <linux/clk-provider.h>
 
 #include <asm/hardware/cache-l2x0.h>
+#include <asm/trusted_foundations.h>
 
 #include "board.h"
 #include "common.h"
@@ -99,6 +100,7 @@ static void __init tegra_init_cache(void)
 
 void __init tegra_init_early(void)
 {
+	of_register_trusted_foundations();
 	tegra_cpu_reset_handler_init();
 	tegra_apb_io_init();
 	tegra_init_fuse();
-- 
1.8.4.2

Re: [PATCH v10 4/7] ARM: tegra: add support for Trusted Foundations

[Stephen Warren]

On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
> Register the firmware operations for Trusted Foundations if the device
> tree indicates it is active on the device.

> diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c

>  void __init tegra_init_early(void)
>  {
> +	of_register_trusted_foundations();
>  	tegra_cpu_reset_handler_init();
>  	tegra_apb_io_init();
>  	tegra_init_fuse();

Your other bugfix patch for 3.13 moved tegra_cpu_reset_handler_init().
Should the call to of_register_trusted_foundations() move with it when
this is applied, or should it just stay right at the start of
tegra_init_early()? Either way is fine; just let me know which way to
fix up the conflict when this gets applied.

Re: [PATCH v10 4/7] ARM: tegra: add support for Trusted Foundations

[Alex Courbot]

On 11/13/2013 05:23 AM, Stephen Warren wrote:
> On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
>> Register the firmware operations for Trusted Foundations if the device
>> tree indicates it is active on the device.
>
>> diff --git a/arch/arm/mach-tegra/common.c b/arch/arm/mach-tegra/common.c
>
>>   void __init tegra_init_early(void)
>>   {
>> +	of_register_trusted_foundations();
>>   	tegra_cpu_reset_handler_init();
>>   	tegra_apb_io_init();
>>   	tegra_init_fuse();
>
> Your other bugfix patch for 3.13 moved tegra_cpu_reset_handler_init().
> Should the call to of_register_trusted_foundations() move with it when
> this is applied, or should it just stay right at the start of
> tegra_init_early()? Either way is fine; just let me know which way to
> fix up the conflict when this gets applied.

I rebased on -next and left it at the start of tegra_init_early(). Even 
though at the moment the only requirement is that the call is made 
before tegra_cpu_reset_handler_init(), it seems to make sense to get rid 
of firmware-related initialization as early as possible.

Btw, this patchset is still based on the 3.12 code, before common.c got 
renamed to tegra.c, so you will have a problem here as well (sorry about 
that). The conflict is easy to resolve, but if you want me to send you a 
properly rebased version, just let me know.

[PATCH v10 5/7] ARM: tegra: split setting of CPU reset handler

[Alexandre Courbot]

Not all Tegra devices can set the CPU reset handler in the same way.
In particular, devices using a TrustZone secure monitor cannot set the
reset handler directly and need to do it through a firmware operation.

This patch separates the act of setting the reset handler from its
preparation, so the former can be implemented in a different way.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/mach-tegra/reset.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index fd0bbf8a6c94..e282395b071c 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -33,26 +33,18 @@
 
 static bool is_enabled;
 
-static void __init tegra_cpu_reset_handler_enable(void)
+static void __init tegra_cpu_reset_handler_set(const u32 reset_address)
 {
-	void __iomem *iram_base = IO_ADDRESS(TEGRA_IRAM_RESET_BASE);
 	void __iomem *evp_cpu_reset =
 		IO_ADDRESS(TEGRA_EXCEPTION_VECTORS_BASE + 0x100);
 	void __iomem *sb_ctrl = IO_ADDRESS(TEGRA_SB_BASE);
 	u32 reg;
 
-	BUG_ON(is_enabled);
-	BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE);
-
-	memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start,
-			tegra_cpu_reset_handler_size);
-
 	/*
 	 * NOTE: This must be the one and only write to the EVP CPU reset
 	 *       vector in the entire system.
 	 */
-	writel(TEGRA_IRAM_RESET_BASE + tegra_cpu_reset_handler_offset,
-			evp_cpu_reset);
+	writel(reset_address, evp_cpu_reset);
 	wmb();
 	reg = readl(evp_cpu_reset);
 
@@ -66,6 +58,21 @@ static void __init tegra_cpu_reset_handler_enable(void)
 		writel(reg, sb_ctrl);
 		wmb();
 	}
+}
+
+static void __init tegra_cpu_reset_handler_enable(void)
+{
+	void __iomem *iram_base = IO_ADDRESS(TEGRA_IRAM_RESET_BASE);
+	const u32 reset_address = TEGRA_IRAM_RESET_BASE +
+						tegra_cpu_reset_handler_offset;
+
+	BUG_ON(is_enabled);
+	BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE);
+
+	memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start,
+			tegra_cpu_reset_handler_size);
+
+	tegra_cpu_reset_handler_set(reset_address);
 
 	is_enabled = true;
 }
-- 
1.8.4.2

[PATCH v10 6/7] ARM: tegra: set CPU reset handler with firmware op

[Alexandre Courbot]

Use a firmware operation to set the CPU reset handler and only resort to
doing it ourselves if there is none defined.

This supports the booting of secondary CPUs on devices using a TrustZone
secure monitor.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/mach-tegra/reset.c | 17 ++++++++++++++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-tegra/reset.c b/arch/arm/mach-tegra/reset.c
index e282395b071c..368af0afde46 100644
--- a/arch/arm/mach-tegra/reset.c
+++ b/arch/arm/mach-tegra/reset.c
@@ -21,6 +21,7 @@
 
 #include <asm/cacheflush.h>
 #include <asm/hardware/cache-l2x0.h>
+#include <asm/firmware.h>
 
 #include "iomap.h"
 #include "irammap.h"
@@ -65,6 +66,7 @@ static void __init tegra_cpu_reset_handler_enable(void)
 	void __iomem *iram_base = IO_ADDRESS(TEGRA_IRAM_RESET_BASE);
 	const u32 reset_address = TEGRA_IRAM_RESET_BASE +
 						tegra_cpu_reset_handler_offset;
+	int err;
 
 	BUG_ON(is_enabled);
 	BUG_ON(tegra_cpu_reset_handler_size > TEGRA_IRAM_RESET_HANDLER_SIZE);
@@ -72,9 +74,18 @@ static void __init tegra_cpu_reset_handler_enable(void)
 	memcpy(iram_base, (void *)__tegra_cpu_reset_handler_start,
 			tegra_cpu_reset_handler_size);
 
-	tegra_cpu_reset_handler_set(reset_address);
-
-	is_enabled = true;
+	err = call_firmware_op(set_cpu_boot_addr, 0, reset_address);
+	switch (err) {
+	case -ENOSYS:
+		tegra_cpu_reset_handler_set(reset_address);
+		/* pass-through */
+	case 0:
+		is_enabled = true;
+		break;
+	default:
+		pr_crit("Cannot set CPU reset handler: %d\n", err);
+		BUG();
+	}
 }
 
 void __init tegra_cpu_reset_handler_init(void)
-- 
1.8.4.2

[PATCH v10 7/7] ARM: tegra: support Trusted Foundations by default

[Alexandre Courbot]

Support for Trusted Foundations is light and allows the kernel to run on
a wider range of devices, so enable it by default.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/configs/tegra_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index ea042e80e54d..dddb97b06b79 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -32,6 +32,7 @@ CONFIG_PCI=y
 CONFIG_PCI_MSI=y
 CONFIG_PCI_TEGRA=y
 CONFIG_PCIEPORTBUS=y
+CONFIG_TRUSTED_FOUNDATIONS=y
 CONFIG_SMP=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
-- 
1.8.4.2

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Stephen Warren]

On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
> Just a set of small fixes to address the concerns expressed on v9 with the
> non-prefixed version DT properties. I hope there won't be a need for an
> eleventh (!) version. :P

BTW, this version looks fine to me. On IRC, Olof said it looked OK to
him. I'm just waiting to hear back from Olof/Russell whether I should
merge this through the Tegra tree, or whether the first 1-3 patches
should go through Russell's tree.

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Olof Johansson]

On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
>> Just a set of small fixes to address the concerns expressed on v9 with the
>> non-prefixed version DT properties. I hope there won't be a need for an
>> eleventh (!) version. :P
>
> BTW, this version looks fine to me. On IRC, Olof said it looked OK to
> him. I'm just waiting to hear back from Olof/Russell whether I should
> merge this through the Tegra tree, or whether the first 1-3 patches
> should go through Russell's tree.

I pinged Russell, and he brought up the fact that there were earlier
requests to move it to drivers/firmware. It would make sense to try to
get that done before merging, especially if you anticipate someone
using TF on 64-bit platforms.


-Olof

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Alex Courbot]

On 11/13/2013 05:38 AM, Olof Johansson wrote:
> On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
>>> Just a set of small fixes to address the concerns expressed on v9 with the
>>> non-prefixed version DT properties. I hope there won't be a need for an
>>> eleventh (!) version. :P
>>
>> BTW, this version looks fine to me. On IRC, Olof said it looked OK to
>> him. I'm just waiting to hear back from Olof/Russell whether I should
>> merge this through the Tegra tree, or whether the first 1-3 patches
>> should go through Russell's tree.
>
> I pinged Russell, and he brought up the fact that there were earlier
> requests to move it to drivers/firmware. It would make sense to try to
> get that done before merging, especially if you anticipate someone
> using TF on 64-bit platforms.

IIRC when we discussed this point your last comment was as follows:

On Tue, Oct 29, 2013 at 6:55 AM, Olof Johansson <olof@lixom.net> wrote:
 > I think we can probably merge this under arch/arm now, and when we
 > figure out what needs to be common with ARM64 we can move it out to a
 > good location. It might be that mostly just a header file with ABI
 > conventions needs to be shared, not actual implementation, for
 > example.

So I thought we agreed on that. If in the end we prefer to move the ARM 
firmware interface into drivers/firmware, I'm fine with that too (Tomasz 
also confirmed he would be ok with it) but I wonder if that would not be 
somehow premature.

Another worry of mine is that this might delay this patchset some more. 
Support for TF is one of the last remaining step towards making NVIDIA 
branded Tegra retail devices (SHIELD and TegraNote at the moment) run 
upstream directly. I missed 3.13, I'd like to make sure I won't miss 
3.14. Would it be acceptable if we move the ARM firmware interface to a 
common place after this patchset is merged?

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Olof Johansson]

On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot <acourbot@nvidia.com> wrote:
> On 11/13/2013 05:38 AM, Olof Johansson wrote:
>>
>> On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren <swarren@wwwdotorg.org>
>> wrote:
>>>
>>> On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
>>>>
>>>> Just a set of small fixes to address the concerns expressed on v9 with
>>>> the
>>>> non-prefixed version DT properties. I hope there won't be a need for an
>>>> eleventh (!) version. :P
>>>
>>>
>>> BTW, this version looks fine to me. On IRC, Olof said it looked OK to
>>> him. I'm just waiting to hear back from Olof/Russell whether I should
>>> merge this through the Tegra tree, or whether the first 1-3 patches
>>> should go through Russell's tree.
>>
>>
>> I pinged Russell, and he brought up the fact that there were earlier
>> requests to move it to drivers/firmware. It would make sense to try to
>> get that done before merging, especially if you anticipate someone
>> using TF on 64-bit platforms.
>
>
> IIRC when we discussed this point your last comment was as follows:

Touche. :) Thanks for the reminder.

> On Tue, Oct 29, 2013 at 6:55 AM, Olof Johansson <olof@lixom.net> wrote:
>> I think we can probably merge this under arch/arm now, and when we
>> figure out what needs to be common with ARM64 we can move it out to a
>> good location. It might be that mostly just a header file with ABI
>> conventions needs to be shared, not actual implementation, for
>> example.
>
> So I thought we agreed on that. If in the end we prefer to move the ARM
> firmware interface into drivers/firmware, I'm fine with that too (Tomasz
> also confirmed he would be ok with it) but I wonder if that would not be
> somehow premature.
>
> Another worry of mine is that this might delay this patchset some more.
> Support for TF is one of the last remaining step towards making NVIDIA
> branded Tegra retail devices (SHIELD and TegraNote at the moment) run
> upstream directly. I missed 3.13, I'd like to make sure I won't miss 3.14.
> Would it be acceptable if we move the ARM firmware interface to a common
> place after this patchset is merged?

Well, as I already said I'm ok with things going into arch/arm to
start with, as long as Russell is. Once we see 64-bit needs for the
same we'll move it out -- it's not like it's a whole lot of code to
start with. But Russell has veto on the topic. :-)

Russell still has his pull requests outstanding so I'm not sure where
things are at, but I don't think this will miss 3.14 at this rate.


-Olof

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Alex Courbot]

On 11/14/2013 02:57 AM, Olof Johansson wrote:
> On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot <acourbot@nvidia.com> wrote:
>> On 11/13/2013 05:38 AM, Olof Johansson wrote:
>>>
>>> On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren <swarren@wwwdotorg.org>
>>> wrote:
>>>>
>>>> On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
>>>>>
>>>>> Just a set of small fixes to address the concerns expressed on v9 with
>>>>> the
>>>>> non-prefixed version DT properties. I hope there won't be a need for an
>>>>> eleventh (!) version. :P
>>>>
>>>>
>>>> BTW, this version looks fine to me. On IRC, Olof said it looked OK to
>>>> him. I'm just waiting to hear back from Olof/Russell whether I should
>>>> merge this through the Tegra tree, or whether the first 1-3 patches
>>>> should go through Russell's tree.
>>>
>>>
>>> I pinged Russell, and he brought up the fact that there were earlier
>>> requests to move it to drivers/firmware. It would make sense to try to
>>> get that done before merging, especially if you anticipate someone
>>> using TF on 64-bit platforms.
>>
>>
>> IIRC when we discussed this point your last comment was as follows:
>
> Touche. :) Thanks for the reminder.
>
>> On Tue, Oct 29, 2013 at 6:55 AM, Olof Johansson <olof@lixom.net> wrote:
>>> I think we can probably merge this under arch/arm now, and when we
>>> figure out what needs to be common with ARM64 we can move it out to a
>>> good location. It might be that mostly just a header file with ABI
>>> conventions needs to be shared, not actual implementation, for
>>> example.
>>
>> So I thought we agreed on that. If in the end we prefer to move the ARM
>> firmware interface into drivers/firmware, I'm fine with that too (Tomasz
>> also confirmed he would be ok with it) but I wonder if that would not be
>> somehow premature.
>>
>> Another worry of mine is that this might delay this patchset some more.
>> Support for TF is one of the last remaining step towards making NVIDIA
>> branded Tegra retail devices (SHIELD and TegraNote at the moment) run
>> upstream directly. I missed 3.13, I'd like to make sure I won't miss 3.14.
>> Would it be acceptable if we move the ARM firmware interface to a common
>> place after this patchset is merged?
>
> Well, as I already said I'm ok with things going into arch/arm to
> start with, as long as Russell is. Once we see 64-bit needs for the
> same we'll move it out -- it's not like it's a whole lot of code to
> start with. But Russell has veto on the topic. :-)

Thanks Olof. Russell, are you ok with the patchset in its current form? 
I can start moving the firmware interface out of arch/arm if that's what 
you want (there is no user outside of ARM at the moment, but as Olof 
pointed out that's not too much code) but I'd really like to see this 
series secured for 3.14.

Thanks,
Alex.

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Alexandre Courbot]

On Thu, Nov 14, 2013 at 10:20 AM, Alex Courbot <acourbot@nvidia.com> wrote:
> On 11/14/2013 02:57 AM, Olof Johansson wrote:
>>
>> On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot <acourbot@nvidia.com> wrote:
>>>
>>> On 11/13/2013 05:38 AM, Olof Johansson wrote:
>>>>
>>>>
>>>> On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren <swarren@wwwdotorg.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
>>>>>>
>>>>>>
>>>>>> Just a set of small fixes to address the concerns expressed on v9 with
>>>>>> the
>>>>>> non-prefixed version DT properties. I hope there won't be a need for
>>>>>> an
>>>>>> eleventh (!) version. :P
>>>>>
>>>>>
>>>>>
>>>>> BTW, this version looks fine to me. On IRC, Olof said it looked OK to
>>>>> him. I'm just waiting to hear back from Olof/Russell whether I should
>>>>> merge this through the Tegra tree, or whether the first 1-3 patches
>>>>> should go through Russell's tree.
>>>>
>>>>
>>>>
>>>> I pinged Russell, and he brought up the fact that there were earlier
>>>> requests to move it to drivers/firmware. It would make sense to try to
>>>> get that done before merging, especially if you anticipate someone
>>>> using TF on 64-bit platforms.
>>>
>>>
>>>
>>> IIRC when we discussed this point your last comment was as follows:
>>
>>
>> Touche. :) Thanks for the reminder.
>>
>>> On Tue, Oct 29, 2013 at 6:55 AM, Olof Johansson <olof@lixom.net> wrote:
>>>>
>>>> I think we can probably merge this under arch/arm now, and when we
>>>> figure out what needs to be common with ARM64 we can move it out to a
>>>> good location. It might be that mostly just a header file with ABI
>>>> conventions needs to be shared, not actual implementation, for
>>>> example.
>>>
>>>
>>> So I thought we agreed on that. If in the end we prefer to move the ARM
>>> firmware interface into drivers/firmware, I'm fine with that too (Tomasz
>>> also confirmed he would be ok with it) but I wonder if that would not be
>>> somehow premature.
>>>
>>> Another worry of mine is that this might delay this patchset some more.
>>> Support for TF is one of the last remaining step towards making NVIDIA
>>> branded Tegra retail devices (SHIELD and TegraNote at the moment) run
>>> upstream directly. I missed 3.13, I'd like to make sure I won't miss
>>> 3.14.
>>> Would it be acceptable if we move the ARM firmware interface to a common
>>> place after this patchset is merged?
>>
>>
>> Well, as I already said I'm ok with things going into arch/arm to
>> start with, as long as Russell is. Once we see 64-bit needs for the
>> same we'll move it out -- it's not like it's a whole lot of code to
>> start with. But Russell has veto on the topic. :-)
>
>
> Thanks Olof. Russell, are you ok with the patchset in its current form? I
> can start moving the firmware interface out of arch/arm if that's what you
> want (there is no user outside of ARM at the moment, but as Olof pointed out
> that's not too much code) but I'd really like to see this series secured for
> 3.14.

Never mind, I have submitted a patch that moves firmware_ops to
drivers/firmware, that will hopefully settle this issue. Then maybe we
can finally flush this series as well (I will need to resubmit a new
version though).

Alex.

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Alex Courbot]

On 11/17/2013 06:03 PM, Alexandre Courbot wrote:
> On Thu, Nov 14, 2013 at 10:20 AM, Alex Courbot <acourbot@nvidia.com> wrote:
>> On 11/14/2013 02:57 AM, Olof Johansson wrote:
>>>
>>> On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot <acourbot@nvidia.com> wrote:
>>>>
>>>> On 11/13/2013 05:38 AM, Olof Johansson wrote:
>>>>>
>>>>>
>>>>> On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren <swarren@wwwdotorg.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
>>>>>>>
>>>>>>>
>>>>>>> Just a set of small fixes to address the concerns expressed on v9 with
>>>>>>> the
>>>>>>> non-prefixed version DT properties. I hope there won't be a need for
>>>>>>> an
>>>>>>> eleventh (!) version. :P
>>>>>>
>>>>>>
>>>>>>
>>>>>> BTW, this version looks fine to me. On IRC, Olof said it looked OK to
>>>>>> him. I'm just waiting to hear back from Olof/Russell whether I should
>>>>>> merge this through the Tegra tree, or whether the first 1-3 patches
>>>>>> should go through Russell's tree.
>>>>>
>>>>>
>>>>>
>>>>> I pinged Russell, and he brought up the fact that there were earlier
>>>>> requests to move it to drivers/firmware. It would make sense to try to
>>>>> get that done before merging, especially if you anticipate someone
>>>>> using TF on 64-bit platforms.
>>>>
>>>>
>>>>
>>>> IIRC when we discussed this point your last comment was as follows:
>>>
>>>
>>> Touche. :) Thanks for the reminder.
>>>
>>>> On Tue, Oct 29, 2013 at 6:55 AM, Olof Johansson <olof@lixom.net> wrote:
>>>>>
>>>>> I think we can probably merge this under arch/arm now, and when we
>>>>> figure out what needs to be common with ARM64 we can move it out to a
>>>>> good location. It might be that mostly just a header file with ABI
>>>>> conventions needs to be shared, not actual implementation, for
>>>>> example.
>>>>
>>>>
>>>> So I thought we agreed on that. If in the end we prefer to move the ARM
>>>> firmware interface into drivers/firmware, I'm fine with that too (Tomasz
>>>> also confirmed he would be ok with it) but I wonder if that would not be
>>>> somehow premature.
>>>>
>>>> Another worry of mine is that this might delay this patchset some more.
>>>> Support for TF is one of the last remaining step towards making NVIDIA
>>>> branded Tegra retail devices (SHIELD and TegraNote at the moment) run
>>>> upstream directly. I missed 3.13, I'd like to make sure I won't miss
>>>> 3.14.
>>>> Would it be acceptable if we move the ARM firmware interface to a common
>>>> place after this patchset is merged?
>>>
>>>
>>> Well, as I already said I'm ok with things going into arch/arm to
>>> start with, as long as Russell is. Once we see 64-bit needs for the
>>> same we'll move it out -- it's not like it's a whole lot of code to
>>> start with. But Russell has veto on the topic. :-)
>>
>>
>> Thanks Olof. Russell, are you ok with the patchset in its current form? I
>> can start moving the firmware interface out of arch/arm if that's what you
>> want (there is no user outside of ARM at the moment, but as Olof pointed out
>> that's not too much code) but I'd really like to see this series secured for
>> 3.14.
>
> Never mind, I have submitted a patch that moves firmware_ops to
> drivers/firmware, that will hopefully settle this issue. Then maybe we
> can finally flush this series as well (I will need to resubmit a new
> version though).

... and that patch is very likely to not make it, for (I think) valid 
reasons. Thus I'm not quite sure where we are with this series now.

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Stephen Warren]

(Russell, a question for you at the bottom)

On 11/13/2013 10:57 AM, Olof Johansson wrote:
> On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot <acourbot@nvidia.com> wrote:
>> On 11/13/2013 05:38 AM, Olof Johansson wrote:
...
>>> I pinged Russell, and he brought up the fact that there were earlier
>>> requests to move it to drivers/firmware. It would make sense to try to
>>> get that done before merging, especially if you anticipate someone
>>> using TF on 64-bit platforms.
>>
>> IIRC when we discussed this point your last comment was as follows:
> 
> Touche. :) Thanks for the reminder.
> 
>> On Tue, Oct 29, 2013 at 6:55 AM, Olof Johansson <olof@lixom.net> wrote:
>>> I think we can probably merge this under arch/arm now, and when we
>>> figure out what needs to be common with ARM64 we can move it out to a
>>> good location. It might be that mostly just a header file with ABI
>>> conventions needs to be shared, not actual implementation, for
>>> example.
>>
>> So I thought we agreed on that. If in the end we prefer to move the ARM
>> firmware interface into drivers/firmware, I'm fine with that too (Tomasz
>> also confirmed he would be ok with it) but I wonder if that would not be
>> somehow premature.
...
> Well, as I already said I'm ok with things going into arch/arm to
> start with, as long as Russell is.
...

Russell, the patch Alex sent to move firmware_ops into drivers/firmware
was rejected, so I don't think we can update this series to move the
code there instead.

So, are you OK with merging this series as-is, in arch/arm/firmware? If
you could ack the patch/series to indicate that, it would be awesome.
Thanks.

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Olof Johansson]

On Thu, Nov 21, 2013 at 10:48 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> (Russell, a question for you at the bottom)
>
> On 11/13/2013 10:57 AM, Olof Johansson wrote:
>> On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot <acourbot@nvidia.com> wrote:
>>> On 11/13/2013 05:38 AM, Olof Johansson wrote:
> ...
>>>> I pinged Russell, and he brought up the fact that there were earlier
>>>> requests to move it to drivers/firmware. It would make sense to try to
>>>> get that done before merging, especially if you anticipate someone
>>>> using TF on 64-bit platforms.
>>>
>>> IIRC when we discussed this point your last comment was as follows:
>>
>> Touche. :) Thanks for the reminder.
>>
>>> On Tue, Oct 29, 2013 at 6:55 AM, Olof Johansson <olof@lixom.net> wrote:
>>>> I think we can probably merge this under arch/arm now, and when we
>>>> figure out what needs to be common with ARM64 we can move it out to a
>>>> good location. It might be that mostly just a header file with ABI
>>>> conventions needs to be shared, not actual implementation, for
>>>> example.
>>>
>>> So I thought we agreed on that. If in the end we prefer to move the ARM
>>> firmware interface into drivers/firmware, I'm fine with that too (Tomasz
>>> also confirmed he would be ok with it) but I wonder if that would not be
>>> somehow premature.
> ...
>> Well, as I already said I'm ok with things going into arch/arm to
>> start with, as long as Russell is.
> ...
>
> Russell, the patch Alex sent to move firmware_ops into drivers/firmware
> was rejected, so I don't think we can update this series to move the
> code there instead.
>
> So, are you OK with merging this series as-is, in arch/arm/firmware? If
> you could ack the patch/series to indicate that, it would be awesome.

Sorry, this was stuck on my to-read-and-reply list.

I think merging for arch/arm is what makes sense here, even if we end
up at some point in the future moving it out. Only time will tell if
that makes sense or not, and it's not going to be a big deal to handle
at that time.

An ack from Russell would be appreciated, or we'd need to set up a
shared branch given the Tegra dependencies that would go on top.
Either is ok with me.


-Olof

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Russell King - ARM Linux]

On Thu, Nov 21, 2013 at 10:51:09AM -0800, Olof Johansson wrote:
> An ack from Russell would be appreciated, or we'd need to set up a
> shared branch given the Tegra dependencies that would go on top.
> Either is ok with me.

Note that I'm *not* looking at anything new until after the merge window
has closed, so I'm not acking or reviewing anything at the moment.

Re: [PATCH v10 0/7] ARM: support for Trusted Foundations secure monitor

[Stephen Warren]

On 11/21/2013 12:00 PM, Russell King - ARM Linux wrote:
> On Thu, Nov 21, 2013 at 10:51:09AM -0800, Olof Johansson wrote:
>> An ack from Russell would be appreciated, or we'd need to set up a
>> shared branch given the Tegra dependencies that would go on top.
>> Either is ok with me.
> 
> Note that I'm *not* looking at anything new until after the merge window
> has closed, so I'm not acking or reviewing anything at the moment.

OK, that's fair. Do we need to ping you again or repost once -rc1 is
out, or do you have a TODO list that you'll check?