From: Tony Lindgren <tony@atomide.com>
To: "Andrew F. Davis" <afd@ti.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>,
linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/4] ARM: OMAP2+: Introduce check for OP-TEE in omap_secure_init()
Date: Thu, 2 Jan 2020 09:14:03 -0800 [thread overview]
Message-ID: <20200102171403.GC16702@atomide.com> (raw)
In-Reply-To: <d7d6f381-be00-3072-0510-a18b736987e7@ti.com>
* Andrew F. Davis <afd@ti.com> [191231 14:16]:
> On 12/31/19 1:32 AM, Lokesh Vutla wrote:
> > This doesn't guarantee that optee driver is probed successfully or firmware
> > installed correctly. Isn't there a better way to detect? Doesn't tee core layer
> > exposes anything?
>
> We don't actually need the kernel-side OP-TEE driver at all here, we are
> making raw SMCCC calls which get handled by OP-TEE using platform
> specific code then emulates the function previously handled by ROM[0]
> and execution is returned. No driver involved for these types of calls.
>
> U-Boot will not add this node to the DT unless OP-TEE is installed
> correctly, but you are right that is no perfect guarantee. OP-TEE's
> kernel driver does do a handshake to verify it is working but this is
> not exposed outside of that driver and happens *way* too late for our
> uses here. Plus as above, we don't need the OP-TEE driver at all and we
> should boot the same without it even enabled.
>
> So my opinion is that if DT says OP-TEE is installed, but it is not,
> then that is a misconfiguration and we usually just have to trust DT for
> most things. If DT is wrong here then the only thing that happens is
> this call safely fails, a message is printed informing the user of the
> problem, and kernel keeps booting (although probably not stable given we
> need these calls for important system configuration).
OK, please add comments to omap_optee_init_check(), it's not obvious
to anybody not dealing with optee directly.
Regards,
Tony
next prev parent reply other threads:[~2020-01-02 17:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-30 18:50 [PATCH v3 0/4] Use ARM SMC Calling Convention when OP-TEE is available Andrew F. Davis
2019-12-30 18:50 ` [PATCH v3 1/4] ARM: OMAP2+: Add omap_secure_init callback hook for secure initialization Andrew F. Davis
2019-12-30 18:50 ` [PATCH v3 2/4] ARM: OMAP2+: Introduce check for OP-TEE in omap_secure_init() Andrew F. Davis
2019-12-31 6:32 ` Lokesh Vutla
2019-12-31 14:15 ` Andrew F. Davis
2020-01-02 17:14 ` Tony Lindgren [this message]
2020-01-02 17:24 ` Andrew F. Davis
2019-12-30 18:50 ` [PATCH v3 3/4] ARM: OMAP2+: Use ARM SMC Calling Convention when OP-TEE is available Andrew F. Davis
2019-12-30 18:50 ` [PATCH v3 4/4] ARM: OMAP2+: sleep43xx: Call secure suspend/resume handlers Andrew F. Davis
2019-12-31 6:20 ` Lokesh Vutla
2019-12-31 14:17 ` Andrew F. Davis
2020-01-02 5:02 ` Lokesh Vutla
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=20200102171403.GC16702@atomide.com \
--to=tony@atomide.com \
--cc=afd@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=lokeshvutla@ti.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox