New attempt to get this merged. ;)
The last open discussion topic for this series is whether to move this into
drivers/ instead of having it depend on ARM. The problem is that the firmware
framework this series is built upon resides in arch/arm/. It would possibly
make sense to move it out of there as well, but doing so requires Tomasz
opinion on the matter and unfortunately I haven't been able to get feedback
from him, even after trying to contact him privately.
At the current state of things, this should be of little concern anyway.
Trusted Foundations is for the moment indeed ARM-only, and both the
Trusted Foundations driver and firmware framework can be moved out of
arch/arm/ at any time without introducing any incompatibility.
Also I have some inprovements to this driver waiting to be submitted, but
would like to get this generally-accepted part merged first instead of
adding new code that will probably need several new rounds of revisions.
Changelog from v8:
- moved includes that depended on config symbols to the top of the file
- use linux/*.h instead of asm/*.h
Alexandre Courbot (5):
ARM: add basic support for Trusted Foundations
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/tl,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 | 79 ++++++++++++++++++++++
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, 237 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/firmware/tl,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.1
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 <[email protected]>
Reviewed-by: Tomasz Figa <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
---
.../arm/firmware/tl,trusted-foundations.txt | 20 ++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/Kconfig | 2 +
arch/arm/Makefile | 1 +
arch/arm/firmware/Kconfig | 28 ++++++++
arch/arm/firmware/Makefile | 1 +
arch/arm/firmware/trusted_foundations.c | 79 ++++++++++++++++++++++
arch/arm/include/asm/trusted_foundations.h | 67 ++++++++++++++++++
8 files changed, 199 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/firmware/tl,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
diff --git a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt
new file mode 100644
index 0000000..2ec75c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/tl,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 "tl,trusted-foundations"
+under the /firmware/ node
+
+Required properties:
+- compatible : "tl,trusted-foundations"
+- version-major : major version number of Trusted Foundations firmware
+- version-minor: minor version number of Trusted Foundations firmware
+
+Example:
+ firmware {
+ trusted-foundations {
+ compatible = "tl,trusted-foundations";
+ version-major = <2>;
+ version-minor = <8>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 2956800..a374eaa 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
+tl Trusted Logic
toshiba Toshiba Corporation
v3 V3 Semiconductor
via VIA Technologies, Inc.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1ad6fb6..bf14cec 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 db50b62..f9a8e93 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 0000000..bb00ccf
--- /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 0000000..a71f165
--- /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 0000000..fe063d5
--- /dev/null
+++ b/arch/arm/firmware/trusted_foundations.c
@@ -0,0 +1,79 @@
+/*
+ * 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, "tl,trusted-foundations");
+ if (!node)
+ return;
+
+ err = of_property_read_u32(node, "version-major", &pdata.version_major);
+ if (err != 0)
+ panic("Trusted Foundation: missing version-major property\n");
+ err = of_property_read_u32(node, "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 0000000..3bd36e2
--- /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.1
Register the firmware operations for Trusted Foundations if the device
tree indicates it is active on the device.
Signed-off-by: Alexandre Courbot <[email protected]>
Reviewed-by: Tomasz Figa <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
---
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 ed9c853..8e51884 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
+"tl,trusted-foundations" binding's documentation for more details.
diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
index 67a76f2..4e51278 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 94a119a..b405e45 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.1
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 <[email protected]>
Reviewed-by: Tomasz Figa <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
---
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 fd0bbf8..e282395 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.1
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 <[email protected]>
Reviewed-by: Tomasz Figa <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
---
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 ea042e8..dddb97b 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.1
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 <[email protected]>
Reviewed-by: Tomasz Figa <[email protected]>
Reviewed-by: Stephen Warren <[email protected]>
---
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 e282395..368af0a 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.1
On Oct 28, 2013, at 5:28 AM, Alexandre Courbot wrote:
> 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 <[email protected]>
> Reviewed-by: Tomasz Figa <[email protected]>
> Reviewed-by: Stephen Warren <[email protected]>
> ---
> .../arm/firmware/tl,trusted-foundations.txt | 20 ++++++
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> arch/arm/Kconfig | 2 +
> arch/arm/Makefile | 1 +
> arch/arm/firmware/Kconfig | 28 ++++++++
> arch/arm/firmware/Makefile | 1 +
> arch/arm/firmware/trusted_foundations.c | 79 ++++++++++++++++++++++
> arch/arm/include/asm/trusted_foundations.h | 67 ++++++++++++++++++
> 8 files changed, 199 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/firmware/tl,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
>
> diff --git a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt
> new file mode 100644
> index 0000000..2ec75c9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/firmware/tl,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 "tl,trusted-foundations"
> +under the /firmware/ node
> +
> +Required properties:
> +- compatible : "tl,trusted-foundations"
> +- version-major : major version number of Trusted Foundations firmware
> +- version-minor: minor version number of Trusted Foundations firmware
vendor prefix version.
> +
> +Example:
> + firmware {
> + trusted-foundations {
> + compatible = "tl,trusted-foundations";
> + version-major = <2>;
> + version-minor = <8>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index 2956800..a374eaa 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
> +tl Trusted Logic
Should this be Trusted Logic Mobility (tlm)?
> toshiba Toshiba Corporation
> v3 V3 Semiconductor
> via VIA Technologies, Inc.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:
>
> On Oct 28, 2013, at 5:28 AM, Alexandre Courbot wrote:
>
> > 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 <[email protected]>
> > Reviewed-by: Tomasz Figa <[email protected]>
> > Reviewed-by: Stephen Warren <[email protected]>
> > ---
> > .../arm/firmware/tl,trusted-foundations.txt | 20 ++++++
> > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > arch/arm/Kconfig | 2 +
> > arch/arm/Makefile | 1 +
> > arch/arm/firmware/Kconfig | 28 ++++++++
> > arch/arm/firmware/Makefile | 1 +
> > arch/arm/firmware/trusted_foundations.c | 79 ++++++++++++++++++++++
> > arch/arm/include/asm/trusted_foundations.h | 67 ++++++++++++++++++
> > 8 files changed, 199 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/arm/firmware/tl,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
> >
> > diff --git a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundations.txt
> > new file mode 100644
> > index 0000000..2ec75c9
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/firmware/tl,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 "tl,trusted-foundations"
> > +under the /firmware/ node
> > +
> > +Required properties:
> > +- compatible : "tl,trusted-foundations"
> > +- version-major : major version number of Trusted Foundations firmware
> > +- version-minor: minor version number of Trusted Foundations firmware
>
> vendor prefix version.
Are you saying he should use tl,version-major tl,version-minor? For bindings
that are already vendor-specific we haven't (on ARM) asked for vendor prefix on
properties. It doesn't mean that we should keep going down that route though,
so I'm just asking for clarification for my own edification. :)
-Olof
On Monday 28 of October 2013 14:56:49 Olof Johansson wrote:
> On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:
> > On Oct 28, 2013, at 5:28 AM, Alexandre Courbot wrote:
> > > 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 <[email protected]>
> > > Reviewed-by: Tomasz Figa <[email protected]>
> > > Reviewed-by: Stephen Warren <[email protected]>
> > > ---
> > > .../arm/firmware/tl,trusted-foundations.txt | 20 ++++++
> > > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > > arch/arm/Kconfig | 2 +
> > > arch/arm/Makefile | 1 +
> > > arch/arm/firmware/Kconfig | 28 ++++++++
> > > arch/arm/firmware/Makefile | 1 +
> > > arch/arm/firmware/trusted_foundations.c | 79
> > > ++++++++++++++++++++++ arch/arm/include/asm/trusted_foundations.h
> > > | 67 ++++++++++++++++++ 8 files changed, 199 insertions(+)
> > > create mode 100644
> > > Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundatio
> > > ns.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
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> > > ions.txt
> > > b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> > > ions.txt new file mode 100644
> > > index 0000000..2ec75c9
> > > --- /dev/null
> > > +++
> > > b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> > > ions.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
> > > "tl,trusted-foundations"
> > > +under the /firmware/ node
> > > +
> > > +Required properties:
> > > +- compatible : "tl,trusted-foundations"
> > > +- version-major : major version number of Trusted Foundations
> > > firmware
> > > +- version-minor: minor version number of Trusted Foundations
> > > firmware
> >
> > vendor prefix version.
>
> Are you saying he should use tl,version-major tl,version-minor? For
> bindings that are already vendor-specific we haven't (on ARM) asked for
> vendor prefix on properties. It doesn't mean that we should keep going
> down that route though, so I'm just asking for clarification for my own
> edification. :)
This is a good question. We should decide what the right thing (TM) is and
write it down. I, on the contrary, was convinced that it's the way Kumar
says.
Best regards,
Tomasz
On Mon, Oct 28, 2013 at 10:28:36AM +0000, Alexandre Courbot wrote:
> 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 <[email protected]>
> Reviewed-by: Tomasz Figa <[email protected]>
> Reviewed-by: Stephen Warren <[email protected]>
> ---
> 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 fd0bbf8..e282395 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);
A memcpy to iomem seems suspect. Should this be memcpy_toio, or is the __iomem
annotation misleading?
Thanks,
Mark.
On Mon, Oct 28, 2013 at 11:31:36PM +0000, Tomasz Figa wrote:
> On Monday 28 of October 2013 14:56:49 Olof Johansson wrote:
> > On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:
> > > On Oct 28, 2013, at 5:28 AM, Alexandre Courbot wrote:
> > > > 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 <[email protected]>
> > > > Reviewed-by: Tomasz Figa <[email protected]>
> > > > Reviewed-by: Stephen Warren <[email protected]>
> > > > ---
> > > > .../arm/firmware/tl,trusted-foundations.txt | 20 ++++++
> > > > .../devicetree/bindings/vendor-prefixes.txt | 1 +
> > > > arch/arm/Kconfig | 2 +
> > > > arch/arm/Makefile | 1 +
> > > > arch/arm/firmware/Kconfig | 28 ++++++++
> > > > arch/arm/firmware/Makefile | 1 +
> > > > arch/arm/firmware/trusted_foundations.c | 79
> > > > ++++++++++++++++++++++ arch/arm/include/asm/trusted_foundations.h
> > > > | 67 ++++++++++++++++++ 8 files changed, 199 insertions(+)
> > > > create mode 100644
> > > > Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundatio
> > > > ns.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
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> > > > ions.txt
> > > > b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> > > > ions.txt new file mode 100644
> > > > index 0000000..2ec75c9
> > > > --- /dev/null
> > > > +++
> > > > b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> > > > ions.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
> > > > "tl,trusted-foundations"
> > > > +under the /firmware/ node
> > > > +
> > > > +Required properties:
> > > > +- compatible : "tl,trusted-foundations"
> > > > +- version-major : major version number of Trusted Foundations
> > > > firmware
> > > > +- version-minor: minor version number of Trusted Foundations
> > > > firmware
> > >
> > > vendor prefix version.
> >
> > Are you saying he should use tl,version-major tl,version-minor? For
> > bindings that are already vendor-specific we haven't (on ARM) asked for
> > vendor prefix on properties. It doesn't mean that we should keep going
> > down that route though, so I'm just asking for clarification for my own
> > edification. :)
>
> This is a good question. We should decide what the right thing (TM) is and
> write it down. I, on the contrary, was convinced that it's the way Kumar
> says.
The impression I got was that properties should be prefixed when they're
extremely vendor-specific and could clash with a more generic property. I'm not
sure that firmware will ever have a generic binding given the variation even in
the set of implemented functionality.
I would imagine that there are many ways different firmwares might be
versioned, and I can't see version-major or version-minor clashing with a
generic property we might add later. However prefixing would not be harmful, so
I'm not opposed to it if others want that.
Another option would be to support a fallback compatible list (e.g.
"tl,trusted-foundations-${MAJOR}-${MINOR}", "tl,trusted-foundations"), and get
versioning information from there. Given that could be painful to handle I
don't want to force it if not required.
Thanks,
Mark.
On Oct 28, 2013, at 7:25 PM, Mark Rutland wrote:
> On Mon, Oct 28, 2013 at 11:31:36PM +0000, Tomasz Figa wrote:
>> On Monday 28 of October 2013 14:56:49 Olof Johansson wrote:
>>> On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:
>>>> On Oct 28, 2013, at 5:28 AM, Alexandre Courbot wrote:
>>>>> 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 <[email protected]>
>>>>> Reviewed-by: Tomasz Figa <[email protected]>
>>>>> Reviewed-by: Stephen Warren <[email protected]>
>>>>> ---
>>>>> .../arm/firmware/tl,trusted-foundations.txt | 20 ++++++
>>>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>>>> arch/arm/Kconfig | 2 +
>>>>> arch/arm/Makefile | 1 +
>>>>> arch/arm/firmware/Kconfig | 28 ++++++++
>>>>> arch/arm/firmware/Makefile | 1 +
>>>>> arch/arm/firmware/trusted_foundations.c | 79
>>>>> ++++++++++++++++++++++ arch/arm/include/asm/trusted_foundations.h
>>>>> | 67 ++++++++++++++++++ 8 files changed, 199 insertions(+)
>>>>> create mode 100644
>>>>> Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundatio
>>>>> ns.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
>>>>>
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
>>>>> ions.txt
>>>>> b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
>>>>> ions.txt new file mode 100644
>>>>> index 0000000..2ec75c9
>>>>> --- /dev/null
>>>>> +++
>>>>> b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
>>>>> ions.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
>>>>> "tl,trusted-foundations"
>>>>> +under the /firmware/ node
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible : "tl,trusted-foundations"
>>>>> +- version-major : major version number of Trusted Foundations
>>>>> firmware
>>>>> +- version-minor: minor version number of Trusted Foundations
>>>>> firmware
>>>>
>>>> vendor prefix version.
>>>
>>> Are you saying he should use tl,version-major tl,version-minor? For
>>> bindings that are already vendor-specific we haven't (on ARM) asked for
>>> vendor prefix on properties. It doesn't mean that we should keep going
>>> down that route though, so I'm just asking for clarification for my own
>>> edification. :)
>>
>> This is a good question. We should decide what the right thing (TM) is and
>> write it down. I, on the contrary, was convinced that it's the way Kumar
>> says.
>
> The impression I got was that properties should be prefixed when they're
> extremely vendor-specific and could clash with a more generic property. I'm not
> sure that firmware will ever have a generic binding given the variation even in
> the set of implemented functionality.
>
> I would imagine that there are many ways different firmwares might be
> versioned, and I can't see version-major or version-minor clashing with a
> generic property we might add later. However prefixing would not be harmful, so
> I'm not opposed to it if others want that.
>
> Another option would be to support a fallback compatible list (e.g.
> "tl,trusted-foundations-${MAJOR}-${MINOR}", "tl,trusted-foundations"), and get
> versioning information from there. Given that could be painful to handle I
> don't want to force it if not required.
>
> Thanks,
> Mark.
I'm of the opinion that making all vendor specific properties vendor prefixed is the easiest rule of thumb and leaves no gray area to have to argue about.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Tue, Oct 29, 2013 at 03:12:05AM -0500, Kumar Gala wrote:
>
> On Oct 28, 2013, at 7:25 PM, Mark Rutland wrote:
>
> > On Mon, Oct 28, 2013 at 11:31:36PM +0000, Tomasz Figa wrote:
> >> On Monday 28 of October 2013 14:56:49 Olof Johansson wrote:
> >>> On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:
> >>>> On Oct 28, 2013, at 5:28 AM, Alexandre Courbot wrote:
> >>>>> 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 <[email protected]>
> >>>>> Reviewed-by: Tomasz Figa <[email protected]>
> >>>>> Reviewed-by: Stephen Warren <[email protected]>
> >>>>> ---
> >>>>> .../arm/firmware/tl,trusted-foundations.txt | 20 ++++++
> >>>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> >>>>> arch/arm/Kconfig | 2 +
> >>>>> arch/arm/Makefile | 1 +
> >>>>> arch/arm/firmware/Kconfig | 28 ++++++++
> >>>>> arch/arm/firmware/Makefile | 1 +
> >>>>> arch/arm/firmware/trusted_foundations.c | 79
> >>>>> ++++++++++++++++++++++ arch/arm/include/asm/trusted_foundations.h
> >>>>> | 67 ++++++++++++++++++ 8 files changed, 199 insertions(+)
> >>>>> create mode 100644
> >>>>> Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundatio
> >>>>> ns.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
> >>>>>
> >>>>> diff --git
> >>>>> a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> >>>>> ions.txt
> >>>>> b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> >>>>> ions.txt new file mode 100644
> >>>>> index 0000000..2ec75c9
> >>>>> --- /dev/null
> >>>>> +++
> >>>>> b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
> >>>>> ions.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
> >>>>> "tl,trusted-foundations"
> >>>>> +under the /firmware/ node
> >>>>> +
> >>>>> +Required properties:
> >>>>> +- compatible : "tl,trusted-foundations"
> >>>>> +- version-major : major version number of Trusted Foundations
> >>>>> firmware
> >>>>> +- version-minor: minor version number of Trusted Foundations
> >>>>> firmware
> >>>>
> >>>> vendor prefix version.
> >>>
> >>> Are you saying he should use tl,version-major tl,version-minor? For
> >>> bindings that are already vendor-specific we haven't (on ARM) asked for
> >>> vendor prefix on properties. It doesn't mean that we should keep going
> >>> down that route though, so I'm just asking for clarification for my own
> >>> edification. :)
> >>
> >> This is a good question. We should decide what the right thing (TM) is and
> >> write it down. I, on the contrary, was convinced that it's the way Kumar
> >> says.
> >
> > The impression I got was that properties should be prefixed when they're
> > extremely vendor-specific and could clash with a more generic property. I'm not
> > sure that firmware will ever have a generic binding given the variation even in
> > the set of implemented functionality.
> >
> > I would imagine that there are many ways different firmwares might be
> > versioned, and I can't see version-major or version-minor clashing with a
> > generic property we might add later. However prefixing would not be harmful, so
> > I'm not opposed to it if others want that.
> >
> > Another option would be to support a fallback compatible list (e.g.
> > "tl,trusted-foundations-${MAJOR}-${MINOR}", "tl,trusted-foundations"), and get
> > versioning information from there. Given that could be painful to handle I
> > don't want to force it if not required.
> >
> > Thanks,
> > Mark.
>
> I'm of the opinion that making all vendor specific properties vendor prefixed is the easiest rule of thumb and leaves no gray area to have to argue about.
That would really help all of us to self-police our submissions and
reduce the burden on the DT maintainer team.
-Matt
On 10/29/2013 05:12 PM, Kumar Gala wrote:
>
> On Oct 28, 2013, at 7:25 PM, Mark Rutland wrote:
>
>> On Mon, Oct 28, 2013 at 11:31:36PM +0000, Tomasz Figa wrote:
>>> On Monday 28 of October 2013 14:56:49 Olof Johansson wrote:
>>>> On Mon, Oct 28, 2013 at 05:57:04AM -0500, Kumar Gala wrote:
>>>>> On Oct 28, 2013, at 5:28 AM, Alexandre Courbot wrote:
>>>>>> 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 <[email protected]>
>>>>>> Reviewed-by: Tomasz Figa <[email protected]>
>>>>>> Reviewed-by: Stephen Warren <[email protected]>
>>>>>> ---
>>>>>> .../arm/firmware/tl,trusted-foundations.txt | 20 ++++++
>>>>>> .../devicetree/bindings/vendor-prefixes.txt | 1 +
>>>>>> arch/arm/Kconfig | 2 +
>>>>>> arch/arm/Makefile | 1 +
>>>>>> arch/arm/firmware/Kconfig | 28 ++++++++
>>>>>> arch/arm/firmware/Makefile | 1 +
>>>>>> arch/arm/firmware/trusted_foundations.c | 79
>>>>>> ++++++++++++++++++++++ arch/arm/include/asm/trusted_foundations.h
>>>>>> | 67 ++++++++++++++++++ 8 files changed, 199 insertions(+)
>>>>>> create mode 100644
>>>>>> Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundatio
>>>>>> ns.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
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
>>>>>> ions.txt
>>>>>> b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
>>>>>> ions.txt new file mode 100644
>>>>>> index 0000000..2ec75c9
>>>>>> --- /dev/null
>>>>>> +++
>>>>>> b/Documentation/devicetree/bindings/arm/firmware/tl,trusted-foundat
>>>>>> ions.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
>>>>>> "tl,trusted-foundations"
>>>>>> +under the /firmware/ node
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible : "tl,trusted-foundations"
>>>>>> +- version-major : major version number of Trusted Foundations
>>>>>> firmware
>>>>>> +- version-minor: minor version number of Trusted Foundations
>>>>>> firmware
>>>>>
>>>>> vendor prefix version.
>>>>
>>>> Are you saying he should use tl,version-major tl,version-minor? For
>>>> bindings that are already vendor-specific we haven't (on ARM) asked for
>>>> vendor prefix on properties. It doesn't mean that we should keep going
>>>> down that route though, so I'm just asking for clarification for my own
>>>> edification. :)
>>>
>>> This is a good question. We should decide what the right thing (TM) is and
>>> write it down. I, on the contrary, was convinced that it's the way Kumar
>>> says.
>>
>> The impression I got was that properties should be prefixed when they're
>> extremely vendor-specific and could clash with a more generic property. I'm not
>> sure that firmware will ever have a generic binding given the variation even in
>> the set of implemented functionality.
>>
>> I would imagine that there are many ways different firmwares might be
>> versioned, and I can't see version-major or version-minor clashing with a
>> generic property we might add later. However prefixing would not be harmful, so
>> I'm not opposed to it if others want that.
>>
>> Another option would be to support a fallback compatible list (e.g.
>> "tl,trusted-foundations-${MAJOR}-${MINOR}", "tl,trusted-foundations"), and get
>> versioning information from there. Given that could be painful to handle I
>> don't want to force it if not required.
>>
>> Thanks,
>> Mark.
>
> I'm of the opinion that making all vendor specific properties vendor prefixed is the easiest rule of thumb and leaves no gray area to have to argue about.
All good points, I will vendor-prefix these properties.
Thanks,
Alex.