All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Rob Herring" <robh@kernel.org>,
	"Grant Likely" <grant.likely@linaro.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Thierry Reding" <treding@nvidia.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	lkml <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH] driver-core: platform: automatically mark wakeup devices
Date: Mon, 18 Jan 2016 08:22:08 -0800	[thread overview]
Message-ID: <CAKdAkRR9S2i+JynF5uib=MaOAcxB__pSVzQO3ijCKbLG2EiMvw@mail.gmail.com> (raw)
In-Reply-To: <2182115.GafOXid1Dx@vostro.rjw.lan>

On Mon, Jan 18, 2016 at 6:47 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Sunday, January 17, 2016 06:11:38 PM Dmitry Torokhov wrote:
>> When probing platform drivers let's check if corresponding devices have
>> "wakeup-source" property defined (either in device tree, ACPI, or static
>> platform properties) and automatically enable such devices as wakeup
>> sources for the system. This will help us standardize on the name for this
>> property and reduce amount of boilerplate code in the drivers.
>
> ACPI has other ways of telling the OS that the device is wakeup-capable,
> but I guess the property in question can be used too (as long as it is
> consistent with the other methods).

I was thinking that down the road ACPI can wire its internal wakeup
knowledge into generic device property. Unfortunately at the moment
most drivers go like this:

- if it is device tree platform: good, we'll take the data from device
tree property and set up driver behavior accordingly;
- if it is legacy board setup: OK, take for driver-specific platform data;
- ACPI... hmm... dunno... enable wakeup and if it is not correct the
system will just not wake up, not the best but not terribly wrong
either.

>
>> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> ---
>>  drivers/base/platform.c | 9 ++++++++-
>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> index 1dd6d3b..d14071a 100644
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -514,9 +514,14 @@ static int platform_drv_probe(struct device *_dev)
>>
>>       ret = dev_pm_domain_attach(_dev, true);
>>       if (ret != -EPROBE_DEFER && drv->probe) {
>> +             bool wakeup = device_property_read_bool(_dev, "wakeup-source");
>> +
>> +             device_init_wakeup(_dev, wakeup);
>
> But I'm wondering if this should be device_set_wakeup_capable(dev, true) rather?
>
> device_init_wakeup() additionally sets the default in sysfs to "do wakeup"
> which in principle may unblock spurious wakeups on some systems.

Why would we not want enable wakeup for devices where system
(platform) tells us that they are wakeup sources? This is how most of
the drivers I am involved in behave. All of them use
device_init_wakeup() and then we adjust the behavior depending on
runtime state, i.e. do not wake up from touchpad when lid is closed
(which is useful if lid is flexible and may interact with touchpad if
slammed down hard enough).

>
>>               ret = drv->probe(dev);
>> -             if (ret)
>> +             if (ret) {
>> +                     device_init_wakeup(_dev, false);
>>                       dev_pm_domain_detach(_dev, true);
>> +             }
>>       }
>>
>>       if (drv->prevent_deferred_probe && ret == -EPROBE_DEFER) {
>> @@ -540,6 +545,8 @@ static int platform_drv_remove(struct device *_dev)
>>
>>       if (drv->remove)
>>               ret = drv->remove(dev);
>> +
>> +     device_init_wakeup(_dev, false);
>>       dev_pm_domain_detach(_dev, true);
>>
>>       return ret;
>>
>

Thanks.

-- 
Dmitry

  parent reply	other threads:[~2016-01-18 16:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-18  2:11 [PATCH] driver-core: platform: automatically mark wakeup devices Dmitry Torokhov
2016-01-18  5:11 ` Greg Kroah-Hartman
2016-01-18  6:14   ` Dmitry Torokhov
2016-01-18 15:35     ` Sudeep Holla
2016-01-18 14:47 ` Rafael J. Wysocki
2016-01-18 15:23   ` Sudeep Holla
2016-01-18 15:41     ` Rafael J. Wysocki
2016-01-18 15:58       ` Sudeep Holla
2016-01-18 17:09         ` Rafael J. Wysocki
2016-01-18 16:22   ` Dmitry Torokhov [this message]
2016-01-18 17:19     ` Rafael J. Wysocki
2016-01-18 17:55       ` Dmitry Torokhov
2016-01-18 22:18         ` Rafael J. Wysocki
2016-01-20  0:45           ` Dmitry Torokhov
2016-01-20  2:40             ` Rafael J. Wysocki
2016-01-20 13:51               ` Rafael J. Wysocki
2016-01-20 23:01                 ` Rafael J. Wysocki
2016-01-21  0:23                   ` Dmitry Torokhov
2016-01-26 16:47                     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKdAkRR9S2i+JynF5uib=MaOAcxB__pSVzQO3ijCKbLG2EiMvw@mail.gmail.com' \
    --to=dmitry.torokhov@gmail.com \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=robh@kernel.org \
    --cc=treding@nvidia.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.