linux-kernel - Re: [PATCH 5/6] Input: evdev - Enable runtime PM of the evdev input handler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 3 Apr 2015 15:03:43 +0200
From:	Tomeu Vizoso <tomeu.vizoso@...labora.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	linux-input@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/6] Input: evdev - Enable runtime PM of the evdev input handler

On 31 March 2015 at 22:31, Dmitry Torokhov <dmitry.torokhov@...il.com> wrote:
> On Tue, Mar 31, 2015 at 06:14:49PM +0200, Tomeu Vizoso wrote:
>> So ancestor devices can remain runtime-suspended when the system goes
>> into a sleep state, they and all of their descendant devices need to
>> have runtime PM enabled.
>
> I am confused. Input devices are not runtime-PM-enabled, so what
> enabling this on evdev handler buys us?

The UVC driver would be enabling runtime PM for the input device that
it registers.

> And what about joydev and
> mousedev? Other handlers that might be attached?

Not sure, tbh. What I have ended up doing in v2 is descending the tree
from the UVC device and enabling runtime PM for all descendants. The
idea is that the UVC driver knows whether it should remain runtime
suspended and that its descendants should copy it.

> The stubbing of prepare also feels wrong: we do want to suspend/resume
> input devices since we want to shut off and restore their leds even if
> device (keyboard) happens to be sleeping.

Fair enough, I have introduced a flag that allows the creator of the
input device to decide that.

Thanks,

Tomeu

> Thanks.
>
>>
>> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
>> ---
>>  drivers/input/evdev.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
>> index a18f41b..3d60c20 100644
>> --- a/drivers/input/evdev.c
>> +++ b/drivers/input/evdev.c
>> @@ -26,6 +26,7 @@
>>  #include <linux/major.h>
>>  #include <linux/device.h>
>>  #include <linux/cdev.h>
>> +#include <linux/pm_runtime.h>
>>  #include "input-compat.h"
>>
>>  enum evdev_clock_type {
>> @@ -1201,6 +1202,8 @@ static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
>>       if (error)
>>               goto err_cleanup_evdev;
>>
>> +     pm_runtime_enable(&evdev->dev);
>> +
>>       return 0;
>>
>>   err_cleanup_evdev:
>> --
>> 2.3.4
>>
>
> --
> Dmitry
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/