linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: linux-tegra@vger.kernel.org, Russell King <linux@armlinux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	Jon Hunter <jonathanh@nvidia.com>
Subject: Re: [PATCH 2/2] firmware: Move Trusted Foundations support
Date: Wed, 10 Apr 2019 17:31:55 +0200	[thread overview]
Message-ID: <20190410153155.GB1460@ulmo> (raw)
In-Reply-To: <b0b88e3b-405d-6199-71ac-07e15a29eb9a@gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 6052 bytes --]

On Wed, Apr 10, 2019 at 01:36:35PM +0300, Dmitry Osipenko wrote:
> 10.04.2019 11:57, Thierry Reding пишет:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > Move the Trusted Foundations support out of arch/arm/firmware and into
> > drivers/firmware where most other firmware support implementations are
> > located.
> > 
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> >  arch/arm/Kconfig                              |  2 --
> >  arch/arm/Makefile                             |  1 -
> >  arch/arm/firmware/Kconfig                     | 29 -------------------
> >  arch/arm/firmware/Makefile                    |  4 ---
> >  arch/arm/mach-tegra/Kconfig                   |  2 +-
> >  arch/arm/mach-tegra/cpuidle-tegra114.c        |  3 +-
> >  arch/arm/mach-tegra/pm.c                      |  3 +-
> >  arch/arm/mach-tegra/reset.c                   |  3 +-
> >  arch/arm/mach-tegra/tegra.c                   |  3 +-
> >  drivers/firmware/Kconfig                      | 15 ++++++++++
> >  drivers/firmware/Makefile                     |  1 +
> >  .../firmware/trusted_foundations.c            |  4 ++-
> >  .../linux/firmware}/trusted_foundations.h     |  4 +--
> >  13 files changed, 30 insertions(+), 44 deletions(-)
> >  delete mode 100644 arch/arm/firmware/Kconfig
> >  delete mode 100644 arch/arm/firmware/Makefile
> >  rename {arch/arm => drivers}/firmware/trusted_foundations.c (98%)
> >  rename {arch/arm/include/asm => include/linux/firmware}/trusted_foundations.h (97%)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 054ead960f98..f006b3c69247 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -899,8 +899,6 @@ config PLAT_PXA
> >  config PLAT_VERSATILE
> >  	bool
> >  
> > -source "arch/arm/firmware/Kconfig"
> > -
> >  source "arch/arm/mm/Kconfig"
> >  
> >  config IWMMXT
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index 807a7d06c2a0..05ecc004de86 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -290,7 +290,6 @@ core-y				+= arch/arm/kernel/ arch/arm/mm/ arch/arm/common/
> >  core-y				+= arch/arm/probes/
> >  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
> > deleted file mode 100644
> > index ad396af68e47..000000000000
> > --- a/arch/arm/firmware/Kconfig
> > +++ /dev/null
> > @@ -1,29 +0,0 @@
> > -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
> > -	default y
> > -	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
> > -	  tlm,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
> > deleted file mode 100644
> > index 6e41336b0bc4..000000000000
> > --- a/arch/arm/firmware/Makefile
> > +++ /dev/null
> > @@ -1,4 +0,0 @@
> > -obj-$(CONFIG_TRUSTED_FOUNDATIONS)	+= trusted_foundations.o
> > -
> > -# tf_generic_smc() fails to build with -fsanitize-coverage=trace-pc
> > -KCOV_INSTRUMENT                := n
> > diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
> > index 7b3fd0995a16..cbad7823f602 100644
> > --- a/arch/arm/mach-tegra/Kconfig
> > +++ b/arch/arm/mach-tegra/Kconfig
> > @@ -3,7 +3,6 @@ menuconfig ARCH_TEGRA
> >  	bool "NVIDIA Tegra"
> >  	depends on ARCH_MULTI_V7
> >  	select ARCH_HAS_RESET_CONTROLLER
> > -	select ARCH_SUPPORTS_TRUSTED_FOUNDATIONS
> >  	select ARM_AMBA
> >  	select ARM_GIC
> >  	select CLKSRC_MMIO
> > @@ -14,6 +13,7 @@ menuconfig ARCH_TEGRA
> >  	select PM_OPP
> >  	select RESET_CONTROLLER
> >  	select SOC_BUS
> > +	select TRUSTED_FOUNDATIONS
> 
> Do we really want to force-enable the driver? I think it's better to
> have a choice and then instead enable the driver in the
> tegra_defconfig.

The driver is getting enabled by default prior to this patch, and given
that it's fairly small, I thought it'd be okay to include it by default.
But I guess there's no harm in enabling it in tegra_defconfig and
multi_v7_defconfig, that way people do have the possibility to disable
it if they really don't want it.

> >  	select ZONE_DMA if ARM_LPAE
> >  	help
> >  	  This enables support for NVIDIA Tegra based systems.
> 
> 
> [snip]
> 
> > --- a/drivers/firmware/Kconfig
> > +++ b/drivers/firmware/Kconfig
> > @@ -267,6 +267,21 @@ config TI_SCI_PROTOCOL
> >  	  This protocol library is used by client drivers to use the features
> >  	  provided by the system controller.
> >  
> > +config TRUSTED_FOUNDATIONS
> > +	bool "Trusted Foundations secure monitor support"
> 
> Th driver shall depend at least on ARM because of the assembly. And
> maybe even on ARCH_TEGRA.

Indeed, I've added a "depends on ARM" in v2.

> Do you know if there are any platforms other than Tegra that use that
> firmware? Won't it make sense to move the driver to tegra/ ?

I don't think there's any reason to make this Tegra specific, even if
this was only ever deployed on Tegra.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-04-10 15:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-10  8:57 [PATCH 1/2] ARM: tegra: Sort dependencies alphabetically Thierry Reding
2019-04-10  8:57 ` [PATCH 2/2] firmware: Move Trusted Foundations support Thierry Reding
2019-04-10 10:36   ` Dmitry Osipenko
2019-04-10 15:31     ` Thierry Reding [this message]
2019-04-15 17:04       ` Dmitry Osipenko
2019-04-10 21:20   ` Dmitry Osipenko
2019-04-11  7:50     ` Thierry Reding
2019-04-11 11:28       ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190410153155.GB1460@ulmo \
    --to=thierry.reding@gmail.com \
    --cc=digetx@gmail.com \
    --cc=jonathanh@nvidia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).