| a31ad933 | 02-Apr-2026 |
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com> |
firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X
The Hamoa-based Lenovo IdeaCentre Mini X provides the same UEFI variable
access through uefisecapp as other Hamoa devices, add it to th
firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X
The Hamoa-based Lenovo IdeaCentre Mini X provides the same UEFI variable
access through uefisecapp as other Hamoa devices, add it to the
allowlist.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260401-ideacentre-v2-3-5745fe2c764e@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 07b97123 | 11-Mar-2026 |
Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com> |
firmware: qcom: scm: Register gunyah watchdog device
To restrict Gunyah watchdog initialization to Qualcomm platforms running
under the Gunyah Hypervisor, register the watchdog device in the QCOM
SC
firmware: qcom: scm: Register gunyah watchdog device
To restrict Gunyah watchdog initialization to Qualcomm platforms running
under the Gunyah Hypervisor, register the watchdog device in the QCOM
SCM driver.
When Gunyah is not present or Gunyah emulates MMIO-based watchdog, we
expect Qualcomm watchdog or ARM SBSA watchdog device to be present in
the devicetree. First, we make sure we're running under the Gunyah
Hypervisor. Then we move to check if any of the above mentioned
watchdog device nodes are present, if not then we proceed to register
the SMC-based Gunyah watchdog device.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Tested-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Hrishabh Rajput <hrishabh.rajput@oss.qualcomm.com>
Signed-off-by: Pavankumar Kondeti <pavan.kondeti@oss.qualcomm.com>
Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260311-gunyah_watchdog-v8-1-4c1c0689de22@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| e3270172 | 10-Mar-2026 |
Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> |
firmware: qcom_scm: don't opencode kmemdup
Lets not opencode kmemdup which is reported by coccinelle tool.
Fix it using kmemdup.
cocci warnings: (new ones prefixed by >>)
>> drivers/firmware/qcom/q
firmware: qcom_scm: don't opencode kmemdup
Lets not opencode kmemdup which is reported by coccinelle tool.
Fix it using kmemdup.
cocci warnings: (new ones prefixed by >>)
>> drivers/firmware/qcom/qcom_scm.c:916:11-18: WARNING opportunity for kmemdup
Fixes: 8b9d2050cfa0 ("firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource table")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202601142144.HvSlBSI9-lkp@intel.com/
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/20260310140255.2520230-1-mukesh.ojha@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 87a1698c | 25-Feb-2026 |
Pankaj Patil <pankaj.patil@oss.qualcomm.com> |
firmware: qcom: scm: Allow QSEECOM on Glymur CRD
Add glymur-crd to QSEECOM allowlist for enabling access to efivars and
uefi bootloader
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
R
firmware: qcom: scm: Allow QSEECOM on Glymur CRD
Add glymur-crd to QSEECOM allowlist for enabling access to efivars and
uefi bootloader
Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260225-qseecom_glymur-v1-1-0cafc709e2ef@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| d98b9784 | 16-Feb-2026 |
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> |
firmware: qcom: scom: Simplify mutex with guard
Simplify error path unlocking mutex with the guard.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dyb
firmware: qcom: scom: Simplify mutex with guard
Simplify error path unlocking mutex with the guard.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260216091525.107935-6-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 4bfb0ec1 | 16-Feb-2026 |
Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> |
firmware: qcom: uefisecapp: Annotate acquiring locks for context tracking
qcuefi_acquire() and qcuefi_release() end with mutex locked or unlocked
respectively, so annotate them so the lock usage wil
firmware: qcom: uefisecapp: Annotate acquiring locks for context tracking
qcuefi_acquire() and qcuefi_release() end with mutex locked or unlocked
respectively, so annotate them so the lock usage will be tracked by
context tracking tools.
Note that mutex is tracked since commit 370f0a345a70 ("locking/mutex:
Support Clang's context analysis").
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260216091525.107935-5-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 34a49e85 | 21-Jan-2026 |
Val Packett <val@packett.cool> |
firmware: qcom: scm: Allow QSEECOM on ECS LIVA QC710
Allow this machine to access efivars through qseecom/uefisecapp.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by
firmware: qcom: scm: Allow QSEECOM on ECS LIVA QC710
Allow this machine to access efivars through qseecom/uefisecapp.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Val Packett <val@packett.cool>
Link: https://lore.kernel.org/r/20260120234029.419825-11-val@packett.cool
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 0924a6fb | 02-Feb-2026 |
Yijie Yang <yijie.yang@oss.qualcomm.com> |
firmware: qcom: scm: Allow QSEECOM on PURWA-IOT-EVK
Add the Purwa-IoT-EVK board to the list to enable access to EFI variables.
Guarantee that subsystems relying on SCM services can access secure-wo
firmware: qcom: scm: Allow QSEECOM on PURWA-IOT-EVK
Add the Purwa-IoT-EVK board to the list to enable access to EFI variables.
Guarantee that subsystems relying on SCM services can access secure-world
features. This change improves reliability and prevents missing
functionality or boot-time issues by making service availability explicit.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260202073555.1345260-2-yijie.yang@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
show more ...
|
| 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 ...
|