Re: [PATCH 1/2] arm64: dts: qcom: ipq5332: Move PHYs and PERST# to Root Port node

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing `phy_exit()` on error path in `qcom_pcie_parse_port()` leaks PHY initialization state.
--

commit a3169d2cae3bc2449e374f733bcb358e726cc377
Author: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>

arm64: dts: qcom: ipq5332: Move PHYs and PERST# to Root Port node

This commit updates the device tree bindings for the IPQ5332 PCIe
interfaces. It moves the PHYs and PERST# properties under the
Root Port nodes to follow the new binding style.

> diff --git a/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts b/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts
> index 79ec77cfe5527..7fcf632e289f0 100644
> --- a/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts
> +++ b/arch/arm64/boot/dts/qcom/ipq5332-rdp441.dts

[ ... ]

> @@ -46,13 +43,15 @@ &pcie0_phy {
>  	status = "okay";
>  };
>  
> +&pcie0_port0 {
> +	reset-gpios = <&tlmm 38 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 39 GPIO_ACTIVE_LOW>;
> +};

[Severity: High]
This is a pre-existing issue, but does moving these properties to the
Root Port node expose a PHY initialization leak on probe deferral?

When the driver processes the port via qcom_pcie_parse_port(), it calls
phy_init() and then immediately calls qcom_pcie_parse_perst(). If parsing
the PERST# GPIO (now added to the port node here) fails with -EPROBE_DEFER,
the function returns early:

drivers/pci/controller/dwc/pcie-qcom.c:qcom_pcie_parse_port() {
    ...
	ret = qcom_pcie_parse_perst(pcie, port, node);
	if (ret)
		return ret;
    ...
}

Because the port is not added to the pcie->ports list until later in
the function, the cleanup loop in the caller qcom_pcie_parse_ports() misses
it entirely:

err_port_del:
	list_for_each_entry_safe(port, tmp_port, &pcie->ports, list) {
		list_for_each_entry_safe(perst, tmp_perst, &port->perst, list)
			list_del(&perst->list);
		phy_exit(port->phy);
		list_del(&port->list);
	}

Could this lead to unbalanced clocks and regulator reference counts by
skipping phy_exit() if the GPIO driver is not yet ready?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602-move_perst_to_rp-v1-0-8ee5b80316da@oss.qualcomm.com?part=1