[PATCH v10 0/3] SCM: Support latest version of waitq-aware firmware

[PATCH v10 0/3] SCM: Support latest version of waitq-aware firmware

[Shivendra Pratap]

This series adds support for the latest improvements made in SCM
firmware that allow for multiple wait-queues in firmware.

To support multi VM synchronization when VMs make SMC calls on same CPU,
waitqueue mechanism is added in firmware which runs at EL2 & EL3 exception
levels.

Thanks to Unnathi for bringing the path to this level of maturity.
P.S. While at Qualcomm, Guru Das Srinagesh authored the initial version of
these patches.
Thanks Guru!

Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>

---
Changes in v10:
- Keeping Reviewed-by from Bartosz
By Mukesh
-firmware: qcom_scm: Add API to get waitqueue IRQ info
 - minor update to commit text.
 - qcom_scm_fill_irq_fwspec_params(): changed name of input parameter
   from virq to hwirq.
 - qcom_scm_get_waitq_irq – declared variables in reverse xmas.
 - qcom_scm_get_waitq_irq - return irq_create_fwspec_mapping directly
   instead of storing return value for return.
firmware: qcom_scm: Support multiple waitq contexts
 - remove error prints form qcom_scm_query_waitq_count.
 - Use `ret < 0` instead of `ret <= 0` to set waitq count as 1.
- Link to v9: https://lore.kernel.org/r/20251123-multi_waitq_scm-v9-0-0080fc259d4d@oss.qualcomm.com

Changes in v9:
By Bart
- Updated commit text for wait_for_completion_state(..., TASK_IDLE).
- Changed variable name of waitq to waitq_comps, to align to its usage.
Others changes
- Move the scm call to get the waitq_count after the clock and memory related
  init in qcom_scm_probe.
- Link to v8: https://lore.kernel.org/r/20251102-multi_waitq_scm-v8-0-d71ee7b93b62@oss.qualcomm.com

Changes in v8:
- Replace "of_node_to_fwnode" with "of_fwnode_handle to align
  with current kernel version.
- Add NULL check for parent_irq_node in function qcom_scm_get_waitq_irq.
- Change declaration of qcom_scm_get_waitq_irq and pass qcom_scm pointer.
- Set the scm->wq_cnt to one, in case where waitqueue is not
  supported by firmware and continue to probe the qcom_scm driver.
- Link to v7: https://lore.kernel.org/all/20250523-multi_waitq_scm-v7-0-5b51b60ed396@oss.qualcomm.com/

Changes in v7:
- Assume failing scm call to mean WAITQ_GET_INFO is not supported on target
  as qcom_scm_is_call_available() is handled in Qualcomm firmware's TZ (EL3),
  which doesn’t implement WAITQ_GET_INFO, and therefore always returns 0.
- Link to v6: https://lore.kernel.org/r/20250425-multi_waitq_scm-v6-0-cba8ca5a6d03@oss.qualcomm.com

Changes in v6:
- Added R-b tag from Bartosz for first patch.
- Check if QCOM_SCM_WAITQ_GET_INFO is available before making scm call,
instead of assuming failing scm call to mean WAITQ_GET_INFO is not
supported on target.
- Add a new patch to check for waitq idle state in wait_for_wq_completion().
- Link to v5: https://lore.kernel.org/all/20250227-multi_waitq_scm-v5-0-16984ea97edf@oss.qualcomm.com/

Changes in v5:
- Use GIC_SPI and GIC_ESPI macros from dt-bindings instead of redefining
- Modified qcom_scm_query_waitq_count to take struct qcom_scm as
argument; scm is anyway stored to global struct __scm after
smp_store_and_release().
- Tested on SM8650 which has multi-waitq support and SM8550, which
doesn't. No error logs are seen.
-Link to v4: https://lore.kernel.org/all/cover.1730742637.git.quic_uchalich@quicinc.com/

Changes in v4:
- Moving back to redefining GIC_IRQ_TYPE_SPI and GIC_IRQ_TYPE_ESPI macros
in qcom_scm as seeing compilation issues in linux/irq.h when including
arm-gic header. Will send a fixes patch and move to dt-bindings in next patchset.
- Fixed a few compilation errors.
- Link to v3: https://lore.kernel.org/all/cover.1730735881.git.quic_uchalich@quicinc.com/

Changes in v3:
- Use GIC_SPI and GIC_ESPI macros from dt-bindings instead of redefining
- Prettified qcom_scm_fill_irq_fwspec_params()
- Moved waitq initialization before smp_store_release()
- There is no Gunyah hypercall API that can be used to fetch IRQ information hence
introducing new SCM call.
- Link to v2: https://lore.kernel.org/all/cover.1724968351.git.quic_uchalich@quicinc.com/

Changes in v2:
- Dropped "Initialize waitq before setting global __scm" as it was merged here:
https://lore.kernel.org/r/1711034642-22860-4-git-send-email-quic_mojha@quicinc.com
- Decoupled "Remove QCOM_SMC_WAITQ_FLAG_WAKE_ALL" from series
- Converted xarray to a statically sized array
- Initialize waitq array in probe function
- Remove reinit of waitq completion struct in scm_get_completion()
- Introduced new APIs to get no. of waitqueue contexts and waitqueue IRQ no.
directly from firmware.
- Link to v1: https://lore.kernel.org/all/20240228-multi_waitq-v1-0-ccb096419af0@quicinc.com/

---
Unnathi Chalicheemala (3):
      firmware: qcom_scm: Add API to get waitqueue IRQ info
      firmware: qcom_scm: Support multiple waitq contexts
      firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()

 drivers/firmware/qcom/qcom_scm.c | 126 +++++++++++++++++++++++++++++++++------
 drivers/firmware/qcom/qcom_scm.h |   1 +
 2 files changed, 108 insertions(+), 19 deletions(-)
---
base-commit: d724c6f85e80a23ed46b7ebc6e38b527c09d64f5
change-id: 20250227-multi_waitq_scm-5bf05480b7b1

Best regards,
-- 
Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>

[PATCH v10 1/3] firmware: qcom_scm: Add API to get waitqueue IRQ info

[Shivendra Pratap]

From: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>

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 <bartosz.golaszewski@linaro.org>
Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
---
 drivers/firmware/qcom/qcom_scm.c | 60 +++++++++++++++++++++++++++++++++++++++-
 drivers/firmware/qcom/qcom_scm.h |  1 +
 2 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index e777b7cb9b127944fe112f453cae9cbc40c06cae..79ab1707f71b0157835deaea6309f33016e3de8c 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -29,12 +29,18 @@
 #include <linux/reset-controller.h>
 #include <linux/sizes.h>
 #include <linux/types.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
 
 #include "qcom_scm.h"
 #include "qcom_tzmem.h"
 
 static u32 download_mode;
 
+#define GIC_SPI_BASE        32
+#define GIC_MAX_SPI       1019  // SPIs in GICv3 spec range from 32..1019
+#define GIC_ESPI_BASE     4096
+#define GIC_MAX_ESPI      5119 // ESPIs in GICv3 spec range from 4096..5119
+
 struct qcom_scm {
 	struct device *dev;
 	struct clk *core_clk;
@@ -2223,6 +2229,55 @@ bool qcom_scm_is_available(void)
 }
 EXPORT_SYMBOL_GPL(qcom_scm_is_available);
 
+static int qcom_scm_fill_irq_fwspec_params(struct irq_fwspec *fwspec, u32 hwirq)
+{
+	if (hwirq >= GIC_SPI_BASE && hwirq <= GIC_MAX_SPI) {
+		fwspec->param[0] = GIC_SPI;
+		fwspec->param[1] = hwirq - GIC_SPI_BASE;
+	} else if (hwirq >= GIC_ESPI_BASE && hwirq <= GIC_MAX_ESPI) {
+		fwspec->param[0] = GIC_ESPI;
+		fwspec->param[1] = hwirq - GIC_ESPI_BASE;
+	} else {
+		WARN(1, "Unexpected hwirq: %d\n", hwirq);
+		return -ENXIO;
+	}
+	fwspec->param[2] = IRQ_TYPE_EDGE_RISING;
+	fwspec->param_count = 3;
+
+	return 0;
+}
+
+static int qcom_scm_get_waitq_irq(struct qcom_scm *scm)
+{
+	struct device_node *parent_irq_node;
+	struct qcom_scm_desc desc = {
+		.svc = QCOM_SCM_SVC_WAITQ,
+		.cmd = QCOM_SCM_WAITQ_GET_INFO,
+		.owner = ARM_SMCCC_OWNER_SIP
+	};
+	struct irq_fwspec fwspec;
+	struct qcom_scm_res res;
+	u32 hwirq;
+	int ret;
+
+	ret = qcom_scm_call_atomic(scm->dev, &desc, &res);
+	if (ret)
+		return ret;
+
+	hwirq = res.result[1] & GENMASK(15, 0);
+
+	ret = qcom_scm_fill_irq_fwspec_params(&fwspec, hwirq);
+	if (ret)
+		return ret;
+	parent_irq_node = of_irq_find_parent(scm->dev->of_node);
+	if (!parent_irq_node)
+		return -ENODEV;
+
+	fwspec.fwnode = of_fwnode_handle(parent_irq_node);
+
+	return irq_create_fwspec_mapping(&fwspec);
+}
+
 static int qcom_scm_assert_valid_wq_ctx(u32 wq_ctx)
 {
 	/* FW currently only supports a single wq_ctx (zero).
@@ -2396,7 +2451,10 @@ static int qcom_scm_probe(struct platform_device *pdev)
 		return dev_err_probe(scm->dev, PTR_ERR(scm->mempool),
 				     "Failed to create the SCM memory pool\n");
 
-	irq = platform_get_irq_optional(pdev, 0);
+	irq = qcom_scm_get_waitq_irq(scm);
+	if (irq < 0)
+		irq = platform_get_irq_optional(pdev, 0);
+
 	if (irq < 0) {
 		if (irq != -ENXIO)
 			return irq;
diff --git a/drivers/firmware/qcom/qcom_scm.h b/drivers/firmware/qcom/qcom_scm.h
index a56c8212cc0c41021e5a067d52b7d5dcc49107ea..8b1e2ea18a59ac143907a381b73236148bace189 100644
--- a/drivers/firmware/qcom/qcom_scm.h
+++ b/drivers/firmware/qcom/qcom_scm.h
@@ -152,6 +152,7 @@ int qcom_scm_shm_bridge_enable(struct device *scm_dev);
 #define QCOM_SCM_SVC_WAITQ			0x24
 #define QCOM_SCM_WAITQ_RESUME			0x02
 #define QCOM_SCM_WAITQ_GET_WQ_CTX		0x03
+#define QCOM_SCM_WAITQ_GET_INFO		0x04
 
 #define QCOM_SCM_SVC_GPU			0x28
 #define QCOM_SCM_SVC_GPU_INIT_REGS		0x01

-- 
2.34.1

Re: [PATCH v10 1/3] firmware: qcom_scm: Add API to get waitqueue IRQ info

[Mukesh Ojha]

On Sun, Nov 30, 2025 at 08:11:02PM +0530, Shivendra Pratap wrote:
> From: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
> 
> 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 <bartosz.golaszewski@linaro.org>
> Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>

LGTM, incase you are going to sent another spin of this..

> ---
>  drivers/firmware/qcom/qcom_scm.c | 60 +++++++++++++++++++++++++++++++++++++++-
>  drivers/firmware/qcom/qcom_scm.h |  1 +
>  2 files changed, 60 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index e777b7cb9b127944fe112f453cae9cbc40c06cae..79ab1707f71b0157835deaea6309f33016e3de8c 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -29,12 +29,18 @@
>  #include <linux/reset-controller.h>
>  #include <linux/sizes.h>
>  #include <linux/types.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>

At most places, where this header is used there is a line feed
before it, if the header before it is not from dt-bindings.

>  
>  #include "qcom_scm.h"
>  #include "qcom_tzmem.h"
>  
>  static u32 download_mode;
>  
> +#define GIC_SPI_BASE        32
> +#define GIC_MAX_SPI       1019  // SPIs in GICv3 spec range from 32..1019
> +#define GIC_ESPI_BASE     4096
> +#define GIC_MAX_ESPI      5119 // ESPIs in GICv3 spec range from 4096..5119
> +
>  struct qcom_scm {
>  	struct device *dev;
>  	struct clk *core_clk;
> @@ -2223,6 +2229,55 @@ bool qcom_scm_is_available(void)
>  }
>  EXPORT_SYMBOL_GPL(qcom_scm_is_available);
>  
> +static int qcom_scm_fill_irq_fwspec_params(struct irq_fwspec *fwspec, u32 hwirq)
> +{
> +	if (hwirq >= GIC_SPI_BASE && hwirq <= GIC_MAX_SPI) {
> +		fwspec->param[0] = GIC_SPI;
> +		fwspec->param[1] = hwirq - GIC_SPI_BASE;
> +	} else if (hwirq >= GIC_ESPI_BASE && hwirq <= GIC_MAX_ESPI) {
> +		fwspec->param[0] = GIC_ESPI;
> +		fwspec->param[1] = hwirq - GIC_ESPI_BASE;
> +	} else {
> +		WARN(1, "Unexpected hwirq: %d\n", hwirq);
> +		return -ENXIO;
> +	}

line feed after } would make it look better..

> +	fwspec->param[2] = IRQ_TYPE_EDGE_RISING;
> +	fwspec->param_count = 3;
> +
> +	return 0;
> +}
> +
> +static int qcom_scm_get_waitq_irq(struct qcom_scm *scm)
> +{
> +	struct device_node *parent_irq_node;

after desc ?

> +	struct qcom_scm_desc desc = {
> +		.svc = QCOM_SCM_SVC_WAITQ,
> +		.cmd = QCOM_SCM_WAITQ_GET_INFO,
> +		.owner = ARM_SMCCC_OWNER_SIP
> +	};
> +	struct irq_fwspec fwspec;
> +	struct qcom_scm_res res;
> +	u32 hwirq;
> +	int ret;
> +
> +	ret = qcom_scm_call_atomic(scm->dev, &desc, &res);
> +	if (ret)
> +		return ret;
> +
> +	hwirq = res.result[1] & GENMASK(15, 0);
> +

redundant line feed ?

> +	ret = qcom_scm_fill_irq_fwspec_params(&fwspec, hwirq);
> +	if (ret)
> +		return ret;

Line feed needed here after return or } ?

> +	parent_irq_node = of_irq_find_parent(scm->dev->of_node);
> +	if (!parent_irq_node)
> +		return -ENODEV;
> +
> +	fwspec.fwnode = of_fwnode_handle(parent_irq_node);
> +
> +	return irq_create_fwspec_mapping(&fwspec);
> +}
> +
>  static int qcom_scm_assert_valid_wq_ctx(u32 wq_ctx)
>  {
>  	/* FW currently only supports a single wq_ctx (zero).
> @@ -2396,7 +2451,10 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  		return dev_err_probe(scm->dev, PTR_ERR(scm->mempool),
>  				     "Failed to create the SCM memory pool\n");
>  
> -	irq = platform_get_irq_optional(pdev, 0);
> +	irq = qcom_scm_get_waitq_irq(scm);
> +	if (irq < 0)
> +		irq = platform_get_irq_optional(pdev, 0);
> +
>  	if (irq < 0) {
>  		if (irq != -ENXIO)
>  			return irq;
> diff --git a/drivers/firmware/qcom/qcom_scm.h b/drivers/firmware/qcom/qcom_scm.h
> index a56c8212cc0c41021e5a067d52b7d5dcc49107ea..8b1e2ea18a59ac143907a381b73236148bace189 100644
> --- a/drivers/firmware/qcom/qcom_scm.h
> +++ b/drivers/firmware/qcom/qcom_scm.h
> @@ -152,6 +152,7 @@ int qcom_scm_shm_bridge_enable(struct device *scm_dev);
>  #define QCOM_SCM_SVC_WAITQ			0x24
>  #define QCOM_SCM_WAITQ_RESUME			0x02
>  #define QCOM_SCM_WAITQ_GET_WQ_CTX		0x03
> +#define QCOM_SCM_WAITQ_GET_INFO		0x04
>  
>  #define QCOM_SCM_SVC_GPU			0x28
>  #define QCOM_SCM_SVC_GPU_INIT_REGS		0x01
> 
> -- 
> 2.34.1
> 

With all the above changes,

Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

-- 
-Mukesh Ojha

Re: [PATCH v10 1/3] firmware: qcom_scm: Add API to get waitqueue IRQ info

[Shivendra Pratap]

On 12/2/2025 5:13 PM, Mukesh Ojha wrote:
> On Sun, Nov 30, 2025 at 08:11:02PM +0530, Shivendra Pratap wrote:
>> From: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
>>

[SNIP..]

>>
>> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
>> index e777b7cb9b127944fe112f453cae9cbc40c06cae..79ab1707f71b0157835deaea6309f33016e3de8c 100644
>> --- a/drivers/firmware/qcom/qcom_scm.c
>> +++ b/drivers/firmware/qcom/qcom_scm.c
>> @@ -29,12 +29,18 @@
>>  #include <linux/reset-controller.h>
>>  #include <linux/sizes.h>
>>  #include <linux/types.h>
>> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> 
> At most places, where this header is used there is a line feed
> before it, if the header before it is not from dt-bindings.

Ack.

> 
>>  
>>  #include "qcom_scm.h"
>>  #include "qcom_tzmem.h"
>>  
>>  static u32 download_mode;
>>  
>> +#define GIC_SPI_BASE        32
>> +#define GIC_MAX_SPI       1019  // SPIs in GICv3 spec range from 32..1019
>> +#define GIC_ESPI_BASE     4096
>> +#define GIC_MAX_ESPI      5119 // ESPIs in GICv3 spec range from 4096..5119
>> +
>>  struct qcom_scm {
>>  	struct device *dev;
>>  	struct clk *core_clk;
>> @@ -2223,6 +2229,55 @@ bool qcom_scm_is_available(void)
>>  }
>>  EXPORT_SYMBOL_GPL(qcom_scm_is_available);
>>  
>> +static int qcom_scm_fill_irq_fwspec_params(struct irq_fwspec *fwspec, u32 hwirq)
>> +{
>> +	if (hwirq >= GIC_SPI_BASE && hwirq <= GIC_MAX_SPI) {
>> +		fwspec->param[0] = GIC_SPI;
>> +		fwspec->param[1] = hwirq - GIC_SPI_BASE;
>> +	} else if (hwirq >= GIC_ESPI_BASE && hwirq <= GIC_MAX_ESPI) {
>> +		fwspec->param[0] = GIC_ESPI;
>> +		fwspec->param[1] = hwirq - GIC_ESPI_BASE;
>> +	} else {
>> +		WARN(1, "Unexpected hwirq: %d\n", hwirq);
>> +		return -ENXIO;
>> +	}
> 
> line feed after } would make it look better..

Ack.

> 
>> +	fwspec->param[2] = IRQ_TYPE_EDGE_RISING;
>> +	fwspec->param_count = 3;
>> +
>> +	return 0;
>> +}
>> +
>> +static int qcom_scm_get_waitq_irq(struct qcom_scm *scm)
>> +{
>> +	struct device_node *parent_irq_node;
> 
> after desc ?

ok.

> 
>> +	struct qcom_scm_desc desc = {
>> +		.svc = QCOM_SCM_SVC_WAITQ,
>> +		.cmd = QCOM_SCM_WAITQ_GET_INFO,
>> +		.owner = ARM_SMCCC_OWNER_SIP
>> +	};
>> +	struct irq_fwspec fwspec;
>> +	struct qcom_scm_res res;
>> +	u32 hwirq;
>> +	int ret;
>> +
>> +	ret = qcom_scm_call_atomic(scm->dev, &desc, &res);
>> +	if (ret)
>> +		return ret;
>> +
>> +	hwirq = res.result[1] & GENMASK(15, 0);
>> +
> 
> redundant line feed ?

will remove. thanks.

> 
>> +	ret = qcom_scm_fill_irq_fwspec_params(&fwspec, hwirq);
>> +	if (ret)
>> +		return ret;
> 
> Line feed needed here after return or } ?

will add it.

thanks,
Shivendra

[PATCH v10 2/3] firmware: qcom_scm: Support multiple waitq contexts

[Shivendra Pratap]

From: Unnathi Chalicheemala <unnathi.chalicheemala@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 <bartosz.golaszewski@linaro.org>
Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
---
 drivers/firmware/qcom/qcom_scm.c | 74 ++++++++++++++++++++++++++++------------
 1 file changed, 52 insertions(+), 22 deletions(-)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index 79ab1707f71b0157835deaea6309f33016e3de8c..ef3d81a5340512a79c252430db5f09cd8c253173 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -47,7 +47,7 @@ struct qcom_scm {
 	struct clk *iface_clk;
 	struct clk *bus_clk;
 	struct icc_path *path;
-	struct completion waitq_comp;
+	struct completion *waitq_comps;
 	struct reset_controller_dev reset;
 
 	/* control access to the interconnect path */
@@ -57,6 +57,7 @@ struct qcom_scm {
 	u64 dload_mode_addr;
 
 	struct qcom_tzmem_pool *mempool;
+	unsigned int wq_cnt;
 };
 
 struct qcom_scm_current_perm_info {
@@ -2247,6 +2248,23 @@ static int qcom_scm_fill_irq_fwspec_params(struct irq_fwspec *fwspec, u32 hwirq)
 	return 0;
 }
 
+static int qcom_scm_query_waitq_count(struct qcom_scm *scm)
+{
+	int ret;
+	struct qcom_scm_desc desc = {
+		.svc = QCOM_SCM_SVC_WAITQ,
+		.cmd = QCOM_SCM_WAITQ_GET_INFO,
+		.owner = ARM_SMCCC_OWNER_SIP
+	};
+	struct qcom_scm_res res;
+
+	ret = qcom_scm_call_atomic(scm->dev, &desc, &res);
+	if (ret)
+		return ret;
+
+	return res.result[0] & GENMASK(7, 0);
+}
+
 static int qcom_scm_get_waitq_irq(struct qcom_scm *scm)
 {
 	struct device_node *parent_irq_node;
@@ -2278,42 +2296,40 @@ static int qcom_scm_get_waitq_irq(struct qcom_scm *scm)
 	return irq_create_fwspec_mapping(&fwspec);
 }
 
-static int qcom_scm_assert_valid_wq_ctx(u32 wq_ctx)
+static struct completion *qcom_scm_get_completion(u32 wq_ctx)
 {
-	/* FW currently only supports a single wq_ctx (zero).
-	 * TODO: Update this logic to include dynamic allocation and lookup of
-	 * completion structs when FW supports more wq_ctx values.
-	 */
-	if (wq_ctx != 0) {
-		dev_err(__scm->dev, "Firmware unexpectedly passed non-zero wq_ctx\n");
-		return -EINVAL;
-	}
+	struct completion *wq;
 
-	return 0;
+	if (WARN_ON_ONCE(wq_ctx >= __scm->wq_cnt))
+		return ERR_PTR(-EINVAL);
+
+	wq = &__scm->waitq_comps[wq_ctx];
+
+	return wq;
 }
 
 int qcom_scm_wait_for_wq_completion(u32 wq_ctx)
 {
-	int ret;
+	struct completion *wq;
 
-	ret = qcom_scm_assert_valid_wq_ctx(wq_ctx);
-	if (ret)
-		return ret;
+	wq = qcom_scm_get_completion(wq_ctx);
+	if (IS_ERR(wq))
+		return PTR_ERR(wq);
 
-	wait_for_completion(&__scm->waitq_comp);
+	wait_for_completion(wq);
 
 	return 0;
 }
 
 static int qcom_scm_waitq_wakeup(unsigned int wq_ctx)
 {
-	int ret;
+	struct completion *wq;
 
-	ret = qcom_scm_assert_valid_wq_ctx(wq_ctx);
-	if (ret)
-		return ret;
+	wq = qcom_scm_get_completion(wq_ctx);
+	if (IS_ERR(wq))
+		return PTR_ERR(wq);
 
-	complete(&__scm->waitq_comp);
+	complete(wq);
 
 	return 0;
 }
@@ -2389,6 +2405,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
 	struct qcom_tzmem_pool_config pool_config;
 	struct qcom_scm *scm;
 	int irq, ret;
+	int i;
 
 	scm = devm_kzalloc(&pdev->dev, sizeof(*scm), GFP_KERNEL);
 	if (!scm)
@@ -2399,7 +2416,6 @@ static int qcom_scm_probe(struct platform_device *pdev)
 	if (ret < 0)
 		return ret;
 
-	init_completion(&scm->waitq_comp);
 	mutex_init(&scm->scm_bw_lock);
 
 	scm->path = devm_of_icc_get(&pdev->dev, NULL);
@@ -2451,6 +2467,20 @@ static int qcom_scm_probe(struct platform_device *pdev)
 		return dev_err_probe(scm->dev, PTR_ERR(scm->mempool),
 				     "Failed to create the SCM memory pool\n");
 
+	ret = qcom_scm_query_waitq_count(scm);
+	if (ret < 0)
+		scm->wq_cnt = 1;
+	else
+		scm->wq_cnt = ret;
+
+	scm->waitq_comps = devm_kcalloc(&pdev->dev, scm->wq_cnt, sizeof(*scm->waitq_comps),
+					GFP_KERNEL);
+	if (!scm->waitq_comps)
+		return -ENOMEM;
+
+	for (i = 0; i < scm->wq_cnt; i++)
+		init_completion(&scm->waitq_comps[i]);
+
 	irq = qcom_scm_get_waitq_irq(scm);
 	if (irq < 0)
 		irq = platform_get_irq_optional(pdev, 0);

-- 
2.34.1

Re: [PATCH v10 2/3] firmware: qcom_scm: Support multiple waitq contexts

[Mukesh Ojha]

On Sun, Nov 30, 2025 at 08:11:03PM +0530, Shivendra Pratap wrote:
> From: Unnathi Chalicheemala <unnathi.chalicheemala@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 <bartosz.golaszewski@linaro.org>
> Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 74 ++++++++++++++++++++++++++++------------
>  1 file changed, 52 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 79ab1707f71b0157835deaea6309f33016e3de8c..ef3d81a5340512a79c252430db5f09cd8c253173 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -47,7 +47,7 @@ struct qcom_scm {
>  	struct clk *iface_clk;
>  	struct clk *bus_clk;
>  	struct icc_path *path;
> -	struct completion waitq_comp;
> +	struct completion *waitq_comps;
>  	struct reset_controller_dev reset;
>  
>  	/* control access to the interconnect path */
> @@ -57,6 +57,7 @@ struct qcom_scm {
>  	u64 dload_mode_addr;
>  
>  	struct qcom_tzmem_pool *mempool;
> +	unsigned int wq_cnt;
>  };
>  
>  struct qcom_scm_current_perm_info {
> @@ -2247,6 +2248,23 @@ static int qcom_scm_fill_irq_fwspec_params(struct irq_fwspec *fwspec, u32 hwirq)
>  	return 0;
>  }
>  
> +static int qcom_scm_query_waitq_count(struct qcom_scm *scm)
> +{
> +	int ret;
> +	struct qcom_scm_desc desc = {
> +		.svc = QCOM_SCM_SVC_WAITQ,
> +		.cmd = QCOM_SCM_WAITQ_GET_INFO,
> +		.owner = ARM_SMCCC_OWNER_SIP
> +	};
> +	struct qcom_scm_res res;

nit: I know, it is not something we are following everywhere in this file.
Move the `ret` to here to follow xmas tree for newer functions

> +
> +	ret = qcom_scm_call_atomic(scm->dev, &desc, &res);
> +	if (ret)
> +		return ret;
> +
> +	return res.result[0] & GENMASK(7, 0);
> +}
> +
>  static int qcom_scm_get_waitq_irq(struct qcom_scm *scm)
>  {
>  	struct device_node *parent_irq_node;
> @@ -2278,42 +2296,40 @@ static int qcom_scm_get_waitq_irq(struct qcom_scm *scm)
>  	return irq_create_fwspec_mapping(&fwspec);
>  }
>  
> -static int qcom_scm_assert_valid_wq_ctx(u32 wq_ctx)
> +static struct completion *qcom_scm_get_completion(u32 wq_ctx)
>  {
> -	/* FW currently only supports a single wq_ctx (zero).
> -	 * TODO: Update this logic to include dynamic allocation and lookup of
> -	 * completion structs when FW supports more wq_ctx values.
> -	 */
> -	if (wq_ctx != 0) {
> -		dev_err(__scm->dev, "Firmware unexpectedly passed non-zero wq_ctx\n");
> -		return -EINVAL;
> -	}
> +	struct completion *wq;
>  
> -	return 0;
> +	if (WARN_ON_ONCE(wq_ctx >= __scm->wq_cnt))
> +		return ERR_PTR(-EINVAL);
> +
> +	wq = &__scm->waitq_comps[wq_ctx];
> +
> +	return wq;
>  }
>  
>  int qcom_scm_wait_for_wq_completion(u32 wq_ctx)
>  {
> -	int ret;
> +	struct completion *wq;
>  
> -	ret = qcom_scm_assert_valid_wq_ctx(wq_ctx);
> -	if (ret)
> -		return ret;
> +	wq = qcom_scm_get_completion(wq_ctx);
> +	if (IS_ERR(wq))
> +		return PTR_ERR(wq);
>  
> -	wait_for_completion(&__scm->waitq_comp);
> +	wait_for_completion(wq);
>  
>  	return 0;
>  }
>  
>  static int qcom_scm_waitq_wakeup(unsigned int wq_ctx)
>  {
> -	int ret;
> +	struct completion *wq;
>  
> -	ret = qcom_scm_assert_valid_wq_ctx(wq_ctx);
> -	if (ret)
> -		return ret;
> +	wq = qcom_scm_get_completion(wq_ctx);
> +	if (IS_ERR(wq))
> +		return PTR_ERR(wq);
>  
> -	complete(&__scm->waitq_comp);
> +	complete(wq);
>  
>  	return 0;
>  }
> @@ -2389,6 +2405,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  	struct qcom_tzmem_pool_config pool_config;
>  	struct qcom_scm *scm;
>  	int irq, ret;
> +	int i;
>  
>  	scm = devm_kzalloc(&pdev->dev, sizeof(*scm), GFP_KERNEL);
>  	if (!scm)
> @@ -2399,7 +2416,6 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  	if (ret < 0)
>  		return ret;
>  
> -	init_completion(&scm->waitq_comp);
>  	mutex_init(&scm->scm_bw_lock);
>  
>  	scm->path = devm_of_icc_get(&pdev->dev, NULL);
> @@ -2451,6 +2467,20 @@ static int qcom_scm_probe(struct platform_device *pdev)
>  		return dev_err_probe(scm->dev, PTR_ERR(scm->mempool),
>  				     "Failed to create the SCM memory pool\n");
>  
> +	ret = qcom_scm_query_waitq_count(scm);
> +	if (ret < 0)
> +		scm->wq_cnt = 1;

#define QCOM_SCM_DEFAULT_WAITQ_COUNT  1

> +	else
> +		scm->wq_cnt = ret;

Since, we are not erroring out, can we do this as

scm->wq_cnt = ret < 0 ? QCOM_SCM_DEFAULT_WAITQ_COUNT : ret; 

> +
> +	scm->waitq_comps = devm_kcalloc(&pdev->dev, scm->wq_cnt, sizeof(*scm->waitq_comps),
> +					GFP_KERNEL);
> +	if (!scm->waitq_comps)
> +		return -ENOMEM;
> +
> +	for (i = 0; i < scm->wq_cnt; i++)
> +		init_completion(&scm->waitq_comps[i]);
> +
>  	irq = qcom_scm_get_waitq_irq(scm);
>  	if (irq < 0)
>  		irq = platform_get_irq_optional(pdev, 0);


Rest all looks good to me.

Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

> 
> -- 
> 2.34.1
> 

-- 
-Mukesh Ojha

[PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()

[Shivendra Pratap]

From: Unnathi Chalicheemala <unnathi.chalicheemala@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: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
---
 drivers/firmware/qcom/qcom_scm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index ef3d81a5340512a79c252430db5f09cd8c253173..45951c04f377b725cdde4696d834435abd92f015 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2316,7 +2316,7 @@ int qcom_scm_wait_for_wq_completion(u32 wq_ctx)
 	if (IS_ERR(wq))
 		return PTR_ERR(wq);
 
-	wait_for_completion(wq);
+	wait_for_completion_state(wq, TASK_IDLE);
 
 	return 0;
 }

-- 
2.34.1

Re: [PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()

[Mukesh Ojha]

On Sun, Nov 30, 2025 at 08:11:04PM +0530, Shivendra Pratap wrote:
> From: Unnathi Chalicheemala <unnathi.chalicheemala@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.

Not only that, it is stuck in D state after holding a mutex, which is
more severe because none of the SMC calls can go through. However, this
has been the case since the day the firmware started supporting waitq
with a single context, which is somewhat acceptable as the firmware does
not allow otherwise. Since, you are adding the multiple waitq context
supported by firmware with your other patches,

Do you plan to support multiple waitq contexts i.e parallel SCM calls,
in SCM driver as well ?

> 
> 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: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
>  drivers/firmware/qcom/qcom_scm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index ef3d81a5340512a79c252430db5f09cd8c253173..45951c04f377b725cdde4696d834435abd92f015 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2316,7 +2316,7 @@ int qcom_scm_wait_for_wq_completion(u32 wq_ctx)
>  	if (IS_ERR(wq))
>  		return PTR_ERR(wq);
>  
> -	wait_for_completion(wq);
> +	wait_for_completion_state(wq, TASK_IDLE);
>  
>  	return 0;
>  }
> 
> -- 
> 2.34.1
> 

-- 
-Mukesh Ojha

Re: [PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()

[Shivendra Pratap]

On 12/3/2025 2:01 PM, Mukesh Ojha wrote:
> On Sun, Nov 30, 2025 at 08:11:04PM +0530, Shivendra Pratap wrote:
>> From: Unnathi Chalicheemala <unnathi.chalicheemala@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.
> 
> Not only that, it is stuck in D state after holding a mutex, which is
> more severe because none of the SMC calls can go through. However, this
> has been the case since the day the firmware started supporting waitq
> with a single context, which is somewhat acceptable as the firmware does
> not allow otherwise. Since, you are adding the multiple waitq context
> supported by firmware with your other patches,
> 
> Do you plan to support multiple waitq contexts i.e parallel SCM calls,
> in SCM driver as well ?

Yes. Parallel SCM can be enabled once this waitq enablement support is
in place.

thanks,
Shivendra

Re: [PATCH v10 3/3] firmware: qcom_scm: Use TASK_IDLE state in wait_for_wq_completion()

[Mukesh Ojha]

On Wed, Dec 03, 2025 at 04:27:25PM +0530, Shivendra Pratap wrote:
> 
> 
> On 12/3/2025 2:01 PM, Mukesh Ojha wrote:
> > On Sun, Nov 30, 2025 at 08:11:04PM +0530, Shivendra Pratap wrote:
> >> From: Unnathi Chalicheemala <unnathi.chalicheemala@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.
> > 
> > Not only that, it is stuck in D state after holding a mutex, which is
> > more severe because none of the SMC calls can go through. However, this
> > has been the case since the day the firmware started supporting waitq
> > with a single context, which is somewhat acceptable as the firmware does
> > not allow otherwise. Since, you are adding the multiple waitq context
> > supported by firmware with your other patches,
> > 
> > Do you plan to support multiple waitq contexts i.e parallel SCM calls,
> > in SCM driver as well ?
> 
> Yes. Parallel SCM can be enabled once this waitq enablement support is
> in place.

Thanks.

Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>

> 
> thanks,
> Shivendra

-- 
-Mukesh Ojha