linux-kernel - Re: Threaded interrupts for synaptic touchscreen in HTC dream

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:	Wed, 22 Jul 2009 16:30:15 -0700
From:	Arve Hjønnevåg <arve@...roid.com>
To:	David Brownell <david-b@...bell.net>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Trilok Soni <soni.trilok@...il.com>,
	Pavel Machek <pavel@....cz>,
	kernel list <linux-kernel@...r.kernel.org>,
	Brian Swetland <swetland@...gle.com>,
	linux-input@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	linux-i2c@...r.kernel.org,
	Joonyoung Shim <jy0922.shim@...sung.com>,
	m.szyprowski@...sung.com, t.fujak@...sung.com,
	kyungmin.park@...sung.com, Daniel Ribeiro <drwyrm@...il.com>
Subject: Re: Threaded interrupts for synaptic touchscreen in HTC dream

2009/7/22 David Brownell <david-b@...bell.net>:
> On Wednesday 22 July 2009, Arve Hjønnevåg wrote:
>> It would also be useful to mask an edge triggered interrupt until the
>> thread handler has finished. The touchscreen on the G1 is connected to
>> an edge triggered interrupt, and the touchscreen may toggle the
>> interrupt line while reading its registers.
>
> To clarify:  if it does toggle, do you want that event to be
> queued up so the IRQ is re-issued -- or not?  That "oneshot"
> mechanism does some of that, though it's for level triggers.

For this driver yes the event should normally be queued up. If there
is an error detected though, there is no need to queue up interrupts
that are generated during the reinit.

Also, if you implement a keypad matrix driver using a threaded
interrupt handler, you will not want the interrupt to be re-issues
unless it occured after the last key was released since the scan
itself always generated more interrupts. This is not specific to
threaded interrupt handlers though, and could be handled by adding a
clear-interrupt function.

>
> Parts of that might be appropriate to handle in the threaded
> IRQ handler itself.  It seems a bit device-specific.

Yes, the driver could request a threaded one-shot interrupt so that it
will work when it is connected to a level triggered interrupt, and
also call disable_interrupt/enable_interrrupt in the handler to avoid
extra interrupts when it is connected to an edge triggered source.
But, it would be nicer if requesting a one-shot interrupt always
works. Also, waiting until the threaded handler runs before masking
the interrupt would not work well if the interrupt line needs software
debouncing.

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