From: Rob Jones <rob.jones@codethink.co.uk>
To: Julia Lawall <julia.lawall@lip6.fr>
Cc: Himangi Saraogi <himangi774@gmail.com>,
Linus Walleij <linus.walleij@linaro.org>,
Alexandre Courbot <gnurou@gmail.com>,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
Randy Dunlap <rdunlap@infradead.org>,
linux-doc@vger.kernel.org, Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.de>,
patches@opensource.wolfsonmicro.com, alsa-devel@alsa-project.org,
Eric Miao <eric.y.miao@gmail.com>,
Russell King <linux@arm.linux.org.uk>,
Haojian Zhuang <haojian.zhuang@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Philipp Zabel <philipp.zabel@gmail.com>,
Paul Parsons <lost.distance@yahoo.com>
Subject: Re: [PATCH 1/5] gpiolib: devres: Introduce the function devm_request_gpio_array
Date: Wed, 09 Jul 2014 13:48:29 +0100 [thread overview]
Message-ID: <53BD3A1D.8060401@codethink.co.uk> (raw)
In-Reply-To: <alpine.DEB.2.10.1407091351530.2375@hadrien>
On 09/07/14 12:52, Julia Lawall wrote:
>
>
> On Wed, 9 Jul 2014, Rob Jones wrote:
>
>> Please note that I submitted a patch on 02/07/14 to create this
>> function which was acked by Linus Walleij on 05/07/14.
>>
>> Great minds think alike, and all that.
>>
>> However, I think that the version I submitted better replicates the
>> original (non devm) functionality, see below.
<snip>
>>> +int devm_gpio_request_array(struct device *dev, const struct gpio *array,
>>> + size_t num)
>>> +{
>>> + int i, err;
>>> +
>>> + for (i = 0; i < num; i++, array++) {
>>> + err = devm_gpio_request_one(dev, array->gpio, array->flags,
>>> + array->label);
>>> + if (err)
>>> + return err;
>>
>> The failure path in the version I submitted frees up any already
>> allocated gpios on the first failure.
>
> Himangi first proposed doing that, but I thought it was not really in the
> spirit of devm functions, which is to leave that implicit. No strong
> opinion on the matter, though.
>
Interestingly, we came at it from the other direction: I originally
didn't have the unwind in and our internal review guys suggested that
it was in the original function so putting it in would:
1. make this a better analogue of the original
2. help avoid deadlocks
3. allow the driver to retry, perhaps requesting reduced functionality.
> julia
>
<snip>
--
Rob Jones
Codethink Ltd
mailto:rob.jones@codethink.co.uk
tel:+44 161 236 5575
WARNING: multiple messages have this Message-ID (diff)
From: rob.jones@codethink.co.uk (Rob Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/5] gpiolib: devres: Introduce the function devm_request_gpio_array
Date: Wed, 09 Jul 2014 13:48:29 +0100 [thread overview]
Message-ID: <53BD3A1D.8060401@codethink.co.uk> (raw)
In-Reply-To: <alpine.DEB.2.10.1407091351530.2375@hadrien>
On 09/07/14 12:52, Julia Lawall wrote:
>
>
> On Wed, 9 Jul 2014, Rob Jones wrote:
>
>> Please note that I submitted a patch on 02/07/14 to create this
>> function which was acked by Linus Walleij on 05/07/14.
>>
>> Great minds think alike, and all that.
>>
>> However, I think that the version I submitted better replicates the
>> original (non devm) functionality, see below.
<snip>
>>> +int devm_gpio_request_array(struct device *dev, const struct gpio *array,
>>> + size_t num)
>>> +{
>>> + int i, err;
>>> +
>>> + for (i = 0; i < num; i++, array++) {
>>> + err = devm_gpio_request_one(dev, array->gpio, array->flags,
>>> + array->label);
>>> + if (err)
>>> + return err;
>>
>> The failure path in the version I submitted frees up any already
>> allocated gpios on the first failure.
>
> Himangi first proposed doing that, but I thought it was not really in the
> spirit of devm functions, which is to leave that implicit. No strong
> opinion on the matter, though.
>
Interestingly, we came at it from the other direction: I originally
didn't have the unwind in and our internal review guys suggested that
it was in the original function so putting it in would:
1. make this a better analogue of the original
2. help avoid deadlocks
3. allow the driver to retry, perhaps requesting reduced functionality.
> julia
>
<snip>
--
Rob Jones
Codethink Ltd
mailto:rob.jones at codethink.co.uk
tel:+44 161 236 5575
next prev parent reply other threads:[~2014-07-09 12:48 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-06 17:46 [PATCH 0/5] Introduce a managed function for gpio_request_array Himangi Saraogi
2014-07-06 17:46 ` Himangi Saraogi
2014-07-06 17:47 ` [PATCH 1/5] gpiolib: devres: Introduce the function devm_request_gpio_array Himangi Saraogi
2014-07-06 17:47 ` Himangi Saraogi
2014-07-09 11:18 ` Rob Jones
2014-07-09 11:18 ` Rob Jones
2014-07-09 11:52 ` Julia Lawall
2014-07-09 11:52 ` Julia Lawall
2014-07-09 12:48 ` Rob Jones [this message]
2014-07-09 12:48 ` Rob Jones
2014-07-10 9:21 ` Linus Walleij
2014-07-10 9:21 ` Linus Walleij
2014-07-10 11:01 ` Rob Jones
2014-07-10 11:01 ` Rob Jones
2014-07-11 0:35 ` Javier Martinez Canillas
2014-07-11 0:35 ` Javier Martinez Canillas
2014-07-11 0:35 ` Javier Martinez Canillas
2014-07-11 10:03 ` Rob Jones
2014-07-11 10:03 ` Rob Jones
2014-07-11 10:03 ` Rob Jones
2014-07-11 10:07 ` Javier Martinez Canillas
2014-07-11 10:07 ` Javier Martinez Canillas
2014-07-11 10:07 ` Javier Martinez Canillas
2014-08-14 15:17 ` Rob Jones
2014-08-14 15:17 ` Rob Jones
2014-08-14 15:17 ` Rob Jones
2014-07-06 17:48 ` [PATCH 2/5] ASoC: wm1250-ev1: Use devm_gpio_request_array Himangi Saraogi
2014-07-06 17:48 ` Himangi Saraogi
2014-07-06 17:49 ` [PATCH 3/5] ASoC: pxa: " Himangi Saraogi
2014-07-06 17:49 ` Himangi Saraogi
2014-07-06 17:51 ` [PATCH 4/5] ASoC: pxa: e800_wm9712: Introduce the use of devm_gpio_request_array Himangi Saraogi
2014-07-06 17:51 ` Himangi Saraogi
2014-07-06 17:52 ` [PATCH 5/5] ASoC: pxa/hx4700: " Himangi Saraogi
2014-07-06 17:52 ` Himangi Saraogi
2014-07-09 10:14 ` [PATCH 0/5] Introduce a managed function for gpio_request_array Linus Walleij
2014-07-09 10:14 ` Linus Walleij
2014-07-09 12:10 ` Alexandre Courbot
2014-07-09 12:10 ` Alexandre Courbot
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=53BD3A1D.8060401@codethink.co.uk \
--to=rob.jones@codethink.co.uk \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=eric.y.miao@gmail.com \
--cc=gnurou@gmail.com \
--cc=haojian.zhuang@gmail.com \
--cc=himangi774@gmail.com \
--cc=julia.lawall@lip6.fr \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=lost.distance@yahoo.com \
--cc=patches@opensource.wolfsonmicro.com \
--cc=perex@perex.cz \
--cc=philipp.zabel@gmail.com \
--cc=rdunlap@infradead.org \
--cc=tiwai@suse.de \
/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.