On Fri, Feb 14, 2025 at 03:32:13PM +0530, Ajay Agarwal wrote: > On Fri, Feb 14, 2025 at 03:12:55PM +0530, Manivannan Sadhasivam wrote: > > On Fri, Feb 14, 2025 at 10:18:27AM +0100, Johan Hovold wrote: > > > On Fri, Feb 14, 2025 at 02:45:03PM +0530, Ajay Agarwal wrote: > > > > > > > Restarting this discussion for skipping the 1 sec of wait time if a > > > > certain platform does not necessarily wish or expect to bring the link > > > > up during probe time. I discussed with William and we think that a > > > > module parameter can be added which if true, would lead to the skipping > > > > of the wait time. By default, this parameter would be false, thereby > > > > ensuring that the current behaviour to wait for the link is maintained. > > > > > > > > Please let me know if this is worth exploring. > > > > > > No, module parameters are a thing of the past (except possibly in vendor > > > kernels). The default behaviour should just work. > > > > > > > +1 > > > > Btw, you need to come up with a valid argument for not enabling the link during > The argument for the link to not come up during probe is simply that the > product does not need the link to be up during probe. The requirement is > that the PCIe RC SW structures be prepared for link-up later, when there > is a trigger from the userspace or the vendor kernel driver. > This is the problem. You are fixing the behavior of the controller driver to a single product line and this is not going to work if the same controller is used in a different product. Instead you should fix the userspace. > I am looking to treat this like USB, say. The USB DWC could be probed when > the cable is not connected. That does not fail the probe. Later when the > cable is connected, the USB link comes up and the enumeration is > performed. > Same with DWC controllers as well, probe doesn't fail even if the link did not come up. Previously you were trying to avoid the delay while waiting for the link up during probe (for which I also asked you to probe the controller driver asynchronously to mitigate the delay). Is this the same case still? And what makes me nervous is the fact that you are trying to upstream a change for your downstream driver, which is a big no-go. > > probe. Also, not waiting for link during probe is also not going to work across > > all platforms where the controller is used, unless your hardware supports > > hotplug or LINK_UP IRQ. > We do not necessarily need the hotplug or LINK_UP IRQ right? Once the > LTSSM training is enabled using the triggers I mentioned above, I can > then wait for the link to come up using `dw_pcie_wait_for_link`. IOW, > polling for the link, which is what the `dw_pcie_host_init` does. > Oh, you do not want link training to be started during probe? So how your 'userspace trigger' is starting it? What is the reason to hold off the link training? - Mani -- மணிவண்ணன் சதாசிவம்
