firmware: qcom_scm: Support multiple waitq contexts - #1167
Open
Shiraz Hashim (shashim-quic) wants to merge 4 commits into
Open
Shiraz Hashim (shashim-quic) wants to merge 4 commits into
Shiraz Hashim (shashim-quic) wants to merge 4 commits into
Conversation
Shiraz Hashim (shashim-quic)
requested review from
a team,
aiquny,
Salendarsingh Gaud (sgaud-quic) and
Trilok Soni (trsoni)
September 22, 2026 13:57
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
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: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
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: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
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: Shiraz Hashim <shiraz.hashim@oss.qualcomm.com>
Shiraz Hashim (shashim-quic)
force-pushed
the
scm-waitq
branch
from
September 22, 2026 14:16
038d71e to
15a6257
Compare
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
… is published In qcom_scm_probe(), devm_request_threaded_irq() is called before smp_store_release(&__scm, scm). Two paths can dereference __scm before it is published, both causing a NULL pointer dereference. The IRQ handler receives scm via its data argument but passes only wq_ctx to qcom_scm_waitq_wakeup() and qcom_scm_get_completion(), which then dereference __scm directly. Thread scm through both functions so the IRQ handler path never touches __scm. Non-atomic SMC calls made during probe (e.g. from qcom_tzmem_init via qcom_scm_shm_bridge_enable) can return WAITQ_SLEEP, causing qcom_scm_wait_for_wq_completion() to run before __scm is published and dereference it. Add platform_set_drvdata(pdev, scm) early in probe and change qcom_scm_wait_for_wq_completion() to take the device pointer and use dev_get_drvdata() to reach scm, removing any dependency on __scm. Fixes: 6bf3259 ("firmware: qcom: scm: Add wait-queue handling logic") Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.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/20260724094939.613844-2-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.