media: iris,venus: Add secure PAS backend support enhancements for OP-TEE - #1849
gouravk-qualcomm wants to merge 8 commits into
Conversation
…MMU handling" This reverts commit bfab35e. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com>
This reverts commit 6852eb7. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com>
…anaged by Linux" This reverts commit a41bd3e. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com>
…y Linux On platforms where a hypervisor is present, all Secure Monitor Calls (SMC) are intercepted. For qcom_scm_pas_auth_and_reset(), the hypervisor registers a Shared Memory (SHM) bridge over the Peripheral Image Loader (PIL) memory region so that TrustZone (TZ) can access it, forwards the authentication SMC to TZ, and upon return maps the PIL region and triggers the co-processor bring-up sequence: HLOS -> Hypervisor(SHM setup) -> TZ(auth) -> Hypervisor(map+reset) -> IRIS On platforms without a hypervisor, Linux drives these steps directly. The SHM bridge infrastructure required for this is already upstream [1]. To isolate firmware memory in its own Input-Output Memory Management Unit (IOMMU) context, a dedicated stream ID (SID) is required, tied to the firmware function ID. This SID is specified via the iommu-map property in the device tree using the firmware function ID as the lookup key. A firmware device is created and mapped to this SID. The presence of a SID mapped to the firmware device via iommu-map is used to detect whether a hypervisor is absent: when the firmware device has a SID mapped, Linux manages the IOMMU directly; when no SID is mapped, a hypervisor is assumed to be present and these steps are skipped. Extend the Iris driver to support Secure Peripheral Authentication Service (PAS) on platforms where Linux manages the IOMMU, by creating the firmware context device and performing the necessary IOMMU mapping when the firmware device SID is present. [1] https://lore.kernel.org/lkml/20260105-kvmrprocv10-v10-0-022e96815380 @oss.qualcomm.com/ Link: https://lore.kernel.org/all/20260715-glymur-v9-6-8cf2cbe12a07@oss.qualcomm.com/ Reviewed-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com> Co-developed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/lkml/20260105-kvmrprocv10-v10-0-022e96815380@oss.qualcomm.com/ Signed-off-by: Vishnu Reddy <busanna.reddy@oss.qualcomm.com>
The Qualcomm MDT loader changed qcom_mdt_pas_load() to take only four arguments and use the PAS context for relocation and memory handling. Update the iris firmware loading path to match that interface by dropping the temporary memremap/memunmap flow, removing the extra mem_virt argument from qcom_mdt_pas_load(), and simplifying the error path accordingly. This keeps the iris driver aligned with the SCM/PAS loader changes and fixes the build failure caused by the old five-argument call. Signed-off-by: Gourav Kumar <gouravk@qti.qualcomm.com>
…ling On platforms where PAS is available, firmware authentication and reset are performed via the secure world, while IOMMU configuration may be handled either by Linux or outside of it. Extend the Venus firmware flow to support both PAS and non-PAS setups. When PAS is available, load the firmware using a PAS context and trigger the prepare/auth/reset sequence. If the firmware device is IOMMU-mapped, use its IOMMU domain to map the reserved firmware memory before reset; otherwise, retain the existing secure-world-managed behavior. When PAS is not available, fall back to the existing non-PAS firmware loading path where Linux performs firmware loading and IOMMU mapping. The firmware stream ID is described via the iommu-map function identifier in the device tree. Signed-off-by: Renjiang Han <renjiang.han@oss.qualcomm.com>
qcom_scm_mem_protect_video_var() is only serviced by the SCM backend; with OP-TEE the TEE owns secure memory protection. Use qcom_pas_get_backend() to issue the SCM call only for the SCM backend. Link: https://lore.kernel.org/all/20260911-video-optee-pas-v1-v1-2-7bbddaaac5ba@kernel.org/ Assisted-by: Copilot:claude-opus-4.8 Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez.ortiz@gmail.com> Co-developed-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
qcom_scm_mem_protect_video_var() is only serviced by the SCM backend; with OP-TEE the TEE owns secure memory protection. Use qcom_pas_get_backend() to issue the SCM call only for the SCM backend. Link: https://lore.kernel.org/all/20260911-video-optee-pas-v1-v1-3-7bbddaaac5ba@kernel.org/ Assisted-by: Copilot:claude-opus-4.8 Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
🔨 Build Failure Analysis — PR #1849PR: #1849
VerdictAll 4 merge conflicts are directly introduced by this PR; the PR modifies the exact files that have conflicts during the automerge integration process. 📎 Detailed analysis: Full report |
🔨 Build Failure Analysis — PR #1849PR: #1849
VerdictAll 7+ merge conflicts are pre-existing integration issues unrelated to this PR. The PR itself does not introduce any compilation errors. The failures occurred during the automerge phase when integrating multiple topic branches, not during the build of this PR's changes. 📎 Detailed analysis: Full report |
PR #1849 — validate-patchPR: #1849
Final Summary
|
PR #1849 — checker-log-analyzerPR: #1849
Detailed report: Full report
|
6 participants
This PR adds the remaining updates required for OP-TEE based secure video firmware loading and PAS handling.
When OP-TEE is used as the PAS backend, secure memory ownership and protection are managed by the TEE rather than SCM. In such configurations, SCM-specific memory protection calls are unnecessary and should be avoided. These changes make the video drivers backend-agnostic while preserving compatibility with existing SCM-based platforms.