linux-kernel - Re: [RFC PATCH] RFC: drivers: gpio: helper for generic pin IRQ handling

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: <710efa0f-063e-8a9e-1c3f-49337506b044@metux.net>
Date:   Wed, 9 Dec 2020 11:23:13 +0100
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Grygorii Strashko <grygorii.strashko@...com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        "Enrico Weigelt, metux IT consult" <info@...ux.net>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        William Breathitt Gray <vilhelm.gray@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        joyce.ooi@...el.com, Andrew Jeffery <andrew@...id.au>,
        Hoan Tran <hoan@...amperecomputing.com>,
        Serge Semin <fancer.lancer@...il.com>, orsonzhai@...il.com,
        baolin.wang7@...il.com, zhang.lyra@...il.com,
        Andy Shevchenko <andy@...nel.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Santosh Shilimkar <ssantosh@...nel.org>,
        Kevin Hilman <khilman@...nel.org>,
        Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Jun Nie <jun.nie@...aro.org>, Shawn Guo <shawnguo@...nel.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux OMAP Mailing List <linux-omap@...r.kernel.org>
Subject: Re: [RFC PATCH] RFC: drivers: gpio: helper for generic pin IRQ
 handling

On 08.12.20 17:18, Grygorii Strashko wrote:

>>>> Having all GPIO drivers doing their IRQ management entirely through the
>>>> GPIO subsystem (eg. never calling generic_handle_irq() and using the
>>>> builtin
>>>> IRQ handling) would also allow a more direct (eg. callback-based)
>>>> pin change
>>>> notification for GPIO consumers, that doesn't involve registering
>>>> them as
>>>> generic IRQ handlers.
> 
> Above part makes me worry - why?

Why so ?

Little clarification, in case i've been a bit confusion - there're two
separate topics:

a) consolidating repeated patterns (eg. calling the actual irq handling)
   into gpiolib, (and later possibly use more fields already existing in
   struct gpio_chip for irq handling)

b) a direct consumer callback for change, where the consumer doesn't
   have to care about IRQs at all (some drivers could even do polling,
   when hw doesn't have IRQs). This is for consumers that don't use
   GPIOs as interrupt source, but more more like a very raw serial port,
   eg. bitbanging of other interfaces (maybe an gpio bus type ? ;-))

The above paragraph just outlines that b) might be much easier to
implement, once the suggested refactoring is done and no driver would
call irq handlers directly anymore. But this hasn't much to do with
the proposal itself, just an idea for future use.

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287