linux-kernel - Re: [PATCH V1] input: keyboard: Add interrupt keyboard driver.

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] [day] [month] [year] [list]

Date:	Fri, 2 Mar 2012 10:54:02 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	"tsoni@...eaurora.org" <tsoni@...eaurora.org>,
	"kyle.manna@...l7.com" <kyle.manna@...l7.com>,
	"aghayal@...eaurora.org" <aghayal@...eaurora.org>,
	"vapier@...too.org" <vapier@...too.org>,
	"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH V1] input: keyboard: Add interrupt keyboard driver.

On Thursday 26 January 2012 07:41 AM, Laxman Dewangan wrote:
> On Thursday 19 January 2012 01:09 PM, Laxman Dewangan wrote:
>> On Thursday, January 19, 2012 1:00 PM, Dmitry Torokhov wrote:
>>
>>
> Hi  Dmitry,
> Do you have any further comment on above approach?  Here is little bit
> background which can help on understanding.
> I am working on some MFD devices and to tried to support the onkey from
> single driver to avoid having driver for each mfd-pmic driver.
>
> When developing this driver, I though of following behaviors of the pmic
> device for power-btn/onkey switches:
> 1. Separate Interrupt for press and release: (Falling and rising
> interrupt, no level interrupt) So two different interrupt will get
> registered and based on interrupt number the key code and key value will
> get reported to input system. Device like AB8500 (ab8500-ponkey.c).
>
> 2. Generates interrupt for only key press, no interrupt for the key
> release (only one interrupt i.e. Falling edge) In this case, it need to
> send the release event automatically after sending press event. So
> whenever there is falling edge on keys, the interrupt get generated, No
> interrupt on pressed level. Devices like ricoh583,  max77663.
>
> 3. Keep generating interrupt if key is pressed but no interrupt after
> release (Kind on level (low) interrupt and so multiple interrupts till
> key pressed.) Devices like tps65910..
> In this case, the device generates level interrupt and if it acked,
> again generates interrupt. So if we send the key press/release together
> without waiting, we will endup with sending the key event multiple time.
> To avoid this I used the debaince logic as follows:
> detect first interrupt, send press event and start timer and wait for
> timer to expire for sending release events. If interrupt again occurs
> before timer expires, restart timer again. Keep doing this until user
> release the key. Once he release the key, there will be no interrupt and
> so timer will be expire after some time i.e. debounce time and then
> report key released.
>
>

Hi Dmitry,
Can you please review the above approach? If you still want to do in 
gpio-keys then I will make new patch and will send but wanted to know 
your opinion about my proposals.
Idea is to get support only interrupt keys.

Thanks,
Laxman
--
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/