diff mbox

[3/5] ARM: firmware: enable Trusted Foundations by default

Message ID 1390299016-14105-4-git-send-email-acourbot@nvidia.com (mailing list archive)
State New, archived
Headers show

Commit Message

Alexandre Courbot Jan. 21, 2014, 10:10 a.m. UTC
As discussed previously (https://lkml.org/lkml/2013/11/26/289), enable
Trusted Foundation support by default since it already depends on a
supporting architecture being selected.

Doing so allows us to remove it from tegra_defconfig.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
 arch/arm/configs/tegra_defconfig | 1 -
 arch/arm/firmware/Kconfig        | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

Comments

Stephen Warren Jan. 22, 2014, 8:42 p.m. UTC | #1
On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
> As discussed previously (https://lkml.org/lkml/2013/11/26/289), enable
> Trusted Foundation support by default since it already depends on a
> supporting architecture being selected.
> 
> Doing so allows us to remove it from tegra_defconfig.

>  arch/arm/configs/tegra_defconfig | 1 -
>  arch/arm/firmware/Kconfig        | 1 +

Can we split out the defconfig and code changes into separate patches?
They need to go through seperate branches, possibly even separate repos.

The defconfig change might not even be necessary; at some point I'll
just rebuild it via "make tegra_defconfig; make savedefconfig" on top of
some linux-next that includes the Kconfig change, and it'll happen
automatically. Still, I guess there's no harm explicitly sending the patch.
Alexandre Courbot Jan. 23, 2014, 7:38 a.m. UTC | #2
On Thu, Jan 23, 2014 at 5:42 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
>> As discussed previously (https://lkml.org/lkml/2013/11/26/289), enable
>> Trusted Foundation support by default since it already depends on a
>> supporting architecture being selected.
>>
>> Doing so allows us to remove it from tegra_defconfig.
>
>>  arch/arm/configs/tegra_defconfig | 1 -
>>  arch/arm/firmware/Kconfig        | 1 +
>
> Can we split out the defconfig and code changes into separate patches?
> They need to go through seperate branches, possibly even separate repos.
>
> The defconfig change might not even be necessary; at some point I'll
> just rebuild it via "make tegra_defconfig; make savedefconfig" on top of
> some linux-next that includes the Kconfig change, and it'll happen
> automatically. Still, I guess there's no harm explicitly sending the patch.

If we can do without the defconfig change then I will just omit it in
the next version - I don't like sending too many oneliners. :P
diff mbox

Patch

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 5fdc9a09d339..e38653876541 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -33,7 +33,6 @@  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
diff --git a/arch/arm/firmware/Kconfig b/arch/arm/firmware/Kconfig
index bb126594995e..ad396af68e47 100644
--- a/arch/arm/firmware/Kconfig
+++ b/arch/arm/firmware/Kconfig
@@ -11,6 +11,7 @@  menu "Firmware options"
 config TRUSTED_FOUNDATIONS
 	bool "Trusted Foundations secure monitor support"
 	depends on ARCH_SUPPORTS_TRUSTED_FOUNDATIONS
+	default y
 	help
 	  Some devices (including most Tegra-based consumer devices on the
 	  market) are booted with the Trusted Foundations secure monitor