Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] `qcom_scm_get_waitq_irq()` returns 0 on failure, but `qcom_scm_probe()` only checks `if (irq < 0)`. This causes the driver to skip the fallback `platform_get_irq_optional()` and incorrectly attempt to request IRQ 0, leading to a probe failure. -- commit a810ba9e83e9707877b7e2fd4e5099068b665038 Author: Julian Braha <[email protected]> firmware: qcom: scm: add missing IRQ_DOMAIN select to QCOM_SCM This commit adds the missing select for IRQ_DOMAIN to the QCOM_SCM kconfig. This ensures the driver will compile successfully since it relies on irq_create_fwspec_mapping(). > diff --git a/drivers/firmware/qcom/Kconfig b/drivers/firmware/qcom/Kconfig > index b477d54b495a6..9d137fa2aa232 100644 > --- a/drivers/firmware/qcom/Kconfig > +++ b/drivers/firmware/qcom/Kconfig > @@ -7,6 +7,7 @@ > menu "Qualcomm firmware drivers" > > config QCOM_SCM > + select IRQ_DOMAIN [Severity: High] This is a pre-existing issue, but since this patch ensures the code using irq_create_fwspec_mapping() is compiled, I noticed a potential regression in how its return value is handled. In drivers/firmware/qcom/qcom_scm.c:qcom_scm_get_waitq_irq(): return irq_create_fwspec_mapping(&fwspec); If irq_create_fwspec_mapping() fails, it returns 0. However, when checked in qcom_scm_probe(): irq = qcom_scm_get_waitq_irq(scm); if (irq < 0) irq = platform_get_irq_optional(pdev, 0); Since 0 is not less than 0, the check misses the failure. Does this cause the driver to skip the fallback path and incorrectly attempt to request irq 0, resulting in a probe failure? Should this check be updated to if (irq <= 0) to properly trigger the fallback path? > select QCOM_TZMEM > tristate > -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
