On Thu, 2018-12-06 at 11:28 +0100, Lucas Stach wrote: > Am Mittwoch, den 05.12.2018, 23:45 -0800 schrieb Andrey Smirnov: > > Building a kernel with CONFIG_PCI_IMX6=y, but CONFIG_PCIEPORTBUS=n > > produces a system where built-in PCIE bridge (16c3:abcd) isn't > > bound > > to pcieport driver. This, in turn, results in a PCIE bus that is > > capable of enumerating attached PCIE device, but lacks functional > > interrupt support. > > This is odd. AFAIK PCI port services are a totally optional thing and > them being absent should not lead to a non-functional PCI bus. So I > would really like to see some deeper analysis what is going on here. I noticed this previously, https://www.spinics.net/lists/linux-pci/msg77840.html What happened was that PCIEPORTBUS *was* selected by all the platform dwc drivers and those selections were removed in: commit f3fdfc4ac3a26865e84627a7fe08a906081e5abc Author: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> Date: Fri May 18 15:08:36 2018 -0500 PCI: Remove host driver Kconfig selection of CONFIG_PCIEPORTBUS Host bridge drivers do not use the portdrv interfaces (struct pcie_device, struct pcie_port_service_driver, pcie_port_service_register(), etc), and they should not select CONFIG_PCIEPORTBUS. I encountered this when a kernel defconfig that previously turned on PCIEPORTBUS stopped turning in on, resulting in the situation that Andrey describes: no errors, device present, but no MSI interrupts. The in kernel defconfigs (mine not being one of those) for all the dwc pcie users should probably be refreshed to enable pcieportbus. It seems appropriate that the port services are optional and it's unfortunate that the kernel defconfig system resolves in the change in this manner, vs keeping pcieportbus on by default. I do know why it is this way and I don't think there is any great solution there. It has never been clear to me why pcieportbus was necessary for MSI.
