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:	Tue, 24 Jul 2012 20:01:56 +0200
From:	Daniel Mack <zonque@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Sven Neumann <s.neumann@...mfeld.com>,
	Olof Johansson <olof@...om.net>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	Eric Miao <eric.y.miao@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Emulating level IRQs (was: Re: [PATCH] Input: eeti_ts: Mark as CONFIG_BROKEN)

On 23.07.2012 18:51, Dmitry Torokhov wrote:
> On Thu, Jul 19, 2012 at 05:36:12PM +0200, Daniel Mack wrote:

>> Ok, finally I found some time. In general, the patch works fine. The
>> only detail I had to amend was the irqflags, which were changed from
>> IRQF_TRIGGER_RISING/IRQF_TRIGGER_FALLING to
>> IRQF_TRIGGER_HIGH/IRQF_TRIGGER_LOW, which doesn't work as the PXA can't
>> deal with level-based IRQs. Changing this back to RISING/FALLING makes
>> the driver work again.
> 
> Hmm, but that would mean we need to restore reading the data in open()
> to make sure we re-arm IRQ in case somebody touched the screen before it
> was opened by userspace...

I had another look at this and don't really know what to do here. We
definitely need level interrupts for this device as the interrupt line's
level is the only that tells us when we can stop reading from the
device. So it's not just the start condition that bites us here.

I copied some people that might help find a solution.

To summarize the problem: The EETI touchscreen is a device that asserts
a GPIO line when it has events to deliver and waits for I2C commands to
empty its buffers. When there are no more buffered events, it will
de-assert the line.

This device is connected to a PXA GPIO that is only able to deliver edge
IRQs, and the old implemenation was to wait for an interrupt and then
read data as long as the IRQ's corresponding GPIO was asserted. However,
expecting that an IRQ is mappable to a GPIO is not something we should
do, so the only clean solution is to teach the PXA GPIO controller level
IRQs.

So it boils down to the question: Is there any easy and generic way to
emulate level irq on chips that don't support that natively?


Daniel





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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ