All of lore.kernel.org
 help / color / mirror / Atom feed
From: Casey Connolly <casey.connolly@linaro.org>
To: Sumit Garg <sumit.garg@kernel.org>,
	u-boot-qcom@groups.io, u-boot@lists.denx.de
Cc: trini@konsulko.com, neil.armstrong@linaro.org,
	jorge.ramirez@oss.qualcomm.com,
	varadarajan.narayanan@oss.qualcomm.com, tonyh@qti.qualcomm.com,
	Sumit Garg <sumit.garg@oss.qualcomm.com>
Subject: Re: [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig
Date: Thu, 8 Jan 2026 17:41:42 +0100	[thread overview]
Message-ID: <c0bc6cab-6eee-40c2-b6f7-ff14d91906c5@linaro.org> (raw)
In-Reply-To: <20251229114312.668068-2-sumit.garg@kernel.org>



On 29/12/2025 12:43, Sumit Garg wrote:
> From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> 
> Recently upstream TF-A/OP-TEE has started gaining support for Qcom
> platforms. RB3Gen2 being the first one and more to come. U-Boot in
> corresponding boot flow is packaged as a position independent executable.
> 
> So, lets add a generic U-Boot defconfig for Qcom platforms to support
> TF-A/OP-TEE based TrustZone stack. Build command:
> 
> $ make qcom_tfa_optee_defconfig
> $ make -j`nproc` DEVICE_TREE=qcom/qcs6490-rb3gen2

This would be better suited as a config fragment rather than a new
defconfig imo.

But more importantly, enabling OPTEE support in U-Boot doesn't imply
that it will be used, just that it's supported.

So I think the more appropriate patch here would be to just enable
OP-TEE in qcom_defconfig (assuming the binary size isn't significantly
affected).

Considering the other patch is based on this assumption that if OP-TEE
support is enabled then the board must be using it, a different approach
is definitely needed.

When I was looking into this last year I remember discussing this same
issue from the Linux side, there is a good argument to be made that
OP-TEE support in Linux shouldn't be based on the devicetree -
particularly in the Qualcomm case where whether or not OP-TEE is used is
a simple software change, nothing to do with hardware.

So in general I'm not particularly keen on this approach, I think it
/might/ be acceptable for U-Boot to have some fixup code to add the
OP-TEE node if OP-TEE is in use with the idea of phasing that out in
favour of runtime detection in the OS itself. I'd also expect that fixup
code to go in the generic U-Boot DT fixup code that runs before we jump
to the OS (like the EFI DT fixup function).

Kind regards,

> 
> For more information refer here:
> https://trustedfirmware-a.readthedocs.io/en/latest/plat/qti/rb3gen2.html
> 
> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
> ---
>  configs/qcom_tfa_optee_defconfig | 7 +++++++
>  1 file changed, 7 insertions(+)
>  create mode 100644 configs/qcom_tfa_optee_defconfig
> 
> diff --git a/configs/qcom_tfa_optee_defconfig b/configs/qcom_tfa_optee_defconfig
> new file mode 100644
> index 00000000000..c398521770f
> --- /dev/null
> +++ b/configs/qcom_tfa_optee_defconfig
> @@ -0,0 +1,7 @@
> +# Configuration for building a generic U-Boot image
> +# with support for TF-A/OP-TEE based Arm TrustZone stack.
> +
> +#include "qcom_defconfig"
> +
> +CONFIG_TEE=y
> +CONFIG_OPTEE=y

-- 
// Casey (she/her)


  reply	other threads:[~2026-01-08 16:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-29 11:43 [PATCH 1/2] mach-snapdragon: of_fixup: Add OP-TEE DT fixup support Sumit Garg
2025-12-29 11:43 ` [PATCH 2/2] configs: Add generic qcom_tfa_optee_defconfig Sumit Garg
2026-01-08 16:41   ` Casey Connolly [this message]
2026-01-09 11:02     ` Sumit Garg
2026-01-14 14:56       ` Casey Connolly
2026-01-15  6:10         ` Sumit Garg
2026-01-15 10:49           ` neil.armstrong
2026-01-15 12:25             ` Sumit Garg
2026-01-15 13:03               ` Neil Armstrong
2026-01-15 13:27                 ` Sumit Garg
2026-01-15 13:35                   ` Neil Armstrong
2026-01-16  6:57                     ` Sumit Garg
2026-01-16  7:34                       ` Neil Armstrong
2026-01-16  7:53                         ` Sumit Garg
2026-01-16  9:53                           ` Neil Armstrong
2026-01-16 12:17                             ` Sumit Garg
2026-01-16 17:46                               ` Casey Connolly
2026-01-21  7:21                                 ` Sumit Garg
2026-01-21 10:38                                   ` Casey Connolly
2026-01-21 11:30                                     ` Sumit Garg
2026-01-08 16:19 ` [PATCH 1/2] mach-snapdragon: of_fixup: Add OP-TEE DT fixup support neil.armstrong
2026-01-09 10:24   ` Sumit Garg
2026-01-21 11:46     ` Neil Armstrong

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=c0bc6cab-6eee-40c2-b6f7-ff14d91906c5@linaro.org \
    --to=casey.connolly@linaro.org \
    --cc=jorge.ramirez@oss.qualcomm.com \
    --cc=neil.armstrong@linaro.org \
    --cc=sumit.garg@kernel.org \
    --cc=sumit.garg@oss.qualcomm.com \
    --cc=tonyh@qti.qualcomm.com \
    --cc=trini@konsulko.com \
    --cc=u-boot-qcom@groups.io \
    --cc=u-boot@lists.denx.de \
    --cc=varadarajan.narayanan@oss.qualcomm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.