From: Lars-Peter Clausen <lars@metafoo.de>
To: Thierry Reding <thierry.reding@gmail.com>,
Mark Brown <broonie@kernel.org>
Cc: Alexandre Courbot <gnurou@gmail.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Rojhalat Ibrahim <imr@rtschenk.de>, Arnd Bergmann <arnd@arndb.de>,
Tomasz Figa <t.figa@samsung.com>,
Maurus Cuelenaere <mcuelenaere@gmail.com>,
Liam Girdwood <lgirdwood@gmail.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
Kukjin Kim <kgene.kim@samsung.com>,
Rob Jones <rob.jones@codethink.co.uk>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [alsa-devel] [PATCH 2/4] ASoC: s3c64xx/smartq: use dynamic registration
Date: Thu, 17 Jul 2014 12:58:25 +0200 [thread overview]
Message-ID: <53C7AC51.6060200@metafoo.de> (raw)
In-Reply-To: <20140717104121.GF17877@ulmo>
On 07/17/2014 12:41 PM, Thierry Reding wrote:
> On Thu, Jul 17, 2014 at 11:17:23AM +0100, Mark Brown wrote:
>> On Thu, Jul 17, 2014 at 05:55:36PM +0900, Alexandre Courbot wrote:
>>
>>> Right. It may very well be that a single flag specifier (as opposed to
>>> an array) will be enough for this case. If you need to request some
>>> GPIOs as input and some other as output then they are clearly
>>> different functions and requesting them together would be an abuse of
>>> the API.
>>
>> Not so sure about that - what about requesting GPIOs for a bidirectional
>> bus? Thinking about SPI bitbanging here.
>
> Wouldn't you want to use a different means that the gpiod_array_*() API
> to handle those cases? gpiod_array_*() is probably most useful to handle
> bulk operations on a set of GPIOs that do essentially the same thing. If
> you get and then need to index into that array to handle them all
> differently then you don't gain very much.
I think the goal of a gpiod_array_* API should be to make requesting
multiple GPIOs that are used by a driver as convenient as possible and at
the same time reduce the amount of boiler plate code necessary. E.g compare
gpios[0] = gpio_get(...);
if (IS_ERR(gpios[0])) {
ret = PTR_ERR(gpios[0]);
goto cleanup;
}
gpios[1] = gpio_get(...);
if (IS_ERR(gpios[1])) {
ret = PTR_ERR(gpios[1]);
goto cleanup;
}
gpios[2] = gpio_get(...);
if (IS_ERR(gpios[2])) {
ret = PTR_ERR(gpioss[2]);
goto cleanup;
}
with
ret = gpio_array_get(..., gpios);
if (ret)
goto err_cleanup;
- Lars
WARNING: multiple messages have this Message-ID (diff)
From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [alsa-devel] [PATCH 2/4] ASoC: s3c64xx/smartq: use dynamic registration
Date: Thu, 17 Jul 2014 12:58:25 +0200 [thread overview]
Message-ID: <53C7AC51.6060200@metafoo.de> (raw)
In-Reply-To: <20140717104121.GF17877@ulmo>
On 07/17/2014 12:41 PM, Thierry Reding wrote:
> On Thu, Jul 17, 2014 at 11:17:23AM +0100, Mark Brown wrote:
>> On Thu, Jul 17, 2014 at 05:55:36PM +0900, Alexandre Courbot wrote:
>>
>>> Right. It may very well be that a single flag specifier (as opposed to
>>> an array) will be enough for this case. If you need to request some
>>> GPIOs as input and some other as output then they are clearly
>>> different functions and requesting them together would be an abuse of
>>> the API.
>>
>> Not so sure about that - what about requesting GPIOs for a bidirectional
>> bus? Thinking about SPI bitbanging here.
>
> Wouldn't you want to use a different means that the gpiod_array_*() API
> to handle those cases? gpiod_array_*() is probably most useful to handle
> bulk operations on a set of GPIOs that do essentially the same thing. If
> you get and then need to index into that array to handle them all
> differently then you don't gain very much.
I think the goal of a gpiod_array_* API should be to make requesting
multiple GPIOs that are used by a driver as convenient as possible and at
the same time reduce the amount of boiler plate code necessary. E.g compare
gpios[0] = gpio_get(...);
if (IS_ERR(gpios[0])) {
ret = PTR_ERR(gpios[0]);
goto cleanup;
}
gpios[1] = gpio_get(...);
if (IS_ERR(gpios[1])) {
ret = PTR_ERR(gpios[1]);
goto cleanup;
}
gpios[2] = gpio_get(...);
if (IS_ERR(gpios[2])) {
ret = PTR_ERR(gpioss[2]);
goto cleanup;
}
with
ret = gpio_array_get(..., gpios);
if (ret)
goto err_cleanup;
- Lars
next prev parent reply other threads:[~2014-07-17 10:58 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-11 13:45 [PATCH] ASoC: s3c64xx/smartq: use dynamic registration Arnd Bergmann
2014-07-11 13:45 ` Arnd Bergmann
2014-07-11 13:45 ` [PATCH 0/4] ASoC: samsung updates from arm testing Arnd Bergmann
2014-07-11 13:45 ` Arnd Bergmann
2014-07-11 13:54 ` Mark Brown
2014-07-11 13:54 ` Mark Brown
2014-07-12 12:35 ` Arnd Bergmann
2014-07-12 12:35 ` Arnd Bergmann
2014-07-11 13:45 ` [PATCH 1/4] ASoC: samsung: add explicit i2c/spi dependencies Arnd Bergmann
2014-07-11 13:45 ` Arnd Bergmann
2014-07-14 18:51 ` Mark Brown
2014-07-14 18:51 ` Mark Brown
2014-07-11 13:45 ` [PATCH 2/4] ASoC: s3c64xx/smartq: use dynamic registration Arnd Bergmann
2014-07-11 13:45 ` Arnd Bergmann
2014-07-12 15:27 ` Lars-Peter Clausen
2014-07-12 15:27 ` [alsa-devel] " Lars-Peter Clausen
2014-07-12 19:49 ` Mark Brown
2014-07-12 19:49 ` [alsa-devel] " Mark Brown
2014-07-13 13:36 ` Lars-Peter Clausen
2014-07-13 13:36 ` [alsa-devel] " Lars-Peter Clausen
2014-07-14 12:15 ` Arnd Bergmann
2014-07-14 12:15 ` [alsa-devel] " Arnd Bergmann
2014-07-14 12:40 ` Lars-Peter Clausen
2014-07-14 12:40 ` [alsa-devel] " Lars-Peter Clausen
2014-07-14 15:46 ` Arnd Bergmann
2014-07-14 15:46 ` [alsa-devel] " Arnd Bergmann
2014-07-14 16:18 ` Lars-Peter Clausen
2014-07-14 16:18 ` [alsa-devel] " Lars-Peter Clausen
2014-07-14 18:23 ` Arnd Bergmann
2014-07-14 18:23 ` [alsa-devel] " Arnd Bergmann
2014-07-14 18:32 ` Lars-Peter Clausen
2014-07-14 18:32 ` [alsa-devel] " Lars-Peter Clausen
2014-07-14 18:36 ` Mark Brown
2014-07-14 18:36 ` [alsa-devel] " Mark Brown
2014-07-15 7:19 ` Arnd Bergmann
2014-07-15 7:19 ` Arnd Bergmann
2014-07-15 7:36 ` Alexandre Courbot
2014-07-15 7:36 ` Alexandre Courbot
2014-07-15 7:58 ` Lars-Peter Clausen
2014-07-15 7:58 ` [alsa-devel] " Lars-Peter Clausen
2014-07-15 9:14 ` Alexandre Courbot
2014-07-15 9:14 ` Alexandre Courbot
2014-07-16 3:00 ` Alexandre Courbot
2014-07-16 3:00 ` Alexandre Courbot
2014-07-16 7:12 ` Thierry Reding
2014-07-16 7:12 ` Thierry Reding
2014-07-16 7:28 ` Alexandre Courbot
2014-07-16 7:28 ` Alexandre Courbot
2014-07-16 7:51 ` Thierry Reding
2014-07-16 7:51 ` Thierry Reding
2014-07-16 8:50 ` Rob Jones
2014-07-16 8:50 ` Rob Jones
2014-07-16 11:09 ` Thierry Reding
2014-07-16 11:09 ` Thierry Reding
2014-07-23 15:20 ` Linus Walleij
2014-07-23 15:20 ` Linus Walleij
2014-07-17 4:28 ` Alexandre Courbot
2014-07-17 4:28 ` Alexandre Courbot
2014-07-17 7:44 ` Thierry Reding
2014-07-17 7:44 ` Thierry Reding
2014-07-17 8:55 ` Alexandre Courbot
2014-07-17 8:55 ` Alexandre Courbot
2014-07-17 10:17 ` Mark Brown
2014-07-17 10:17 ` Mark Brown
2014-07-17 10:41 ` Thierry Reding
2014-07-17 10:41 ` Thierry Reding
2014-07-17 10:58 ` Lars-Peter Clausen [this message]
2014-07-17 10:58 ` Lars-Peter Clausen
2014-07-17 11:05 ` Mark Brown
2014-07-17 11:05 ` Mark Brown
2014-07-21 3:36 ` Alexandre Courbot
2014-07-21 3:36 ` Alexandre Courbot
2014-07-21 10:04 ` Mark Brown
2014-07-21 10:04 ` [alsa-devel] " Mark Brown
2014-07-21 14:19 ` Alexandre Courbot
2014-07-21 14:19 ` Alexandre Courbot
2014-07-16 9:48 ` Mark Brown
2014-07-16 9:48 ` Mark Brown
2014-07-24 15:10 ` Alexandre Courbot
2014-07-24 15:10 ` Alexandre Courbot
2014-07-15 10:39 ` Mark Brown
2014-07-15 10:39 ` Mark Brown
2014-07-14 15:58 ` Mark Brown
2014-07-14 15:58 ` [alsa-devel] " Mark Brown
2014-07-11 13:45 ` [PATCH 2/4] ASoC: samsung/smartq: " Arnd Bergmann
2014-07-11 13:45 ` Arnd Bergmann
2014-07-11 13:45 ` [PATCH 3/4] ASoC: samsung: s3c24xx dmaengine follow-up Arnd Bergmann
2014-07-11 13:45 ` Arnd Bergmann
2014-07-14 18:51 ` Mark Brown
2014-07-14 18:51 ` Mark Brown
2014-07-11 13:45 ` [PATCH 4/4] ASoC: samsung: remove unused DMA data Arnd Bergmann
2014-07-11 13:45 ` Arnd Bergmann
2014-07-14 18:54 ` Mark Brown
2014-07-14 18:54 ` Mark Brown
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=53C7AC51.6060200@metafoo.de \
--to=lars@metafoo.de \
--cc=alsa-devel@alsa-project.org \
--cc=arnd@arndb.de \
--cc=broonie@kernel.org \
--cc=gnurou@gmail.com \
--cc=imr@rtschenk.de \
--cc=kgene.kim@samsung.com \
--cc=lgirdwood@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mcuelenaere@gmail.com \
--cc=rob.jones@codethink.co.uk \
--cc=t.figa@samsung.com \
--cc=thierry.reding@gmail.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.