On 8/14/2025 8:52 AM, Konrad Dybcio wrote:
On 8/13/25 11:37 PM, Amirreza Zarrabi wrote:
On 8/13/2025 7:53 PM, Konrad Dybcio wrote:
On 8/13/25 2:35 AM, Amirreza Zarrabi wrote:
Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in the secure world, accessed via objects. A QTEE client can invoke these objects to request services. Similarly, QTEE can request services from the nonsecure world using objects exported to the secure world.
Add low-level primitives to facilitate the invocation of objects hosted in QTEE, as well as those hosted in the nonsecure world.
If support for object invocation is available, the qcom_scm allocates a dedicated child platform device. The driver for this device communicates with QTEE using low-level primitives.
Tested-by: Neil Armstrong neil.armstrong@linaro.org Tested-by: Harshal Dev quic_hdev@quicinc.com Signed-off-by: Amirreza Zarrabi amirreza.zarrabi@oss.qualcomm.com
[...]
/**
- qcom_scm_is_available() - Checks if SCM is available
*/ @@ -2326,6 +2444,16 @@ static int qcom_scm_probe(struct platform_device *pdev) ret = qcom_scm_qseecom_init(scm); WARN(ret < 0, "failed to initialize qseecom: %d\n", ret);
- /*
* Initialize the QTEE object interface.** This only represents the availability for QTEE object invocation* and callback support. On failure, ignore the result. Any subsystem* depending on it may fail if it tries to access this interface.*/- ret = qcom_scm_qtee_init(scm);
- WARN(ret < 0, "failed to initialize qcomtee: %d\n", ret);
This will throw a WARN on *a lot* of platforms, ranging from Chromebooks running TF-A (with a reduced SMC handler), through platforms requiring QCOM_SCM_SMCINVOKE_INVOKE_LEGACY (0x00) cmd
Are you suggesting I remove the WARN? If so, how should the user be notified? Should the error simply be ignored?
I suggest using dev_info/dev_notice, WARN prints multiple dozen lines and taints the kernel
Konrad
Ack.
Amir