> https://bugzilla.kernel.org/show_bug.cgi?id=53811 > It appears that the SCI is generated when hotplug event occurs even if the root > port is in low power state. But because the configuration space of subordinate > devices is not accessible when the root port is in low power state, the > hotplugged device is not detected. If the problem is with config space access, not with the SCI, why can't you just put the root port back in D0 before scanning its secondary bus? That seems like a more direct fix. >> However, I don't think this is a complete solution because acpiphp does not >> claim all root ports that can generate hotplug SCI events. Bug #54981 is one >> example. > > In #54981, if acpiphp is used, PCIe hotplug does not work regardless we put the > root port into low power state or not. If pciehp is used, the pciehp will > register the hotplug slots, so that we will prevent putting the root port into > low power state. So I think the comment #26 patch is a practical solution. My point here is not about power; only that acpiphp cannot reliably identify all slots, so we can't rely on slot presence as a way to decide what to do about power. On the machine in bug #54981, we must use acpiphp because the BIOS doesn't let us use pciehp. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
