Re: [PATCH 6/7] arm64: dts: qcom: sm8350: modernize PCIe entries

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but moving the reset GPIO lookup to the root port node exposes a pre-existing resource leak in `qcom_pcie_parse_port()`. The function initializes the PHY via `phy_init(phy)`. Immediately afterward, it calls `qcom_pcie_parse_perst()` to acquire the reset GPIO. If `qcom_pcie_parse_perst()` fails (e.g., returning `-EPROBE_DEFER` because the GPIO controller is not yet ready), `qcom_pcie_parse_port()` exits immediately and returns the error without calling `phy_exit(phy)`. Because the `port` structure is only added to the `pcie->ports` list at the very end of the function, the cleanup block in the caller `qcom_pcie_parse_ports()` skips this newly allocated port and fails to execute `phy_exit()`. This results in leaked PHY initialization references.
--

commit d344e05b9227f3ae995aa63413819de4bd38ce62
Author: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

arm64: dts: qcom: sm8350: modernize PCIe entries

This commit modernizes the device tree for the SM8350 platform by moving
the PERST# / WAKE pins and PHYs to the PCIe port instead of the RC device
to resolve recent kernel warnings.

> diff --git a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> index 5f975d0094658..4973a3eb11b5b 100644
> --- a/arch/arm64/boot/dts/qcom/sm8350-hdk.dts
> +++ b/arch/arm64/boot/dts/qcom/sm8350-hdk.dts

[ ... ]

> @@ -493,12 +493,14 @@ &pcie0 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pcie0_default_state>;
>  
> -	perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> -	wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> -
>  	status = "okay";
>  };
>  
> +&pcie0_port0 {
> +	reset-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> +	wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> +};

[Severity: High]
This is a pre-existing issue, but moving the reset GPIO lookup to the root
port node exposes a resource leak in the driver's error handling.

If the GPIO controller is not yet ready and qcom_pcie_parse_perst() defers,
does the driver leak the PHY initialization reference?

Looking at drivers/pci/controller/dwc/pcie-qcom.c:qcom_pcie_parse_port(),
the function initializes the PHY:

    ret = phy_init(phy);
    if (ret)
        return ret;
    
    INIT_LIST_HEAD(&port->perst);
    
    ret = qcom_pcie_parse_perst(pcie, port, node);
    if (ret)
        return ret;

When qcom_pcie_parse_perst() returns an error, the function returns
immediately without calling phy_exit(phy). Because the port structure is only
added to the pcie->ports list at the very end of the function, the cleanup
block in the caller qcom_pcie_parse_ports() skips this newly allocated port
and fails to execute phy_exit().

Could this keep the PHY permanently enabled across probe deferrals, and
should the error path be updated to ensure phy_exit() is called?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601-sm8350-wifi-v1-0-242917d88031@oss.qualcomm.com?part=6