From: David Laight <David.Laight@ACULAB.COM>
To: 'Andrzej Hajda' <a.hajda@samsung.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Ben Dooks <ben@trinity.fluff.org>
Cc: driverdevel <devel@driverdev.osuosl.org>,
Linux MIPS Mailing List <linux-mips@linux-mips.org>,
"spear-devel@list.st.com" <spear-devel@list.st.com>,
David Daney <ddaney.cavm@gmail.com>,
Linux-sh list <linux-sh@vger.kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
"patches@opensource.wolfsonmicro.com"
<patches@opensource.wolfsonmicro.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>, "m@bues.ch" <m@bues.ch>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
linux-samsungsoc@vger.kerne
Subject: RE: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
Date: Mon, 9 Jun 2014 13:43:56 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com> (raw)
In-Reply-To: <5395B379.2010706@samsung.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andrzej Hajda' <a.hajda@samsung.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Ben Dooks <ben@trinity.fluff.org>
Cc: Linux MIPS Mailing List <linux-mips@linux-mips.org>,
"m@bues.ch" <m@bues.ch>, Linux-sh list <linux-sh@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
driverdevel <devel@driverdev.osuosl.org>,
Alexandre Courbot <gnurou@gmail.com>,
"patches@opensource.wolfsonmicro.com"
<patches@opensource.wolfsonmicro.com>,
"linux-samsungsoc@vger.kernel.org"
<linux-samsungsoc@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
"spear-devel@list.st.com" <spear-devel@list.st.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
David Daney <ddaney.cavm@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
Date: Mon, 9 Jun 2014 13:43:56 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com> (raw)
In-Reply-To: <5395B379.2010706@samsung.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: David Laight <David.Laight@ACULAB.COM>
To: 'Andrzej Hajda' <a.hajda@samsung.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Ben Dooks <ben@trinity.fluff.org>
Cc: Linux MIPS Mailing List <linux-mips@linux-mips.org>,
"m@bues.ch" <m@bues.ch>, Linux-sh list <linux-sh@vger.kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
driverdevel <devel@driverdev.osuosl.org>,
Alexandre Courbot <gnurou@gmail.com>,
"patches@opensource.wolfsonmicro.com"
<patches@opensource.wolfsonmicro.com>,
"linux-samsungsoc@vger.kernel.org"
<linux-samsungsoc@vger.kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"linux-input@vger.kernel.org" <linux-input@vger.kernel.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
"spear-devel@list.st.com" <spear-devel@list.st.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
David Daney <ddaney.cavm@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
linux-wireless <linux-wireless@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
Date: Mon, 9 Jun 2014 13:43:56 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com> (raw)
Message-ID: <20140609134356.vcRn3PVF5hpWLJBIx3Rk6CAQjFASRouzWSu0_TfMOcQ@z> (raw)
In-Reply-To: <5395B379.2010706@samsung.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: David.Laight@ACULAB.COM (David Laight)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void
Date: Mon, 9 Jun 2014 13:43:56 +0000 [thread overview]
Message-ID: <063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com> (raw)
In-Reply-To: <5395B379.2010706@samsung.com>
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
next prev parent reply other threads:[~2014-06-09 13:43 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-29 21:54 [PATCH] gpio: removes all usage of gpiochip_remove retval abdoulaye berthe
2014-05-29 21:54 ` abdoulaye berthe
2014-05-29 21:54 ` abdoulaye berthe
2014-05-29 22:14 ` David Daney
2014-05-29 22:14 ` David Daney
2014-05-29 22:14 ` David Daney
2014-05-29 22:14 ` David Daney
2014-05-29 23:16 ` abdoulaye berthe
2014-05-29 23:16 ` abdoulaye berthe
2014-05-29 23:40 ` Stephen Rothwell
2014-05-29 23:40 ` Stephen Rothwell
2014-05-29 23:40 ` Stephen Rothwell
2014-05-29 23:40 ` Stephen Rothwell
2014-05-30 11:30 ` [PATCH 1/2] " abdoulaye berthe
2014-05-30 11:30 ` abdoulaye berthe
2014-05-30 11:30 ` abdoulaye berthe
2014-05-30 11:30 ` [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void abdoulaye berthe
2014-05-30 11:30 ` abdoulaye berthe
2014-05-30 11:30 ` abdoulaye berthe
2014-05-30 11:39 ` Geert Uytterhoeven
2014-05-30 11:39 ` Geert Uytterhoeven
2014-05-30 11:39 ` Geert Uytterhoeven
2014-05-30 11:39 ` Geert Uytterhoeven
2014-05-30 11:39 ` Geert Uytterhoeven
2014-05-30 11:39 ` Geert Uytterhoeven
2014-05-30 11:39 ` Geert Uytterhoeven
2014-05-30 15:48 ` Ralf Baechle
2014-05-30 15:48 ` Ralf Baechle
2014-05-30 15:48 ` Ralf Baechle
2014-05-30 15:48 ` Ralf Baechle
2014-05-30 15:48 ` Ralf Baechle
2014-05-30 15:48 ` Ralf Baechle
2014-05-30 15:48 ` Ralf Baechle
2014-05-30 17:33 ` David Daney
2014-05-30 17:33 ` David Daney
2014-05-30 17:33 ` David Daney
2014-05-30 17:33 ` David Daney
2014-05-30 17:33 ` David Daney
2014-05-30 17:33 ` David Daney
2014-05-30 18:16 ` Lars-Peter Clausen
2014-05-30 18:16 ` Lars-Peter Clausen
2014-05-30 18:16 ` Lars-Peter Clausen
2014-05-30 18:16 ` Lars-Peter Clausen
2014-05-30 18:16 ` Lars-Peter Clausen
2014-05-30 18:16 ` Lars-Peter Clausen
2014-05-30 23:29 ` Greg KH
2014-05-30 23:29 ` Greg KH
2014-05-30 23:29 ` Greg KH
2014-05-30 23:29 ` Greg KH
2014-05-30 23:29 ` Greg KH
2014-05-30 23:29 ` Greg KH
2014-05-31 7:35 ` Lars-Peter Clausen
2014-05-31 7:35 ` Lars-Peter Clausen
2014-05-31 7:35 ` Lars-Peter Clausen
2014-05-31 7:35 ` Lars-Peter Clausen
2014-05-31 7:35 ` Lars-Peter Clausen
2014-05-31 7:35 ` Lars-Peter Clausen
2014-05-31 12:19 ` Dan Carpenter
2014-05-31 12:19 ` Dan Carpenter
2014-05-31 12:19 ` Dan Carpenter
2014-05-31 12:19 ` Dan Carpenter
2014-05-31 12:19 ` Dan Carpenter
2014-06-08 23:18 ` Ben Dooks
2014-06-08 23:18 ` Ben Dooks
2014-06-08 23:18 ` Ben Dooks
2014-06-08 23:18 ` Ben Dooks
2014-06-08 23:18 ` Ben Dooks
2014-06-08 23:18 ` Ben Dooks
2014-06-09 11:29 ` Lars-Peter Clausen
2014-06-09 11:29 ` Lars-Peter Clausen
2014-06-09 11:29 ` Lars-Peter Clausen
2014-06-09 11:29 ` Lars-Peter Clausen
2014-06-09 11:29 ` Lars-Peter Clausen
2014-06-09 13:15 ` Andrzej Hajda
2014-06-09 13:15 ` Andrzej Hajda
2014-06-09 13:15 ` Andrzej Hajda
2014-06-09 13:15 ` Andrzej Hajda
2014-06-09 13:15 ` Andrzej Hajda
2014-06-09 13:43 ` David Laight [this message]
2014-06-09 13:43 ` David Laight
2014-06-09 13:43 ` David Laight
2014-06-09 13:43 ` David Laight
2014-06-10 6:57 ` Andrzej Hajda
2014-06-10 6:57 ` Andrzej Hajda
2014-06-10 6:57 ` Andrzej Hajda
2014-06-10 6:57 ` Andrzej Hajda
2014-06-10 6:57 ` Andrzej Hajda
2014-05-30 11:37 ` [PATCH 1/2] gpio: removes all usage of gpiochip_remove retval abdoulaye berthe
2014-05-30 11:37 ` [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void abdoulaye berthe
2014-05-30 15:59 ` [PATCH 1/2] gpio: removes all usage of gpiochip_remove retval Alexandre Courbot
2014-06-04 18:22 ` [PATCH 0/2] gpiochip remove abdoulaye berthe
2014-06-04 18:22 ` [PATCH 1/2] gpio: removes all usage of gpiochip_remove retval abdoulaye berthe
2014-07-04 22:35 ` Linus Walleij
2014-07-05 16:28 ` [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void abdoulaye berthe
2014-07-05 20:28 ` [PATCH] gpio: removes all usage of gpiochip_remove retval abdoulaye berthe
2014-07-09 7:45 ` Linus Walleij
2014-07-12 20:30 ` [PATCH 0/3] remove all usage of gpio_remove retval abdoulaye berthe
2014-07-12 20:30 ` [PATCH 1/1] gpio: remove all usage of gpio_remove retval in driver/gpio abdoulaye berthe
2014-07-12 20:30 ` [PATCH 2/2] pinctrl: remove all usage of gpio_remove ret val in driver/pinctl abdoulaye berthe
2014-07-22 14:34 ` Linus Walleij
2014-07-12 20:30 ` [PATCH 3/3] driver:gpio remove all usage of gpio_remove retval in driver abdoulaye berthe
2014-07-22 15:08 ` Linus Walleij
2014-07-22 15:08 ` Linus Walleij
2014-07-22 15:08 ` Linus Walleij
2014-07-22 15:11 ` Mark Brown
2014-07-22 15:11 ` Mark Brown
2014-07-24 8:29 ` Linus Walleij
2014-07-24 8:29 ` Linus Walleij
2014-07-22 15:17 ` Michael Büsch
2014-07-22 15:17 ` Michael Büsch
2014-07-22 16:01 ` Lee Jones
2014-07-22 16:01 ` Lee Jones
2014-07-22 17:51 ` Dmitry Torokhov
2014-07-22 17:51 ` Dmitry Torokhov
2014-07-22 19:17 ` Mauro Carvalho Chehab
2014-07-22 19:17 ` Mauro Carvalho Chehab
2014-07-29 11:30 ` Tomi Valkeinen
2014-07-29 11:30 ` Tomi Valkeinen
2014-07-29 11:30 ` Tomi Valkeinen
2014-06-04 18:22 ` [PATCH 2/2] gpio: gpiolib: set gpiochip_remove retval to void abdoulaye berthe
2014-06-08 12:12 ` Alexandre Courbot
2014-06-09 21:22 ` abdoulaye berthe
2014-07-04 22:55 ` Linus Walleij
2014-06-04 18:35 ` [PATCH 0/2] gpiochip remove abdoulaye berthe
2014-05-29 23:25 ` [PATCH] gpio: removes all usage of gpiochip_remove retval Greg KH
2014-05-29 23:25 ` Greg KH
2014-05-29 23:25 ` Greg KH
2014-05-29 23:25 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=063D6719AE5E284EB5DD2968C1650D6D17259A1F@AcuExch.aculab.com \
--to=david.laight@aculab.com \
--cc=a.hajda@samsung.com \
--cc=ben@trinity.fluff.org \
--cc=ddaney.cavm@gmail.com \
--cc=devel@driverdev.osuosl.org \
--cc=geert@linux-m68k.org \
--cc=lars@metafoo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-samsungsoc@vger.kerne \
--cc=linux-sh@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=m@bues.ch \
--cc=netdev@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=spear-devel@list.st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.