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

[Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>]

On Fri, Feb 16, 2024 at 06:07:23PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 15, 2024 at 07:39:08PM +0530, Manivannan Sadhasivam wrote:
> > On Wed, Feb 14, 2024 at 04:02:28PM -0600, Bjorn Helgaas wrote:
> > > On Tue, Feb 06, 2024 at 10:40:43PM +0530, Manivannan Sadhasivam wrote:
> > > > ...
> > > 
> > > > ... And for your usecase, allowing the controller driver to
> > > > start the link post boot just because a device on your Pixel
> > > > phone comes up later is not a good argument. You _should_not_
> > > > define the behavior of a controller driver based on one
> > > > platform, it is really a bad design.
> > > 
> > > I haven't followed the entire discussion, and I don't know much
> > > about the specifics of Ajay's situation, but from the controller
> > > driver's point of view, shouldn't a device coming up later look
> > > like a normal hot-add?
> > 
> > Yes, but most of the form factors that these drivers work with do
> > not support native hotplug. So users have to rescan the bus through
> > sysfs.
> > 
> > > I think most drivers are designed with the assumption that
> > > Endpoints are present and powered up at the time of host
> > > controller probe, which seems a little stronger than necessary.
> > 
> > Most of the drivers work with endpoints that are fixed in the board
> > design (like M.2), so the endpoints would be up when the controller
> > probes.
> >
> > > I think the host controller probe should initialize the Root Port
> > > such that its LTSSM enters the Detect state, and that much should
> > > be basically straight-line code with no waiting.  If no Endpoint
> > > is attached, i.e., "the slot is empty", it would be nice if the
> > > probe could then complete immediately without waiting at all.
> > 
> > Atleast on Qcom platforms, the LTSSM would be in "Detect" state even
> > if no endpoints are found during probe. Then once an endpoint comes
> > up later, link training happens and user can rescan the bus through
> > sysfs.
> 
> Can the hardware tell us when the link state changes?  If so, we
> should be able to scan the bus automatically without the need for
> sysfs.  For example, if the Root Port advertised PCI_EXP_FLAGS_SLOT, 
> we might be able to use a Data Link Layer State Changed interrupt to
> scan the bus via pciehp when the Endpoint is powered up, even if the
> Endpoint is actually soldered down and not physically hot-pluggable.
> 

I don't think the state change interrupt is generated on Qcom platforms. I will
check with the hw team and reply back.

As a reply to my earlier question on requiring 1s delay for waiting for the link
to come up during boot:

PCIe spec r5, sec 6.6.1 says:

"Unless Readiness Notifications mechanisms are used, the Root Complex and/or
system software must allow at least 1.0 s after a Conventional Reset of a
device, before determining that the device is broken if it fails to return
a Successful Completion status for a valid Configuration Request. This period is
independent of how quickly Link training completes."

So this might be the reason. If so, I don't see a way to avoid the delay.

- Mani

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