On Thu, Nov 14, 2019 at 1:31 AM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote: > > This is fine, but it feels like sort of a blunt instrument. Is there > any practical way to clear pci_host_bridge.native_pcie_hotplug (and > native_aer if appropriate) for the PHBs in question? That would also > prevent pciehp from binding. It is a large hammer, but I don't see a better way to handle it for the moment. I had another look and my initial assessment was wrong in that it's the portbus driver which claims the MSI rather than pciehp itself. The MSI in the PCIe capability is shared between hotplug events, PMEs, and BW notifications so to make the portbus concept work the portbus driver needs to own the interrupt. Basicly, pnv_php and portbus are fundamentally at odds with each other and can't be used concurrently. I also think there's some latent issues with the interaction of DPC and EEH since they operate off the same set of error messages. We haven't run into any problems yet, but I think that's largely because we haven't shipped any systems with DPC enabled. In any case, I'd prefer we disabled portbus until we've fully unpacked what's going on there. > We might someday pull portdrv into the PCI core directly instead of as > a separate driver, and I'm thinking that might be easier if we have > more specific indications of what the core shouldn't use. It's not intended to be a permanent change. In the long term I want to move everything except the initialisation and reset of the PHB out of firmware and into the kernel so we can use more of the native PCIe management features.
