Re: [PATCH v3 2/3] arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Removing the `qcom,x1e80100-pdc` compatible string to bypass the hardware register bug inadvertently also bypasses the firmware SCM call used to configure the PDC pass-through mode.
--

--- Patch [2]: [PATCH v3 2/3] arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC ---
commit e773040084ef92725984012956d31476c93e6557
Author: Maulik Shah <maulik.shah@oss.qualcomm.com>

arm64: dts: qcom: purwa: Drop the Hamoa workaround for PDC

This commit drops the "qcom,x1e80100-pdc" compatible string for the X1P42100
PDC node to remove a hardware register workaround. It replaces it with a
device-specific string and the generic "qcom,pdc" fallback.

> diff --git a/arch/arm64/boot/dts/qcom/purwa.dtsi b/arch/arm64/boot/dts/qcom/purwa.dtsi
> --- a/arch/arm64/boot/dts/qcom/purwa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/purwa.dtsi
> @@ -174,6 +174,11 @@ &pcie6a_phy {
>  	compatible = "qcom,x1p42100-qmp-gen4x4-pcie-phy";
>  };
>  
> +/* X1P42100 PDC is same as X1E80100, but without hardware register bug */
> +&pdc {
> +	compatible = "qcom,x1p42100-pdc", "qcom,pdc";
> +};
> +

[Severity: Medium]
Does dropping the "qcom,x1e80100-pdc" compatible string also unintentionally
bypass the firmware SCM call needed to configure the PDC pass-through mode?

Looking at qcom_pdc_probe() in drivers/irqchip/qcom-pdc.c, the SCM call is
coupled directly to this compatible string:

drivers/irqchip/qcom-pdc.c:qcom_pdc_probe() {
    if (of_device_is_compatible(node, "qcom,x1e80100-pdc")) {
        pdc->prev_base = devm_ioremap(dev, res.start - PDC_DRV_SIZE,...);
        ...
        pdc->x1e_quirk = true;

        if (!qcom_scm_is_available())
            return -EPROBE_DEFER;

        ret = qcom_scm_io_writel(PDC_GPIO_INT_CTL_ENABLE, PDC_PASS_THROUGH_MODE);
        ...
    }
}

If the X1P firmware boots in secondary mode (similar to X1E firmware on CRD
boards), skipping this SCM call might cause the kernel to assume pass-through
mode while the hardware remains in secondary mode.

Could this lead to an interrupt storm and system lockup due to omitted
Ack/Clear operations for latched GPIO interrupts?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260715-purwa-pdc-v3-0-be08934dc916@oss.qualcomm.com?part=2