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:	Fri, 1 Apr 2016 15:29:21 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Alexander Stein <alexander.stein@...tec-electronic.com>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] gpio: mcp23s08: Add support for level triggered interrupts

On Thu, Mar 31, 2016 at 10:58 AM, Alexander Stein
<alexander.stein@...tec-electronic.com> wrote:
> On Thursday 31 March 2016 10:41:24, Linus Walleij wrote:

> From the reference manual:
>> The INTCAP register captures the GPIO port value at
>> the time the interrupt occurred. The register is ‘read
>> only’ and is updated only when an interrupt occurs. The
>> register will remain unchanged until the interrupt is
>> cleared via a read of INTCAP or GPIO.
>
> So, i guess you're right. Although currently I don't know why
> handle_simple_irq would not work if this would not be the case.

The usual construction is that for edge triggered interrupts
there is an ACK register where a bit goes to "1" whenever it
triggers on an edge, and this must be taken down by an explicit
read or even write of the ACK registers.

Level triggered interrupts by contrast, are just a register
reflecting the value of the interrupt line: it only remains set
to "1" as long as the external source holds it high, and will
go low as soon as the device causing he interrupt releases
it.

Therefor level triggered interrupts often do not need any
explicit ACK at all.

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ