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 F08F5C4361B for ; Wed, 9 Dec 2020 10:26:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9D52A23B79 for ; Wed, 9 Dec 2020 10:26:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729849AbgLIK0L (ORCPT ); Wed, 9 Dec 2020 05:26:11 -0500 Received: from mout.kundenserver.de ([217.72.192.75]:40611 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729231AbgLIK0L (ORCPT ); Wed, 9 Dec 2020 05:26:11 -0500 Received: from [192.168.1.155] ([77.2.91.93]) by mrelayeu.kundenserver.de (mreue106 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MLyzP-1kVgl53LKj-00I0YQ; Wed, 09 Dec 2020 11:23:18 +0100 Subject: Re: [RFC PATCH] RFC: drivers: gpio: helper for generic pin IRQ handling To: Grygorii Strashko , 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 , 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> <0c16ab33-f87f-b32d-53d0-a44a5fecd6dc@ti.com> From: "Enrico Weigelt, metux IT consult" Message-ID: <710efa0f-063e-8a9e-1c3f-49337506b044@metux.net> Date: Wed, 9 Dec 2020 11:23:13 +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: <0c16ab33-f87f-b32d-53d0-a44a5fecd6dc@ti.com> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:EfePztOrymHKfYxNnLFVD8MbCqHmMYcSjnD/zRYzwOVK50PaTDO V16L1ULFXQ8mFROXQORa51saqagaRj87zvo+tqf9TrXBvhhqerIr9nW39zr18JXrhWrrq9F /g4k+ySn0i/LI9LrCSEb14O0Yp1PDmhhhQeUjyekHFqYY4CrmtWz6c0IuepbOjPEU/7wnGU 3g/e8ENQ+K2rHKNG1DWRg== X-UI-Out-Filterresults: notjunk:1;V03:K0:BNgWdIM3ZTw=:BDjkTcychAye7DhF3ue5DL l5rChA9jUpaOxlxRC2BB4JwAQ25N88VnNyrLsh+VGdOyEfCU7M2weQuQCPg6LLDVG93Z7OrHb JZ2XRMSIRbFXyD8IG1rXnfQrd/fhrYKL8ChQLOofoPXz9ZHD2upIJN3b2k8W2hqtFmzHC0Foy Scv6TPvDXeUQzhH4kAYZh0mQb26QHXX39eUbopKRPptcqETtWd96FGoxaVMOAm7uXoX9qj9RP /XIgNfpv7mOaRachs05+cg5wXTBXnBAhNHlOME5EC1E99V04hWO9aSwlCNYhP0Akf+8pFppwx 1YCljurh8GWwIao/VXO5KiniQtBqqpizxzNd5lZQGmcprKoLQgZ/jBI2ai55wSMsx4lz3aPea GgGTjupmD9KNiKq7DCBQNYi8BIA3lBzq6XYxmZbhA4aPVpSLejLksZdiBOfEO/ABI4EDA7CeX 313QpFPGDZ9byhZo9dycobO/QMLuU2hWJbdTi445uQaejdyafS8I Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@metux.net -- +49-151-27565287