linux-kernel - Re: [PATCH v2 3/5] [RFC] gpio: pca953x: hack to map LEVEL irqs to EDGE irqs (may loose interrupts/hang)

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: <CAHp75VctneZKFrRr5bgq6w1L9JkDzbKW421aDLQU2jf9vZgmFA@mail.gmail.com>
Date:   Tue, 10 Apr 2018 17:38:17 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
Cc:     Kumar Gala <galak@...eaurora.org>,
        Rob Herring <robh+dt@...nel.org>,
        Pawel Moll <pawel.moll@....com>,
        Mark Rutland <mark.rutland@....com>,
        Ian Campbell <ijc+devicetree@...lion.org.uk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>,
        devicetree <devicetree@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Discussions about the Letux Kernel 
        <letux-kernel@...nphoenux.org>, kernel@...a-handheld.com
Subject: Re: [PATCH v2 3/5] [RFC] gpio: pca953x: hack to map LEVEL irqs to
 EDGE irqs (may loose interrupts/hang)

On Wed, Apr 4, 2018 at 10:00 PM, H. Nikolaus Schaller <hns@...delico.com> wrote:

> in driver code. Therefore, the pca953x driver rejects the
> setup of the irq because it can only handle EDGE interrupts
> so far.
>
> This hack translates level interrupts to edge interrupts
> for the pca953x chips. This is enough for initial testing,
> but not a good solution since interrupts may be lost.
>
> If for example the connected chip requests a IRQ_TYPE_LEVEL_LOW
> this may have the reason that there may be multiple different
> interrupt sources in the chip - wired-or together to the
> input of the pca953x. Now if we do edge detecion only,
> the first interrupt will generate an EDGE_FALLING, but a
> second one won't ever if the first interrupt wasn't already
> processed.
>
> IMHO a better solution would be to make the pca953x interrupt
> handler check if the irq input is still in the active
> level and run the device specific handler again.

What I thought about is to enable such exclusively for "L" variants of
the chips and check latched values.

-- 
With Best Regards,
Andy Shevchenko