| 8b9d2050 | 05-Jan-2026 |
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> |
firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table
Qualcomm remote processor may rely on Static and Dynamic resources for it to be functional. Static resources are fixed like
firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table
Qualcomm remote processor may rely on Static and Dynamic resources for it to be functional. Static resources are fixed like for example, memory-mapped addresses required by the subsystem and dynamic resources, such as shared memory in DDR etc., are determined at runtime during the boot process.
For most of the Qualcomm SoCs, when run with Gunyah or older QHEE hypervisor, all the resources whether it is static or dynamic, is managed by the hypervisor. Dynamic resources if it is present for a remote processor will always be coming from secure world via SMC call while static resources may be present in remote processor firmware binary or it may be coming qcom_scm_pas_get_rsc_table() SMC call along with dynamic resources.
Some of the remote processor drivers, such as video, GPU, IPA, etc., do not check whether resources are present in their remote processor firmware binary. In such cases, the caller of this function should set input_rt and input_rt_size as NULL and zero respectively. Remoteproc framework has method to check whether firmware binary contain resources or not and they should be pass resource table pointer to input_rt and resource table size to input_rt_size and this will be forwarded to TrustZone for authentication. TrustZone will then append the dynamic resources and return the complete resource table in the passed output buffer.
More about documentation on resource table format can be found in include/linux/remoteproc.h
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-11-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| b0199258 | 05-Jan-2026 |
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> |
firmware: qcom_scm: Add SHM bridge handling for PAS when running without QHEE
On SoCs running with a non-Gunyah-based hypervisor, Linux must take responsibility for creating the SHM bridge both for
firmware: qcom_scm: Add SHM bridge handling for PAS when running without QHEE
On SoCs running with a non-Gunyah-based hypervisor, Linux must take responsibility for creating the SHM bridge both for metadata (before calling qcom_scm_pas_init_image()) and for remoteproc memory (before calling qcom_scm_pas_auth_and_reset()). We have taken care the things required for qcom_scm_pas_auth_and_reset(). Lets put these awareness of above conditions into qcom_scm_pas_init_image() and qcom_scm_pas_metadata_release().
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-10-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 223a8716 | 05-Jan-2026 |
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> |
firmware: qcom_scm: Refactor qcom_scm_pas_init_image()
Refactor qcom_scm_pas_init_image() by moving the memory allocation, copy, and free operations to a higher-level function, and isolate the actua
firmware: qcom_scm: Refactor qcom_scm_pas_init_image()
Refactor qcom_scm_pas_init_image() by moving the memory allocation, copy, and free operations to a higher-level function, and isolate the actual SMC call in a separate function. The main intention is to allow flexibility for different allocators and to respect any constraints that the allocator API may impose before invoking the actual SCM function.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-9-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 4a7d6a78 | 05-Jan-2026 |
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> |
firmware: qcom_scm: Add a prep version of auth_and_reset function
For memory passed to TrustZone (TZ), it must either be part of a pool registered with TZ or explicitly registered via SHMbridge SMC
firmware: qcom_scm: Add a prep version of auth_and_reset function
For memory passed to TrustZone (TZ), it must either be part of a pool registered with TZ or explicitly registered via SHMbridge SMC calls. When Gunyah hypervisor is present, PAS SMC calls from Linux running at EL1 are trapped by Gunyah running @ EL2, which handles SHMbridge creation for both metadata and remoteproc carveout memory before invoking the calls to TZ.
On SoCs running with a non-Gunyah-based hypervisor, Linux must take responsibility for creating the SHM bridge before invoking PAS SMC calls. For the auth_and_reset() call, the remoteproc carveout memory must first be registered with TZ via a SHMbridge SMC call and once authentication and reset are complete, the SHMbridge memory can be deregistered.
Introduce qcom_scm_pas_prepare_and_auth_reset(), which sets up the SHM bridge over the remoteproc carveout memory when Linux operates at EL2. This behavior is indicated by a new field added to the PAS context data structure. The function then invokes the auth_and_reset SMC call.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-8-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| b13d8baf | 05-Jan-2026 |
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> |
remoteproc: pas: Replace metadata context with PAS context structure
As a superset of the existing metadata context, the PAS context structure enables both remoteproc and non-remoteproc subsystems t
remoteproc: pas: Replace metadata context with PAS context structure
As a superset of the existing metadata context, the PAS context structure enables both remoteproc and non-remoteproc subsystems to better support scenarios where the SoC runs with or without the Gunyah hypervisor. To reflect this, relevant SCM and metadata functions are updated to incorporate PAS context awareness and remove metadata context data structure completely.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-5-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| ccb7bde5 | 05-Jan-2026 |
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> |
firmware: qcom_scm: Introduce PAS context allocator helper function
When the Peripheral Authentication Service (PAS) method runs on a SoC where Linux operates at EL2 (i.e., without the Gunyah hyperv
firmware: qcom_scm: Introduce PAS context allocator helper function
When the Peripheral Authentication Service (PAS) method runs on a SoC where Linux operates at EL2 (i.e., without the Gunyah hypervisor), the reset sequences are handled by TrustZone. In such cases, Linux must perform additional steps before invoking PAS SMC calls, such as creating a SHM bridge. Therefore, PAS SMC calls require awareness and handling of these additional steps when Linux runs at EL2.
To support this, there is a need for a data structure that can be initialized prior to invoking any SMC or MDT functions. This structure allows those functions to determine whether they are operating in the presence or absence of the Gunyah hypervisor and behave accordingly.
Currently, remoteproc and non-remoteproc subsystems use different variants of the MDT loader helper API, primarily due to differences in metadata context handling. Remoteproc subsystems retain the metadata context until authentication and reset are completed, while non-remoteproc subsystems (e.g., video, graphics, IPA, etc.) do not retain the metadata context and can free it within the qcom_scm_pas_init() call by passing a NULL context parameter and due to these differences, it is not possible to extend metadata context handling to support remoteproc and non remoteproc subsystem use PAS operations, when Linux operates at EL2.
Add PAS context data structure allocator helper function.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-4-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 69054348 | 05-Jan-2026 |
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> |
firmware: qcom_scm: Rename peripheral as pas_id
Peripheral and pas_id refers to unique id for a subsystem and used only when peripheral authentication service from secure world is utilized.
Lets re
firmware: qcom_scm: Rename peripheral as pas_id
Peripheral and pas_id refers to unique id for a subsystem and used only when peripheral authentication service from secure world is utilized.
Lets rename peripheral to pas_id to reflect closer to its meaning.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-3-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 366f05e3 | 17-Dec-2025 |
Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> |
firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()
When the kernel issues an SMC (Secure Monitor Call) and the firmware requests the kernel to wait, the waiting thread enters an uni
firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()
When the kernel issues an SMC (Secure Monitor Call) and the firmware requests the kernel to wait, the waiting thread enters an uninterruptible (D) state. In case of an extended wait request by the firmware, any device suspend request, cannot proceed because of the thread stuck in D state. This blocks the device suspend.
Replace wait_for_completion() with wait_for_completion_state(..., TASK_IDLE), so that the waiting thread, show up in TASK_IDLE state, instead of TASK_UNINTERRUPTIBLE (D state). This allows the thread to block until completion, without blocking the device suspend.
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <brgl@kernel.org> Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-3-f21e50e792b8@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| ccd207ec | 17-Dec-2025 |
Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> |
firmware: qcom_scm: Support multiple waitq contexts
Currently, only a single waitqueue context exists in the driver. Multi-waitqueue mechanism is added in firmware to support the case, when multiple
firmware: qcom_scm: Support multiple waitq contexts
Currently, only a single waitqueue context exists in the driver. Multi-waitqueue mechanism is added in firmware to support the case, when multiple VMs make SMC calls or single VM making multiple calls on same CPU. Enhance the driver to support multiple waitqueue when support is present in the firmware.
When VMs make a SMC call, firmware allocates a waitqueue context, assuming the SMC call to be a blocking call. The SMC calls that cannot acquire resources, while execution in firmware, are returned to sleep in the calling VM. When the resource becomes available in the firmware, the VM gets notified to wake the sleeping thread and resume SMC call. The current qcom_scm driver supports single waitqueue as the old firmwares support only single waitqueue with waitqueue id zero. Multi-waitqueue mechanism is added in firmware starting SM8650 to support the case when multiple VMs make SMC calls or single VM making multiple calls on same CPU. To enable this support in qcom_scm driver, add support for handling multiple waitqueues. For instance, SM8650 firmware can allocate two such waitq contexts, so the driver needs to implement two waitqueue contexts. For a generalized approach, the number of supported waitqueues can be queried from the firmware using a SMC call.
Introduce qcom_scm_query_waitq_count to get the number of waitqueue contexts supported by the firmware and allocate “N” unique waitqueue contexts with a dynamic sized array where each unique wq_ctx is associated with a struct completion variable for easy lookup. Older targets which support only a single waitqueue, may return an error for qcom_scm_query_waitq_count, set the wq_cnt to one for such failures.
Reviewed-by: Bartosz Golaszewski <brgl@kernel.org> Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-2-f21e50e792b8@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| da9e6b1a | 17-Dec-2025 |
Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> |
firmware: qcom_scm: Add API to get waitqueue IRQ info
Bootloader and firmware for SM8650 and older chipsets expect node name as "qcom_scm", in order to patch the wait queue IRQ information. However,
firmware: qcom_scm: Add API to get waitqueue IRQ info
Bootloader and firmware for SM8650 and older chipsets expect node name as "qcom_scm", in order to patch the wait queue IRQ information. However, DeviceTree uses node name "scm" and this mismatch prevents firmware from correctly identifying waitqueue IRQ information. Waitqueue IRQ is used for signaling between secure and non-secure worlds.
To resolve this, introduce qcom_scm_get_waitq_irq() that'll get the hardware IRQ number to be used from firmware instead of relying on data provided by devicetree, thereby bypassing the DeviceTree node name mismatch.
This hardware IRQ number is converted to a Linux IRQ number using newly qcom_scm_fill_irq_fwspec_params(). This Linux IRQ number is then supplied to the threaded_irq call.
Reviewed-by: Bartosz Golaszewski <brgl@kernel.org> Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com> Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251217-multi_waitq_scm-v11-1-f21e50e792b8@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 0ea45354 | 15-Sep-2025 |
Bjorn Andersson <andersson@kernel.org> |
Merge branch '20250911-qcom-tee-using-tee-ss-without-mem-obj-v12-2-17f07a942b8d@oss.qualcomm.com' into drivers-for-6.18
Merge the addition of support for object invocation into the SCM driver though
Merge branch '20250911-qcom-tee-using-tee-ss-without-mem-obj-v12-2-17f07a942b8d@oss.qualcomm.com' into drivers-for-6.18
Merge the addition of support for object invocation into the SCM driver though a topic branch, to enable sharing this with TEE subsystem.
show more ...
|
| 4b700098 | 12-Sep-2025 |
Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com> |
firmware: qcom: scm: add support for object invocation
Qualcomm TEE (QTEE) hosts Trusted Applications (TAs) and services in the secure world, accessed via objects. A QTEE client can invoke these obj
firmware: qcom: scm: add support for object invocation
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> Link: https://lore.kernel.org/r/20250911-qcom-tee-using-tee-ss-without-mem-obj-v12-2-17f07a942b8d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 3cc9a8ca | 21-Jul-2025 |
Nikita Travkin <nikita@trvn.ru> |
firmware: qcom: tzmem: disable sc7180 platform
When SHM bridge is enabled, assigning RMTFS memory causes the calling core to hang if the system is running in EL1.
Disable SHM bridge on sc7180 devic
firmware: qcom: tzmem: disable sc7180 platform
When SHM bridge is enabled, assigning RMTFS memory causes the calling core to hang if the system is running in EL1.
Disable SHM bridge on sc7180 devices to avoid that hang.
Signed-off-by: Nikita Travkin <nikita@trvn.ru> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250721-sc7180-shm-hang-v1-1-99ad9ffeb5b4@trvn.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 30ee285f | 16-Jul-2025 |
Val Packett <val@packett.cool> |
firmware: qcom: scm: Allow QSEECOM on Dell Inspiron 7441 / Latitude 7455
Allow these machines to access efivars through qseecom/uefisecapp.
Signed-off-by: Val Packett <val@packett.cool> Reviewed-by
firmware: qcom: scm: Allow QSEECOM on Dell Inspiron 7441 / Latitude 7455
Allow these machines to access efivars through qseecom/uefisecapp.
Signed-off-by: Val Packett <val@packett.cool> Reviewed-by: Laurentiu Tudor <laurentiu.tudor1@dell.com> Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250716003139.18543-5-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|