On Sun, Feb 12, 2017 at 05:07:45PM +0100, Lukas Wunner wrote:
> Commit 68db9bc81436 ("PCI: pciehp: Add runtime PM support for PCIe
> hotplug ports") extended runtime PM for PCIe ports to hotplug ports.
> However Yinghai Lu reported the following breakage caused by the commit:
>
> * After disabling a slot on one of his servers, the slot signals PME
> which causes pciehp to immediately re-enable the card, thus defeating
> manual slot control via sysfs.
I don't think we've clearly established this. It surprises me that a
Downstream Port would signal PME after turning off power to the slot.
Wouldn't that make PME useless?
I'd like to look at this in a little more detail, either by turning
off PM and pciehp and poking things manually with setpci, or possibly
by adding some debug output in the PME ISR and the pciehp ISR and
"write command" paths.
> * On another server which has a Power Controller for PCIe hotplug ports
> (PCIe r3.1, sec 6.7.1.8), the slot cannot be re-enabled after manually
> disabling it via sysfs since commit 68db9bc81436 acquired a runtime
> ref only *after* enabling power on the slot, yet this particular
> SkyLake server requires that the port is in D0 when enabling power.
So this server requires that the Downstream Port must be in D0 before
we turn on power to the slot below the Downstream Port? That seems
like it would be a requirement for *all* systems. If the bridge is
not in D0, we can't generate any PCI transactions on the secondary bus
(PCI PM r1.1., Table 19), so we can't enumerate anything in the slot.
Bjorn
