On 6/25/25 1:38 PM, Lukas Wunner wrote: > On Wed, Jun 25, 2025 at 09:38:19AM +0530, Krishna Kumar wrote: >> On 6/21/25 3:29 PM, Lukas Wunner wrote: >>> On Fri, Jun 20, 2025 at 02:56:51PM +0530, Krishna Kumar wrote: >>>> 5. If point 3 and 4 does not solve the problem, then only we should >>>> move to pciehp.c. But AFAIK, PPC/Powernv is DT based while pciehp.c >>>> may be only supporting acpi (I have to check it on this). We need to >>>> provide PHB related information via DTB and maintain the related >>>> topology information via dtb and then it can be doable. >>> pciehp is not ACPI-specific. The PCIe port service driver in >>> drivers/pci/pcie/portdrv.c binds to any PCIe port, examines the >>> port's capabilities (e.g. hotplug, AER, DPC, ...) and instantiates >>> sub-devices to which pciehp and the other drivers such as aer bind. >> 1. If we get PHB info from mmcfg via acpi table in x86 and create a >> root port from there with some address/entity and if this Acpi and >> associated entity is not present for PPC, then it can be a problem. >> >> 2. PPC is normally based on DTB entity and it identifies PHB and pcie >> devices from there. If this all the information is correctly map >> via portdrv.c then there is no problem and whatever you are telling >> is correct and it will work. >> >> 3. But if point 2 is not handled correctly we need to just aligned with >> port related data structure to make it work. > PCI devices do not have to be enumerated in the devicetree (or in ACPI > DSDT) because PCI is an enumerable bus (like USB). Only the host bridge > has to be enumerated in the devicetree or DSDT. The kernel can find the > PCI devices below the host bridge itself. Yes in DFS manner (once it gets to know the PHB address via -acpi in X86 and via DTB in PPC) > Hot-plugged devices are > usually not described in the devicetree or DSDT because one doesn't > know their properties in advance. > > pnv_php.c seems to search the devicetree for hotplug slots and > instantiates them. My expectation would be that any hotplug-capable > PCIe Root Port or Downstream Port, which is *not* described in the > devicetree such that pnv_php.c creates a slot for it, is handled by > pciehp. Your are correct, pnv_php.c heavily depends on slot id and DTB nodes. Thats how its designed. Can we decouple it via DTB nodes, I will come back on this. > > Timothy was talking about a Microsemi PCIe switch below the Root Port. > My understanding is that the Downstream Ports of that switch are > hotplug-capable. I understand it. > So unless you've disabled CONFIG_HOTPLUG_PCI_PCIE, > I'd expect those ports to be handled by pciehp. I need to check it and test it, but yeah- it may or maynot work and I will confirm it only after some study and testing (maybe in 1-2 week) > Assuming they're not > described as a "ibm,ioda2-phb" compatible device in the devicetree, > but why would they? HW topology and DTB is based on IODA and it will keep changing, not frequently but eventually. > > Thanks, > > Lukas
Best Regards, Krishna
