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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <502131EB.4000100@gmail.com>
Date:	Tue, 07 Aug 2012 17:19:07 +0200
From:	Daniel Mack <zonque@...il.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Eric Miao <eric.y.miao@...il.com>,
	Haojian Zhuang <haojian.zhuang@...il.com>,
	Sven Neumann <s.neumann@...mfeld.com>,
	Olof Johansson <olof@...om.net>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Emulating level IRQs

On 06.08.2012 18:36, Mark Brown wrote:
> On Mon, Aug 06, 2012 at 09:45:13AM +0800, Eric Miao wrote:
> 
>> So my understanding, if it's correct, that we can treat the EETI chip as having
>> two separate inputs: one IRQ line (for the event notification) and one GPIO line
>> (for a condition where data are emptied), we could naturally have two numbers
>> in the driver, but unfortunately they end up being in sync as they are
>> physically
>> one pin.
> 
> ...unless the interrupt controller supports level IRQs at which point we
> don't need the GPIO, of course :/ .

Exactly. My question was rather - like the subject says ;) - if there is
a way to emulate level IRQs on controllers that can't do that natively.

But ok, I followed Eric's suggestion now and implemented it that way.
This also works fine for me.

Dmitry, are you fine with that patch?


Many thanks for the input, everyone!
Daniel



View attachment "0001-Input-eeti_ts-pass-gpio-value-instead-of-IRQ.patch" of type "text/x-patch" (3731 bytes)