[PATCH] PCI: mediatek-gen3: Ignore link up timeout

Manivannan Sadhasivam mani at kernel.org
Wed Dec 17 22:11:36 PST 2025


On Wed, Nov 05, 2025 at 02:28:14PM +0800, Chen-Yu Tsai wrote:
> As mentioned in commit 886a9c134755 ("PCI: dwc: Move link handling into
> common code") come up later" in the code, it is possible for link up to
> occur later:
> 
>   Let's standardize this to succeed as there are usecases where devices
>   (and the link) appear later even without hotplug. For example, a
>   reconfigured FPGA device.
> 
> Another case for this is the new PCIe power control stuff. The power
> control mechanism only gets triggered in the PCI core after the driver
> calls into pci_host_probe(). The power control framework then triggers
> a bus rescan. In most driver implementations, this sequence happens
> after link training. If the driver errors out when link training times
> out, it will never get to the point where the device gets turned on.
> 
> Ignore the link up timeout, and lower the error message down to a
> warning.
> 
> This makes PCIe devices that have not-always-on power rails work.
> However there may be some reversal of PCIe power sequencing, since now
> the PERST# and clocks are enabled in the driver, while the power is
> applied afterwards.
> 
> Signed-off-by: Chen-Yu Tsai <wenst at chromium.org>
> ---
> The change works to get my PCIe WiFi device working, but I wonder if
> the driver should expose more fine grained controls for the link clock
> and PERST# (when it is owned by the controller and not just a GPIO) to
> the power control framework. This applies not just to this driver.
> 
> The PCI standard says that PERST# should hold the device in reset until
> the power rails are valid or stable, i.e. at their designated voltages.

I believe this patch is no longer necessary once you adopt to the new pwrctrl
APIs proposed here: https://lore.kernel.org/linux-pci/20251216-pci-pwrctrl-rework-v2-0-745a563b9be6@oss.qualcomm.com/

I plan to get this series merged asap for v6.20 so that we can apply mtk changes
on top once you send them.

- Mani

> ---
>  drivers/pci/controller/pcie-mediatek-gen3.c | 13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/controller/pcie-mediatek-gen3.c b/drivers/pci/controller/pcie-mediatek-gen3.c
> index 75ddb8bee168..5bdb312c9f9b 100644
> --- a/drivers/pci/controller/pcie-mediatek-gen3.c
> +++ b/drivers/pci/controller/pcie-mediatek-gen3.c
> @@ -504,10 +504,15 @@ static int mtk_pcie_startup_port(struct mtk_gen3_pcie *pcie)
>  		ltssm_index = PCIE_LTSSM_STATE(val);
>  		ltssm_state = ltssm_index >= ARRAY_SIZE(ltssm_str) ?
>  			      "Unknown state" : ltssm_str[ltssm_index];
> -		dev_err(pcie->dev,
> -			"PCIe link down, current LTSSM state: %s (%#x)\n",
> -			ltssm_state, val);
> -		return err;
> +		dev_warn(pcie->dev,
> +			 "PCIe link down, current LTSSM state: %s (%#x)\n",
> +			 ltssm_state, val);
> +
> +		/*
> +		 * Ignore the timeout, as the link may come up later,
> +		 * such as when the PCI power control enables power to the
> +		 * device, at which point it triggers a rescan.
> +		 */
>  	}
>  
>  	mtk_pcie_enable_msi(pcie);
> -- 
> 2.51.2.1026.g39e6a42477-goog
> 

-- 
மணிவண்ணன் சதாசிவம்



More information about the Linux-mediatek mailing list