All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: Grant Likely <grant.likely@secretlab.ca>,
	Linus Walleij <linus.walleij@linaro.org>,
	Guenter Roeck <linux@roeck-us.net>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	devicetree-discuss@lists.ozlabs.org,
	Alexandre Courbot <gnurou@gmail.com>
Subject: Re: [PATCH 0/4] gpio: introduce descriptor-based interface
Date: Tue, 8 Jan 2013 13:06:02 +0000	[thread overview]
Message-ID: <201301081306.02942.arnd@arndb.de> (raw)
In-Reply-To: <1357629535-26033-1-git-send-email-acourbot@nvidia.com>

On Tuesday 08 January 2013, Alexandre Courbot wrote:
> This series introduce a first take at implementing the RFC for the new GPIO API
> that I submitted last month. It proposes a new, opaque descriptor-based GPIO API
> that becomes available when GPIOlib is compiled, and provides a safer, more
> abstract alternative to the current integer-based interface. GPIOlib internals
> are also switched to use the descriptor logic, and the former integer API
> becomes a lightweight wrapper around the new descriptor-based API.
> 
> Functionally speaking the new API is identical to the integer-based API, with
> only the prefix changing from gpio_ to gpiod_. However, the second patch
> introduces new functions for obtaining GPIOs from a device and a consumer name,
> in a fashion similar to what is done with e.g. regulators and PWMs.

I like the interface, good idea!

A few questions:

Is there a plan for migrating all the existing users of the current GPIO
interface?

How do you want to deal with drivers that work on platforms that currently
don't use gpiolib but have their own implementation of asm/gpio.h? Are
we going to phase them out?

If we are adding a new way to deal with GPIOs, would it make sense to
have that more closely integrated into pinctrl in one form or another?
My feeling is that there is already a significant overlap between the
two, and while the addition of the gpiod_* functions doesn't necessarily
make this worse, it could be a chance to improve the current situation
to make the interface more consistent with pinctrl.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] gpio: introduce descriptor-based interface
Date: Tue, 8 Jan 2013 13:06:02 +0000	[thread overview]
Message-ID: <201301081306.02942.arnd@arndb.de> (raw)
In-Reply-To: <1357629535-26033-1-git-send-email-acourbot@nvidia.com>

On Tuesday 08 January 2013, Alexandre Courbot wrote:
> This series introduce a first take at implementing the RFC for the new GPIO API
> that I submitted last month. It proposes a new, opaque descriptor-based GPIO API
> that becomes available when GPIOlib is compiled, and provides a safer, more
> abstract alternative to the current integer-based interface. GPIOlib internals
> are also switched to use the descriptor logic, and the former integer API
> becomes a lightweight wrapper around the new descriptor-based API.
> 
> Functionally speaking the new API is identical to the integer-based API, with
> only the prefix changing from gpio_ to gpiod_. However, the second patch
> introduces new functions for obtaining GPIOs from a device and a consumer name,
> in a fashion similar to what is done with e.g. regulators and PWMs.

I like the interface, good idea!

A few questions:

Is there a plan for migrating all the existing users of the current GPIO
interface?

How do you want to deal with drivers that work on platforms that currently
don't use gpiolib but have their own implementation of asm/gpio.h? Are
we going to phase them out?

If we are adding a new way to deal with GPIOs, would it make sense to
have that more closely integrated into pinctrl in one form or another?
My feeling is that there is already a significant overlap between the
two, and while the addition of the gpiod_* functions doesn't necessarily
make this worse, it could be a chance to improve the current situation
to make the interface more consistent with pinctrl.

	Arnd

  parent reply	other threads:[~2013-01-08 13:06 UTC|newest]

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-08  7:18 [PATCH 0/4] gpio: introduce descriptor-based interface Alexandre Courbot
2013-01-08  7:18 ` Alexandre Courbot
2013-01-08  7:18 ` Alexandre Courbot
2013-01-08  7:18 ` [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08 12:59   ` Arnd Bergmann
2013-01-08 12:59     ` Arnd Bergmann
2013-01-09  1:06     ` Alexandre Courbot
2013-01-09  1:06       ` Alexandre Courbot
2013-01-09 10:25       ` Russell King - ARM Linux
2013-01-09 10:25         ` Russell King - ARM Linux
2013-01-09 10:35       ` Arnd Bergmann
2013-01-09 10:35         ` Arnd Bergmann
2013-01-09 10:44         ` Russell King - ARM Linux
2013-01-09 10:44           ` Russell King - ARM Linux
2013-01-09 11:10           ` Russell King - ARM Linux
2013-01-09 11:10             ` Russell King - ARM Linux
     [not found]             ` <20130109111055.GG3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-09 11:52               ` Arnd Bergmann
2013-01-09 11:52                 ` Arnd Bergmann
2013-01-09 11:52                 ` Arnd Bergmann
2013-01-09 14:44             ` Nicolas Pitre
2013-01-09 14:44               ` Nicolas Pitre
2013-01-09 15:04               ` [PATCH] Proposed removal of IS_ERR_OR_NULL() (was: Re: [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface) Russell King - ARM Linux
2013-01-09 15:04                 ` Russell King - ARM Linux
     [not found]                 ` <20130109150427.GL3931-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2013-01-09 15:21                   ` Grant Likely
2013-01-09 15:21                     ` Grant Likely
2013-01-09 15:21                     ` Grant Likely
2013-01-09 15:26                     ` Arnd Bergmann
2013-01-09 15:26                       ` Arnd Bergmann
2013-01-09 15:27                 ` Nicolas Pitre
2013-01-09 15:27                   ` Nicolas Pitre
2013-01-09 15:51                   ` Russell King - ARM Linux
2013-01-09 15:51                     ` Russell King - ARM Linux
2013-01-09 16:09                     ` Nicolas Pitre
2013-01-09 16:09                       ` Nicolas Pitre
2013-01-09 16:21                       ` Russell King - ARM Linux
2013-01-09 16:21                         ` Russell King - ARM Linux
2013-01-09 17:12                         ` Russell King - ARM Linux
2013-01-09 17:12                           ` Russell King - ARM Linux
2013-01-09 17:52                           ` Tony Lindgren
2013-01-09 17:52                             ` Tony Lindgren
2013-01-17 10:28                 ` Linus Walleij
2013-01-17 10:28                   ` Linus Walleij
2013-01-10  8:36             ` [PATCH 1/4] gpiolib: introduce descriptor-based GPIO interface Thierry Reding
2013-01-10  8:36               ` Thierry Reding
2013-01-08  7:18 ` [PATCH 2/4] gpiolib: add gpiod_get and gpiod_put functions Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08 13:07   ` Arnd Bergmann
2013-01-08 13:07     ` Arnd Bergmann
2013-01-09  1:49     ` Alexandre Courbot
2013-01-09  1:49       ` Alexandre Courbot
2013-01-08  7:18 ` [PATCH 3/4] gpiolib: of: convert OF helpers to descriptor API Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08  7:18 ` [PATCH 4/4] gpiolib: add documentation for new gpiod_ API Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08  7:18   ` Alexandre Courbot
2013-01-08 13:06 ` Arnd Bergmann [this message]
2013-01-08 13:06   ` [PATCH 0/4] gpio: introduce descriptor-based interface Arnd Bergmann
2013-01-09  1:48   ` Alexandre Courbot
2013-01-09  1:48     ` Alexandre Courbot
2013-01-09 10:46     ` Arnd Bergmann
2013-01-09 10:46       ` Arnd Bergmann
2013-01-10  4:07       ` Alex Courbot
2013-01-10  4:07         ` Alex Courbot
2013-01-10 10:08         ` Arnd Bergmann
2013-01-10 10:08           ` Arnd Bergmann
2013-01-14 10:21           ` Alex Courbot
2013-01-14 10:21             ` Alex Courbot
2013-01-14 10:21             ` Alex Courbot
2013-01-14 10:46             ` Arnd Bergmann
2013-01-14 10:46               ` Arnd Bergmann
2013-01-14 10:46               ` Arnd Bergmann
2013-01-14 10:21           ` Alex Courbot
2013-01-17 11:15           ` Linus Walleij
2013-01-17 11:15             ` Linus Walleij
2013-01-17 12:02             ` Greg Ungerer
2013-01-17 12:02               ` Greg Ungerer
2013-01-17 16:50               ` Steven King
2013-01-17 16:50                 ` Steven King
2013-01-17 16:50                 ` Steven King
2013-01-17 19:22                 ` Arnd Bergmann
2013-01-17 19:22                   ` Arnd Bergmann
2013-01-20  6:07                 ` Alex Courbot
2013-01-20  6:07                   ` Alex Courbot
2013-01-20  6:07                   ` Alex Courbot
2013-01-22  8:55                   ` Linus Walleij
2013-01-22  8:55                     ` Linus Walleij
2013-01-17 11:25           ` Linus Walleij
2013-01-17 11:25             ` Linus Walleij

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=201301081306.02942.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=acourbot@nvidia.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=gnurou@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /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.