Re: [PATCH v3] PCI: imx6: Fix i.MX6Q/DL boot hang caused by improper PHY power sequencing

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The removal of explicit PHY power-up delays causes a boot regression on boards without a PERST# GPIO or explicit Root Port nodes in the device tree.
- [Medium] Incorrect teardown ordering in `imx_pcie_host_exit()` violates LIFO symmetry by asserting the core reset after the PHY is powered off and exited.
--

--- Patch [1]: [PATCH v3] PCI: imx6: Fix i.MX6Q/DL boot hang caused by improper PHY power sequencing ---
commit 00ce7804e098bc0e8573a15a850f6250a9cb1245
Author: Richard Zhu <[email protected]>
PCI: imx6: Fix i.MX6Q/DL boot hang caused by improper PHY power sequencing

This commit fixes a boot hang on i.MX6Q/DL variants by correcting the PHY power
sequencing and TEST_PD control logic. It removes an explicit delay during clock
enable, assuming the PERST# toggling sequence provides sufficient stabilization
time. It also adds explicit core reset assertions in the error paths.

Link: https://lore.kernel.org/lkml/[email protected]/

> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index e25f938eefe23..45ab21c9769a4 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -681,21 +681,12 @@ static int imx_pcie_attach_pd(struct device *dev)
>  
>  static int imx6q_pcie_enable_ref_clk(struct imx_pcie *imx_pcie, bool enable)
>  {
> -	if (enable) {
> -		/* power up core phy and enable ref clock */
> -		regmap_clear_bits(imx_pcie->iomuxc_gpr, IOMUXC_GPR1, IMX6Q_GPR1_PCIE_TEST_PD);
> -		/*
> -		 * The async reset input need ref clock to sync internally,
> -		 * when the ref clock comes after reset, internal synced
> -		 * reset time is too short, cannot meet the requirement.
> -		 * Add a ~10us delay here.
> -		 */
> -		usleep_range(10, 100);

[Severity: High]
The commit message states that the ~120us delay needed between TEST_PD
de-assertion and link training is satisfied by the PERST# toggling sequence.
Does this break boards that don't define a reset GPIO (like
imx6qdl-sabrelite.dtsi)?

If the device tree lacks a PERST# GPIO or explicit Root Port nodes,
imx_pcie_assert_perst() returns immediately:

static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool assert)
{
        [ ... ]
        if (!bridge || list_empty(&bridge->ports))
                return;
        [ ... ]
}

Because of this early return, there will be no delay before link training
begins in imx_pcie_host_init(). Could this lead to a boot hang on these
boards due to the missing PHY stabilization delay?

[ ... ]

> @@ -1475,6 +1467,7 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
>  		if (phy_power_off(imx_pcie->phy))
>  			dev_err(pci->dev, "unable to power off PHY\n");
>  		phy_exit(imx_pcie->phy);
>  	}
> +	imx_pcie_assert_core_reset(imx_pcie);

[Severity: Medium]
Is the teardown ordering correct here?

During initialization, the core reset is asserted before powering on the PHY.
The error path err_phy_off in imx_pcie_host_init() correctly mirrors this
by asserting the core reset before powering off the PHY.

However, this sequence in imx_pcie_host_exit() asserts the core reset
after the PHY has already been powered off and exited. Should
imx_pcie_assert_core_reset() be called before phy_power_off() to maintain
proper LIFO teardown symmetry?

>  	imx_pcie_clk_disable(imx_pcie);
>  
>  	if (!pci->pp.skip_pwrctrl_off)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1