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 -- மணிவண்ணன் சதாசிவம்
