[Regression] PCI / PM: Simplify device wakeup settings code

[Regression] PCI / PM: Simplify device wakeup settings code

[Joseph Salisbury]

Hi Rafael,

A kernel bug report was opened against Ubuntu [0].  After a kernel
bisect, it was found that reverting the following two commits resolved
this bug:

0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
 
This is a regression introduced in v4.13-rc1 and still exists in
mainline.  The bug causes the battery to drain when the system is
powered down and unplugged, which does not happed prior to these two
commits.  The bisect actually pointed to commit de3ef1e, but reverting
these two commits fixes the issue.
    
I was hoping to get your feedback, since you are the patch author.  Do
you think gathering any additional data will help diagnose this issue,
or would it be best to submit a revert request?
   
   
Thanks,

Joe

[0] http://pad.lv/1745646

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
<joseph.salisbury@canonical.com> wrote:
> Hi Rafael,
>
> A kernel bug report was opened against Ubuntu [0].  After a kernel
> bisect, it was found that reverting the following two commits resolved
> this bug:
>
> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>
> This is a regression introduced in v4.13-rc1 and still exists in
> mainline.  The bug causes the battery to drain when the system is
> powered down and unplugged, which does not happed prior to these two
> commits.

What system and what do you mean by "powered down"?  How much time
does it take for the battery to drain now?

> The bisect actually pointed to commit de3ef1e, but reverting
> these two commits fixes the issue.
>
> I was hoping to get your feedback, since you are the patch author.  Do
> you think gathering any additional data will help diagnose this issue,
> or would it be best to submit a revert request?

First, reverting these is not an option or you will break systems
relying on them now.  4.13 is three releases back at this point.

Second, your issue appears to be related to the suspend/shutdown path
whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
change in pci_enable_wake() causes the problem to happen.  Can you try
to revert this one alone and see if that helps?

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Joseph Salisbury]

On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
> <joseph.salisbury@canonical.com> wrote:
>> Hi Rafael,
>>
>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>> bisect, it was found that reverting the following two commits resolved
>> this bug:
>>
>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>>
>> This is a regression introduced in v4.13-rc1 and still exists in
>> mainline.  The bug causes the battery to drain when the system is
>> powered down and unplugged, which does not happed prior to these two
>> commits.
> What system and what do you mean by "powered down"?  How much time
> does it take for the battery to drain now?
By powered down, the bug reporter is saying physically powered off and
unplugged.  The system is a HP laptop:

dmi.chassis.vendor: HP
dmi.product.family: 103C_5335KV HP Notebook
dmi.product.name: HP Notebook
vendor_id    : GenuineIntel
cpu family    : 6


>
>> The bisect actually pointed to commit de3ef1e, but reverting
>> these two commits fixes the issue.
>>
>> I was hoping to get your feedback, since you are the patch author.  Do
>> you think gathering any additional data will help diagnose this issue,
>> or would it be best to submit a revert request?
> First, reverting these is not an option or you will break systems
> relying on them now.  4.13 is three releases back at this point.
>
> Second, your issue appears to be related to the suspend/shutdown path
> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
> change in pci_enable_wake() causes the problem to happen.  Can you try
> to revert this one alone and see if that helps?
A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
tested.  However, the test kernel still exhibited the bug.

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
<joseph.salisbury@canonical.com> wrote:
> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>> <joseph.salisbury@canonical.com> wrote:
>>> Hi Rafael,
>>>
>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>>> bisect, it was found that reverting the following two commits resolved
>>> this bug:
>>>
>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>>>
>>> This is a regression introduced in v4.13-rc1 and still exists in
>>> mainline.  The bug causes the battery to drain when the system is
>>> powered down and unplugged, which does not happed prior to these two
>>> commits.
>> What system and what do you mean by "powered down"?  How much time
>> does it take for the battery to drain now?
> By powered down, the bug reporter is saying physically powered off and
> unplugged.  The system is a HP laptop:
>
> dmi.chassis.vendor: HP
> dmi.product.family: 103C_5335KV HP Notebook
> dmi.product.name: HP Notebook
> vendor_id    : GenuineIntel
> cpu family    : 6
>
>
>>
>>> The bisect actually pointed to commit de3ef1e, but reverting
>>> these two commits fixes the issue.
>>>
>>> I was hoping to get your feedback, since you are the patch author.  Do
>>> you think gathering any additional data will help diagnose this issue,
>>> or would it be best to submit a revert request?
>> First, reverting these is not an option or you will break systems
>> relying on them now.  4.13 is three releases back at this point.
>>
>> Second, your issue appears to be related to the suspend/shutdown path
>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>> change in pci_enable_wake() causes the problem to happen.  Can you try
>> to revert this one alone and see if that helps?
> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
> tested.  However, the test kernel still exhibited the bug.

So essentially the bisection result cannot be trusted.

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Joseph Salisbury]

On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
> <joseph.salisbury@canonical.com> wrote:
>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>>> <joseph.salisbury@canonical.com> wrote:
>>>> Hi Rafael,
>>>>
>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>>>> bisect, it was found that reverting the following two commits resolved
>>>> this bug:
>>>>
>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>>>>
>>>> This is a regression introduced in v4.13-rc1 and still exists in
>>>> mainline.  The bug causes the battery to drain when the system is
>>>> powered down and unplugged, which does not happed prior to these two
>>>> commits.
>>> What system and what do you mean by "powered down"?  How much time
>>> does it take for the battery to drain now?
>> By powered down, the bug reporter is saying physically powered off and
>> unplugged.  The system is a HP laptop:
>>
>> dmi.chassis.vendor: HP
>> dmi.product.family: 103C_5335KV HP Notebook
>> dmi.product.name: HP Notebook
>> vendor_id    : GenuineIntel
>> cpu family    : 6
>>
>>
>>>> The bisect actually pointed to commit de3ef1e, but reverting
>>>> these two commits fixes the issue.
>>>>
>>>> I was hoping to get your feedback, since you are the patch author.  Do
>>>> you think gathering any additional data will help diagnose this issue,
>>>> or would it be best to submit a revert request?
>>> First, reverting these is not an option or you will break systems
>>> relying on them now.  4.13 is three releases back at this point.
>>>
>>> Second, your issue appears to be related to the suspend/shutdown path
>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>>> to revert this one alone and see if that helps?
>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>> tested.  However, the test kernel still exhibited the bug.
> So essentially the bisection result cannot be trusted.
Yes, the bisect results were different than usual.  The bisect reported
commit de3ef1eb1cd0 as the first bad commit.  I could not revet commit
de3ef1eb1cd0 without either back porting  the revert of that commit or
reverting 0ce3fcaff929 first.  However, the bug still happened with
these two reverted.  I needed to revert 0847684cfc5f and 0ce3fcaff929
for the bug to go away.  I reverted 0ce3fcaff929 in this case to also
avoid having to back port the revert of 0847684cfc5f.  I was unsure if
these unexpected results were due to the interaction/dependency between
the commits or due to inaccurate testing by the end user.

I'll build some more test kernels and have the user perform some more
testing to see if the bug can be specifically narrowed down to 0847684cfc5f.

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Joseph Salisbury]

On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
> <joseph.salisbury@canonical.com> wrote:
>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>>> <joseph.salisbury@canonical.com> wrote:
>>>> Hi Rafael,
>>>>
>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>>>> bisect, it was found that reverting the following two commits resolved
>>>> this bug:
>>>>
>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>>>>
>>>> This is a regression introduced in v4.13-rc1 and still exists in
>>>> mainline.  The bug causes the battery to drain when the system is
>>>> powered down and unplugged, which does not happed prior to these two
>>>> commits.
>>> What system and what do you mean by "powered down"?  How much time
>>> does it take for the battery to drain now?
>> By powered down, the bug reporter is saying physically powered off and
>> unplugged.  The system is a HP laptop:
>>
>> dmi.chassis.vendor: HP
>> dmi.product.family: 103C_5335KV HP Notebook
>> dmi.product.name: HP Notebook
>> vendor_id    : GenuineIntel
>> cpu family    : 6
>>
>>
>>>> The bisect actually pointed to commit de3ef1e, but reverting
>>>> these two commits fixes the issue.
>>>>
>>>> I was hoping to get your feedback, since you are the patch author.  Do
>>>> you think gathering any additional data will help diagnose this issue,
>>>> or would it be best to submit a revert request?
>>> First, reverting these is not an option or you will break systems
>>> relying on them now.  4.13 is three releases back at this point.
>>>
>>> Second, your issue appears to be related to the suspend/shutdown path
>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>>> to revert this one alone and see if that helps?
>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>> tested.  However, the test kernel still exhibited the bug.
> So essentially the bisection result cannot be trusted.

We performed some more testing and confirmed just a revert of the
following commit resolves the bug:

0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")

Can you think of any suggestions to help debug further?

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
<joseph.salisbury@canonical.com> wrote:
> On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
>> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
>> <joseph.salisbury@canonical.com> wrote:
>>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>>>> <joseph.salisbury@canonical.com> wrote:
>>>>> Hi Rafael,
>>>>>
>>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>>>>> bisect, it was found that reverting the following two commits resolved
>>>>> this bug:
>>>>>
>>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>>>>>
>>>>> This is a regression introduced in v4.13-rc1 and still exists in
>>>>> mainline.  The bug causes the battery to drain when the system is
>>>>> powered down and unplugged, which does not happed prior to these two
>>>>> commits.
>>>> What system and what do you mean by "powered down"?  How much time
>>>> does it take for the battery to drain now?
>>> By powered down, the bug reporter is saying physically powered off and
>>> unplugged.  The system is a HP laptop:
>>>
>>> dmi.chassis.vendor: HP
>>> dmi.product.family: 103C_5335KV HP Notebook
>>> dmi.product.name: HP Notebook
>>> vendor_id    : GenuineIntel
>>> cpu family    : 6
>>>
>>>
>>>>> The bisect actually pointed to commit de3ef1e, but reverting
>>>>> these two commits fixes the issue.
>>>>>
>>>>> I was hoping to get your feedback, since you are the patch author.  Do
>>>>> you think gathering any additional data will help diagnose this issue,
>>>>> or would it be best to submit a revert request?
>>>> First, reverting these is not an option or you will break systems
>>>> relying on them now.  4.13 is three releases back at this point.
>>>>
>>>> Second, your issue appears to be related to the suspend/shutdown path
>>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>>>> to revert this one alone and see if that helps?
>>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>>> tested.  However, the test kernel still exhibited the bug.
>> So essentially the bisection result cannot be trusted.
>
> We performed some more testing and confirmed just a revert of the
> following commit resolves the bug:
>
> 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")

Thanks for confirming this!

> Can you think of any suggestions to help debug further?

The root cause of the regression is likely the change in
pci_enable_wake() removing the device_may_wakeup() check from it.

Probably, one of the drivers in the platform calls pci_enable_wake()
directly from its ->shutdown() callback and that causes the device to
be set up for system wakeup which in turn causes the power draw while
the system is off to increase.

I would look at the PCI drivers used on that platform to find which of
them call pci_enable_wake() directly from ->shutdown() and I would
make these calls conditional on device_may_wakeup().

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Bjorn Helgaas]

On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
> <joseph.salisbury@canonical.com> wrote:
> > On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
> >> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
> >> <joseph.salisbury@canonical.com> wrote:
> >>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
> >>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
> >>>> <joseph.salisbury@canonical.com> wrote:
> >>>>> Hi Rafael,
> >>>>>
> >>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
> >>>>> bisect, it was found that reverting the following two commits resolved
> >>>>> this bug:
> >>>>>
> >>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
> >>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
> >>>>>
> >>>>> This is a regression introduced in v4.13-rc1 and still exists in
> >>>>> mainline.  The bug causes the battery to drain when the system is
> >>>>> powered down and unplugged, which does not happed prior to these two
> >>>>> commits.
> >>>> What system and what do you mean by "powered down"?  How much time
> >>>> does it take for the battery to drain now?
> >>> By powered down, the bug reporter is saying physically powered off and
> >>> unplugged.  The system is a HP laptop:
> >>>
> >>> dmi.chassis.vendor: HP
> >>> dmi.product.family: 103C_5335KV HP Notebook
> >>> dmi.product.name: HP Notebook
> >>> vendor_id    : GenuineIntel
> >>> cpu family    : 6
> >>>
> >>>
> >>>>> The bisect actually pointed to commit de3ef1e, but reverting
> >>>>> these two commits fixes the issue.
> >>>>>
> >>>>> I was hoping to get your feedback, since you are the patch author.  Do
> >>>>> you think gathering any additional data will help diagnose this issue,
> >>>>> or would it be best to submit a revert request?
> >>>> First, reverting these is not an option or you will break systems
> >>>> relying on them now.  4.13 is three releases back at this point.
> >>>>
> >>>> Second, your issue appears to be related to the suspend/shutdown path
> >>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
> >>>> change in pci_enable_wake() causes the problem to happen.  Can you try
> >>>> to revert this one alone and see if that helps?
> >>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
> >>> tested.  However, the test kernel still exhibited the bug.
> >> So essentially the bisection result cannot be trusted.
> >
> > We performed some more testing and confirmed just a revert of the
> > following commit resolves the bug:
> >
> > 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
> 
> Thanks for confirming this!
> 
> > Can you think of any suggestions to help debug further?
> 
> The root cause of the regression is likely the change in
> pci_enable_wake() removing the device_may_wakeup() check from it.
> 
> Probably, one of the drivers in the platform calls pci_enable_wake()
> directly from its ->shutdown() callback and that causes the device to
> be set up for system wakeup which in turn causes the power draw while
> the system is off to increase.
> 
> I would look at the PCI drivers used on that platform to find which of
> them call pci_enable_wake() directly from ->shutdown() and I would
> make these calls conditional on device_may_wakeup().

I took a quick look with

  git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"

and didn't notice any pci_enable_wake() callers that called
device_may_wakeup() first.

Probably a dumb question, but would it make sense to restore the
device_may_wakeup() check in pci_enable_wake(), e.g.,

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index e597655a5643..9fa64c175f92 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1932,6 +1932,9 @@ int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
 {
 	int ret = 0;
 
+	if (enable && !device_may_wakeup(&dev->dev))
+		return -EINVAL;
+
 	/*
 	 * Bridges can only signal wakeup on behalf of subordinate devices,
 	 * but that is set up elsewhere, so skip them.

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
>> <joseph.salisbury@canonical.com> wrote:
>> > On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
>> >> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
>> >> <joseph.salisbury@canonical.com> wrote:
>> >>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>> >>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>> >>>> <joseph.salisbury@canonical.com> wrote:
>> >>>>> Hi Rafael,
>> >>>>>
>> >>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>> >>>>> bisect, it was found that reverting the following two commits resolved
>> >>>>> this bug:
>> >>>>>
>> >>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>> >>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>> >>>>>
>> >>>>> This is a regression introduced in v4.13-rc1 and still exists in
>> >>>>> mainline.  The bug causes the battery to drain when the system is
>> >>>>> powered down and unplugged, which does not happed prior to these two
>> >>>>> commits.
>> >>>> What system and what do you mean by "powered down"?  How much time
>> >>>> does it take for the battery to drain now?
>> >>> By powered down, the bug reporter is saying physically powered off and
>> >>> unplugged.  The system is a HP laptop:
>> >>>
>> >>> dmi.chassis.vendor: HP
>> >>> dmi.product.family: 103C_5335KV HP Notebook
>> >>> dmi.product.name: HP Notebook
>> >>> vendor_id    : GenuineIntel
>> >>> cpu family    : 6
>> >>>
>> >>>
>> >>>>> The bisect actually pointed to commit de3ef1e, but reverting
>> >>>>> these two commits fixes the issue.
>> >>>>>
>> >>>>> I was hoping to get your feedback, since you are the patch author.  Do
>> >>>>> you think gathering any additional data will help diagnose this issue,
>> >>>>> or would it be best to submit a revert request?
>> >>>> First, reverting these is not an option or you will break systems
>> >>>> relying on them now.  4.13 is three releases back at this point.
>> >>>>
>> >>>> Second, your issue appears to be related to the suspend/shutdown path
>> >>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>> >>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>> >>>> to revert this one alone and see if that helps?
>> >>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>> >>> tested.  However, the test kernel still exhibited the bug.
>> >> So essentially the bisection result cannot be trusted.
>> >
>> > We performed some more testing and confirmed just a revert of the
>> > following commit resolves the bug:
>> >
>> > 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
>>
>> Thanks for confirming this!
>>
>> > Can you think of any suggestions to help debug further?
>>
>> The root cause of the regression is likely the change in
>> pci_enable_wake() removing the device_may_wakeup() check from it.
>>
>> Probably, one of the drivers in the platform calls pci_enable_wake()
>> directly from its ->shutdown() callback and that causes the device to
>> be set up for system wakeup which in turn causes the power draw while
>> the system is off to increase.
>>
>> I would look at the PCI drivers used on that platform to find which of
>> them call pci_enable_wake() directly from ->shutdown() and I would
>> make these calls conditional on device_may_wakeup().
>
> I took a quick look with
>
>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
>
> and didn't notice any pci_enable_wake() callers that called
> device_may_wakeup() first.
>
> Probably a dumb question, but would it make sense to restore the
> device_may_wakeup() check in pci_enable_wake(), e.g.,

At least as a matter of test, yes, it would, but not this way:

> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index e597655a5643..9fa64c175f92 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -1932,6 +1932,9 @@ int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
>  {
>         int ret = 0;
>
> +       if (enable && !device_may_wakeup(&dev->dev))
> +               return -EINVAL;
> +
>         /*
>          * Bridges can only signal wakeup on behalf of subordinate devices,
>          * but that is set up elsewhere, so skip them.

because that would break runtime PM wakeup for devices that aren't
allowed to wake up the system from sleep.

Anyway, if the patch above makes the problem go away, it will mean we
are on the right track.

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
>> <joseph.salisbury@canonical.com> wrote:
>> > On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
>> >> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
>> >> <joseph.salisbury@canonical.com> wrote:
>> >>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>> >>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>> >>>> <joseph.salisbury@canonical.com> wrote:
>> >>>>> Hi Rafael,
>> >>>>>
>> >>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>> >>>>> bisect, it was found that reverting the following two commits resolved
>> >>>>> this bug:
>> >>>>>
>> >>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>> >>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>> >>>>>
>> >>>>> This is a regression introduced in v4.13-rc1 and still exists in
>> >>>>> mainline.  The bug causes the battery to drain when the system is
>> >>>>> powered down and unplugged, which does not happed prior to these two
>> >>>>> commits.
>> >>>> What system and what do you mean by "powered down"?  How much time
>> >>>> does it take for the battery to drain now?
>> >>> By powered down, the bug reporter is saying physically powered off and
>> >>> unplugged.  The system is a HP laptop:
>> >>>
>> >>> dmi.chassis.vendor: HP
>> >>> dmi.product.family: 103C_5335KV HP Notebook
>> >>> dmi.product.name: HP Notebook
>> >>> vendor_id    : GenuineIntel
>> >>> cpu family    : 6
>> >>>
>> >>>
>> >>>>> The bisect actually pointed to commit de3ef1e, but reverting
>> >>>>> these two commits fixes the issue.
>> >>>>>
>> >>>>> I was hoping to get your feedback, since you are the patch author.  Do
>> >>>>> you think gathering any additional data will help diagnose this issue,
>> >>>>> or would it be best to submit a revert request?
>> >>>> First, reverting these is not an option or you will break systems
>> >>>> relying on them now.  4.13 is three releases back at this point.
>> >>>>
>> >>>> Second, your issue appears to be related to the suspend/shutdown path
>> >>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>> >>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>> >>>> to revert this one alone and see if that helps?
>> >>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>> >>> tested.  However, the test kernel still exhibited the bug.
>> >> So essentially the bisection result cannot be trusted.
>> >
>> > We performed some more testing and confirmed just a revert of the
>> > following commit resolves the bug:
>> >
>> > 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
>>
>> Thanks for confirming this!
>>
>> > Can you think of any suggestions to help debug further?
>>
>> The root cause of the regression is likely the change in
>> pci_enable_wake() removing the device_may_wakeup() check from it.
>>
>> Probably, one of the drivers in the platform calls pci_enable_wake()
>> directly from its ->shutdown() callback and that causes the device to
>> be set up for system wakeup which in turn causes the power draw while
>> the system is off to increase.
>>
>> I would look at the PCI drivers used on that platform to find which of
>> them call pci_enable_wake() directly from ->shutdown() and I would
>> make these calls conditional on device_may_wakeup().
>
> I took a quick look with
>
>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
>
> and didn't notice any pci_enable_wake() callers that called
> device_may_wakeup() first.

I've just look at a bunch of network drivers doing that.

It looks like I may need to restore __pci_enable_wake() with an extra
"runtime" argument for internal use.

Joseph, can you ask the reporter to test the Bjorn's patch, please?

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Joseph Salisbury]

On 05/02/2018 06:41 AM, Rafael J. Wysocki wrote:
> On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
>>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
>>> <joseph.salisbury@canonical.com> wrote:
>>>> On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
>>>>> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>>>>>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>>>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>>>> Hi Rafael,
>>>>>>>>
>>>>>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>>>>>>>> bisect, it was found that reverting the following two commits resolved
>>>>>>>> this bug:
>>>>>>>>
>>>>>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>>>>>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>>>>>>>>
>>>>>>>> This is a regression introduced in v4.13-rc1 and still exists in
>>>>>>>> mainline.  The bug causes the battery to drain when the system is
>>>>>>>> powered down and unplugged, which does not happed prior to these two
>>>>>>>> commits.
>>>>>>> What system and what do you mean by "powered down"?  How much time
>>>>>>> does it take for the battery to drain now?
>>>>>> By powered down, the bug reporter is saying physically powered off and
>>>>>> unplugged.  The system is a HP laptop:
>>>>>>
>>>>>> dmi.chassis.vendor: HP
>>>>>> dmi.product.family: 103C_5335KV HP Notebook
>>>>>> dmi.product.name: HP Notebook
>>>>>> vendor_id    : GenuineIntel
>>>>>> cpu family    : 6
>>>>>>
>>>>>>
>>>>>>>> The bisect actually pointed to commit de3ef1e, but reverting
>>>>>>>> these two commits fixes the issue.
>>>>>>>>
>>>>>>>> I was hoping to get your feedback, since you are the patch author.  Do
>>>>>>>> you think gathering any additional data will help diagnose this issue,
>>>>>>>> or would it be best to submit a revert request?
>>>>>>> First, reverting these is not an option or you will break systems
>>>>>>> relying on them now.  4.13 is three releases back at this point.
>>>>>>>
>>>>>>> Second, your issue appears to be related to the suspend/shutdown path
>>>>>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>>>>>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>>>>>>> to revert this one alone and see if that helps?
>>>>>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>>>>>> tested.  However, the test kernel still exhibited the bug.
>>>>> So essentially the bisection result cannot be trusted.
>>>> We performed some more testing and confirmed just a revert of the
>>>> following commit resolves the bug:
>>>>
>>>> 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
>>> Thanks for confirming this!
>>>
>>>> Can you think of any suggestions to help debug further?
>>> The root cause of the regression is likely the change in
>>> pci_enable_wake() removing the device_may_wakeup() check from it.
>>>
>>> Probably, one of the drivers in the platform calls pci_enable_wake()
>>> directly from its ->shutdown() callback and that causes the device to
>>> be set up for system wakeup which in turn causes the power draw while
>>> the system is off to increase.
>>>
>>> I would look at the PCI drivers used on that platform to find which of
>>> them call pci_enable_wake() directly from ->shutdown() and I would
>>> make these calls conditional on device_may_wakeup().
>> I took a quick look with
>>
>>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
>>
>> and didn't notice any pci_enable_wake() callers that called
>> device_may_wakeup() first.
> I've just look at a bunch of network drivers doing that.
>
> It looks like I may need to restore __pci_enable_wake() with an extra
> "runtime" argument for internal use.
>
> Joseph, can you ask the reporter to test the Bjorn's patch, please?

Yes, I'll get him a test kernel and respond with the results.

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Joseph Salisbury]

On 05/02/2018 06:41 AM, Rafael J. Wysocki wrote:
> On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
>>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
>>> <joseph.salisbury@canonical.com> wrote:
>>>> On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
>>>>> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>>>>>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>>>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>>>> Hi Rafael,
>>>>>>>>
>>>>>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>>>>>>>> bisect, it was found that reverting the following two commits resolved
>>>>>>>> this bug:
>>>>>>>>
>>>>>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>>>>>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>>>>>>>>
>>>>>>>> This is a regression introduced in v4.13-rc1 and still exists in
>>>>>>>> mainline.  The bug causes the battery to drain when the system is
>>>>>>>> powered down and unplugged, which does not happed prior to these two
>>>>>>>> commits.
>>>>>>> What system and what do you mean by "powered down"?  How much time
>>>>>>> does it take for the battery to drain now?
>>>>>> By powered down, the bug reporter is saying physically powered off and
>>>>>> unplugged.  The system is a HP laptop:
>>>>>>
>>>>>> dmi.chassis.vendor: HP
>>>>>> dmi.product.family: 103C_5335KV HP Notebook
>>>>>> dmi.product.name: HP Notebook
>>>>>> vendor_id    : GenuineIntel
>>>>>> cpu family    : 6
>>>>>>
>>>>>>
>>>>>>>> The bisect actually pointed to commit de3ef1e, but reverting
>>>>>>>> these two commits fixes the issue.
>>>>>>>>
>>>>>>>> I was hoping to get your feedback, since you are the patch author.  Do
>>>>>>>> you think gathering any additional data will help diagnose this issue,
>>>>>>>> or would it be best to submit a revert request?
>>>>>>> First, reverting these is not an option or you will break systems
>>>>>>> relying on them now.  4.13 is three releases back at this point.
>>>>>>>
>>>>>>> Second, your issue appears to be related to the suspend/shutdown path
>>>>>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>>>>>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>>>>>>> to revert this one alone and see if that helps?
>>>>>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>>>>>> tested.  However, the test kernel still exhibited the bug.
>>>>> So essentially the bisection result cannot be trusted.
>>>> We performed some more testing and confirmed just a revert of the
>>>> following commit resolves the bug:
>>>>
>>>> 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
>>> Thanks for confirming this!
>>>
>>>> Can you think of any suggestions to help debug further?
>>> The root cause of the regression is likely the change in
>>> pci_enable_wake() removing the device_may_wakeup() check from it.
>>>
>>> Probably, one of the drivers in the platform calls pci_enable_wake()
>>> directly from its ->shutdown() callback and that causes the device to
>>> be set up for system wakeup which in turn causes the power draw while
>>> the system is off to increase.
>>>
>>> I would look at the PCI drivers used on that platform to find which of
>>> them call pci_enable_wake() directly from ->shutdown() and I would
>>> make these calls conditional on device_may_wakeup().
>> I took a quick look with
>>
>>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
>>
>> and didn't notice any pci_enable_wake() callers that called
>> device_may_wakeup() first.
> I've just look at a bunch of network drivers doing that.
>
> It looks like I may need to restore __pci_enable_wake() with an extra
> "runtime" argument for internal use.
>
> Joseph, can you ask the reporter to test the Bjorn's patch, please?

The bug reporter has testing Bjorn's patch.  It did in fact resolve the
bug.  Thanks for the quick help, Rafael and Bjorn!

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Bjorn Helgaas]

On Thu, May 03, 2018 at 02:29:02PM -0400, Joseph Salisbury wrote:
> On 05/02/2018 06:41 AM, Rafael J. Wysocki wrote:
> > On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
> >>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
> >>> <joseph.salisbury@canonical.com> wrote:
> >>>> On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
> >>>>> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
> >>>>> <joseph.salisbury@canonical.com> wrote:
> >>>>>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
> >>>>>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
> >>>>>>> <joseph.salisbury@canonical.com> wrote:
> >>>>>>>> Hi Rafael,
> >>>>>>>>
> >>>>>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
> >>>>>>>> bisect, it was found that reverting the following two commits resolved
> >>>>>>>> this bug:
> >>>>>>>>
> >>>>>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
> >>>>>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
> >>>>>>>>
> >>>>>>>> This is a regression introduced in v4.13-rc1 and still exists in
> >>>>>>>> mainline.  The bug causes the battery to drain when the system is
> >>>>>>>> powered down and unplugged, which does not happed prior to these two
> >>>>>>>> commits.
> >>>>>>> What system and what do you mean by "powered down"?  How much time
> >>>>>>> does it take for the battery to drain now?
> >>>>>> By powered down, the bug reporter is saying physically powered off and
> >>>>>> unplugged.  The system is a HP laptop:
> >>>>>>
> >>>>>> dmi.chassis.vendor: HP
> >>>>>> dmi.product.family: 103C_5335KV HP Notebook
> >>>>>> dmi.product.name: HP Notebook
> >>>>>> vendor_id    : GenuineIntel
> >>>>>> cpu family    : 6
> >>>>>>
> >>>>>>
> >>>>>>>> The bisect actually pointed to commit de3ef1e, but reverting
> >>>>>>>> these two commits fixes the issue.
> >>>>>>>>
> >>>>>>>> I was hoping to get your feedback, since you are the patch author.  Do
> >>>>>>>> you think gathering any additional data will help diagnose this issue,
> >>>>>>>> or would it be best to submit a revert request?
> >>>>>>> First, reverting these is not an option or you will break systems
> >>>>>>> relying on them now.  4.13 is three releases back at this point.
> >>>>>>>
> >>>>>>> Second, your issue appears to be related to the suspend/shutdown path
> >>>>>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
> >>>>>>> change in pci_enable_wake() causes the problem to happen.  Can you try
> >>>>>>> to revert this one alone and see if that helps?
> >>>>>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
> >>>>>> tested.  However, the test kernel still exhibited the bug.
> >>>>> So essentially the bisection result cannot be trusted.
> >>>> We performed some more testing and confirmed just a revert of the
> >>>> following commit resolves the bug:
> >>>>
> >>>> 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
> >>> Thanks for confirming this!
> >>>
> >>>> Can you think of any suggestions to help debug further?
> >>> The root cause of the regression is likely the change in
> >>> pci_enable_wake() removing the device_may_wakeup() check from it.
> >>>
> >>> Probably, one of the drivers in the platform calls pci_enable_wake()
> >>> directly from its ->shutdown() callback and that causes the device to
> >>> be set up for system wakeup which in turn causes the power draw while
> >>> the system is off to increase.
> >>>
> >>> I would look at the PCI drivers used on that platform to find which of
> >>> them call pci_enable_wake() directly from ->shutdown() and I would
> >>> make these calls conditional on device_may_wakeup().
> >> I took a quick look with
> >>
> >>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
> >>
> >> and didn't notice any pci_enable_wake() callers that called
> >> device_may_wakeup() first.
> > I've just look at a bunch of network drivers doing that.
> >
> > It looks like I may need to restore __pci_enable_wake() with an extra
> > "runtime" argument for internal use.
> >
> > Joseph, can you ask the reporter to test the Bjorn's patch, please?
> 
> The bug reporter has testing Bjorn's patch.  It did in fact resolve the
> bug.  Thanks for the quick help, Rafael and Bjorn!

Just as a word of caution, I think Rafael said my patch was not the
right fix because it would break something else.  So I would wait for
a better patch from Rafael before actually resolving this issue.

Bjorn

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Thu, May 3, 2018 at 9:11 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Thu, May 03, 2018 at 02:29:02PM -0400, Joseph Salisbury wrote:
>> On 05/02/2018 06:41 AM, Rafael J. Wysocki wrote:
>> > On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>> >> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
>> >>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
>> >>> <joseph.salisbury@canonical.com> wrote:
>> >>>> On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
>> >>>>> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
>> >>>>> <joseph.salisbury@canonical.com> wrote:
>> >>>>>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>> >>>>>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>> >>>>>>> <joseph.salisbury@canonical.com> wrote:
>> >>>>>>>> Hi Rafael,
>> >>>>>>>>
>> >>>>>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>> >>>>>>>> bisect, it was found that reverting the following two commits resolved
>> >>>>>>>> this bug:
>> >>>>>>>>
>> >>>>>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>> >>>>>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>> >>>>>>>>
>> >>>>>>>> This is a regression introduced in v4.13-rc1 and still exists in
>> >>>>>>>> mainline.  The bug causes the battery to drain when the system is
>> >>>>>>>> powered down and unplugged, which does not happed prior to these two
>> >>>>>>>> commits.
>> >>>>>>> What system and what do you mean by "powered down"?  How much time
>> >>>>>>> does it take for the battery to drain now?
>> >>>>>> By powered down, the bug reporter is saying physically powered off and
>> >>>>>> unplugged.  The system is a HP laptop:
>> >>>>>>
>> >>>>>> dmi.chassis.vendor: HP
>> >>>>>> dmi.product.family: 103C_5335KV HP Notebook
>> >>>>>> dmi.product.name: HP Notebook
>> >>>>>> vendor_id    : GenuineIntel
>> >>>>>> cpu family    : 6
>> >>>>>>
>> >>>>>>
>> >>>>>>>> The bisect actually pointed to commit de3ef1e, but reverting
>> >>>>>>>> these two commits fixes the issue.
>> >>>>>>>>
>> >>>>>>>> I was hoping to get your feedback, since you are the patch author.  Do
>> >>>>>>>> you think gathering any additional data will help diagnose this issue,
>> >>>>>>>> or would it be best to submit a revert request?
>> >>>>>>> First, reverting these is not an option or you will break systems
>> >>>>>>> relying on them now.  4.13 is three releases back at this point.
>> >>>>>>>
>> >>>>>>> Second, your issue appears to be related to the suspend/shutdown path
>> >>>>>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>> >>>>>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>> >>>>>>> to revert this one alone and see if that helps?
>> >>>>>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>> >>>>>> tested.  However, the test kernel still exhibited the bug.
>> >>>>> So essentially the bisection result cannot be trusted.
>> >>>> We performed some more testing and confirmed just a revert of the
>> >>>> following commit resolves the bug:
>> >>>>
>> >>>> 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
>> >>> Thanks for confirming this!
>> >>>
>> >>>> Can you think of any suggestions to help debug further?
>> >>> The root cause of the regression is likely the change in
>> >>> pci_enable_wake() removing the device_may_wakeup() check from it.
>> >>>
>> >>> Probably, one of the drivers in the platform calls pci_enable_wake()
>> >>> directly from its ->shutdown() callback and that causes the device to
>> >>> be set up for system wakeup which in turn causes the power draw while
>> >>> the system is off to increase.
>> >>>
>> >>> I would look at the PCI drivers used on that platform to find which of
>> >>> them call pci_enable_wake() directly from ->shutdown() and I would
>> >>> make these calls conditional on device_may_wakeup().
>> >> I took a quick look with
>> >>
>> >>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
>> >>
>> >> and didn't notice any pci_enable_wake() callers that called
>> >> device_may_wakeup() first.
>> > I've just look at a bunch of network drivers doing that.
>> >
>> > It looks like I may need to restore __pci_enable_wake() with an extra
>> > "runtime" argument for internal use.
>> >
>> > Joseph, can you ask the reporter to test the Bjorn's patch, please?
>>
>> The bug reporter has testing Bjorn's patch.  It did in fact resolve the
>> bug.  Thanks for the quick help, Rafael and Bjorn!
>
> Just as a word of caution, I think Rafael said my patch was not the
> right fix because it would break something else.  So I would wait for
> a better patch from Rafael before actually resolving this issue.

I'll do my best to provide one in the next couple of days.

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Thursday, May 3, 2018 11:29:18 PM CEST Rafael J. Wysocki wrote:
> On Thu, May 3, 2018 at 9:11 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Thu, May 03, 2018 at 02:29:02PM -0400, Joseph Salisbury wrote:
> >> On 05/02/2018 06:41 AM, Rafael J. Wysocki wrote:
> >> > On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >> >> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
> >> >>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
> >> >>> <joseph.salisbury@canonical.com> wrote:
> >> >>>> On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
> >> >>>>> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
> >> >>>>> <joseph.salisbury@canonical.com> wrote:
> >> >>>>>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
> >> >>>>>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
> >> >>>>>>> <joseph.salisbury@canonical.com> wrote:
> >> >>>>>>>> Hi Rafael,
> >> >>>>>>>>
> >> >>>>>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
> >> >>>>>>>> bisect, it was found that reverting the following two commits resolved
> >> >>>>>>>> this bug:
> >> >>>>>>>>
> >> >>>>>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
> >> >>>>>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
> >> >>>>>>>>
> >> >>>>>>>> This is a regression introduced in v4.13-rc1 and still exists in
> >> >>>>>>>> mainline.  The bug causes the battery to drain when the system is
> >> >>>>>>>> powered down and unplugged, which does not happed prior to these two
> >> >>>>>>>> commits.
> >> >>>>>>> What system and what do you mean by "powered down"?  How much time
> >> >>>>>>> does it take for the battery to drain now?
> >> >>>>>> By powered down, the bug reporter is saying physically powered off and
> >> >>>>>> unplugged.  The system is a HP laptop:
> >> >>>>>>
> >> >>>>>> dmi.chassis.vendor: HP
> >> >>>>>> dmi.product.family: 103C_5335KV HP Notebook
> >> >>>>>> dmi.product.name: HP Notebook
> >> >>>>>> vendor_id    : GenuineIntel
> >> >>>>>> cpu family    : 6
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>>> The bisect actually pointed to commit de3ef1e, but reverting
> >> >>>>>>>> these two commits fixes the issue.
> >> >>>>>>>>
> >> >>>>>>>> I was hoping to get your feedback, since you are the patch author.  Do
> >> >>>>>>>> you think gathering any additional data will help diagnose this issue,
> >> >>>>>>>> or would it be best to submit a revert request?
> >> >>>>>>> First, reverting these is not an option or you will break systems
> >> >>>>>>> relying on them now.  4.13 is three releases back at this point.
> >> >>>>>>>
> >> >>>>>>> Second, your issue appears to be related to the suspend/shutdown path
> >> >>>>>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
> >> >>>>>>> change in pci_enable_wake() causes the problem to happen.  Can you try
> >> >>>>>>> to revert this one alone and see if that helps?
> >> >>>>>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
> >> >>>>>> tested.  However, the test kernel still exhibited the bug.
> >> >>>>> So essentially the bisection result cannot be trusted.
> >> >>>> We performed some more testing and confirmed just a revert of the
> >> >>>> following commit resolves the bug:
> >> >>>>
> >> >>>> 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
> >> >>> Thanks for confirming this!
> >> >>>
> >> >>>> Can you think of any suggestions to help debug further?
> >> >>> The root cause of the regression is likely the change in
> >> >>> pci_enable_wake() removing the device_may_wakeup() check from it.
> >> >>>
> >> >>> Probably, one of the drivers in the platform calls pci_enable_wake()
> >> >>> directly from its ->shutdown() callback and that causes the device to
> >> >>> be set up for system wakeup which in turn causes the power draw while
> >> >>> the system is off to increase.
> >> >>>
> >> >>> I would look at the PCI drivers used on that platform to find which of
> >> >>> them call pci_enable_wake() directly from ->shutdown() and I would
> >> >>> make these calls conditional on device_may_wakeup().
> >> >> I took a quick look with
> >> >>
> >> >>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
> >> >>
> >> >> and didn't notice any pci_enable_wake() callers that called
> >> >> device_may_wakeup() first.
> >> > I've just look at a bunch of network drivers doing that.
> >> >
> >> > It looks like I may need to restore __pci_enable_wake() with an extra
> >> > "runtime" argument for internal use.
> >> >
> >> > Joseph, can you ask the reporter to test the Bjorn's patch, please?
> >>
> >> The bug reporter has testing Bjorn's patch.  It did in fact resolve the
> >> bug.  Thanks for the quick help, Rafael and Bjorn!
> >
> > Just as a word of caution, I think Rafael said my patch was not the
> > right fix because it would break something else.  So I would wait for
> > a better patch from Rafael before actually resolving this issue.
> 
> I'll do my best to provide one in the next couple of days.

Something like the appended one (compiled-only at this point).

Joseph, this should be functionally equivalent to the Bjorn's patch except
for the runtime PM part which is irrelevant for the issue in question, but
please ask the reported to test this one too.

If it is confirmed to work, I'll repost it with a proper changelog.

---
 drivers/pci/pci.c |   31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

Index: linux-pm/drivers/pci/pci.c
===================================================================
--- linux-pm.orig/drivers/pci/pci.c
+++ linux-pm/drivers/pci/pci.c
@@ -1910,7 +1910,7 @@ void pci_pme_active(struct pci_dev *dev,
 EXPORT_SYMBOL(pci_pme_active);
 
 /**
- * pci_enable_wake - enable PCI device as wakeup event source
+ * __pci_enable_wake - enable PCI device as wakeup event source
  * @dev: PCI device affected
  * @state: PCI state from which device will issue wakeup events
  * @enable: True to enable event generation; false to disable
@@ -1928,7 +1928,7 @@ EXPORT_SYMBOL(pci_pme_active);
  * Error code depending on the platform is returned if both the platform and
  * the native mechanism fail to enable the generation of wake-up events
  */
-int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
+static int __pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
 {
 	int ret = 0;
 
@@ -1969,6 +1969,23 @@ int pci_enable_wake(struct pci_dev *dev,
 
 	return ret;
 }
+
+/**
+ * pci_enable_wake - enable PCI device as wakeup event source
+ * @pci_dev: Target device
+ * @state: PCI state from which device will issue wakeup events
+ * @enable: Whether or not to enable event generation
+ *
+ * If @enable is set and device_may_wakeup() returns false for the device, it
+ * will not be enabled to generate wakeup events.
+ */
+int pci_enable_wake(struct pci_dev *pci_dev, pci_power_t state, bool enable)
+{
+	if (enable && !device_may_wakeup(&pci_dev->dev))
+		return -EINVAL;
+
+	return __pci_enable_wake(pci_dev, state, enable);
+}
 EXPORT_SYMBOL(pci_enable_wake);
 
 /**
@@ -1981,9 +1998,9 @@ EXPORT_SYMBOL(pci_enable_wake);
  * should not be called twice in a row to enable wake-up due to PCI PM vs ACPI
  * ordering constraints.
  *
- * This function only returns error code if the device is not capable of
- * generating PME# from both D3_hot and D3_cold, and the platform is unable to
- * enable wake-up power for it.
+ * This function only returns error code if the device is not allowed to wake
+ * up the system from sleep or it is not capable of generating PME# from both
+ * D3_hot and D3_cold and the platform is unable to enable wake-up power for it.
  */
 int pci_wake_from_d3(struct pci_dev *dev, bool enable)
 {
@@ -2114,12 +2131,12 @@ int pci_finish_runtime_suspend(struct pc
 
 	dev->runtime_d3cold = target_state == PCI_D3cold;
 
-	pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
+	__pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
 
 	error = pci_set_power_state(dev, target_state);
 
 	if (error) {
-		pci_enable_wake(dev, target_state, false);
+		__pci_enable_wake(dev, target_state, false);
 		dev->runtime_d3cold = false;
 	}
 

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Joseph Salisbury]

On 05/04/2018 07:14 AM, Rafael J. Wysocki wrote:
> On Thursday, May 3, 2018 11:29:18 PM CEST Rafael J. Wysocki wrote:
>> On Thu, May 3, 2018 at 9:11 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>> On Thu, May 03, 2018 at 02:29:02PM -0400, Joseph Salisbury wrote:
>>>> On 05/02/2018 06:41 AM, Rafael J. Wysocki wrote:
>>>>> On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>>>>>> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
>>>>>>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
>>>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>>>> On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
>>>>>>>>> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
>>>>>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>>>>>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
>>>>>>>>>>> <joseph.salisbury@canonical.com> wrote:
>>>>>>>>>>>> Hi Rafael,
>>>>>>>>>>>>
>>>>>>>>>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
>>>>>>>>>>>> bisect, it was found that reverting the following two commits resolved
>>>>>>>>>>>> this bug:
>>>>>>>>>>>>
>>>>>>>>>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
>>>>>>>>>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
>>>>>>>>>>>>
>>>>>>>>>>>> This is a regression introduced in v4.13-rc1 and still exists in
>>>>>>>>>>>> mainline.  The bug causes the battery to drain when the system is
>>>>>>>>>>>> powered down and unplugged, which does not happed prior to these two
>>>>>>>>>>>> commits.
>>>>>>>>>>> What system and what do you mean by "powered down"?  How much time
>>>>>>>>>>> does it take for the battery to drain now?
>>>>>>>>>> By powered down, the bug reporter is saying physically powered off and
>>>>>>>>>> unplugged.  The system is a HP laptop:
>>>>>>>>>>
>>>>>>>>>> dmi.chassis.vendor: HP
>>>>>>>>>> dmi.product.family: 103C_5335KV HP Notebook
>>>>>>>>>> dmi.product.name: HP Notebook
>>>>>>>>>> vendor_id    : GenuineIntel
>>>>>>>>>> cpu family    : 6
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>> The bisect actually pointed to commit de3ef1e, but reverting
>>>>>>>>>>>> these two commits fixes the issue.
>>>>>>>>>>>>
>>>>>>>>>>>> I was hoping to get your feedback, since you are the patch author.  Do
>>>>>>>>>>>> you think gathering any additional data will help diagnose this issue,
>>>>>>>>>>>> or would it be best to submit a revert request?
>>>>>>>>>>> First, reverting these is not an option or you will break systems
>>>>>>>>>>> relying on them now.  4.13 is three releases back at this point.
>>>>>>>>>>>
>>>>>>>>>>> Second, your issue appears to be related to the suspend/shutdown path
>>>>>>>>>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
>>>>>>>>>>> change in pci_enable_wake() causes the problem to happen.  Can you try
>>>>>>>>>>> to revert this one alone and see if that helps?
>>>>>>>>>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
>>>>>>>>>> tested.  However, the test kernel still exhibited the bug.
>>>>>>>>> So essentially the bisection result cannot be trusted.
>>>>>>>> We performed some more testing and confirmed just a revert of the
>>>>>>>> following commit resolves the bug:
>>>>>>>>
>>>>>>>> 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
>>>>>>> Thanks for confirming this!
>>>>>>>
>>>>>>>> Can you think of any suggestions to help debug further?
>>>>>>> The root cause of the regression is likely the change in
>>>>>>> pci_enable_wake() removing the device_may_wakeup() check from it.
>>>>>>>
>>>>>>> Probably, one of the drivers in the platform calls pci_enable_wake()
>>>>>>> directly from its ->shutdown() callback and that causes the device to
>>>>>>> be set up for system wakeup which in turn causes the power draw while
>>>>>>> the system is off to increase.
>>>>>>>
>>>>>>> I would look at the PCI drivers used on that platform to find which of
>>>>>>> them call pci_enable_wake() directly from ->shutdown() and I would
>>>>>>> make these calls conditional on device_may_wakeup().
>>>>>> I took a quick look with
>>>>>>
>>>>>>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
>>>>>>
>>>>>> and didn't notice any pci_enable_wake() callers that called
>>>>>> device_may_wakeup() first.
>>>>> I've just look at a bunch of network drivers doing that.
>>>>>
>>>>> It looks like I may need to restore __pci_enable_wake() with an extra
>>>>> "runtime" argument for internal use.
>>>>>
>>>>> Joseph, can you ask the reporter to test the Bjorn's patch, please?
>>>> The bug reporter has testing Bjorn's patch.  It did in fact resolve the
>>>> bug.  Thanks for the quick help, Rafael and Bjorn!
>>> Just as a word of caution, I think Rafael said my patch was not the
>>> right fix because it would break something else.  So I would wait for
>>> a better patch from Rafael before actually resolving this issue.
>> I'll do my best to provide one in the next couple of days.
> Something like the appended one (compiled-only at this point).
>
> Joseph, this should be functionally equivalent to the Bjorn's patch except
> for the runtime PM part which is irrelevant for the issue in question, but
> please ask the reported to test this one too.
>
> If it is confirmed to work, I'll repost it with a proper changelog.
The bug reporter confirms that your latest patch also resolves the bug. 
Thanks!

>
> ---
>  drivers/pci/pci.c |   31 ++++++++++++++++++++++++-------
>  1 file changed, 24 insertions(+), 7 deletions(-)
>
> Index: linux-pm/drivers/pci/pci.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci.c
> +++ linux-pm/drivers/pci/pci.c
> @@ -1910,7 +1910,7 @@ void pci_pme_active(struct pci_dev *dev,
>  EXPORT_SYMBOL(pci_pme_active);
>  
>  /**
> - * pci_enable_wake - enable PCI device as wakeup event source
> + * __pci_enable_wake - enable PCI device as wakeup event source
>   * @dev: PCI device affected
>   * @state: PCI state from which device will issue wakeup events
>   * @enable: True to enable event generation; false to disable
> @@ -1928,7 +1928,7 @@ EXPORT_SYMBOL(pci_pme_active);
>   * Error code depending on the platform is returned if both the platform and
>   * the native mechanism fail to enable the generation of wake-up events
>   */
> -int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
> +static int __pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
>  {
>  	int ret = 0;
>  
> @@ -1969,6 +1969,23 @@ int pci_enable_wake(struct pci_dev *dev,
>  
>  	return ret;
>  }
> +
> +/**
> + * pci_enable_wake - enable PCI device as wakeup event source
> + * @pci_dev: Target device
> + * @state: PCI state from which device will issue wakeup events
> + * @enable: Whether or not to enable event generation
> + *
> + * If @enable is set and device_may_wakeup() returns false for the device, it
> + * will not be enabled to generate wakeup events.
> + */
> +int pci_enable_wake(struct pci_dev *pci_dev, pci_power_t state, bool enable)
> +{
> +	if (enable && !device_may_wakeup(&pci_dev->dev))
> +		return -EINVAL;
> +
> +	return __pci_enable_wake(pci_dev, state, enable);
> +}
>  EXPORT_SYMBOL(pci_enable_wake);
>  
>  /**
> @@ -1981,9 +1998,9 @@ EXPORT_SYMBOL(pci_enable_wake);
>   * should not be called twice in a row to enable wake-up due to PCI PM vs ACPI
>   * ordering constraints.
>   *
> - * This function only returns error code if the device is not capable of
> - * generating PME# from both D3_hot and D3_cold, and the platform is unable to
> - * enable wake-up power for it.
> + * This function only returns error code if the device is not allowed to wake
> + * up the system from sleep or it is not capable of generating PME# from both
> + * D3_hot and D3_cold and the platform is unable to enable wake-up power for it.
>   */
>  int pci_wake_from_d3(struct pci_dev *dev, bool enable)
>  {
> @@ -2114,12 +2131,12 @@ int pci_finish_runtime_suspend(struct pc
>  
>  	dev->runtime_d3cold = target_state == PCI_D3cold;
>  
> -	pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
> +	__pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
>  
>  	error = pci_set_power_state(dev, target_state);
>  
>  	if (error) {
> -		pci_enable_wake(dev, target_state, false);
> +		__pci_enable_wake(dev, target_state, false);
>  		dev->runtime_d3cold = false;
>  	}
>  
>

Re: [Regression] PCI / PM: Simplify device wakeup settings code

[Rafael J. Wysocki]

On Monday, May 7, 2018 6:15:01 PM CEST Joseph Salisbury wrote:
> On 05/04/2018 07:14 AM, Rafael J. Wysocki wrote:
> > On Thursday, May 3, 2018 11:29:18 PM CEST Rafael J. Wysocki wrote:
> >> On Thu, May 3, 2018 at 9:11 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >>> On Thu, May 03, 2018 at 02:29:02PM -0400, Joseph Salisbury wrote:
> >>>> On 05/02/2018 06:41 AM, Rafael J. Wysocki wrote:
> >>>>> On Tue, May 1, 2018 at 9:55 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> >>>>>> On Tue, May 01, 2018 at 10:34:29AM +0200, Rafael J. Wysocki wrote:
> >>>>>>> On Mon, Apr 30, 2018 at 4:22 PM, Joseph Salisbury
> >>>>>>> <joseph.salisbury@canonical.com> wrote:
> >>>>>>>> On 04/16/2018 11:58 AM, Rafael J. Wysocki wrote:
> >>>>>>>>> On Mon, Apr 16, 2018 at 5:31 PM, Joseph Salisbury
> >>>>>>>>> <joseph.salisbury@canonical.com> wrote:
> >>>>>>>>>> On 04/13/2018 05:34 PM, Rafael J. Wysocki wrote:
> >>>>>>>>>>> On Fri, Apr 13, 2018 at 7:56 PM, Joseph Salisbury
> >>>>>>>>>>> <joseph.salisbury@canonical.com> wrote:
> >>>>>>>>>>>> Hi Rafael,
> >>>>>>>>>>>>
> >>>>>>>>>>>> A kernel bug report was opened against Ubuntu [0].  After a kernel
> >>>>>>>>>>>> bisect, it was found that reverting the following two commits resolved
> >>>>>>>>>>>> this bug:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 0ce3fcaff929 ("PCI / PM: Restore PME Enable after config space restoration")
> >>>>>>>>>>>> 0847684cfc5f("PCI / PM: Simplify device wakeup settings code")
> >>>>>>>>>>>>
> >>>>>>>>>>>> This is a regression introduced in v4.13-rc1 and still exists in
> >>>>>>>>>>>> mainline.  The bug causes the battery to drain when the system is
> >>>>>>>>>>>> powered down and unplugged, which does not happed prior to these two
> >>>>>>>>>>>> commits.
> >>>>>>>>>>> What system and what do you mean by "powered down"?  How much time
> >>>>>>>>>>> does it take for the battery to drain now?
> >>>>>>>>>> By powered down, the bug reporter is saying physically powered off and
> >>>>>>>>>> unplugged.  The system is a HP laptop:
> >>>>>>>>>>
> >>>>>>>>>> dmi.chassis.vendor: HP
> >>>>>>>>>> dmi.product.family: 103C_5335KV HP Notebook
> >>>>>>>>>> dmi.product.name: HP Notebook
> >>>>>>>>>> vendor_id    : GenuineIntel
> >>>>>>>>>> cpu family    : 6
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>> The bisect actually pointed to commit de3ef1e, but reverting
> >>>>>>>>>>>> these two commits fixes the issue.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I was hoping to get your feedback, since you are the patch author.  Do
> >>>>>>>>>>>> you think gathering any additional data will help diagnose this issue,
> >>>>>>>>>>>> or would it be best to submit a revert request?
> >>>>>>>>>>> First, reverting these is not an option or you will break systems
> >>>>>>>>>>> relying on them now.  4.13 is three releases back at this point.
> >>>>>>>>>>>
> >>>>>>>>>>> Second, your issue appears to be related to the suspend/shutdown path
> >>>>>>>>>>> whereas commit 0ce3fcaff929 is mostly about resume, so presumably the
> >>>>>>>>>>> change in pci_enable_wake() causes the problem to happen.  Can you try
> >>>>>>>>>>> to revert this one alone and see if that helps?
> >>>>>>>>>> A test kernel with commits 0ce3fcaff929 and de3ef1eb1cd0 reverted was
> >>>>>>>>>> tested.  However, the test kernel still exhibited the bug.
> >>>>>>>>> So essentially the bisection result cannot be trusted.
> >>>>>>>> We performed some more testing and confirmed just a revert of the
> >>>>>>>> following commit resolves the bug:
> >>>>>>>>
> >>>>>>>> 0847684cfc5f0 ("PCI / PM: Simplify device wakeup settings code")
> >>>>>>> Thanks for confirming this!
> >>>>>>>
> >>>>>>>> Can you think of any suggestions to help debug further?
> >>>>>>> The root cause of the regression is likely the change in
> >>>>>>> pci_enable_wake() removing the device_may_wakeup() check from it.
> >>>>>>>
> >>>>>>> Probably, one of the drivers in the platform calls pci_enable_wake()
> >>>>>>> directly from its ->shutdown() callback and that causes the device to
> >>>>>>> be set up for system wakeup which in turn causes the power draw while
> >>>>>>> the system is off to increase.
> >>>>>>>
> >>>>>>> I would look at the PCI drivers used on that platform to find which of
> >>>>>>> them call pci_enable_wake() directly from ->shutdown() and I would
> >>>>>>> make these calls conditional on device_may_wakeup().
> >>>>>> I took a quick look with
> >>>>>>
> >>>>>>   git grep -E "pci_enable_wake\(.*[^0]\);|device_may_wakeup"
> >>>>>>
> >>>>>> and didn't notice any pci_enable_wake() callers that called
> >>>>>> device_may_wakeup() first.
> >>>>> I've just look at a bunch of network drivers doing that.
> >>>>>
> >>>>> It looks like I may need to restore __pci_enable_wake() with an extra
> >>>>> "runtime" argument for internal use.
> >>>>>
> >>>>> Joseph, can you ask the reporter to test the Bjorn's patch, please?
> >>>> The bug reporter has testing Bjorn's patch.  It did in fact resolve the
> >>>> bug.  Thanks for the quick help, Rafael and Bjorn!
> >>> Just as a word of caution, I think Rafael said my patch was not the
> >>> right fix because it would break something else.  So I would wait for
> >>> a better patch from Rafael before actually resolving this issue.
> >> I'll do my best to provide one in the next couple of days.
> > Something like the appended one (compiled-only at this point).
> >
> > Joseph, this should be functionally equivalent to the Bjorn's patch except
> > for the runtime PM part which is irrelevant for the issue in question, but
> > please ask the reported to test this one too.
> >
> > If it is confirmed to work, I'll repost it with a proper changelog.
> The bug reporter confirms that your latest patch also resolves the bug. 
> Thanks!

Thanks for the confirmation.

[PATCH] PCI / PM: Check device_may_wakeup() in pci_enable_wake()

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
went too far and dropped the device_may_wakeup() check from
pci_enable_wake() which causes wakeup to be enabled during system
suspend, hibernation or shutdown for some PCI devices that are not
allowed by user space to wake up the system from sleep (or power off).

As a result of this excessive power is drawn by some of the affected
systems while in sleep states or off.

Restore the device_may_wakeup() check in pci_enable_wake(), but make
sure that the PCI bus type's runtime suspend callback will not call
device_may_wakeup() which is about system wakeup from sleep and not
about device wakeup from runtime suspend.

Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/pci/pci.c |   29 +++++++++++++++++++++++------
 1 file changed, 23 insertions(+), 6 deletions(-)

Index: linux-pm/drivers/pci/pci.c
===================================================================
--- linux-pm.orig/drivers/pci/pci.c
+++ linux-pm/drivers/pci/pci.c
@@ -1910,7 +1910,7 @@ void pci_pme_active(struct pci_dev *dev,
 EXPORT_SYMBOL(pci_pme_active);
 
 /**
- * pci_enable_wake - enable PCI device as wakeup event source
+ * __pci_enable_wake - enable PCI device as wakeup event source
  * @dev: PCI device affected
  * @state: PCI state from which device will issue wakeup events
  * @enable: True to enable event generation; false to disable
@@ -1928,7 +1928,7 @@ EXPORT_SYMBOL(pci_pme_active);
  * Error code depending on the platform is returned if both the platform and
  * the native mechanism fail to enable the generation of wake-up events
  */
-int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
+static int __pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
 {
 	int ret = 0;
 
@@ -1969,6 +1969,23 @@ int pci_enable_wake(struct pci_dev *dev,
 
 	return ret;
 }
+
+/**
+ * pci_enable_wake - change wakeup settings for a PCI device
+ * @pci_dev: Target device
+ * @state: PCI state from which device will issue wakeup events
+ * @enable: Whether or not to enable event generation
+ *
+ * If @enable is set, check device_may_wakeup() for the device before calling
+ * __pci_enable_wake() for it.
+ */
+int pci_enable_wake(struct pci_dev *pci_dev, pci_power_t state, bool enable)
+{
+	if (enable && !device_may_wakeup(&pci_dev->dev))
+		return -EINVAL;
+
+	return __pci_enable_wake(pci_dev, state, enable);
+}
 EXPORT_SYMBOL(pci_enable_wake);
 
 /**
@@ -1981,9 +1998,9 @@ EXPORT_SYMBOL(pci_enable_wake);
  * should not be called twice in a row to enable wake-up due to PCI PM vs ACPI
  * ordering constraints.
  *
- * This function only returns error code if the device is not capable of
- * generating PME# from both D3_hot and D3_cold, and the platform is unable to
- * enable wake-up power for it.
+ * This function only returns error code if the device is not allowed to wake
+ * up the system from sleep or it is not capable of generating PME# from both
+ * D3_hot and D3_cold and the platform is unable to enable wake-up power for it.
  */
 int pci_wake_from_d3(struct pci_dev *dev, bool enable)
 {
@@ -2114,7 +2131,7 @@ int pci_finish_runtime_suspend(struct pc
 
 	dev->runtime_d3cold = target_state == PCI_D3cold;
 
-	pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
+	__pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
 
 	error = pci_set_power_state(dev, target_state);
 

Re: [PATCH] PCI / PM: Check device_may_wakeup() in pci_enable_wake()

[Rafael J. Wysocki]

On Wed, May 9, 2018 at 12:18 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
> went too far and dropped the device_may_wakeup() check from
> pci_enable_wake() which causes wakeup to be enabled during system
> suspend, hibernation or shutdown for some PCI devices that are not
> allowed by user space to wake up the system from sleep (or power off).
>
> As a result of this excessive power is drawn by some of the affected
> systems while in sleep states or off.
>
> Restore the device_may_wakeup() check in pci_enable_wake(), but make
> sure that the PCI bus type's runtime suspend callback will not call
> device_may_wakeup() which is about system wakeup from sleep and not
> about device wakeup from runtime suspend.
>
> Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
> Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Bjorn, any concerns here?

> ---
>  drivers/pci/pci.c |   29 +++++++++++++++++++++++------
>  1 file changed, 23 insertions(+), 6 deletions(-)
>
> Index: linux-pm/drivers/pci/pci.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci.c
> +++ linux-pm/drivers/pci/pci.c
> @@ -1910,7 +1910,7 @@ void pci_pme_active(struct pci_dev *dev,
>  EXPORT_SYMBOL(pci_pme_active);
>
>  /**
> - * pci_enable_wake - enable PCI device as wakeup event source
> + * __pci_enable_wake - enable PCI device as wakeup event source
>   * @dev: PCI device affected
>   * @state: PCI state from which device will issue wakeup events
>   * @enable: True to enable event generation; false to disable
> @@ -1928,7 +1928,7 @@ EXPORT_SYMBOL(pci_pme_active);
>   * Error code depending on the platform is returned if both the platform and
>   * the native mechanism fail to enable the generation of wake-up events
>   */
> -int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
> +static int __pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
>  {
>         int ret = 0;
>
> @@ -1969,6 +1969,23 @@ int pci_enable_wake(struct pci_dev *dev,
>
>         return ret;
>  }
> +
> +/**
> + * pci_enable_wake - change wakeup settings for a PCI device
> + * @pci_dev: Target device
> + * @state: PCI state from which device will issue wakeup events
> + * @enable: Whether or not to enable event generation
> + *
> + * If @enable is set, check device_may_wakeup() for the device before calling
> + * __pci_enable_wake() for it.
> + */
> +int pci_enable_wake(struct pci_dev *pci_dev, pci_power_t state, bool enable)
> +{
> +       if (enable && !device_may_wakeup(&pci_dev->dev))
> +               return -EINVAL;
> +
> +       return __pci_enable_wake(pci_dev, state, enable);
> +}
>  EXPORT_SYMBOL(pci_enable_wake);
>
>  /**
> @@ -1981,9 +1998,9 @@ EXPORT_SYMBOL(pci_enable_wake);
>   * should not be called twice in a row to enable wake-up due to PCI PM vs ACPI
>   * ordering constraints.
>   *
> - * This function only returns error code if the device is not capable of
> - * generating PME# from both D3_hot and D3_cold, and the platform is unable to
> - * enable wake-up power for it.
> + * This function only returns error code if the device is not allowed to wake
> + * up the system from sleep or it is not capable of generating PME# from both
> + * D3_hot and D3_cold and the platform is unable to enable wake-up power for it.
>   */
>  int pci_wake_from_d3(struct pci_dev *dev, bool enable)
>  {
> @@ -2114,7 +2131,7 @@ int pci_finish_runtime_suspend(struct pc
>
>         dev->runtime_d3cold = target_state == PCI_D3cold;
>
> -       pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
> +       __pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
>
>         error = pci_set_power_state(dev, target_state);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] PCI / PM: Check device_may_wakeup() in pci_enable_wake()

[Bjorn Helgaas]

On Wed, May 09, 2018 at 12:18:32AM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
> went too far and dropped the device_may_wakeup() check from
> pci_enable_wake() which causes wakeup to be enabled during system
> suspend, hibernation or shutdown for some PCI devices that are not
> allowed by user space to wake up the system from sleep (or power off).
> 
> As a result of this excessive power is drawn by some of the affected
> systems while in sleep states or off.
> 
> Restore the device_may_wakeup() check in pci_enable_wake(), but make
> sure that the PCI bus type's runtime suspend callback will not call
> device_may_wakeup() which is about system wakeup from sleep and not
> about device wakeup from runtime suspend.
> 
> Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
> Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

0847684cfc5f0 appeared in v4.13, which raises the question of whether
this problem is important enough for a stable backport.  Up to you :)

> ---
>  drivers/pci/pci.c |   29 +++++++++++++++++++++++------
>  1 file changed, 23 insertions(+), 6 deletions(-)
> 
> Index: linux-pm/drivers/pci/pci.c
> ===================================================================
> --- linux-pm.orig/drivers/pci/pci.c
> +++ linux-pm/drivers/pci/pci.c
> @@ -1910,7 +1910,7 @@ void pci_pme_active(struct pci_dev *dev,
>  EXPORT_SYMBOL(pci_pme_active);
>  
>  /**
> - * pci_enable_wake - enable PCI device as wakeup event source
> + * __pci_enable_wake - enable PCI device as wakeup event source
>   * @dev: PCI device affected
>   * @state: PCI state from which device will issue wakeup events
>   * @enable: True to enable event generation; false to disable
> @@ -1928,7 +1928,7 @@ EXPORT_SYMBOL(pci_pme_active);
>   * Error code depending on the platform is returned if both the platform and
>   * the native mechanism fail to enable the generation of wake-up events
>   */
> -int pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
> +static int __pci_enable_wake(struct pci_dev *dev, pci_power_t state, bool enable)
>  {
>  	int ret = 0;
>  
> @@ -1969,6 +1969,23 @@ int pci_enable_wake(struct pci_dev *dev,
>  
>  	return ret;
>  }
> +
> +/**
> + * pci_enable_wake - change wakeup settings for a PCI device
> + * @pci_dev: Target device
> + * @state: PCI state from which device will issue wakeup events
> + * @enable: Whether or not to enable event generation
> + *
> + * If @enable is set, check device_may_wakeup() for the device before calling
> + * __pci_enable_wake() for it.
> + */
> +int pci_enable_wake(struct pci_dev *pci_dev, pci_power_t state, bool enable)
> +{
> +	if (enable && !device_may_wakeup(&pci_dev->dev))
> +		return -EINVAL;
> +
> +	return __pci_enable_wake(pci_dev, state, enable);
> +}
>  EXPORT_SYMBOL(pci_enable_wake);
>  
>  /**
> @@ -1981,9 +1998,9 @@ EXPORT_SYMBOL(pci_enable_wake);
>   * should not be called twice in a row to enable wake-up due to PCI PM vs ACPI
>   * ordering constraints.
>   *
> - * This function only returns error code if the device is not capable of
> - * generating PME# from both D3_hot and D3_cold, and the platform is unable to
> - * enable wake-up power for it.
> + * This function only returns error code if the device is not allowed to wake
> + * up the system from sleep or it is not capable of generating PME# from both
> + * D3_hot and D3_cold and the platform is unable to enable wake-up power for it.
>   */
>  int pci_wake_from_d3(struct pci_dev *dev, bool enable)
>  {
> @@ -2114,7 +2131,7 @@ int pci_finish_runtime_suspend(struct pc
>  
>  	dev->runtime_d3cold = target_state == PCI_D3cold;
>  
> -	pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
> +	__pci_enable_wake(dev, target_state, pci_dev_run_wake(dev));
>  
>  	error = pci_set_power_state(dev, target_state);
>  
> 

Re: [PATCH] PCI / PM: Check device_may_wakeup() in pci_enable_wake()

[Rafael J. Wysocki]

On Thu, May 10, 2018 at 3:03 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, May 09, 2018 at 12:18:32AM +0200, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
>> went too far and dropped the device_may_wakeup() check from
>> pci_enable_wake() which causes wakeup to be enabled during system
>> suspend, hibernation or shutdown for some PCI devices that are not
>> allowed by user space to wake up the system from sleep (or power off).
>>
>> As a result of this excessive power is drawn by some of the affected
>> systems while in sleep states or off.
>>
>> Restore the device_may_wakeup() check in pci_enable_wake(), but make
>> sure that the PCI bus type's runtime suspend callback will not call
>> device_may_wakeup() which is about system wakeup from sleep and not
>> about device wakeup from runtime suspend.
>>
>> Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
>> Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
>
> 0847684cfc5f0 appeared in v4.13, which raises the question of whether
> this problem is important enough for a stable backport.  Up to you :)

Yes, it is IMO, thank you!