On Fri, Aug 05, 2011 at 12:33:31PM -0700, Stephen Warren wrote:

Russell King - ARM Linux wrote at Friday, August 05, 2011 1:15 PM:

quoted

On Fri, Aug 05, 2011 at 08:43:20AM -0700, Stephen Warren wrote:

quoted

Russell King - ARM Linux wrote at Friday, August 05, 2011 3:40 AM:

quoted

On Thu, Aug 04, 2011 at 05:00:17PM -0600, Stephen Warren wrote:

quoted

In http://www.spinics.net/lists/linux-tegra/msg01731.html, Mark Brown
pointed out that it was a little silly forcing every board or driver
to gpio_request() a GPIO that is later converted to an IRQ, and passed
to request_irq. The first patch in this series instead makes the core
IRQ code perform these calls when appropriate, to avoid duplicating it
everywhere.

Trying to go from IRQ to GPIO is not a good idea - most of the
IRQ <-> GPIO macros we have today are just plain broken.  Many of them
just add or subtract a constant, which means non-GPIO IRQs have an
apparant GPIO number too.  Couple this with the fact that all positive
GPIO numbers are valid, and this is a recipe for wrong GPIOs getting
used and GPIOs being requested for non-GPIO IRQs.

I think this was also discussed in the past, and the conclusion was that
IRQs should be kept separate from GPIOs.  Maybe views have changed since
then...

However, if we do want to do this, then it would be much better to provide
a new API for requesting GPIO IRQs, eg:

gpio_request_irq()

which would wrap around request_threaded_irq(), takes a GPIO number,
does the GPIO->IRQ conversion internally, and whatever GPIO setup is
required.  Something like this:

With that approach, drivers need to explicitly know whether they're
passed a GPIO or an IRQ, and do something different, or they need to
choose to only accept a GPIO or IRQ.

You completely missed the biggest reason why your approach is broken.

No, I didn't.

Yes you did.

I was discussing whether an alternative API for IRQ registration
would work, and I was pointing out some problems with it.

That has nothing to do with whether my original proposal is workable.

And that proves that you missed the point.  I am suggesting an alternative
solution precisely because your original proposal is unworkable.