Serge, On 25/10/23 15:58, Serge Semin wrote: > Hi Siddharth, Bjorn > > On Wed, Oct 25, 2023 at 10:32:50AM +0530, Siddharth Vadapalli wrote: ... >> > >> ks_pcie_probe() >> dw_pcie_host_init() >> pci_host_probe() >> ks_pcie_v3_65_add_bus() > > I guess what Bjorn implied was to add the ks_pcie_v3_65_add_bus() > invocation to the host_init() callback, i.e. in ks_pcie_host_init(). I misunderstood the term "host_init()", and interpret it as "dw_pcie_host_init()", due to which I thought I will add it after dw_pcie_host_init() invocation in ks_pcie_probe. Thank you for clarifying. > Moreover initializing the BARs/MSI after all the PCIe hierarchy has > been probed will eventually cause problems since MSI's won't work > until the ks_pcie_v3_65_add_bus() is called. > >> >> Since the .add_bus() method will be removed following this change, I suppose >> that the patch I post for it can be applied instead of this v3 patch which fixes >> pci_ops. >> > >> The patch I plan to post as a replacement for the current patch which shall also >> remove the ks_pcie_v3_65_add_bus() and the .add_bus() method is: > > Just a note. Seeing the Bjorn's suggestion may cause a regression on > the Keystone PCIe Host v3.65 I would suggest to merge in the original > fix as is and post an additional cleanup patch, like below with proper > modifications, on top of it. Thus we'll minimize a risk to break > things at least on the stable kernels. I will post it as a separate cleanup patch in that case and this v3 patch can be merged independently as you suggested. -- Regards, Siddharth.
