On Tue, Aug 1, 2017 at 3:58 PM, Winkler, Tomas <tomas.winkler@xxxxxxxxx> wrote: >> >> Hi, >> >> On Tue, Aug 1, 2017 at 7:25 AM, Usyskin, Alexander >> <alexander.usyskin@xxxxxxxxx> wrote: >> > Hi >> > >> > We using pci_dev_run_wake that changed in mentioned patch to decide if >> > to replace usual PM callbacks with domain ones. >> > IIRC, the mei device is not remote wakeable on that platform, so we >> > should set domain callbacks. >> > There was a patch in PM framework that squashes runtime suspend with >> > usual suspend for some devices. >> > May it be that now pci_dev_run_wake returns true form mei and we are >> > not setting domain callbacks? >> > In that case we going through PCI device level PM path and may trigger >> that squash. >> > That will explain lack of mei logs on suspend. >> > >> > Dominik, can you try comment out "if (!pci_dev_run_wake(pdev))" >> > at drivers/misc/mei/pci-me.c (around line 223) to set domain callbacks >> > by force to see if this is indeed the case? >> >> Why exactly do you need the pci_dev_run_wake(pdev) check? > > We need to re-review this code now, but as far as I remember. > On some platforms with NFC connected via MEI, there was no PME enabled, hence we needed to keep in band irq opened for rx to wake us up. But pci_dev_run_wake() returning "true" doesn't guarantee that wakeup signaling will actually work. What it tells you is merely that everything appears to be in place for wakeup to work from the software perspective and it is a bit biased on the optimistic side, so I'm not really sure if that's what you need. Maybe you should just override the PCI PM unconditionally and do what's needed from you PM domain callbacks. Dunno. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
