linux-kernel - Re: [PATCH] Input: Add ioctl to block suspend while event queue is not empty.

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]

Message-ID: <CAMP5XgfrG=3qeFasg4prBu88-Ox59_PtFw-rpgb=PN=uo6VPuw@mail.gmail.com>
Date:	Mon, 13 Feb 2012 15:52:14 -0800
From:	Arve Hjønnevåg <arve@...roid.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	linux-input@...r.kernel.org, linux-pm@...r.kernel.org,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Matthew Garrett <mjg@...hat.com>,
	Chase Douglas <chase.douglas@...onical.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Input: Add ioctl to block suspend while event queue is
 not empty.

2012/2/11 Rafael J. Wysocki <rjw@...k.pl>:
> Hi,
>
> On Saturday, January 21, 2012, Arve Hjønnevåg wrote:
>> Add an ioctl, EVIOCSSUSPENDBLOCK, to block suspend while the event
>> queue is not empty. This allows userspace code to process input
>> events while the device appears to be asleep.
>
> I have two questions to start with, if you don't mind:
>
> (1) Does Android user space use an analogous interface right now or is it
>    a prototype?
>

Yes (for the next version), but with a wakelock based implementation.

> (2) What exactly are the use cases for it (ie. what problem does it address
>    that cannot be addressed in a different way)?
>

The reason for adding an ioctl versus the old android version with
used a wakelock for all input events, is that not all input events are
wakeup events. Specifically some sensors generate input events at such
a high rate that they prevent suspend while the sensor is on even
though the driver has a suspend hook that turns the sensor off.

If you are asking why input events need to block suspend at all, this
was the example used in the suspend blocker documentation:
- The Keypad driver gets an interrupt. It then calls suspend_block on the
  keypad-scan suspend_blocker and starts scanning the keypad matrix.
- The keypad-scan code detects a key change and reports it to the input-event
  driver.
- The input-event driver sees the key change, enqueues an event, and calls
  suspend_block on the input-event-queue suspend_blocker.
- The keypad-scan code detects that no keys are held and calls suspend_unblock
  on the keypad-scan suspend_blocker.
- The user-space input-event thread returns from select/poll, calls
  suspend_block on the process-input-events suspend_blocker and then calls read
  on the input-event device.
- The input-event driver dequeues the key-event and, since the queue is now
  empty, it calls suspend_unblock on the input-event-queue suspend_blocker.
- The user-space input-event thread returns from read. If it determines that
  the key should be ignored, it calls suspend_unblock on the
  process_input_events suspend_blocker and then calls select or poll. The
  system will automatically suspend again, since now no suspend blockers are
  active.


-- 
Arve Hjønnevåg
--
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/