linux-kernel - Re: [PATCH 3/3] Input: omap4-keypad - check state again for lost key-up interrupts

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: <20200306191021.GH217608@dtor-ws>
Date:   Fri, 6 Mar 2020 11:10:21 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Tony Lindgren <tony@...mide.com>
Cc:     linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-omap@...r.kernel.org,
        Arthur Demchenkov <spinal.by@...il.com>,
        Merlijn Wajer <merlijn@...zup.org>,
        Pavel Machek <pavel@....cz>,
        Sebastian Reichel <sre@...nel.org>, ruleh <ruleh@....de>
Subject: Re: [PATCH 3/3] Input: omap4-keypad - check state again for lost
 key-up interrupts

On Fri, Feb 28, 2020 at 09:12:23AM -0800, Tony Lindgren wrote:
> We only have partial errata i689 implemented with Commit 6c3516fed7b6
> ("Input: omap-keypad - fix keyboard debounce configuration"). We are
> still missing the check for lost key-up interrupts as described in the
> omap4 silicon errata documentation as Errata ID i689 "1.32 Keyboard Key
> Up Event Can Be Missed":
> 
> "When a key is released for a time shorter than the debounce time,
>  in-between 2 key press (KP1 and KP2), the keyboard state machine will go
>  to idle mode and will never detect the key release (after KP1, and also
>  after KP2), and thus will never generate a new IRQ indicating the key
>  release."
> 
> Let's check the keyboard state with delayed_work after each event. And
> if the problem state is detect, let's clear all events.
> 
> Cc: Arthur Demchenkov <spinal.by@...il.com>
> Cc: Merlijn Wajer <merlijn@...zup.org>
> Cc: Pavel Machek <pavel@....cz>
> Cc: Sebastian Reichel <sre@...nel.org>
> Signed-off-by: Tony Lindgren <tony@...mide.com>
> ---
>  drivers/input/keyboard/omap4-keypad.c | 56 ++++++++++++++++++++++++---
>  1 file changed, 50 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -71,6 +71,8 @@ struct omap4_keypad {
>  	void __iomem *base;
>  	bool irq_wake_enabled;
>  	unsigned int irq;
> +	struct delayed_work key_work;
> +	struct mutex lock;		/* for key scan */

I think having threaded interrupt and delayed work together defeats the
purpose of having threaded interrupt. If you want to add a delay before
repeating scan I think you can add it directly in
omap4_keypad_irq_thread_fn(). Or is there a concern that we will not
rely quickly enough on additional key presses? It is unclear to me if
additional key press within the debounce time will result in additional
interrupt.

Thanks.

-- 
Dmitry