On Thu, Oct 27, 2022 at 08:03:42AM +0200, Lukas Wunner wrote: > On Tue, Oct 25, 2022 at 04:25:21PM -0500, Bjorn Helgaas wrote: > > N.B. This changes the order of pmac_ohci_off() and pmac_ohci_on(). > > Previously, pmac_ohci_off() was called *after* pci_save_state() and > > pci_set_power_state(), and this change calls it *before*. > > > > Similarly, pmac_ohci_on() was previously called *before* > > pci_set_power_state() and pci_restore_state() and this change calls it > > *after*. > > Seems likely the ordering change may break things. > > pmac_ohci_on/off() toggles PMAC_FTR_1394_ENABLE, which is defined as: > > * enable/disable the firewire cell of an uninorth ASIC. > > It sounds like it will cut power to the firewire controller and I'd > expect that pci_save_state() will then not be able to access config > space. Yeah, definitely a risk, so I won't merge this myself since I have no insight or way to test it. > The only way to make this work is to define a struct dev_pm_domain > whose ->suspend_noirq callback first invokes the pci_bus_type > ->suspend_noirq callback and then cuts power to the firewire cell > by calling pmac_ohci_off(). > > I've done something like this for Thunderbolt power management on > x86 Macs a few years back but didn't get around to upstream it so far: > > https://github.com/l1k/linux/commit/4db7f0b1f5c9 Wow, that's some impressive reverse engineering and work! We're not quite there yet, but if we ever get to the point where this driver is the only thing preventing us from removing the PCI legacy PM hooks, I think I'd be inclined to just sacrifice PM completely for this driver. I can't really see putting in the kind of work you did for Thunderbolt. Bjorn
