From: David Brownell <david-b@pacbell.net>
To: "H Hartley Sweeten" <hartleys@visionengravers.com>
Cc: "Linux Kernel" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] gpiolib: add gpio_request/free_irq
Date: Tue, 9 Jun 2009 17:56:11 -0700 [thread overview]
Message-ID: <200906091756.11839.david-b@pacbell.net> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE19090191701F@mi8nycmail19.Mi8.com>
On Tuesday 09 June 2009, H Hartley Sweeten wrote:
> On Friday, June 05, 2009 10:20 PM, David Brownell wrote:
> > On Friday 05 June 2009, H Hartley Sweeten wrote:
> > Add support functions to gpiolib to request/free gpio irqs.
> >
> > I'm not keen on this.
> >
> > - At best it's a convenience layer ... for something that's
> > not the least bit awkward to do otherwise.
>
> ... deletia ...
>
> > - Coupling it to gpiolib sort of defeats the point of saying
> > that gpiolib is just an *implementation* of the interface.
> > Where's the code to run for non-gpiolib platforms?
> >
>
> But if a driver is using the gpiolib interface calls wouldn't that
> prevent that driver from working on a platform that does not support
> gpiolib? File include/linux/gpio.h defines all the gpiolib calls to
> either return an error code or WARN_ON(1) when called.
There are three kinds of config to be concerned with:
- Platform doesn't support the GPIO calls at all. In those
cases, drivers using <linux/gpio.h> get NOP stubs; you have
this case covered.
- Platforms supporting the calls but not using gpiolib.
That's the case I pointed out -- you don't handle it.
- Platforms supporting the calls with gpiolib. This is the
other case you handle.
> > - Since it implicitly couples gpio_request() to a flavor of
> > request_irq(), it precludes sharing those IRQs.
> >
>
> Can't the IRQ be shared by passing IRQF_SHARED as one of the flags?
Only one of them will be able to gpio_request(), so it
doesn't matter at all what you say to request_irq().
> > Basically, board setup can know that the GPIO is being used
> > as an IRQ, and do the request()/direction_input() before it
> > passes gpio_to_irq() to the driver. That's worked in every
> > case I've happened across so far...
>
> I agree it works as-is right now. I just thought this would be a
> convenient wrapper to handle a common setup step. If it's overkill
> or not appropriate to add to gpiolib please disregard the patch.
next prev parent reply other threads:[~2009-06-10 1:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-05 18:51 H Hartley Sweeten
2009-06-06 3:51 ` Ben Nizette
2009-06-06 5:19 ` David Brownell
2009-06-09 18:11 ` H Hartley Sweeten
2009-06-10 0:56 ` David Brownell [this message]
2009-06-10 17:07 ` H Hartley Sweeten
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=200906091756.11839.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=hartleys@visionengravers.com \
--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
all inboxes | Powered by JetHome®