From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7185DC433FE for ; Wed, 9 Dec 2020 08:54:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 36B8D23A6C for ; Wed, 9 Dec 2020 08:54:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727121AbgLIIyP (ORCPT ); Wed, 9 Dec 2020 03:54:15 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:53181 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725942AbgLIIyP (ORCPT ); Wed, 9 Dec 2020 03:54:15 -0500 Received: from [192.168.1.155] ([77.2.91.93]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MyK9S-1jux8A4AO4-00ykZ1; Wed, 09 Dec 2020 09:51:23 +0100 Subject: Re: [RFC PATCH] RFC: drivers: gpio: helper for generic pin IRQ handling To: Andy Shevchenko , "Enrico Weigelt, metux IT consult" Cc: Linux Kernel Mailing List , William Breathitt Gray , Linus Walleij , Bartosz Golaszewski , joyce.ooi@intel.com, Andrew Jeffery , Hoan Tran , Serge Semin , orsonzhai@gmail.com, baolin.wang7@gmail.com, zhang.lyra@gmail.com, Andy Shevchenko , Matthias Brugger , Grygorii Strashko , Santosh Shilimkar , Kevin Hilman , Manivannan Sadhasivam , Jun Nie , Shawn Guo , Philipp Zabel , "open list:GPIO SUBSYSTEM" , Linux OMAP Mailing List References: <20201208141429.8836-1-info@metux.net> From: "Enrico Weigelt, metux IT consult" Message-ID: <39d03958-786e-a6c8-a1e9-9b8a751e4c9e@metux.net> Date: Wed, 9 Dec 2020 09:51:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:EuKdMo+/U1o5sFyWn2fUeeb59IOsjJ1lKvxlbr6jwLrI3rpvFd4 nhAYSKUtpDAcHNztBd1k9lK6qbyB1EcO8lUbEIU5JHIuIhzzSdv4XgexxRWXPF00dGCmnbf nYQOr067XFqPOQiO8XUmYaHJ4wg6GfRagiQcILR4wwkTZgwJdowyWBZ0VPnXmbiUND2mKf9 wYeFaMGInmTUtMMfCkfUg== X-UI-Out-Filterresults: notjunk:1;V03:K0:MzrASONKidU=:2JvqAQMMojOiNOBmF4oVsI UjxeFmft5OCgVFjNWuGw9iiMHyWs0gBwNW+1RbqjeGsXuBgPo796Xq4ZZv5+2sfyV+hd12CrE EefDT434K7Io5QJGQvg/XvTcEbRA2uQyjC6ENbKlkH57TzhOeQNSqUyEdA46wGS8/1M51hLBZ WuV+KrkvIwX06gKHr0UqFsDpHDmFu1o7JC7/YetwlnSjuuEqZwL6Dz+NXFjjiqHVNrAkCQBEv zZNwDPdei+yEotyWDlKwnw7Kk3bXhdm4LxWZ+ws8xyqLuvxtsBdFYc6ou+l6WGEZTjIuG/kB8 QcWRe9NZ74Wl+5CCPfvN6q8dNHVHUmYrh02AfpGJGi8VtWsi08DpWoiqrdD8dD2+smmPlkMNj Ip2kWmByQUeGlqnvgP1TuNeyldHDhZ2vtOJj7gfbiuKl5CdhmVjKWS5ZaSE7B Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@metux.net -- +49-151-27565287