On Mon, Nov 04, 2024 at 08:20:55AM -0800, Unnathi Chalicheemala wrote:
> 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
> defined fill_irq_fwspec_params(). This Linux IRQ number is then supplied
> to the threaded_irq call.
>
> Signed-off-by: Unnathi Chalicheemala <quic_uchalich@xxxxxxxxxxx>
> ---
> drivers/firmware/qcom/qcom_scm.c | 52 +++++++++++++++++++++++++++++++-
> drivers/firmware/qcom/qcom_scm.h | 1 +
> 2 files changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 10986cb11ec0..ec1205474a3a 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -11,6 +11,7 @@
> #include <linux/completion.h>
> #include <linux/cpumask.h>
> #include <linux/dma-mapping.h>
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <linux/err.h>
> #include <linux/export.h>
> #include <linux/firmware/qcom/qcom_scm.h>
> @@ -35,6 +36,11 @@
>
> 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;
> @@ -1830,6 +1836,50 @@ 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 virq)
> +{
> + if (virq >= GIC_SPI_BASE && virq <= GIC_SPI_MAX) {
> + fwspec->param[0] = GIC_SPI;
> + fwspec->param[1] = virq - GIC_SPI_BASE;
> + } else if (virq >= GIC_ESPI_BASE && virq <= GIC_ESPI_MAX) {
> + fwspec->param[0] = GIC_ESPI;
> + fwspec->param[1] = virq - GIC_ESPI_BASE;
> + } else {
> + WARN(1, "Unexpected virq: %d\n", virq);
> + return -ENXIO;
> + }
> + fwspec->param[2] = IRQ_TYPE_EDGE_RISING;
> + fwspec->param_count = 3;
> +
> + return 0;
> +}
> +
> +static int qcom_scm_get_waitq_irq(void)
> +{
> + int ret;
> + u32 hwirq;
> + 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;
> + struct irq_fwspec fwspec;
> +
> + ret = qcom_scm_call_atomic(__scm->dev, &desc, &res);
> + if (ret)
> + return ret;
> +
What would be the return value on older firmware where WAITQ_GET_INFO
command is not supported? See below comment on the expected return
value from qcom_scm_get_waitq_irq().
> + fwspec.fwnode = of_node_to_fwnode(__scm->dev->of_node);
> + hwirq = res.result[1] & GENMASK(15, 0);
> + ret = qcom_scm_fill_irq_fwspec_params(&fwspec, hwirq);
> + if (ret)
> + return ret;
> + ret = irq_create_fwspec_mapping(&fwspec);
> +
> + return ret;
> +}
> +
> static int qcom_scm_assert_valid_wq_ctx(u32 wq_ctx)
> {
> /* FW currently only supports a single wq_ctx (zero).
> @@ -1986,7 +2036,7 @@ static int qcom_scm_probe(struct platform_device *pdev)
> /* Let all above stores be available after this */
> smp_store_release(&__scm, scm);
>
> - irq = platform_get_irq_optional(pdev, 0);
> + irq = qcom_scm_get_waitq_irq();
> if (irq < 0) {
> if (irq != -ENXIO)
> return irq;
Here we fail probe for any return value other than -ENXIO, would that
cause problems with older firmware?
Thanks,
Pavan
