linux-kernel - Re: [RFC PATCH] Input: gpio_keys: Fix suspend/resume press event lost

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: <5106A39A.5010402@ti.com>
Date:	Mon, 28 Jan 2013 18:13:14 +0200
From:	"ivan.khoronzhuk" <ivan.khoronzhuk@...com>
To:	NeilBrown <neilb@...e.de>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	<linux-kernel@...r.kernel.org>, <linux-input@...r.kernel.org>,
	Bengt Jonsson <bengt.g.jonsson@...ricsson.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Bill Pemberton <wfp5p@...ginia.edu>
Subject: Re: [RFC PATCH] Input: gpio_keys: Fix suspend/resume press event
 lost

On 01/22/2013 07:24 AM, NeilBrown wrote:
> On Mon, 21 Jan 2013 15:57:18 -0800 Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
>
>> Hi Ivan,
>>
>> On Mon, Jan 21, 2013 at 03:15:14PM +0200, Ivan Khoronzhuk wrote:
>>> Rebased on linux_omap/master.
>>>
>>> During suspend/resume the key press can be lost if time of resume
>>> sequence is significant.
>>>
>>> If press event cannot be remembered then the driver can read the
>>> current button state only in time of interrupt handling. But in some
>>> cases when time between IRQ and IRQ handler is significant we can
>>> read incorrect state. As a particular case, when device is in suspend
>>> we press wakupable key and up it back in a jiffy, the interrupt
>>> handler read the state of up but the interrupt source is press indeed.
>>> As a result, in a OS like android, we resume then suspend right away
>>> because the key state is not changed.
>>>
>>> This patch add to gpio_keys framework opportunity to recover lost of
>>> press key event at resuming. The variable "key_pressed" from
>>> gpio_button_data structure is not used for gpio keys, it is only used
>>> for gpio irq keys, so it is logically used to remember press lost
>>> while resuming.
>> The same could happen if you delay processing of interrupt long enough
>> during normal operation. If key is released by the time you get around
>> to reading it you will not see a key press.
>>
>> To me this sounds like you need to speed up your resume process so that
>> you can start serving interrupts quicker.
>>
> Agreed.  When I was looking at this I found that any genuine button press
> would have at least 70msec between press and release, while the device could
> wake up to the point of being able to handle interrupts in about 14msec.
> That is enough of a gap to make it pointless to try to 'fix' the code.
>
> With enough verbose debugging enabled that 14msec can easily grow to
> hundreds, but then if  you have debugging enabled to can discipline yourself
> to hold the button for longer.
>
> Ivan: What sort of delay are you seeing between the button press and the
> interrupt routine running?  And can you measure how long the button is
> typically down for?
>
> NeilBrown

In my case I have the delay between the button press and the ISR
about 145ms. If the button down for 120ms the IRQ press event is
lost and if 160ms event is captured. I cannot speed up resume
process enough to guarantee correct work, so I wrote this fix.

-- 
Regards,
Ivan Khoronzhuk

--
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/