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: <39d03958-786e-a6c8-a1e9-9b8a751e4c9e@metux.net>
Date:   Wed, 9 Dec 2020 09:51:18 +0100
From:   "Enrico Weigelt, metux IT consult" <info@...ux.net>
To:     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>,
        Grygorii Strashko <grygorii.strashko@...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 15:19, Andy Shevchenko wrote:

Hi,

> Have you able to test them all?

Not yet. It's still an *RFC*, I just like to discuss whether the whole
idea makes sense at all.

In case we come to the consensus that we should do it, I'm going to
split up the patch and rework everything more carefully (for now,
it's just a draft for illustrating the general idea)

I'd also like to hear your opinion on whether we can consolidate these
things even more, eg. using struct gpio_chip's irq data (enabled by
CONFIG_GPIOLIB_IRQCHIP) instead of own fields.

An interesting question here is how to do that w/o gpiolib assuming
they've been managed by it - for example gpiochip_remove (which
cleans up the IRQ stuff) is called by gpiochip_remove(), so we have to
make sure that the driver clears the corresponding fields before
gpiochip_remove() is called. So far so good. BUT: gpiochip_remove()
is also called in error paths, when registration fails in the middle,
and there the driver cannot act properly.

Maybe introduce a flag for telling gpiolib that it should leave these
fields alone and let the driver do everything ?

> As the PCA953x case showed us this is not so simple, 

Can you tell me more about it ?
(BTW haven't touched it in my patch)

> besides the name
> which sucks — we don't *raise* and IRQ we *handle* it.

right, the naming was bad, forgot to correct that before sending.

--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