On Mon, Mar 14, 2016 at 11:32:59AM +0200, Mika Westerberg wrote: > > What happens if the PCIe port initially can be put in D3hot, but we we > > later hot-add a device that would disqualify it? > > > > Oh, I think I see -- we walk the subordinate devices every time we > > would like to put the port in D3hot: > > > > pcie_port_suspend_noirq > > pcie_port_suspend_allowed > > dmi_get_date > > pcie_port_can_suspend > > pci_walk_bus > > > > I guess that should work, but it seems clunky to do all that work, > > even though it's not really a performance path. What if we did this: > > > > - add a d3hot_allowed bit in struct pci_dev > > > > - when enumerating a port, set d3hot_allowed if BIOS is new enough > > (it makes me a bit nervous that we apparently default to enabling > > D3hot on arches without DMI) > > > > - when enumerating devices, clear d3hot_allowed in upstream bridge > > if necessary > > > > - when removing last device on a bus, re-do port config (set > > d3hot_allowed if appropriate) > > Sounds reasonable. I'll give it a try. It looks like we cannot use this approach. Userspace (and drivers) can prevent devices from entering D3cold by changing dev->d3cold_allowed. That can happen after the device has been enumerated. -- 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
