All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Alex Courbot <acourbot@nvidia.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	Stephen Warren <swarren@wwwdotorg.org>,
	"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: Thu, 29 Nov 2012 17:34:07 +0000	[thread overview]
Message-ID: <20121129173407.11A543E0A04@localhost> (raw)
In-Reply-To: <2022442.P80mCjSeu2@percival>

On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot <acourbot@nvidia.com> wrote:
> On Monday 26 November 2012 19:14:31 Grant Likely wrote:
> > I don't have any problem with a gpio_get function, but I do agree that
> > making it return an opaque handle is how it should be written with a new
> > set of accessors. The handle should probably be simply the pointer to
> > the &gpio_desc[number] which is a private table in gpiolib.c. The
> > definition of it isn't available outside of gpiolib.c
> 
> That looks like a reasonable approach, but this would make the new API 
> available only to systems that use GPIOlib. Shouldn't we be concerned about 
> making this available to all GPIO implementations? Or is GPIOlib so widely 
> used that we don't care?

I'm tempted to say non-gpiolib is not supported. However, there isn't
anything that would prevent non-gpiolib users from implementing the api
themselves, but they'd need to provide their own handle..

g.

  reply	other threads:[~2012-11-29 17:34 UTC|newest]

Thread overview: 23+ 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  9:04 ` 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-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
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-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 [this message]
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=20121129173407.11A543E0A04@localhost \
    --to=grant.likely@secretlab.ca \
    --cc=acourbot@nvidia.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swarren@wwwdotorg.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 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.