Re: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+]

[Rafael J. Wysocki]

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