[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2qojq77l7xeivmvt4mqjpdelj2ph2rht44qzkaf3ikq5qpq6gp@tj542kt77dkg>
Date: Thu, 18 Dec 2025 11:41:36 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Chen-Yu Tsai <wenst@...omium.org>
Cc: Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Ryder Lee <ryder.lee@...iatek.com>,
Jianjun Wang <jianjun.wang@...iatek.com>, Lorenzo Pieralisi <lpieralisi@...nel.org>,
Krzysztof Wilczyński <kwilczynski@...nel.org>, Rob Herring <robh@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>, Bartosz Golaszewski <brgl@...ev.pl>, linux-pci@...r.kernel.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: mediatek-gen3: Ignore link up timeout
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@...omium.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
>
--
மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists