linux-kernel - Re: Emulating level IRQs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAN1soZy-_MdjqS3r3Tc1XET6tPzMxDqjYq3Tn0fYLBNNUkdVAg@mail.gmail.com>
Date:	Mon, 6 Aug 2012 00:56:42 +0800
From:	Haojian Zhuang <haojian.zhuang@...il.com>
To:	Daniel Mack <zonque@...il.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Sven Neumann <s.neumann@...mfeld.com>,
	Olof Johansson <olof@...om.net>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, Eric Miao <eric.y.miao@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Emulating level IRQs

On Mon, Aug 6, 2012 at 12:22 AM, Daniel Mack <zonque@...il.com> wrote:
> On 24.07.2012 20:01, Daniel Mack wrote:
>> 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?
>
> Otherwise, we would need some sort of generic irq_to_gpio() again, and
> the interrupt line the driver listens to must have support for that sort
> of mapping.
>
> Any opinion on this, anyone?
>
Since you're using gpio as input, you need to call gpio_request() and set it
as input direction. And you could also transfer the gpio number into touch
driver via platform data. Is it OK for you?

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