linux-kernel - Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2] drivers: gpio: add virtio-gpio guest driver

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]

Date:   Wed, 9 Dec 2020 22:22:30 +0200
From:   Grygorii Strashko <grygorii.strashko@...com>
To:     Linus Walleij <linus.walleij@...aro.org>,
        Arnd Bergmann <arnd@...nel.org>
CC:     "Enrico Weigelt, metux IT consult" <lkml@...ux.net>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Jason Wang <jasowang@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Linux Doc Mailing List <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        <virtualization@...ts.linux-foundation.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>
Subject: Re: Howto listen to/handle gpio state changes ? Re: [PATCH v2 2/2]
 drivers: gpio: add virtio-gpio guest driver



On 09/12/2020 14:53, Linus Walleij wrote:
> On Wed, Dec 9, 2020 at 12:19 PM Arnd Bergmann <arnd@...nel.org> wrote:
>> On Wed, Dec 9, 2020 at 9:51 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>>> On Tue, Dec 8, 2020 at 3:07 PM Enrico Weigelt, metux IT consult <lkml@...ux.net> wrote:
>>
>>> What we need to understand is if your new usecase is an outlier
>>> so it is simplest modeled by a "mock" irq_chip or we have to design
>>> something new altogether like notifications on changes. I suspect
>>> irq_chip would be best because all drivers using GPIOs for interrupts
>>> are expecting interrupts, and it would be an enormous task to
>>> change them all and really annoying to create a new mechanism
>>> on the side.
>>
>> I would expect the platform abstraction to actually be close enough
>> to a chained irqchip that it actually works: the notification should
>> come in via vring_interrupt(), which is a normal interrupt handler
>> that calls vq->vq.callback(), calling generic_handle_irq() (and
>> possibly chained_irq_enter()/chained_irq_exit() around it) like the
>> other gpio drivers do should just work here I think, and if it did
>> not, then I would expect this to be just a bug in the driver rather
>> than something missing in the gpio framework.
> 
> Performance/latency-wise that would also be strongly encouraged.
> 
> Tglx isn't super-happy about the chained interrupts at times, as they
> can create really nasty bugs, but a pure IRQ in fastpath of some
> kinde is preferable and intuitive either way.

In my opinion the problem here is that proposed patch somehow describes Front end, but
says nothing about Backend and overall design.

What is expected to be virtualized? whole GPIO chip? or set of GPIOs from different GPIO chips?
Most often nobody want to give Guest access to the whole GPIO chip, so, most probably, smth. similar to
GPIO Aggregator will be needed.

How is situation going to be resolved that GPIO framework and IRQ framework are independent, but intersect, and
GPIO controller drivers have no idea who and how requesting GPIO IRQ - threaded vs non-threaded vs oneshot.
So, some information need to be transferred to Back end  - at minimum IRQ triggering type.

Overall, it might be better to start from pure gpio and leave GPIO IRQ aside.
-- 
Best regards,
grygorii