mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.



  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®