summaryrefslogtreecommitdiffstats
path: root/Documentation/tee/qtee.rst
diff options
context:
space:
mode:
authorDonggeun Yoo <donggeunyoo.kernel@gmail.com>2026-09-02 00:21:26 +0900
committerJonathan Cameron <jonathan.cameron@oss.qualcomm.com>2026-09-07 02:24:53 +0100
commite24328974a88aa8541e94e8bb8dfa2ade1b3c45d (patch)
tree43a2533acc955d11f5cb8be1ecba0ab8ba4cbb1e /Documentation/tee/qtee.rst
downloadlinux-stable-e24328974a88aa8541e94e8bb8dfa2ade1b3c45d.tar.gz
linux-stable-e24328974a88aa8541e94e8bb8dfa2ade1b3c45d.zip
iio: proximity: vl53l0x-i2c: claim direct mode for raw readsgrafted
vl53l0x_read_raw() starts a single-shot ranging measurement and reads back the result. Once the triggered buffer is enabled the sensor runs in continuous mode and its data-ready interrupt is routed to the trigger, so a concurrent in_distance_raw read disturbs the streaming setup and never gets its completion, returning -ETIMEDOUT. The original submission claimed direct mode here, but it was dropped during review because the driver had no buffer support at the time [1]. Continuous (buffered) mode was later added without restoring the claim [2], reintroducing the conflict. Reject direct reads while buffered capture is active by claiming direct mode around the measurement, as the vl53l1x sibling already does. Fixes: 762186c6e7b1 ("iio: proximity: vl53l0x-i2c: Added continuous mode support") Link: https://lore.kernel.org/linux-iio/20180911160300.GA9212@himanshu-Vostro-3559/ [1] Link: https://lore.kernel.org/linux-iio/20240909101508.263085-3-abhashkumarjha123@gmail.com/ [2] Signed-off-by: Donggeun Yoo <donggeunyoo.kernel@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
Diffstat (limited to 'Documentation/tee/qtee.rst')
-rw-r--r--Documentation/tee/qtee.rst96
1 files changed, 96 insertions, 0 deletions
diff --git a/Documentation/tee/qtee.rst b/Documentation/tee/qtee.rst
new file mode 100644
index 000000000..2fa2c1bf6
--- /dev/null
+++ b/Documentation/tee/qtee.rst
@@ -0,0 +1,96 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=============================================
+QTEE (Qualcomm Trusted Execution Environment)
+=============================================
+
+The QTEE driver handles communication with Qualcomm TEE [1].
+
+The lowest level of communication with QTEE builds on the ARM SMC Calling
+Convention (SMCCC) [2], which is the foundation for QTEE's Secure Channel
+Manager (SCM) [3] used internally by the driver.
+
+In a QTEE-based system, services are represented as objects with a series of
+operations that can be called to produce results, including other objects.
+
+When an object is hosted within QTEE, executing its operations is referred
+to as "direct invocation". QTEE can also invoke objects hosted in the non-secure
+world using a method known as "callback request".
+
+The SCM provides two functions to support direct invocation and callback requests:
+
+- QCOM_SCM_SMCINVOKE_INVOKE: Used for direct invocation. It can return either
+ a result or initiate a callback request.
+- QCOM_SCM_SMCINVOKE_CB_RSP: Used to submit a response to a callback request
+ triggered by a previous direct invocation.
+
+The QTEE Transport Message [4] is stacked on top of the SCM driver functions.
+
+A message consists of two buffers shared with QTEE: inbound and outbound
+buffers. The inbound buffer is used for direct invocation, and the outbound
+buffer is used to make callback requests. This picture shows the contents of
+a QTEE transport message::
+
+ +---------------------+
+ | v
+ +-----------------+-------+-------+------+--------------------------+
+ | qcomtee_msg_ |object | buffer | |
+ | object_invoke | id | offset, size | | (inbound buffer)
+ +-----------------+-------+--------------+--------------------------+
+ <---- header -----><---- arguments ------><- in/out buffer payload ->
+
+ +-----------+
+ | v
+ +-----------------+-------+-------+------+----------------------+
+ | qcomtee_msg_ |object | buffer | |
+ | callback | id | offset, size | | (outbound buffer)
+ +-----------------+-------+--------------+----------------------+
+
+Each buffer is started with a header and array of arguments.
+
+QTEE Transport Message supports four types of arguments:
+
+- Input Object (IO) is an object parameter to the current invocation
+ or callback request.
+- Output Object (OO) is an object parameter from the current invocation
+ or callback request.
+- Input Buffer (IB) is (offset, size) pair to the inbound or outbound region
+ to store parameter to the current invocation or callback request.
+- Output Buffer (OB) is (offset, size) pair to the inbound or outbound region
+ to store parameter from the current invocation or callback request.
+
+Picture of the relationship between the different components in the QTEE
+architecture::
+
+ User space Kernel Secure world
+ ~~~~~~~~~~ ~~~~~~ ~~~~~~~~~~~~
+ +--------+ +----------+ +--------------+
+ | Client | |callback | | Trusted |
+ +--------+ |server | | Application |
+ /\ +----------+ +--------------+
+ || +----------+ /\ /\
+ || |callback | || ||
+ || |server | || \/
+ || +----------+ || +--------------+
+ || /\ || | TEE Internal |
+ || || || | API |
+ \/ \/ \/ +--------+--------+ +--------------+
+ +---------------------+ | TEE | QTEE | | QTEE |
+ | libqcomtee [5] | | subsys | driver | | Trusted OS |
+ +-------+-------------+--+----+-------+----+-------------+--------------+
+ | Generic TEE API | | QTEE MSG |
+ | IOCTL (TEE_IOC_*) | | SMCCC (QCOM_SCM_SMCINVOKE_*) |
+ +-----------------------------+ +---------------------------------+
+
+References
+==========
+
+[1] https://docs.qualcomm.com/bundle/publicresource/topics/80-70015-11/qualcomm-trusted-execution-environment.html
+
+[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html
+
+[3] drivers/firmware/qcom/qcom_scm.c
+
+[4] drivers/tee/qcomtee/qcomtee_msg.h
+
+[5] https://github.com/quic/quic-teec