Re: [PATCH] Revert "PCI: dwc: Wait for link up only if link is started"

Johan Hovold
2023-07-26T08:40:52Z

On Tue, Jul 25, 2023 at 03:05:15PM -0500, Bjorn Helgaas wrote:
> [+cc Fabio, Xiaolei, Jon]
>
> On Thu, Jul 06, 2023 at 10:26:10AM +0200, Johan Hovold wrote:
> > This reverts commit da56a1bfbab55189595e588f1d984bdfb5cf5924.
> >
> > A recent commit broke controller probe by returning an error in case the
> > link does not come up during host initialisation.
> >
> > As explained in commit 886a9c134755 ("PCI: dwc: Move link handling into
> > common code") and as indicated by the comment "Ignore errors, the link
> > may come up later" in the code, waiting for link up and ignoring errors
> > is the intended behaviour:
> >
> > 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.
> >
> > Reverting the offending commit specifically fixes a regression on
> > Qualcomm platforms like the Lenovo ThinkPad X13s which no longer reach
> > the interconnect sync state if a slot does not have a device populated
> > (e.g. an optional modem).
> >
> > Note that enabling asynchronous probing by default as was done for
> > Qualcomm platforms by commit c0e1eb441b1d ("PCI: qcom: Enable async
> > probe by default"), should take care of any related boot time concerns.
> >
> > Finally, note that the intel-gw driver is the only driver currently not
> > providing a start_link callback and instead starts the link in its
> > host_init callback, and which may avoid an additional one-second timeout
> > during probe by making the link-up wait conditional. If anyone cares,
> > that can be done in a follow-up patch with a proper motivation.
> >
> > Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started")
> > Reported-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > Cc: Sajid Dalvi <sdalvi@google.com>
> > Cc: Ajay Agarwal <ajayagarwal@google.com>
> > Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
>
> da56a1bfbab5 appeared in v6.5-rc1, so we should definitely fix this
> before v6.5.
>
> Based on the conversation here, I applied this to for-linus for v6.5.
>
> I looked for Bjorn A's report but couldn't find it; I'd like to
> include the URL if there is one. I did add the reports from Fabio
> Estevam, Xiaolei Wang, and Jon Hunter (Fabio and Xiaolei even included
> patches).

Bjorn only mentioned to me off-list that that something was wrong with
PCI in linux-next and that it prevented us from reaching the sync state.
So there is no URL to a public report to link to.

> Current commit log, corrections/additions welcome:
>
> This reverts commit da56a1bfbab55189595e588f1d984bdfb5cf5924.
>
> Bjorn Andersson, Fabio Estevam, Xiaolei Wang, and Jon Hunter reported that
> da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started") broke
> controller probing by returning an error in case the link does not come up
> during host initialisation, e.g., when the slot is empty.

I think that adding the corresponding Reported-by tags and Links after
my SoB below should be enough to credit reports that I was not aware of
when investigating this.

But if you decide to rewrite this paragraph, then please spell out "for
example" as I would not use "e.g." outside of parentheses.

> As explained in commit 886a9c134755 ("PCI: dwc: Move link handling into
> common code") and as indicated by the comment "Ignore errors, the link may
> come up later" in the code, waiting for link up and ignoring errors is the
> intended behaviour:
>
> 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.
>
> Reverting the offending commit specifically fixes a regression on Qualcomm
> platforms like the Lenovo ThinkPad X13s which no longer reach the
> interconnect sync state if a slot does not have a device populated (e.g. an
> optional modem).
>
> Note that enabling asynchronous probing by default as was done for Qualcomm
> platforms by commit c0e1eb441b1d ("PCI: qcom: Enable async probe by
> default"), should take care of any related boot time concerns.
>
> Finally, note that the intel-gw driver is the only driver currently not
> providing a .start_link() callback and instead starts the link in its
> .host_init() callback, which may avoid an additional one-second timeout
> during probe by making the link-up wait conditional. If anyone cares, that
> can be done in a follow-up patch with a proper motivation.
>
> [bhelgaas: add Fabio Estevam, Xiaolei Wang, Jon Hunter reports]
> Fixes: da56a1bfbab5 ("PCI: dwc: Wait for link up only if link is started")
> Link: https://lore.kernel.org/r/20230704122635.1362156-1-festevam@gmail.com/
> Link: https://lore.kernel.org/r/20230705010624.3912934-1-xiaolei.wang@windriver.com/
> Link: https://lore.kernel.org/r/6ca287a1-6c7c-7b90-9022-9e73fb82b564@nvidia.com
> Link: https://lore.kernel.org/r/20230706082610.26584-1-johan+linaro@kernel.org
> Reported-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> Reported-by: Fabio Estevam <festevam@gmail.com>
> Reported-by: Xiaolei Wang <xiaolei.wang@windriver.com>
> Reported-by: Jon Hunter <jonathanh@nvidia.com>
> Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Cc: Sajid Dalvi <sdalvi@google.com>
> Cc: Ajay Agarwal <ajayagarwal@google.com>

Looks like you've "sorted" the trailers here instead of keeping the
temporal order (which would make it more clear what you added after I
posted the patch) and adding each Link after its corresponding
Reported-by tag (e.g. as suggested by checkpatch these days).

Johan