From: Harshal Dev <harshal.dev@oss.qualcomm.com>
To: Eric Biggers <ebiggers@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
Abel Vesa <abelvesa@kernel.org>,
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>,
Neeraj Soni <neeraj.soni@oss.qualcomm.com>,
Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>,
Sumit Garg <sumit.garg@oss.qualcomm.com>,
Selvam Sathappan Periakaruppan
<selvam.periakaruppan@oss.qualcomm.com>,
Jens Wiklander <jens.wiklander@oss.qualcomm.com>
Cc: Basant Kumar <basantk@qti.qualcomm.com>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-crypto@vger.kernel.org, op-tee@lists.trustedfirmware.org
Subject: Re: [PATCH v2 4/6] tee: optee: Register TEE devices on the platform bus
Date: Sat, 14 Nov 2026 02:15:46 +0530 [thread overview]
Message-ID: <1317a8b2-2f12-416c-aa12-8d0262e0d3c9@oss.qualcomm.com> (raw)
In-Reply-To: <197d7d58-9791-483f-9a7f-40747f44d1ee@oss.qualcomm.com>
Hi,
On 11-11-2026 08:27 pm, Harshal Dev wrote:
> + op-tee@lists.trustedfirmware.org, Jens Wiklander <jens.wiklander@oss.qualcomm.com>
>
> On 11-11-2026 07:47 pm, Harshal Dev wrote:
>> The Qualcomm Inline Crypto Engine (ICE) driver is an independent platform
>> driver which polls on availability of a TEE interface (SCM driver) before
>> checking if the ICE secure service is supported by QTEE by querying the
>> qcom_scm_ice_available() API.
>>
>> The TEE subsystem currently does not provide any way to notify regarding
>> the availability of a TEE interface, i.e. whether QCOMTEE or OPTEE have
>> probed. And so when migrating to the TEE subsystem via an ICE TEE client
>> driver, ICE needs to defer probe until the OPTEE ICE Pseudo TA becomes
>> available on the TEE bus. This means that for OPTEE builds without the
>> ICE PTA, the ICE driver would indefintely defer probe and the dependent
>> UFS/SDHC storage driver will fail to come online.
>>
>> Add support for optionally registering the back-end TEE devices which
>> represent a particular TEE (say OPTEE) on the platform bus via the
>> tee_platform_device_register() API.
I've been thinking a bit more about this. Instead of introducing a new
API on the TEE subsystem for re-registering the back-end TEE device on a
platform/auxiliary bus, can we just register the (OP)TEE device on the TEE
bus itself once all the Pseudo TAs have been enumerated?
This could be a reserved device with a reserved UUID that the client drivers
cannot interact with via the usual tee_open_session() function, and would be
returned an error.
A TEE client driver who wants to be notified once all the PTAs have been
enumerated on the TEE bus can register for this reserved OPTEE UUID and be
informed of this event via its registered probe() function for this device.
The TEE back-end device would be a sort of "end-of-line" marker for all the
PTAs on the TEE bus.
Let me know your thoughts.
Regards,
Harshal
>> This allows drivers which poll on
>> TEE secure interface availability to be notified even if the TEE service
>> itself is not supported.
>>
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
next prev parent reply other threads:[~2026-11-13 20:45 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 14:17 [PATCH v2 0/6] Add support for a TEE agnostic Inline Crypto Engine service Harshal Dev
2026-11-11 14:17 ` [PATCH v2 1/6] soc: qcom: ice: Add TZ agnostic re-direction functions Harshal Dev
2026-11-11 14:17 ` [PATCH v2 2/6] firmware: qcom_scm: Transition to ICE TZ agnostic operations Harshal Dev
2026-11-11 14:17 ` [PATCH v2 3/6] firmware: qcom: Add a TEE bus based ICE back-end Harshal Dev
2026-11-11 14:17 ` [PATCH v2 4/6] tee: optee: Register TEE devices on the platform bus Harshal Dev
2026-11-11 14:57 ` Harshal Dev
2026-11-13 20:45 ` Harshal Dev [this message]
2026-11-11 14:17 ` [PATCH v2 5/6] soc: qcom: ice: Migrate to the TZ agnostic ICE APIs Harshal Dev
2026-11-11 14:17 ` [PATCH v2 6/6] firmware: qcom: scm: Drop exported ICE wrapper functions Harshal Dev
2026-11-11 14:21 ` [PATCH v2 0/6] Add support for a TEE agnostic Inline Crypto Engine service Harshal Dev
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=1317a8b2-2f12-416c-aa12-8d0262e0d3c9@oss.qualcomm.com \
--to=harshal.dev@oss.qualcomm.com \
--cc=abelvesa@kernel.org \
--cc=andersson@kernel.org \
--cc=basantk@qti.qualcomm.com \
--cc=ebiggers@kernel.org \
--cc=jens.wiklander@oss.qualcomm.com \
--cc=konradybcio@kernel.org \
--cc=kuldeep.singh@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--cc=neeraj.soni@oss.qualcomm.com \
--cc=op-tee@lists.trustedfirmware.org \
--cc=selvam.periakaruppan@oss.qualcomm.com \
--cc=sumit.garg@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®