linux-kernel - Re: [PATCH] pinctrl: st: don't specify default interrupt trigger

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:   Mon, 24 Oct 2016 01:30:13 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Patrice CHOTARD <patrice.chotard@...com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "open list:ARM/STI ARCHITECTURE" <kernel@...inux.com>,
        Peter Griffin <peter.griffin@...aro.org>,
        Lee Jones <lee.jones@...aro.org>
Subject: Re: [PATCH] pinctrl: st: don't specify default interrupt trigger

On Tue, Oct 18, 2016 at 9:16 AM,  <patrice.chotard@...com> wrote:

> From: Patrice Chotard <patrice.chotard@...com>
>
> Thanks to 332e99d5ae4 which now alerts of default
> trigger usage when configuring interrupts.
>
> Signed-off-by: Patrice Chotard <patrice.chotard@...com>

Patch applied with Peter's ACK.

Pls also look into the following: __gpio_irq_handler seems to be
doing some stuff per-IRQ that only pertains to edge-triggered IRQs.
Normally that should be handled by:

- Setting default handler to handle_bad_irq()
- Setting handler to handle_edge_irq() or handle_level_irq() in .set_type()
- Implement .irq_ack() on the irqchip and handle the edge-specific ACKing
  there.

See for example drivers/gpio/gpio-pl061.c.

I am not *sure* this applies to pinctrl-st.c but please check if it provides
more elegant code. Notmally the .irq_ack() is for edge detection hardware
that allows ACKing the ege IRQ in a separate register and after that we
can raise another edge IRQ while the current IRQ is being handled.

Yours,
Linus Walleij