summaryrefslogtreecommitdiff
path: root/drivers/firmware/qcom
AgeCommit message (Collapse)Author
9 daysfirmware: qcom: scm: Add minidump SRAM supportMukesh Ojha
On most Qualcomm SoCs where minidump is supported, a word in always-on SRAM is shared between the operating system (OS) and boot firmware. Before DDR is initialized on the warm reset following a crash, firmware reads this word to decide if minidump is enabled and collect a minidump, and where to deliver it (USB upload to a host, or save to local storage). The OS is expected to select one of the destinations. The SRAM region is described by a 'sram' phandle on the SCM DT node. If the property is absent the feature is silently disabled, keeping existing SoCs unaffected. Expose a 'minidump_dest' module parameter (default: usb) so the user can select the destination. Only the string names "usb" or "storage" are accepted. 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/20260624190830.3131112-6-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
9 daysfirmware: qcom: scm: use dev_err_probe() for dload address failureMukesh Ojha
Replace the bare `return ret` after qcom_scm_find_dload_address() with dev_err_probe() to produce a consistent, deferred-probe-aware error message when the download-mode address cannot be resolved. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-5-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
9 daysfirmware: qcom: scm: Fix missing smp_load_acquire()Mukesh Ojha
__scm is published in qcom_scm_probe() with smp_store_release() but qcom_scm_set_download_mode() reads it directly without smp_load_acquire(), creating a potential ordering violation where a CPU could observe a stale or partially initialised __scm pointer. Use smp_load_acquire() to acquire __scm in the qcom_scm_set_download_mode() function. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260624190830.3131112-4-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
11 daysfirmware: qcom: scm: Allow QSEECOM on Honor Magicbook Art 14Konstantin Shabanov
Allow particular machine accessing eg. efivars. Signed-off-by: Konstantin Shabanov <mail@etehtsea.me> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260629154812.9066-5-mail@etehtsea.me Signed-off-by: Bjorn Andersson <andersson@kernel.org>
11 daysfirmware: qcom: scm: instrument SMC call path with tracepointsYuvaraj Ranganathan
Wire the five tracepoints defined in qcom_scm_trace.h into the SMC execution path by including the header with CREATE_TRACE_POINTS. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Yuvaraj Ranganathan <yuvaraj.ranganathan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260522-scm-tracepoints-v2-2-e27cdbe0c585@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
11 daysfirmware: qcom: scm: add trace events for the SMC call interfaceYuvaraj Ranganathan
The SCM SMC call path is opaque at runtime. Stalls caused by firmware congestion, QCOM_SCM_WAITQ_SLEEP/RESUME cycles, and EBUSY retry loops are invisible without recompiling the kernel with temporary printk statements or attaching a hardware debugger. Add five TRACE_EVENTs covering the complete lifecycle of an SCM call: scm_smc_request Emit before each arm_smccc_smc_quirk() invocation. Records the SMC function ID, decoded service and command identifiers, argument count, and up to six register arguments in hex and decimal. Because the caller loops on QCOM_SCM_INTERRUPTED, this event fires once per physical SMC instruction including inte scm_smc_done Emit after the outer __scm_smc_do() returns, pairing each request with its final outcome. Records the SMC function ID, the kernel error code returned to the caller, and the four firmware result registers a0-a3. scm_waitq_sleep Emit when the firmware returns QCOM_SCM_WAITQ_SLEEP. Records the wait-queue context and the SMC call context handles required to issue the matching WAITQ_RESUME. scm_waitq_resume Emit just before constructing and sending the WAITQ_RESUME follow-up call. Records the SMC call context handle being resumed. scm_waitq_get_wq_ctx Emit after a successful WAITQ_GET_WQ_CTX fast-call. Records the returned wait-queue context, flags, and more_pending indicator. These events let ftrace and perf reconstruct the full sequence of firmware interactions, measure per-call and end-to-end latency, and attribute waitqueue stalls to specific service/command pairs without modifying driver source. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Yuvaraj Ranganathan <yuvaraj.ranganathan@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260522-scm-tracepoints-v2-1-e27cdbe0c585@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
13 daysfirmware: qcom: Add a PAS TEE serviceSumit Garg
Add support for Peripheral Authentication Service (PAS) driver based on TEE bus with OP-TEE providing the backend PAS service implementation. The TEE PAS service ABI is designed to be extensible with additional API as PTA_QCOM_PAS_CAPABILITIES. This allows to accommodate any future extensions of the PAS service needed while still maintaining backwards compatibility. Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650 Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260702115835.167602-4-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
13 daysfirmware: qcom_scm: Migrate to generic PAS serviceSumit Garg
With the availability of generic PAS service, let's add SCM calls as a backend to keep supporting legacy QTEE interfaces. The exported qcom_scm* wrappers will get dropped once all the client drivers get migrated as part of future patches. Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260702115835.167602-3-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
13 daysfirmware: qcom: Add a generic PAS serviceSumit Garg
Qcom platforms has the legacy of using non-standard SCM calls splintered over the various kernel drivers. These SCM calls aren't compliant with the standard SMC calling conventions which is a prerequisite to enable migration to the FF-A specifications from Arm. OP-TEE as an alternative trusted OS to Qualcomm TEE (QTEE) can't support these non-standard SCM calls. And even for newer architectures using S-EL2 with Hafnium support, QTEE won't be able to support SCM calls either with FF-A requirements coming in. And with both OP-TEE and QTEE drivers well integrated in the TEE subsystem, it makes further sense to reuse the TEE bus client drivers infrastructure. The added benefit of TEE bus infrastructure is that there is support for discoverable/enumerable services. With that client drivers don't have to manually invoke a special SCM call to know the service status. So enable the generic Peripheral Authentication Service (PAS) provided by the firmware. It acts as the common layer with different TZ backends plugged in whether it's an SCM implementation or a proper TEE bus based PAS service implementation. Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Tested-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> # Lemans Reviewed-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Tested-by: Vignesh Viswanathan <vignesh.viswanathan@oss.qualcomm.com> # IPQ9650 Signed-off-by: Sumit Garg <sumit.garg@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260702115835.167602-2-sumit.garg@kernel.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-05-13firmware: qcom: scm: Allow QSEECOM on Surface Pro 12inHarrison Vanderbyl
Add the Surface Pro 12in to the QSEECOM allowlist so that the Qualcomm Secure Execution Environment interface is available on this device. Signed-off-by: Harrison Vanderbyl <harrison.vanderbyl@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/92171ad5e7851e6758dd205246b4289f32e12655.1778498477.git.harrison.vanderbyl@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-04-02firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini XBjorn Andersson
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>
2026-03-30firmware: qcom: scm: Register gunyah watchdog deviceHrishabh Rajput
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>
2026-03-30firmware: qcom: scm: Allow QSEECOM on Mahua CRDGopikrishna Garmidi
Add Mahua CRD board to the QSEECOM allowlist for enabling access to efivars and uefi bootloader. Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260322-mahua-qcom_scm-support-v1-1-00c50db332ee@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-23firmware: qcom_scm: don't opencode kmemdupMukesh Ojha
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>
2026-03-18firmware: qcom: scm: Allow QSEECOM on Glymur CRDPankaj Patil
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>
2026-03-18firmware: qcom: scom: Simplify mutex with guardKrzysztof Kozlowski
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>
2026-03-18firmware: qcom: uefisecapp: Annotate acquiring locks for context trackingKrzysztof Kozlowski
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>
2026-03-18firmware: qcom: uefisecapp: Simplify mutex with guardKrzysztof Kozlowski
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-4-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-03-04firmware: qcom: scm: Allow QSEECOM on ECS LIVA QC710Val Packett
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>
2026-03-04firmware: qcom: scm: Allow QSEECOM on PURWA-IOT-EVKYijie Yang
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>
2026-02-25firmware: qcom: scm: allow QSEECOM on ASUS Vivobook X1P42100 variantJens Glathe
Enables access to EFI variables on this machine. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Tested-by: Colin K. Williams <colin@li-nk.org> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20260214-b4-vivobook-v3-2-3c88065bbf77@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-02-21Convert more 'alloc_obj' cases to default GFP_KERNEL argumentsLinus Torvalds
This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-10Merge tag 'soc-dt-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/socLinus Torvalds
Pull SoC devicetree updates from Arnd Bergmann: "There are a handful of new SoCs this time, all of these are more or less related to chips in a wider family: - SpacemiT Key Stone K3 is an 8-core risc-v chip, and the first widely available RVA23 implementation. Note that this is entirely unrelated with the similarly named Texas Instruments K3 chip family that follwed the TI Keystone2 SoC. - The Realtek Kent family of SoCs contains three chip models rtd1501s, rtd1861b and rtd1920s, and is related to their earlier Set-top-box and NAS products such as rtd1619, but is built on newer Arm Cortex-A78 cores. - The Qualcomm Milos family includes the Snapdragon 7s Gen 3 (SM7635) mobile phone SoC built around Armv9 Kryo cores of the Arm Cortex-A720 generation. This one is used in the Fairphone Gen 6 - Qualcomm Kaanapali is a new SoC based around eight high performance Oryon CPU cores - NXP i.MX8QP and i.MX952 are both feature reduced versions of chips we already support, i.e. the i.MX8QM and i.MX952, with fewer CPU cores and I/O interfaces. As part of a cleanup, a number of SoC specific devicetree files got removed because they did not have a single board using the .dtsi files and they were never compile tested as a result: Samsung s3c6400, ST spear320s, ST stm32mp21xc/stm32mp23xc/stm32mp25xc, Renesas r8a779m0/r8a779m2/r8a779m4/r8a779m6/r8a779m7/r8a779m8/r8a779mb/ r9a07g044c1/r9a07g044l1/r9a07g054l1/r9a09g047e37, and TI am3703/am3715. All of these could be restored easily if a new board gets merged. Broadcom/Cavium/Marvell ThunderX2 gets removed along with its only machine, as all remaining users are assumed to be using ACPI based firmware. A relatively small number of 43 boards get added this time, and almost all of them for arm64. Aside from the reference boards for the newly added SoCs, this includes: - Three server boards use 32-bit ASpeed BMCs - One more reference board for 32-bit Microchip LAN9668 - 64-bit Arm single-board computers based on Amlogic s905y4, CIX sky1, NXP ls1028a/imx8mn/imx8mp/imx91/imx93/imx95, Qualcomm qcs6490/qrb2210 and Rockchip rk3568/rk3588s - Carrier board for SOMs using Intel agilex5, Marvell Armada 7020, NXP iMX8QP, Mediatek mt8370/mt8390 and rockchip rk3588 - Two mobile phones using Snapdragon 845 - A gaming device and a NAS box, both based on Rockchips rk356x On top of the newly added boards and SoCs, there is a lot of background activity going into cleanups, in particular towards getting a warning-free dtc build, and the usual work on adding support for more hardware on the previously added machines" * tag 'soc-dt-7.0' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (757 commits) dt-bindings: intel: Add Agilex eMMC support arm64: dts: socfpga: agilex: add emmc support arm64: dts: intel: agilex5: Add simple-bus node on top of dma controller node ARM: dts: socfpga: fix dtbs_check warning for fpga-region ARM: dts: socfpga: add #address-cells and #size-cells for sram node dt-bindings: altera: document syscon as fallback for sys-mgr arm64: dts: altera: Use lowercase hex dt-bindings: arm: altera: combine Intel's SoCFPGA into altera.yaml arm64: dts: socfpga: agilex5: Add IOMMUS property for ethernet nodes arm64: dts: socfpga: agilex5: add support for modular board dt-bindings: intel: Add Agilex5 SoCFPGA modular board arm64: dts: socfpga: agilex5: Add dma-coherent property arm64: dts: realtek: Add Kent SoC and EVB device trees dt-bindings: arm: realtek: Add Kent Soc family compatibles ARM: dts: samsung: Drop s3c6400.dtsi ARM: dts: nuvoton: Minor whitespace cleanup MAINTAINERS: Add Falcon DB arm64: dts: a7k: add COM Express boards ARM: dts: microchip: Drop usb_a9g20-dab-mmx.dtsi arm64: dts: rockchip: Fix rk3588 PCIe range mappings ...
2026-01-13Merge branch '20260105-kvmrprocv10-v10-0-022e96815380@oss.qualcomm.com' into ↵Bjorn Andersson
drivers-for-6.20 Merge the support for loading and managing the TrustZone-based remote processors found in the Glymur platform through a topic branch, as it's a mix of qcom-soc and remoteproc patches.
2026-01-13firmware: qcom_scm: Add qcom_scm_pas_get_rsc_table() to get resource tableMukesh Ojha
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>
2026-01-13firmware: qcom_scm: Add SHM bridge handling for PAS when running without QHEEMukesh Ojha
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>
2026-01-13firmware: qcom_scm: Refactor qcom_scm_pas_init_image()Mukesh Ojha
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>
2026-01-13firmware: qcom_scm: Add a prep version of auth_and_reset functionMukesh Ojha
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>
2026-01-13remoteproc: pas: Replace metadata context with PAS context structureMukesh Ojha
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>
2026-01-13firmware: qcom_scm: Introduce PAS context allocator helper functionMukesh Ojha
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>
2026-01-13firmware: qcom_scm: Rename peripheral as pas_idMukesh Ojha
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>
2026-01-13firmware: qcom_scm: Remove redundant piece of codeMukesh Ojha
The qcom_scm_pas_metadata_release() function already frees the allocated memory and sets ctx->ptr to NULL. Resetting ctx->phys and ctx->size to zero is unnecessary because the context is expected to be discarded after release. Lets removes redundant assignments. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260105-kvmrprocv10-v10-2-022e96815380@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2026-01-03firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()Unnathi Chalicheemala
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>
2026-01-03firmware: qcom_scm: Support multiple waitq contextsUnnathi Chalicheemala
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>
2026-01-03firmware: qcom_scm: Add API to get waitqueue IRQ infoUnnathi Chalicheemala
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>
2026-01-03firmware: qcom: scm: allow QSEECOM on Surface Pro 11Dale Whinham
Enables access to EFI variables on this machine. Signed-off-by: Dale Whinham <daleyo@gmail.com> Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251220-surface-sp11-for-next-v6-2-81f7451edb77@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-12-16firmware: qcom: scm: QSEECOM on Medion SPRCHRGD 14 S1Georg Gottleuber
This is needed to access EFI variables from Linux. Signed-off-by: Ettore Chimenti <ettore.chimenti@linaro.org> Signed-off-by: Georg Gottleuber <ggo@tuxedocomputers.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251204155212.230058-7-ggo@tuxedocomputers.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-11-26firmware: qcom: scm: Simplify with of_machine_device_match()Krzysztof Kozlowski
Replace open-coded getting root OF node and matching against it with new of_machine_device_match() helper. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20251112-b4-of-match-matchine-data-v2-6-d46b72003fd6@linaro.org Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
2025-09-15Merge branch ↵Bjorn Andersson
'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.
2025-09-15firmware: qcom: scm: add support for object invocationAmirreza Zarrabi
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>
2025-09-15firmware: qcom: tzmem: export shm_bridge create/deleteAmirreza Zarrabi
Anyone with access to contiguous physical memory should be able to share memory with QTEE using shm_bridge. Tested-by: Neil Armstrong <neil.armstrong@linaro.org> Tested-by: Harshal Dev <quic_hdev@quicinc.com> Reviewed-by: Kuldeep Singh <quic_kuldsing@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-1-17f07a942b8d@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-09-11firmware: qcom: tzmem: disable sc7180 platformNikita Travkin
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>
2025-09-01firmware: qcom: scm: Allow QSEECOM on Dell Inspiron 7441 / Latitude 7455Val Packett
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>
2025-09-01firmware: qcom: scm: Allow QSEECOM on Lenovo Thinkbook 16Jens Glathe
Allow particular machine accessing eg. efivars. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz> Link: https://lore.kernel.org/r/20250822-tb16-dt-v12-2-bab6c2986351@oldschoolsolutions.biz Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-08-11firmware: qcom: scm: Allow QSEECOM on HAMOA-IOT-EVKYijie Yang
Add the Hamoa-IoT-EVK board to the list to enable access to EFI variables. Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250804-hamoa_initial-v4-2-19edbb28677b@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-08-11firmware: qcom: scm: preserve assign_mem() error return valueMukesh Ojha
When qcom_scm_assign_mem() fails, the error value is currently being overwritten after it is logged, resulting in the loss of the original error code. Fix this by retaining and returning the original error value as intended. Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250807124451.2623019-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-07-16firmware: qcom: scm: request the waitqueue irq *after* initializing SCMBartosz Golaszewski
There's a subtle race in the SCM driver: we assign the __scm pointer before requesting the waitqueue interrupt. Assigning __scm marks the SCM API as ready to accept calls. It's possible that a user makes a call right after we set __scm and the firmware raises an interrupt before the driver's ready to service it. Move the __scm assignment after we request the interrupt. This has the added benefit of allowing us to drop the goto label. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20250630-qcom-scm-race-v2-4-fa3851c98611@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2025-07-16firmware: qcom: scm: initialize tzmem before marking SCM as availableBartosz Golaszewski
Now that qcom_scm_shm_bridge_enable() uses the struct device passed to it as argument to make the QCOM_SCM_MP_SHM_BRIDGE_ENABLE SCM call, we can move the TZMem initialization before the assignment of the __scm pointer in the SCM driver (which marks SCM as ready to users) thus fixing the potential race between consumer calls and the memory pool initialization. Reported-by: Johan Hovold <johan+linaro@kernel.org> Closes: https://lore.kernel.org/all/20250120151000.13870-1-johan+linaro@kernel.org/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Link: https://lore.kernel.org/r/20250630-qcom-scm-race-v2-3-fa3851c98611@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org>
generated by cgit v1.2.3 (git 2.39.1) at 2026-07-22 11:13:25 +0000