From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Laight Subject: RE: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void Date: Mon, 9 Jun 2014 13:43:56 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com> References: <20140530094025.3b78301e@canb.auug.org.au> <1401449454-30895-1-git-send-email-berthe.ab@gmail.com> <1401449454-30895-2-git-send-email-berthe.ab@gmail.com> <5388C0F1.90503@gmail.com> <5388CB1B.3090802@metafoo.de> <20140608231823.GB10112@trinity.fluff.org> <53959A93.7080308@metafoo.de> <5395B379.2010706@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5395B379.2010706@samsung.com> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: driverdev-devel-bounces@linuxdriverproject.org To: 'Andrzej Hajda' , Lars-Peter Clausen , Ben Dooks Cc: driverdevel , Linux MIPS Mailing List , "spear-devel@list.st.com" , David Daney , Linux-sh list , "netdev@vger.kernel.org" , Linus Walleij , "patches@opensource.wolfsonmicro.com" , linux-wireless , "linux-kernel@vger.kernel.org" , "platform-driver-x86@vger.kernel.org" , "linux-gpio@vger.kernel.org" , Geert Uytterhoeven , "linux-arm-kernel@lists.infradead.org" , "m@bues.ch" , "linux-input@vger.kernel.org" , linux-samsungsoc@vger.kerne List-Id: linux-leds@vger.kernel.org From: Of Andrzej Hajda ... > > You can't error out on module unload, although that's not really relevant > > here. gpiochip_remove() is typically called when the device that registered > > the GPIO chip is unbound. And despite some remove() callbacks having a > > return type of int you can not abort the removal of a device. > > It is a design flaw in many subsystems having providers and consumers, > not only GPIO. The same situation is with clock providers, regulators, > phys, drm_panels, ..., at least it was such last time I have tested it. > > The problem is that many frameworks assumes that lifetime of provider is > always bigger than lifetime of its consumers, and this is wrong > assumption - usually it is not possible to prevent unbinding driver from > device, so if the device is a provider there is no way to inform > consumers about his removal. > > Some solution for such problems is to use some kind of availability > callbacks for requesting resources (gpios, clocks, regulators,...) > instead of simple 'getters' (clk_get, gpiod_get). Callbacks should > guarantee that the resource is always valid between callback reporting > its availability and callback reporting its removal. Such approach seems > to be complicated at the first sight but it should allow to make the > code safe and as a bonus it will allow to avoid deferred probing. > Btw I have send already RFC for such framework [1]. Callbacks for delete are generally a locking nightmare. A two-way handshake is also usually needed to avoid problems with concurrent disconnect requests. David From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 09 Jun 2014 15:44:41 +0200 (CEST) Received: from mx0.aculab.com ([213.249.233.131]:39962 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with SMTP id S6819313AbaFINojXiEca convert rfc822-to-8bit (ORCPT ); Mon, 9 Jun 2014 15:44:39 +0200 Received: (qmail 8940 invoked from network); 9 Jun 2014 13:44:36 -0000 Received: from localhost (127.0.0.1) by mx0.aculab.com with SMTP; 9 Jun 2014 13:44:36 -0000 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 08135-02 for ; Mon, 9 Jun 2014 14:44:29 +0100 (BST) Received: (qmail 8868 invoked by uid 599); 9 Jun 2014 13:44:28 -0000 Received: from unknown (HELO AcuExch.aculab.com) (10.202.163.4) by mx0.aculab.com (qpsmtpd/0.28) with ESMTP; Mon, 09 Jun 2014 14:44:28 +0100 Received: from ACUEXCH.Aculab.com ([::1]) by AcuExch.aculab.com ([::1]) with mapi id 14.03.0123.003; Mon, 9 Jun 2014 14:43:56 +0100 From: David Laight To: 'Andrzej Hajda' , Lars-Peter Clausen , Ben Dooks CC: Linux MIPS Mailing List , "m@bues.ch" , Linux-sh list , Linus Walleij , "platform-driver-x86@vger.kernel.org" , "linux-leds@vger.kernel.org" , driverdevel , Alexandre Courbot , "patches@opensource.wolfsonmicro.com" , "linux-samsungsoc@vger.kernel.org" , Geert Uytterhoeven , "linux-input@vger.kernel.org" , Linux Media Mailing List , "spear-devel@list.st.com" , "linux-gpio@vger.kernel.org" , David Daney , "linux-arm-kernel@lists.infradead.org" , "netdev@vger.kernel.org" , linux-wireless , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void Thread-Topic: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void Thread-Index: AQHPg+T3C2ikfzU+v0axMk1kdlYMtJtow1QA Date: Mon, 9 Jun 2014 13:43:56 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com> References: <20140530094025.3b78301e@canb.auug.org.au> <1401449454-30895-1-git-send-email-berthe.ab@gmail.com> <1401449454-30895-2-git-send-email-berthe.ab@gmail.com> <5388C0F1.90503@gmail.com> <5388CB1B.3090802@metafoo.de> <20140608231823.GB10112@trinity.fluff.org> <53959A93.7080308@metafoo.de> <5395B379.2010706@samsung.com> In-Reply-To: <5395B379.2010706@samsung.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Virus-Scanned: by iCritical at mx0.aculab.com Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 40457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: David.Laight@ACULAB.COM Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips From: Of Andrzej Hajda ... > > You can't error out on module unload, although that's not really relevant > > here. gpiochip_remove() is typically called when the device that registered > > the GPIO chip is unbound. And despite some remove() callbacks having a > > return type of int you can not abort the removal of a device. > > It is a design flaw in many subsystems having providers and consumers, > not only GPIO. The same situation is with clock providers, regulators, > phys, drm_panels, ..., at least it was such last time I have tested it. > > The problem is that many frameworks assumes that lifetime of provider is > always bigger than lifetime of its consumers, and this is wrong > assumption - usually it is not possible to prevent unbinding driver from > device, so if the device is a provider there is no way to inform > consumers about his removal. > > Some solution for such problems is to use some kind of availability > callbacks for requesting resources (gpios, clocks, regulators,...) > instead of simple 'getters' (clk_get, gpiod_get). Callbacks should > guarantee that the resource is always valid between callback reporting > its availability and callback reporting its removal. Such approach seems > to be complicated at the first sight but it should allow to make the > code safe and as a bonus it will allow to avoid deferred probing. > Btw I have send already RFC for such framework [1]. Callbacks for delete are generally a locking nightmare. A two-way handshake is also usually needed to avoid problems with concurrent disconnect requests. David From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0.aculab.com ([213.249.233.131]:39962 "HELO mx0.aculab.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with SMTP id S6819313AbaFINojXiEca convert rfc822-to-8bit (ORCPT ); Mon, 9 Jun 2014 15:44:39 +0200 Received: from mx0.aculab.com ([127.0.0.1]) by localhost (mx0.aculab.com [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 08135-02 for ; Mon, 9 Jun 2014 14:44:29 +0100 (BST) From: David Laight Subject: RE: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void Date: Mon, 9 Jun 2014 13:43:56 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com> References: <20140530094025.3b78301e@canb.auug.org.au> <1401449454-30895-1-git-send-email-berthe.ab@gmail.com> <1401449454-30895-2-git-send-email-berthe.ab@gmail.com> <5388C0F1.90503@gmail.com> <5388CB1B.3090802@metafoo.de> <20140608231823.GB10112@trinity.fluff.org> <53959A93.7080308@metafoo.de> <5395B379.2010706@samsung.com> In-Reply-To: <5395B379.2010706@samsung.com> Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: 'Andrzej Hajda' , Lars-Peter Clausen , Ben Dooks Cc: Linux MIPS Mailing List , "m@bues.ch" , Linux-sh list , Linus Walleij , "platform-driver-x86@vger.kernel.org" , "linux-leds@vger.kernel.org" , driverdevel , Alexandre Courbot , "patches@opensource.wolfsonmicro.com" , "linux-samsungsoc@vger.kernel.org" , Geert Uytterhoeven , "linux-input@vger.kernel.org" , Linux Media Mailing List , "spear-devel@list.st.com" , "linux-gpio@vger.kernel.org" , David Daney , "linux-arm-kernel@lists.infradead.org" , "netdev@vger.kernel.org" , linux-wireless , "linux-kernel@vger.kernel.org" Message-ID: <20140609134356.vcRn3PVF5hpWLJBIx3Rk6CAQjFASRouzWSu0_TfMOcQ@z> From: Of Andrzej Hajda ... > > You can't error out on module unload, although that's not really relevant > > here. gpiochip_remove() is typically called when the device that registered > > the GPIO chip is unbound. And despite some remove() callbacks having a > > return type of int you can not abort the removal of a device. > > It is a design flaw in many subsystems having providers and consumers, > not only GPIO. The same situation is with clock providers, regulators, > phys, drm_panels, ..., at least it was such last time I have tested it. > > The problem is that many frameworks assumes that lifetime of provider is > always bigger than lifetime of its consumers, and this is wrong > assumption - usually it is not possible to prevent unbinding driver from > device, so if the device is a provider there is no way to inform > consumers about his removal. > > Some solution for such problems is to use some kind of availability > callbacks for requesting resources (gpios, clocks, regulators,...) > instead of simple 'getters' (clk_get, gpiod_get). Callbacks should > guarantee that the resource is always valid between callback reporting > its availability and callback reporting its removal. Such approach seems > to be complicated at the first sight but it should allow to make the > code safe and as a bonus it will allow to avoid deferred probing. > Btw I have send already RFC for such framework [1]. Callbacks for delete are generally a locking nightmare. A two-way handshake is also usually needed to avoid problems with concurrent disconnect requests. David From mboxrd@z Thu Jan 1 00:00:00 1970 From: David.Laight@ACULAB.COM (David Laight) Date: Mon, 9 Jun 2014 13:43:56 +0000 Subject: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void In-Reply-To: <5395B379.2010706@samsung.com> References: <20140530094025.3b78301e@canb.auug.org.au> <1401449454-30895-1-git-send-email-berthe.ab@gmail.com> <1401449454-30895-2-git-send-email-berthe.ab@gmail.com> <5388C0F1.90503@gmail.com> <5388CB1B.3090802@metafoo.de> <20140608231823.GB10112@trinity.fluff.org> <53959A93.7080308@metafoo.de> <5395B379.2010706@samsung.com> Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org From: Of Andrzej Hajda ... > > You can't error out on module unload, although that's not really relevant > > here. gpiochip_remove() is typically called when the device that registered > > the GPIO chip is unbound. And despite some remove() callbacks having a > > return type of int you can not abort the removal of a device. > > It is a design flaw in many subsystems having providers and consumers, > not only GPIO. The same situation is with clock providers, regulators, > phys, drm_panels, ..., at least it was such last time I have tested it. > > The problem is that many frameworks assumes that lifetime of provider is > always bigger than lifetime of its consumers, and this is wrong > assumption - usually it is not possible to prevent unbinding driver from > device, so if the device is a provider there is no way to inform > consumers about his removal. > > Some solution for such problems is to use some kind of availability > callbacks for requesting resources (gpios, clocks, regulators,...) > instead of simple 'getters' (clk_get, gpiod_get). Callbacks should > guarantee that the resource is always valid between callback reporting > its availability and callback reporting its removal. Such approach seems > to be complicated at the first sight but it should allow to make the > code safe and as a bonus it will allow to avoid deferred probing. > Btw I have send already RFC for such framework [1]. Callbacks for delete are generally a locking nightmare. A two-way handshake is also usually needed to avoid problems with concurrent disconnect requests. David