diff options
| author | Donggeun Yoo <donggeunyoo.kernel@gmail.com> | 2026-09-02 00:21:26 +0900 |
|---|---|---|
| committer | Jonathan Cameron <jonathan.cameron@oss.qualcomm.com> | 2026-09-07 02:24:53 +0100 |
| commit | e24328974a88aa8541e94e8bb8dfa2ade1b3c45d (patch) | |
| tree | 43a2533acc955d11f5cb8be1ecba0ab8ba4cbb1e /Documentation/tee/qtee.rst | |
| download | linux-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.rst | 96 |
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 |
