devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Alex Courbot <acourbot@nvidia.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org
Subject: Re: How about a gpio_get(device *, char *) function?
Date: Mon, 05 Nov 2012 10:35:11 -0700	[thread overview]
Message-ID: <5097F8CF.5090100@wwwdotorg.org> (raw)
In-Reply-To: <CACRpkdZc3cEGfSKW-b=G31yuw_E-GOXid3jkxZ0tuKYGYRE5Nw@mail.gmail.com>

On 11/04/2012 11:04 AM, Linus Walleij wrote:
> On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot <acourbot@nvidia.com> wrote:
> 
>> Would anyone be opposed to having a gpio_get() function that works similarly
>> to e.g. regulator_get() and clk_get()?
> 
> I understand the concept and why you want to do this.
> 
> However I think the global GPIO numberspace defeats the
> purpose.
> 
> gpio_get() should get an abstract handle just like clk_get() or
> regulator_get(), not a fixed numeral.

I don't really see why the return type of gpio_get() influences whether
it can be implemented or not.

If gpio_get() were implemented today, it could return an integer with
the same value as any other GPIO functions use already.

With board files, some "gpio map" table would simply contain the same
int GPIO ID value the table as is used anywhere else already. With DT,
the same xlate function would translate from DT GPIO-chip-relative
IDs/specifiers into the global number space in the same way that we do
today via other APIs.

If the GPIO subsystem were reworked as you propose, this API could be
reworked in exactly the same way, or if implemented after the rework, it
would return whatever handle type was in use at the time.

  parent reply	other threads:[~2012-11-05 17:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31  9:04 How about a gpio_get(device *, char *) function? Alex Courbot
2012-10-31 15:25 ` Stephen Warren
     [not found]   ` <509142F5.4010307-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-01  2:48     ` Alex Courbot
2012-11-04 18:04 ` Linus Walleij
2012-11-05  7:31   ` Alex Courbot
2012-11-05 12:09     ` Linus Walleij
2012-11-26 11:25       ` Grant Likely
2012-11-05 17:35   ` Stephen Warren [this message]
2012-11-06  1:33     ` Alex Courbot
2012-11-07 21:24       ` Linus Walleij
2012-11-08  6:14         ` Alex Courbot
     [not found]         ` <CACRpkdYqCQc0Er1JR_eVzZPCycvKjd0Pph8Dcay0FbU3Q64D8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-08  6:23           ` Alex Courbot
2012-11-13 13:13             ` Linus Walleij
2012-11-07 21:28     ` Linus Walleij
2012-11-26 11:14       ` Grant Likely
2012-11-28  3:38         ` Alex Courbot
2012-11-29 17:34           ` Grant Likely
2012-12-01 18:41             ` Linus Walleij
2012-12-03 14:15               ` Grant Likely
2012-11-26 11:17 ` Grant Likely

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=5097F8CF.5090100@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=acourbot@nvidia.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).