linux-kernel - Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing handle

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]

Message-ID: <20170321164330.GB6986@localhost.localdomain>
Date:   Tue, 21 Mar 2017 16:43:30 +0000
From:   Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To:     Tony Lindgren <tony@...mide.com>
CC:     Mark Brown <broonie@...nel.org>, <linux-kernel@...r.kernel.org>,
        <linux-omap@...r.kernel.org>, Lee Jones <lee.jones@...aro.org>,
        Marcel Partap <mpartap@....net>,
        Michael Scott <michael.scott@...aro.org>,
        "Sebastian Reichel" <sre@...nel.org>
Subject: Re: [PATCH 1/4] regmap: irq: Fix lost interrupts by introducing
 handle_reread

On Tue, Mar 21, 2017 at 08:41:22AM -0700, Tony Lindgren wrote:
> * Charles Keepax <ckeepax@...nsource.wolfsonmicro.com> [170321 02:24]:
> > On Mon, Mar 20, 2017 at 08:33:42AM -0700, Tony Lindgren wrote:
> > > * Charles Keepax <ckeepax@...nsource.wolfsonmicro.com> [170320 08:15]:
> > > > On Thu, Mar 16, 2017 at 05:36:30PM -0700, Tony Lindgren wrote:
> > That sounds a lot like a level triggered IRQ. If they are
> > repeatedly reading the GPIO line until it returns to high to know
> > they need to process more IRQs, that implies the line is staying
> > low whilst IRQs need handling which is level triggered.
> 
> Yeah.. Actually my description above is a bit wrong sorry. It seems
> the GPIO line changes status too early in some cases meaning the
> interrupts stop. So it's like a buggy implementation of level IRQ
> that stops driving the GPIO interrupt line to the SoC in some cases
> even with PMIC interrupts pending. So it seems like a bug in the
> CPCAP PMIC.
> 
> So the handling needs to be "read while CPCAP interrupts in the
> registers even if the GPIO line to SoC has cleared stopped
> signaling interrupts" :)
> 

Ah ok thanks for taking the time to explain that. Yeah that
sounds like the PMIC hardware is a bit buggy so you will
presumably need something to support this.

Thanks,
Charles