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:	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)

Powered by blists - more mailing lists