Re: [PATCH 4/5] firmware: qcom: scm: Allow QSEECOM on Kalambo CRD

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect error check for irq_create_fwspec_mapping() return value breaks deferred probing and causes permanent probe failure.
--

--- Patch [4]: [PATCH 4/5] firmware: qcom: scm: Allow QSEECOM on Kalambo CRD ---
commit 64635e7b37ce27df0438767be7b9b4011a0fa5f6
Author: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>

firmware: qcom: scm: Allow QSEECOM on Kalambo CRD

This commit adds the Kalambo CRD board to the QSEECOM allowlist. This
enables access to efivars on this platform.

> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index f35f2ee391304..d1cc6c908daa4 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2327,6 +2327,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
>  	{ .compatible = "microsoft,romulus15", },
>  	{ .compatible = "qcom,glymur-crd" },
>  	{ .compatible = "qcom,hamoa-iot-evk" },
> +	{ .compatible = "qcom,kalambo-crd" },

[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in
qcom_scm_probe() related to how the return value of qcom_scm_get_waitq_irq()
is checked.

When qcom_scm probes before the interrupt controller,
irq_create_fwspec_mapping() fails to find the IRQ domain and returns 0 to
indicate a failure to map the IRQ.

drivers/firmware/qcom/qcom_scm.c:qcom_scm_get_waitq_irq() {
    ...
    return irq_create_fwspec_mapping(&fwspec);
}

This means qcom_scm_get_waitq_irq() can return 0. However, in qcom_scm_probe():

drivers/firmware/qcom/qcom_scm.c:qcom_scm_probe() {
    ...
	irq = qcom_scm_get_waitq_irq(scm);
	if (irq < 0)
		irq = platform_get_irq_optional(pdev, 0);
    ...
}

Should this check be if irq <= 0?

By only checking irq < 0, a return value of 0 bypasses the fallback to
platform_get_irq_optional(). This function would have correctly deferred the
probe by returning -EPROBE_DEFER.

Does this instead cause the driver to attempt to request IRQ 0 via
devm_request_threaded_irq(), which would fail with -EINVAL and result in a
permanent probe failure for the qcom_scm driver during boot?

>  	{ .compatible = "qcom,mahua-crd" },
>  	{ .compatible = "qcom,purwa-iot-evk" },
>  	{ .compatible = "qcom,sc8180x-primus" },

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260718-b4-kalambo-crd-v1-0-a1069b5a2757@oss.qualcomm.com?part=4