linux-kernel - Re: [Stratos-dev] [PATCH V4 2/2] gpio: virtio: Add IRQ support

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]

Message-ID: <20210810073512.5n5vsjvvurgdemk6@vireshk-i7>
Date:   Tue, 10 Aug 2021 13:05:12 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     "Michael S. Tsirkin" <mst@...hat.com>,
        Viresh Kumar <vireshk@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Cornelia Huck <cohuck@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:DRM DRIVER FOR QEMU'S CIRRUS DEVICE" 
        <virtualization@...ts.linux-foundation.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Marc Zyngier <maz@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>,
        Jason Wang <jasowang@...hat.com>,
        Stratos Mailing List <stratos-dev@...lists.linaro.org>
Subject: Re: [Stratos-dev] [PATCH V4 2/2] gpio: virtio: Add IRQ support

On 09-08-21, 13:19, Arnd Bergmann wrote:
> I don't see anything wrong with this version,

Great.

> but let's see what
> Marc thinks. I expect that he can still poke some holes in it, or
> at least find some simplifications.

Right, though I may resend the patches properly first to make it less
confusing.

> I was slightly surprised at the relation between the disabled and
> masked states, where 'disable' always implies 'mask' and
> 'enable' always implies 'unmask', but I don't actually know how
> those two are actually defined in the irqchip code in Linux, so
> I assume you did this correctly.

I did have a look at the irq-core, but didn't go in real depth. I
rather saw how stuff happens at the driver's end.

- On setup-irq, the core only calls enable() and not unmask().
- On interrupt, the core calls mask(), followed by unmask() (which can
  be delayed for threaded irqs).
- On disable_irq(), the core only calls disable().
- On enable_irq(), the core only calls enable().

And so I ended up at this version :)

-- 
viresh