From: Alex Courbot <acourbot@nvidia.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Grant Likely <grant.likely@secretlab.ca>,
"devicetree-discuss@lists.ozlabs.org"
<devicetree-discuss@lists.ozlabs.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: How about a gpio_get(device *, char *) function?
Date: Mon, 5 Nov 2012 16:31:23 +0900 [thread overview]
Message-ID: <7471321.6NJDeDGfYW@percival> (raw)
In-Reply-To: <CACRpkdZc3cEGfSKW-b=G31yuw_E-GOXid3jkxZ0tuKYGYRE5Nw@mail.gmail.com>
Hi Linus, thanks for the reply!
On Monday 05 November 2012 02:04:33 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.
>
> That is the only way to really transit away from the global GPIO
> numberspace.
Interesting. I see you already gave the whole thing a thought. What I don't
understand however is what is so wrong with the current GPIO numberspace that
you want to replace it? Whether we use simple integers or blind pointers, the
adressable space will basically remain the same. GPIO numbers can actually be
considered as handles, and actually I would not mind typedef'ing "int" to a
GPIO handle type in order to add more opacity to the framework.
Also the current DT bindings will likely continue to require the legacy API
anyway, so I am not sure we can make it go away.
My initial thought was to build something on top of the existing scheme to
address my immediate needs - what you are talking about is much more scary. :)
Could you elaborate on your motivations for such a radical direction?
Thanks,
Alex.
next prev parent reply other threads:[~2012-11-05 7:31 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 [this message]
2012-11-05 12:09 ` Linus Walleij
2012-11-26 11:25 ` Grant Likely
2012-11-05 17:35 ` Stephen Warren
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=7471321.6NJDeDGfYW@percival \
--to=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).