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 <[email protected]> >>> Tested-by: Harshal Dev <[email protected]> >>> Signed-off-by: Amirreza Zarrabi <[email protected]> >>> ---
[...] >>> /** >>> * 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
