[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJZ5v0iu23LqdKUJA5OQGF3Yqq3=k+nfNUVn-LFpYgkDrgokCg@mail.gmail.com>
Date: Tue, 5 Jun 2018 11:14:07 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Ravi Chandra Sadineni <ravisadineni@...omium.org>,
"Rafael J. Wysocki" <rafael@...nel.org>, chenhong3@...wei.com,
Ravi Chandra Sadineni <ravisadineni@...gle.com>,
Dmitry Torokhov <dtor@...gle.com>,
Todd Broch <tbroch@...gle.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-input@...r.kernel.org, Rajat Jain <rajatja@...gle.com>,
Benson Leung <bleung@...gle.com>
Subject: Re: [PATCH V2] i8042: Increment wakeup_count for the respective port.
On Mon, Jun 4, 2018 at 11:53 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
> On Fri, Jun 01, 2018 at 06:07:08PM -0700, Ravi Chandra Sadineni wrote:
>> Call pm_wakeup_event on every irq. This should help us in identifying if
>> keyboard was a potential wake reason for the last resume.
>>
>> Signed-off-by: Ravi Chandra Sadineni <ravisadineni@...omium.org>
>> ---
>> V2: Increment the wakeup count only when there is a irq and not when the
>> method is called internally.
>>
>> drivers/input/serio/i8042.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
>> index 824f4c1c1f310..2bd6f2633e29a 100644
>> --- a/drivers/input/serio/i8042.c
>> +++ b/drivers/input/serio/i8042.c
>> @@ -573,6 +573,9 @@ static irqreturn_t i8042_interrupt(int irq, void *dev_id)
>> port = &i8042_ports[port_no];
>> serio = port->exists ? port->serio : NULL;
>>
>> + if (irq && serio && device_may_wakeup(&serio->dev))
>> + pm_wakeup_event(&serio->dev, 0);
>
> The constant checks for device_may_wakeup() before calling
> pm_wakeup_event()needed to avoid warnings in wakeup_source_activate()
> (?) are annoying.
I'm not following you here.
pm_wakeup_event() ->
pm_wakeup_dev_event() ->
pm_wakeup_ws_event(dev->power.wakeup, ...)
Checks if the first arg is NULL and returns quietly if so.
I don't see why you need the device_may_wakeup() check.
> Rafael, can we move the check into pm_wakeup_dev_event()?
That would be redundant, wouldn't it?
> I am also confused when pm_wakeup_event() vs pm_wakeup_hard_event() vs
> pm_wakeup_dev_event() should be used, if any. Is there any guidance?
First off, the "hard" variant is for when you want to abort suspends
in progress or wake up from suspend to idle regardless of whether or
not wakeup source tracking is enabled.
Second, use pm_wakeup_dev_event() if the decision on "hard" vs "soft"
needs to be made at run time.
Thanks,
Rafael
Powered by blists - more mailing lists