On Mon, Dec 14, 2020 at 4:43 AM Daniel Thompson <daniel.thompson@xxxxxxxxxx> wrote: > > On Fri, Dec 11, 2020 at 05:05:58PM +0000, Daniel Thompson wrote: > > On Fri, Dec 11, 2020 at 08:37:40AM -0600, Rob Herring wrote: > > > On Fri, Dec 11, 2020 at 6:15 AM Daniel Thompson > > > > BTW I noticed many other pcie-designware drivers take advantage > > > > of a function called dw_pcie_wait_for_link() in their init paths... > > > > but my naive attempts to add it to the layerscape driver results > > > > in non-booting systems so I haven't embarrassed myself by including > > > > that in the patch! > > > > > > You need to look at what's pending for v5.11, because I reworked this > > > to be more unified. The ordering of init is also possibly changed. The > > > sequence is now like this: > > > > > > dw_pcie_setup_rc(pp); > > > dw_pcie_msi_init(pp); > > > > > > if (!dw_pcie_link_up(pci) && pci->ops->start_link) { > > > ret = pci->ops->start_link(pci); > > > if (ret) > > > goto err_free_msi; > > > } > > > > > > /* Ignore errors, the link may come up later */ > > > dw_pcie_wait_for_link(pci); > > > > Thanks. That looks likely to fix it since IIUC dw_pcie_wait_for_link() > > will end up waiting somewhat like the double check I added to > > ls_pcie_link_up(). > > > > I'll take a look at let you know. > > Yes. These changes have fixed the enumeration problems for me. > > I tested pci/next and I cherry picked your patch series onto v5.10 and > both are working well. > > Given this fixes a bug for me, do you think there is any scope for me > to whittle down your series into patches for the stable kernels or am > I likely to find too many extra bits being pulled in? I think I'd just go the adding a delay route. It's a fairly big series and depends on my other clean-up done in 5.10. And there's at least some possibility it regresses some platform given the limited testing linux-next gets. Rob