linux-kernel - Re: [PATCH v3 2/3] Input: omap-keypad: errata i689: Correct debounce time

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:	Mon, 29 Jul 2013 21:08:12 +0300
From:	Felipe Balbi <balbi@...com>
To:	Illia Smyrnov <illia.smyrnov@...com>
CC:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	<linux-input@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-omap@...r.kernel.org>, Felipe Balbi <balbi@...com>
Subject: Re: [PATCH v3 2/3] Input: omap-keypad: errata i689: Correct debounce
 time

Hi,

On Mon, Jul 29, 2013 at 07:45:10PM +0300, Illia Smyrnov wrote:
> From: Axel Haslam <axelhaslam@...com>
> 
> Set debounce time value to 12ms to workaround the errata.
> 
> ERRATA DESCRIPTION:
> 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.
> From the operating system standpoint, only a key press as been detected,
> and the key will keep on being printed on the screen until another or
> the same key is pressed again.When the failing state has been reached,
> the KBD_STATEMACHINE register will show "idle state" and the KBD_FULLCODE
> register won't be empty, this is the signature of the bug.There is no impact
> on the power consumption of the system as the state machine goes to IDLE state.
> 
> WORKAROUND:
> First thing is to program the debounce time correctly:
> If X (us) is the maximum time of bounces when a key is pressed or released,
> and Y (us) is the minimum time of a key release that is expected to be detected,
> then the debounce time should be set to a value inbetween X and Y.
> 
> In case it is still possible to get shorter than debounce time key-release
> events, then the only solution is to implement a software workaround:
> 
> Before printing a second character on the screen, the software must check if
> the keyboard has hit the failing condition (cf signature of the bug above)
> or if the key is still really pressed and then take the appropriate actions.
> 
> Silicon revisions impacted: OMAP4430 ES 1.0,2.0,2.1,2.2,2.3
>                             OMAP4460 ES 1.0,1.1
>                             OMAP5430 ES 1.0

if only these are affected, should you have revision check ? Also we
don't support OMAP5430 ES 1.0. I say this because, IMO, debouncing time
is likely to be board-specific and/or application-specific.

> diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
> index feab00f..e8bdc76 100644
> --- a/drivers/input/keyboard/omap4-keypad.c
> +++ b/drivers/input/keyboard/omap4-keypad.c
> @@ -62,8 +62,10 @@
>  
>  /* OMAP4 values */
>  #define OMAP4_VAL_IRQDISABLE		0x0
> -#define OMAP4_VAL_DEBOUNCINGTIME	0x7
> -#define OMAP4_VAL_PVT			0x7
> +
> +/* Errata i689: set debounce time value to 12ms */
> +#define OMAP4_VAL_DEBOUNCINGTIME	0x2
> +#define OMAP4_VAL_PVT			0x6

to make this easier to understand, you might want to convert this into a
better macro that takes an argument in microseconds and you calculate
the debouncing time which should be written to HW.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)